mbox series

[V3,0/9] spi: bcm2835aux: bug fixes and improvements

Message ID 20190330093106.20723-1-kernel@martin.sperl.org (mailing list archive)
Headers show
Series spi: bcm2835aux: bug fixes and improvements | expand

Message

Martin Sperl March 30, 2019, 9:30 a.m. UTC
From: Martin Sperl <kernel@martin.sperl.org>

Set of patches improving the spi-bcm2835aux driver and fixing
a data read corruption bug.

The main motivation is a rare data corruption fix that is mostly
observed in polling mode first reported by Hubert Denkmair.

So this patchset first implements a means to control the parameters
of when polling mode is used via module parameters and exports
the corresponding statistics.

As stated in original patch the driver does not support native CS.
But when cs-gpios is not configured in the dt (so a buggy dt) it is
still working with a lot of limitations, but the driver does not report
this fact.

So this patchset adds reporting and allows for a single native CS
(with limited functionality) to continue working with a buggy DT.
One question here remains: do we need to legacy support DTs
that are not following specs in the first place?

Then there is the real fix for the data-corruption which is split
into 3 parts: some code cleanup with code reuse, removing "dangerous"
fifo read (possibly introducing fifo data corruption) and safe fifo read.

Also we remove some dead code.

---
Changelog:
  V1 -> V2: reordering commits as per request of Stefan Wahren
            to help backporting the "essential" bugfixes go in first
	    remove the dependency on a different patchset focused on
	    making cs_change delay configurable
  V2 -> V3: incorporated feedback by Stefan Wahren

Martin Sperl (9):
  spi: bcm2835aux: unifying code between polling and interrupt driven
    code
  spi: bcm2835aux: remove dangerous uncontrolled read of fifo
  spi: bcm2835aux: fix corruptions for longer spi transfers
  spi: bcm2835aux: remove dead code
  spi: bcm2835aux: fix driver to not allow 65535 (=-1) cs-gpios
  spi: bcm2835aux: warn in dmesg that native cs is not really supported
  spi: bcm2835aux: setup gpio-cs to output and correct level during
    setup
  spi: bcm2835aux: add driver stats to debugfs
  spi: bcm2835aux: make the polling duration limits configurable

 drivers/spi/spi-bcm2835aux.c | 204 +++++++++++++++++++++++++++++++------------
 1 file changed, 147 insertions(+), 57 deletions(-)

--
2.11.0

Comments

Stefan Wahren April 2, 2019, 5:03 p.m. UTC | #1
> kernel@martin.sperl.org hat am 30. März 2019 um 10:30 geschrieben:
> 
> 
> From: Martin Sperl <kernel@martin.sperl.org>
> 
> Set of patches improving the spi-bcm2835aux driver and fixing
> a data read corruption bug.
> 
> The main motivation is a rare data corruption fix that is mostly
> observed in polling mode first reported by Hubert Denkmair.
> 
> So this patchset first implements a means to control the parameters
> of when polling mode is used via module parameters and exports
> the corresponding statistics.
> 
> As stated in original patch the driver does not support native CS.
> But when cs-gpios is not configured in the dt (so a buggy dt) it is
> still working with a lot of limitations, but the driver does not report
> this fact.
> 
> So this patchset adds reporting and allows for a single native CS
> (with limited functionality) to continue working with a buggy DT.
> One question here remains: do we need to legacy support DTs
> that are not following specs in the first place?
> 
> Then there is the real fix for the data-corruption which is split
> into 3 parts: some code cleanup with code reuse, removing "dangerous"
> fifo read (possibly introducing fifo data corruption) and safe fifo read.
> 
> Also we remove some dead code.
> 
> ---
> Changelog:
>   V1 -> V2: reordering commits as per request of Stefan Wahren
>             to help backporting the "essential" bugfixes go in first
> 	    remove the dependency on a different patchset focused on
> 	    making cs_change delay configurable
>   V2 -> V3: incorporated feedback by Stefan Wahren

The whole series is:

Acked-by: Stefan Wahren <stefan.wahren@i2se.com>

Thanks