Re: Fwd: Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask

From: Neeraj Upadhyay
Date: Mon Jun 17 2019 - 09:27:26 EST


Thanks for the review, Linus.

On 6/17/19 5:20 PM, Linus Walleij wrote:
On Mon, Jun 17, 2019 at 12:35 PM Neeraj Upadhyay <neeraju@xxxxxxxxxxxxxx> wrote:

Hi Stephen, there is one use case with is not covered by commit
b55326dc969e (

"pinctrl: msm: Really mask level interrupts to prevent latching"). That
happens when

gpio line is toggled between i/o mode and interrupt mode :

1. GPIO is configured as irq line. Peripheral raises interrupt.

2. IRQ handler runs and disables the irq line (through wq work).

3. GPIO is configured for input and and data is received from the
peripheral.
There is no distinction between using a GPIO line as input
and using it for IRQ. All input GPIOs can be used for IRQs,
if the hardware supports it (has an irqchip).

Ok


4. Now, when GPIO is re-enabled as irq, we see spurious irq, and there
isn't

any data received on the gpio line, when it is read back after
configuring as input.
That's an interesting usecase. Hans Verkuil reworked the
GPIO irq support very elegantly exactly to support this type
of usecase (irq switch on and off dynamically), where he
was even switching the line into output mode between
the IRQ trains. (one-wire transcactions for CEC).

Patch https://lkml.org/lkml/2019/6/17/226 tries to cover this use case.
Can you please provide your comments?
What this patch does is clear all pending IRQs at irq
unmask. This is usually safe, unless there may be cases
where you *want* to catch any pending IRQs. I guess
normally you don't so it should be safe?

We want to clear pending status at irq enable. Afaik, no,

we don't normally track these pending irqs. So, should be

fine here.


The corner case is when you start some transaction
or whatever that gets ACKed by an IRQ and you actually
get the IRQ back before you had time to execute the code
enabling the IRQ.

That would be racy and bad code, as you should clearly
enable the IRQ first, then start the transaction. So I think
this patch is safe.

But let's see what Bjorn says.

Yours,
Linus Walleij

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation