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 <[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.
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 _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
