On Wed, Dec 03, 2014 at 03:16:41PM +0000, Iain Baron wrote: Please fix your mailer to word wrap within paragraphs so your mail is legible. > > If we can safely handle not having the callback then we should fix the > > call site to safely handle a null pointer rather than adding dummy > > callbacks. That way this is fixed once for all drivers that need it. > Is it better to test for a null pointer at the spi-bitbang call-site, > or get spi-bitbang to add a dummy callback of its own in > spi_bitbang_start? The former has the overhead of a test every call, > even for those drivers that provide the callback, while the latter has > the overhead of a dummy call only for those drivers that don't. If this is a valid thing to do it is better to have the test; if you really want to avoid the test then the core needs to provide the default implementation that users can reference. > > I'd expect to see some code that checks to see if the caller is trying > > to change paramters. > If you mean in the spi-altera code: The spi-altera driver does not > know what the hardware fixed parameters are, so it can't make a > decision about whether the caller is trying to change them to > something else. > If you mean in the spi-bitbang code: The code appears to do this with > the do_setup test, but it will always do a setup for the very first > transfer in a message regardless, invoking the missing callback. In some generic code. There's nothing device specific about a missing callback. If the device does not know the initial settings we can at least check that nothing is trying to change the settings later.
Attachment:
signature.asc
Description: Digital signature
