On Fri, Apr 09, 2010 at 10:18:16PM +0200, Corentin Chary wrote: > On Fri, Apr 9, 2010 at 9:11 PM, Carlos Corbacho > <carlos@xxxxxxxxxxxxxxxxxxx> wrote: > > On Friday 09 April 2010 18:49:02 Dmitry Torokhov wrote: > >> On Fri, Apr 09, 2010 at 11:03:20PM +0800, Yong Wang wrote: > >> > Currently there is no easy way to associate driver data kind of thing > >> > with wmi drivers thus global variables have to be used to pass that > >> > information between functions. Add a pair of functions to support > >> > that. > > > > NAK > > > >> It looks like once you compete the conversion and have platform device > >> you can attach to it instead of needing driver data in WMI. > >> > > > > I'm with Dmitry on this one. Please avoid adding this kind of stuff to WMI - > > it's just intended to be a thin wrapper around ACPI calls, not a full driver > > class with its' own mechanisms for data storage, etc. > > > > You can probably just use > platform_get_drvdata(_dev) - platform_set_drvdata(_dev,data) > wihtout a lot of change in the following patchs. Thanks for all your comments, guys! Regarding platform_[g/s]et_drvdata, I actually thought about that. By '_dev', do you mean the one defined in struct wmi_block? If so, currently there is no way to get it. We still need to add some new functions into wmi.c to export it for people to perform platform_[g/s]et_drvdata upon it. Right? Thanks -Yong -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
