On Wed, Apr 06, 2011 at 10:56:47AM -0700, Greg KH wrote: > On Wed, Apr 06, 2011 at 07:05:38PM +0200, Samuel Ortiz wrote: > > Hi Greg, > > > > On Wed, Apr 06, 2011 at 08:58:05AM -0700, Greg KH wrote: > > > On Wed, Apr 06, 2011 at 05:23:23PM +0200, Samuel Ortiz wrote: > > > > --- a/include/linux/device.h > > > > +++ b/include/linux/device.h > > > > @@ -33,6 +33,7 @@ struct class; > > > > struct subsys_private; > > > > struct bus_type; > > > > struct device_node; > > > > +struct mfd_cell; > > > > > > > > struct bus_attribute { > > > > struct attribute attr; > > > > @@ -444,6 +445,8 @@ struct device { > > > > struct device_node *of_node; /* associated device tree node */ > > > > const struct of_device_id *of_match; /* matching of_device_id from driver */ > > > > > > > > + struct mfd_cell *mfd_cell; /* MFD cell pointer */ > > > > + > > > > > > What is a "MFD cell pointer" and why is it needed in struct device? > > An MFD cell is an MFD instantiated device. > > MFD (Multi Function Device) drivers instantiate platform devices. Those > > devices drivers sometimes need a platform data pointer, sometimes an MFD > > specific pointer, and sometimes both. Also, some of those drivers have been > > implemented as MFD sub drivers, while others know nothing about MFD and just > > expect a plain platform_data pointer. > > That sounds like a bug in those drivers, why not fix them to properly > pass in the correct pointer? Because they're drivers for generic IPs, not MFD ones. By forcing them to use MFD specific structure and APIs, we make it more difficult for platform code to instantiate them. The timberdale MFD for example is built with a Xilinx SPI controller, and a Micrel ks8842 ethernet switch IP. Forcing those devices into being MFD devices would mean any platform willing to instantiate them would have to use the MFD APIs. That sounds a bit artificial to me. Although there is currently no drivers instantiated by both an MFD driver and some platform code, Grant complaint about the Xilinx SPI driver moving from a platform driver to an MFD one makes sense to me. > > So, adding an MFD cell pointer to the device structure allows us to cleanly > > pass both pieces of information, while keeping all the MFD sub drivers > > independant from the MFD core if they want/can. > > They shouldn't be "independant", Excuse my poor spelling. > make them "dependant" and go from there. That's what the code currently does. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html