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-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
