Re: [PATCH] spi-altera: Fix NULL pointer dereference in spi_bitbang_transfer_one

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]