[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201211201611.28646.arnd@arndb.de>
Date: Tue, 20 Nov 2012 16:11:28 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Lars Poeschel <poeschel@...onage.de>
Cc: Lars Poeschel <larsi@....tu-dresden.de>, FlorianSchandinat@....de,
mathieu.poirier@...aro.org, linux-fbdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] video console: add a driver for lcd2s character display
On Tuesday 20 November 2012, Lars Poeschel wrote:
> >
> > It's better to define the struct consw as a preinitialized
> > 'static const' object, rather than dynamically setting each
> > member.
>
> I could not find a place to store the drivers private data inside the struct
> vc_data. I wanted to have the struct consw inside the drivers private data
> (struct lcd2s_data) to be able to container_of to the drivers private data in
> the consw.con_* functions. This makes it possible to use more than one actual
> lcd2s display with the same driver. Otherwise I have to store the struct
> i2c_client somewhere statically and the driver can control only one display
> and has to forbid to be probed a second time. Or am I wrong somewhere ?
I believe you can only have one device anyway, because of the way you
register using "take_over_console(&data->consw, LCD2S_FIRST, LCD2S_LAST, 1);"
Whichever lcd2s was last registered gets VC 8 and 9. This is not nice, but
I think it's similar to how all the other VC work. They consequently don't
store per-device data at all, but just have global variables for device
specific data. We generally discourage this behaviour for device drivers,
but I woulnd't expect you to change the way that VC works, so you can just
do the same here.
Things would be different if this was a "console" driver rather than a "vc"
driver.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists