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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Apr 2011 11:38:54 -0700
From:	Greg KH <gregkh@...e.de>
To:	Andres Salomon <dilinger@...ued.net>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	khali@...ux-fr.org, ben-linux@...ff.org,
	Peter Korsgaard <jacmet@...site.dk>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	linux-i2c@...r.kernel.org, linux-media@...r.kernel.org,
	netdev@...r.kernel.org, spi-devel-general@...ts.sourceforge.net,
	Mocean Laboratories <info@...ean-labs.com>
Subject: 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:
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html