diff mbox

[v2] spi: bcm2835aux: ensure interrupts are enabled for shared handler

Message ID 20180523205220.7394-1-robh@kernel.org (mailing list archive)
State New, archived
Headers show

Commit Message

Rob Herring (Arm) May 23, 2018, 8:52 p.m. UTC 
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.

The root cause however is a bug in the shared handler. A shared handler
must correctly identify it actually handled an interrupt. The handler
here was processing data whether interrupts were enabled or not.
It would return IRQ_HANDLED if there was any data and not only when
there was an actual interrupt pending. The result is that another
device's IRQ could cause the SPI's IRQ handler to run and process data
when the the SPI driver working in polled mode. Fix this by adding a
check in the IRQ handler that the TXEMPTY or IDLE interrupts are enabled
and always return IRQ_NONE when they are not.

[1] https://patchwork.kernel.org/patch/9781221/

Cc: Alexander Graf <agraf@suse.de>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-spi@vger.kernel.org
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Rob Herring <robh@kernel.org>
---
Still hoping someone can test this as I have not.

v2:
- Expand commit message text about shared handler req. and how polled 
  mode causes the problem.

 drivers/spi/spi-bcm2835aux.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Eric Anholt May 30, 2018, 7:11 p.m. UTC | #1 
Rob Herring <robh@kernel.org> writes:

> The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
> Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
> DT change which breaks compatibility with older kernels. The AUX irqchip
> was already rejected for upstream[1] and the DT change would break
> working systems if the DTB is updated to a newer one. The latter issue
> was brought to my attention by Alex Graf.
>
> The root cause however is a bug in the shared handler. A shared handler
> must correctly identify it actually handled an interrupt. The handler
> here was processing data whether interrupts were enabled or not.
> It would return IRQ_HANDLED if there was any data and not only when
> there was an actual interrupt pending. The result is that another
> device's IRQ could cause the SPI's IRQ handler to run and process data
> when the the SPI driver working in polled mode. Fix this by adding a
> check in the IRQ handler that the TXEMPTY or IDLE interrupts are enabled
> and always return IRQ_NONE when they are not.

FWIW, I see v1 already applied in -next.
Rob Herring (Arm) May 30, 2018, 9:44 p.m. UTC | #2 
On Wed, May 30, 2018 at 2:11 PM, Eric Anholt <eric@anholt.net> wrote:
> Rob Herring <robh@kernel.org> writes:
>
>> The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
>> Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
>> DT change which breaks compatibility with older kernels. The AUX irqchip
>> was already rejected for upstream[1] and the DT change would break
>> working systems if the DTB is updated to a newer one. The latter issue
>> was brought to my attention by Alex Graf.
>>
>> The root cause however is a bug in the shared handler. A shared handler
>> must correctly identify it actually handled an interrupt. The handler
>> here was processing data whether interrupts were enabled or not.
>> It would return IRQ_HANDLED if there was any data and not only when
>> there was an actual interrupt pending. The result is that another
>> device's IRQ could cause the SPI's IRQ handler to run and process data
>> when the the SPI driver working in polled mode. Fix this by adding a
>> check in the IRQ handler that the TXEMPTY or IDLE interrupts are enabled
>> and always return IRQ_NONE when they are not.
>
> FWIW, I see v1 already applied in -next.

Sigh, indeed. I thought I had checked that. Though Mark had comments
on the commit msg, so I assumed he wanted changes. The automated
applied emails just get lost in my inbox. It would be nice if they
kept the subject instead of adding 'Applied "...' so gmail would group
them. Of course, it would be nice if gmail could honor threading too.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index 1431cb98fe40..3094d818cf06 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@  static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
 	struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
 	irqreturn_t ret = IRQ_NONE;
 
+	/* IRQ may be shared, so return if our interrupts are disabled */
+	if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+	      (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+		return ret;
+
 	/* check if we have data to read */
 	while (bs->rx_len &&
 	       (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &