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.