On Fri, Apr 25, 2008 at 09:02:27AM +0200, Takashi Iwai wrote: > Mark Brown wrote: > > I think about it it may be best to just do the same thing as the > > platform bus does and define accessor macros for getting at this from a > > struct snd_ac97). > Not really as same as device_data. Normally, device data is handled > by superseding the base device class (just includes struct device) and > retrieve the class via container_of() or such. That's normal usage for getting generic class data, not for obtaining information specific to a particular driver. > In this case, however, you don't know exactly whether the given struct > ac97 is really created by the specific controller, and thus you cannot > assume that the ac97 can be cast to its specific class. Right, which is why the device_data pointer is used by things like platform drivers for getting device-specific (as opposed to class specific) data into the driver from the machine code. > For multiple anonymous data, we can use a data with a key like below: This sounds like a reinvention of OpenFirmware, which presents pretty much the same sort of key/value interface. It'd be nice to be able to share the same client code. > and the controller driver assigns the data like Doing this would mean that the controller would need to be modified for each system that wants to pass configuration data to a driver - at that point much of the win from providing an interface like this is lost. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
