On Thu, Sep 02, 2010 at 02:13:48PM +0800, Feng Tang wrote: > Hi David, > > > > > Grant also asked me the same question. > > > > > > I saw him ask a different question (which > > I quoted) ... > > My mistake, I tried to answer Grant's and your questions in one email to > keep the discussion in one thread. > > > > > > > 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. If the spi_driver gets unbound and rebound, then the original platform-set value for bits_per_word is lost and the behaviour changes. 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. 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
