On Wed, 1 Sep 2010 23:46:18 +0800 David Brownell <[email protected]> wrote:
> Re $SUBJECT ... consider it a quirk of how > SPI devices get setup that this field isn't > one of the ones the platform code can set up. > > I've thought about fixing this before, > and decided against it: > > > > What is the use case that you would want to do > > this. Knowing what the bits_per_word should > > be is the responsibility of the spi device > > driver. What is the > use-case where the > > driver wouldn't know what bits_per_word > > should be? > > What's the case where platform code could > know "better" than the driver? Grant also asked me the same question. 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. One of my intension of this patch is to save some extra spi_setup. For many spi protocol drivers in kernel, spi_setup() will be called twice for them, first time is inside spi_new_device(it calls spi_add_device), the second time will be inside driver's probe func, after setting bits_per_word info. So if we can set it before registering board info, then the second spi_setup can be removed for many drivers. 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
