Re: [PATCH] spi: add a bits_per_word to struct spi_board_info

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Thu, Sep 09, 2010 at 11:14:45AM +0800, Feng Tang wrote:
> Hi Grant,
> 
> On Thu, 9 Sep 2010 04:21:59 +0800
> Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> 
> > > > 
> > > >  Yes, driver itself
> > > > > know the bits_per_word info best in most case, but there
> > > > > is
> > > > > some device (Option GTM501L spi modem) which supports
> > > > > multiple
> > > > > bits_per_mode option, and here platform code
> > > > is the good place to set it.
> > > > 
> > > > 
> > > > Not unless it knows which mode the driver uses...
> > > > a kind of layering violation.
> > > 
> > > spi_board_info has a member of "mode", so for my platform, I prefer
> > > to set all these infos in platform code, while protocol driver can
> > > check if the preset infos like speed_hz/mode/bits_per_word are
> > > supported.
> > 
> > The real problem is that spi_drivers are normally allowed to change
> > bits_per_word as needed. 
> 
> For drivers who don't accept bits_per_word comes from platform code, it
> could just ignores it and set the value it wants.
> 
> > If the spi_driver gets unbound and
> > rebound, then the original platform-set value for bits_per_word is
> > lost and the behaviour changes.  
> 
> Um, if you are talking about driver load/unload, then the bits_per_word
> info won't get lost as it is set to spi_device from spi_board_info when
> spi_new_device get called.

No, I'm talking about a specific device's spi_driver being unloaded
and reloaded.  spi_new_device would only be called if the spi bus
driver was reloaded, triggering a call to spi_register_master().

> > If you really want to give the driver
> > hints about the best setting for bits_per_word or similar, then you
> > should probably use a driver-specific pdata structure.
> 
> Good point, really a solution to the GTM501L modem driver. But still,
> adding the bits_per_word to spi_board_info will be more generic when
> more devices which support multiple bits models show up.

As described above, anything that a driver can legally modify cannot
be "preset" by the platform code because the initial preset values
will get lost.  A different mechanism must be used so that initial
conditions remain unchanged between successive binding of a driver.

g.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd