spi: add bits_per_word_mask check in spi_setup
PATCH 1/1 spi: add bits_per_word_mask check in spi_setup
The spi_setup should fail if underlying controller or its driver does not support requested bits_per_word. So if the master driver set mask and let core do bits_per_word check then we should also test this mask in spi_setup.
--- drivers/spi/spi.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
drivers/spi/spi.c +9 -0
@@ -1326,6 +1326,15 @@ int spi_setup(struct spi_device *spi)if (!spi->bits_per_word) spi->bits_per_word =8 ; +if (spi->master->bits_per_word_mask) { +/* Only 32 bits fit in the mask */ +if (spi->bits_per_word >32 ) +return -EINVAL ; +if (!(spi->master->bits_per_word_mask & +BIT (spi->bits_per_word -1 ))) +return -EINVAL ; + } +if (spi->master->setup) status = spi->master->setup (spi);
Signature · 1 line
1.7.0.4
A message that is not in the archive (sent off-list or not yet received): 1372287286-12682-1-git-send-email-scott.jiang.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
drivers/spi/spi.c int spi_setup(struct spi_device *spi) · line 1336
Quoted 8 lines · Scott Jiang
drivers/spi/spi.c +8
-0+if (spi->master->bits_per_word_mask) { +/* Only 32 bits fit in the mask */ +if (spi->bits_per_word >32 ) +return -EINVAL ; +if (!(spi->master->bits_per_word_mask & +BIT (spi->bits_per_word -1 ))) +return -EINVAL ; + }
Thinking about this a bit it might reject a valid transfer - it only checks the setting in the SPI device, not the setting in the transfer. This means that if the transfer overrides an unsuitable setting in the controller then an error will be generated as the fixed setting won't be seen. It's hard to imagine when that would happen without something being very confused but still feels better to check the bits per word from the first transfer too.
_______________________________________________
Uclinux-dist-devel mailing list Uclinux-dist-devel-ZG0+EudsQA8dtHy/[email protected]
https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines
drivers/spi/spi.c int spi_setup(struct spi_device *spi) · line 1336
Quoted 8 lines
drivers/spi/spi.c +8
-0+if (spi->master->bits_per_word_mask) { +/* Only 32 bits fit in the mask */ +if (spi->bits_per_word >32 ) +return -EINVAL ; +if (!(spi->master->bits_per_word_mask & +BIT (spi->bits_per_word -1 ))) +return -EINVAL ; + }
Quoted 7 lines
Thinking about this a bit it might reject a valid transfer - it only checks the setting in the SPI device, not the setting in the transfer. This means that if the transfer overrides an unsuitable setting in the controller then an error will be generated as the fixed setting won't be seen. It's hard to imagine when that would happen without something being very confused but still feels better to check the bits per word from the first transfer too.
But the API description said that this call would fail if the protocol driver specifies an option
that the underlying controller or its driver does not support. It's strange if I request 9 bits per
word in setup successfully while calling it in transfer fail.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
A message that is not in the archive (sent off-list or not yet received): CAHG8p1DeSojQ-kn=GZTFpaepUTDCme7NA+=Vani3zK1QePDCzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 8 lines · Scott Jiang
Quoted 2 lines
Thinking about this a bit it might reject a valid transfer - it only checks the setting in the SPI device, not the setting in the transfer.
But the API description said that this call would fail if the protocol driver specifies an option
that the underlying controller or its driver does not support. It's strange if I request 9 bits per
word in setup successfully while calling it in transfer fail.
Yes, it's a bit odd (and I'd never expect a failure to actually trigger here that wasn't going to be repeated in the actual transfer) but it seems more robust.
_______________________________________________
Uclinux-dist-devel mailing list Uclinux-dist-devel-ZG0+EudsQA8dtHy/[email protected]
https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel