[PATCH v4 3/8] wireless: wl1271: add platform driver to get board data

[Russell King - ARM Linux]

On Thu, Aug 12, 2010 at 12:57:18AM +0530, DebBarma, Tarun Kanti wrote:
> 
> > -----Original Message-----
> > From: Felipe Balbi [mailto:felipe.balbi at nokia.com]
> > Sent: Thursday, August 12, 2010 12:27 AM
> > To: DebBarma, Tarun Kanti
> > Cc: Balbi Felipe (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux-
> > wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux-
> > omap at vger.kernel.org; Ido Yariv; Mark Brown; linux-arm-
> > kernel at lists.infradead.org; Chikkature Rajashekar, Madhusudhan; Coelho
> > Luciano (Nokia-MS/Helsinki); akpm at linux-foundation.org; San Mehat; Quadros
> > Roger (Nokia-MS/Helsinki); Tony Lindgren; Nicolas Pitre; Pandita, Vikram;
> > Kalle Valo
> > Subject: Re: [PATCH v4 3/8] wireless: wl1271: add platform driver to get
> > board data
> > 
> > Hi,
> > 
> > On Wed, Aug 11, 2010 at 08:52:54PM +0200, ext DebBarma, Tarun Kanti wrote:
> > >True; however if we go by that argument than we can also assume pdata
> > >is valid, so that we would not need the below check.
> > 
> > of course not. You can have devices that just play well with default
> > values or devices where you don't need the flexibility of platform data.
> > That's why we check.
> > 
> > platform_device pointers on the other hand, are guaranteed to be always
> > true, if it isn't then you should oops, you deserve to oops because
> > something is really really wrong.
> >
> Sounds perfect!
> What that means is _probe() function makes sense only for cases where we
> have valid platform data because we are returning right at the top if
> pdata is not valid. If this is the case I was curious to know why not
> framework make another check for valid pdata before calling _probe()
> instead of coming all the way to _probe() and then returning! 

Platform devices are not for passing platform data around - they're for
declaring platform hardware devices that we want drivers to handle -
and it depends on the driver whether having platform data is appropriate
or not.

This proposal is, IMHO, abusing the platform device/driver support to
achieve its own goals.  I've outlined a far simpler and easiler solution
which avoids this kind of abuse, and given suggestions on how to extend
it to support multiple instances.