Hi Grant, On Thu, 9 Sep 2010 04:21:59 +0800 Grant Likely <[email protected]> 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 _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
