Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers

On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote:

quoted

quoted

We've been faced with the problem of being able to pass both MFD
related data and a platform_data pointer to some of those drivers.
Squeezing the MFD bits in the sub driver platform_data pointer
doesn't work for drivers that know nothing about MFDs. It also adds
an additional dependency on the MFD API to all MFD sub drivers.
That prevents any of those drivers to eventually be used as plain
platform device drivers.

Then they shouldn't be "plain" platform drivers, that should only be
reserved for drivers that are the "lowest" type.  Just make them MFD
devices and go from there.

The problem is of mixing "plain" platform devices and MFD devices.

Then don't do that.

It's reasonable to assume that different hardware may be using
one method or the other to create devices; in order to maintain
compatibility with the driver, one either needs to use a plain platform
device.  Alternatively, if an MFD-specific device class is created,
then MFD devices would start showing up in weird places.

Then fix it.  Lots of other drivers handle different "bus types" just
fine (look at the EHCI USB driver for an example.)  Don't polute the
driver core just because you don't want to fix up the individual driver
issues that are quite obvious.

thanks,

greg k-h