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

[Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

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.

> 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.

Thanks,
Feng


------------------------------------------------------------------------------
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