Linux-ARM-MSM Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
@ 2019-05-31  6:51 Tengfei Fan
  2019-06-07 21:08 ` Linus Walleij
  0 siblings, 1 reply; 8+ messages in thread
From: Tengfei Fan @ 2019-05-31  6:51 UTC (permalink / raw)
  To: bjorn.andersson, andy.gross, david.brown, linus.walleij
  Cc: linux-arm-msm, linux-gpio, linux-kernel, Tengfei Fan

The gpio interrupt status bit is getting set after the
irq is disabled and causing an immediate interrupt after
enablling the irq, so clear status bit on irq_unmask.

Signed-off-by: Tengfei Fan <tengfeif@codeaurora.org>
---
 drivers/pinctrl/qcom/pinctrl-msm.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index ee81198..7283c50 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -740,6 +740,7 @@ static void msm_gpio_irq_mask(struct irq_data *d)
 static void msm_gpio_irq_unmask(struct irq_data *d)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+	uint32_t irqtype = irqd_get_trigger_type(d);
 	struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
 	const struct msm_pingroup *g;
 	unsigned long flags;
@@ -749,6 +750,12 @@ static void msm_gpio_irq_unmask(struct irq_data *d)
 
 	raw_spin_lock_irqsave(&pctrl->lock, flags);
 
+	if (irqtype & (IRQF_TRIGGER_HIGH | IRQF_TRIGGER_LOW)) {
+		val = readl_relaxed(pctrl->regs + g->intr_status_reg);
+		val &= ~BIT(g->intr_status_bit);
+		 writel_relaxed(val, pctrl->regs + g->intr_status_reg);
+	}
+
 	val = msm_readl_intr_cfg(pctrl, g);
 	val |= BIT(g->intr_raw_status_bit);
 	val |= BIT(g->intr_enable_bit);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
  2019-05-31  6:51 [PATCH] pinctrl: qcom: Clear status bit on irq_unmask Tengfei Fan
@ 2019-06-07 21:08 ` Linus Walleij
  2019-06-10 14:51   ` Stephen Boyd
  0 siblings, 1 reply; 8+ messages in thread
From: Linus Walleij @ 2019-06-07 21:08 UTC (permalink / raw)
  To: Tengfei Fan, Bjorn Andersson, Stephen Boyd, Niklas Cassel
  Cc: Andy Gross, David Brown, MSM, open list:GPIO SUBSYSTEM, linux-kernel

On Fri, May 31, 2019 at 8:52 AM Tengfei Fan <tengfeif@codeaurora.org> wrote:

> The gpio interrupt status bit is getting set after the
> irq is disabled and causing an immediate interrupt after
> enablling the irq, so clear status bit on irq_unmask.
>
> Signed-off-by: Tengfei Fan <tengfeif@codeaurora.org>

This looks pretty serious, can one of the Qcom maintainers ACK
this?

Should it be sent to fixes and even stable?

Fixes: tag?

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
  2019-06-07 21:08 ` Linus Walleij
@ 2019-06-10 14:51   ` Stephen Boyd
  2019-06-11 10:41     ` tengfeif
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Boyd @ 2019-06-10 14:51 UTC (permalink / raw)
  To: Bjorn Andersson, Linus Walleij, Niklas Cassel, Tengfei Fan
  Cc: Andy Gross, David Brown, MSM, open list:GPIO SUBSYSTEM, linux-kernel

Quoting Linus Walleij (2019-06-07 14:08:10)
> On Fri, May 31, 2019 at 8:52 AM Tengfei Fan <tengfeif@codeaurora.org> wrote:
> 
> > The gpio interrupt status bit is getting set after the
> > irq is disabled and causing an immediate interrupt after
> > enablling the irq, so clear status bit on irq_unmask.
> >
> > Signed-off-by: Tengfei Fan <tengfeif@codeaurora.org>
> 
> This looks pretty serious, can one of the Qcom maintainers ACK
> this?
> 
> Should it be sent to fixes and even stable?
> 
> Fixes: tag?
> 

How is the interrupt status bit getting set after the irq is disabled?
It looks like this is a level type interrupt? I thought that after
commit b55326dc969e ("pinctrl: msm: Really mask level interrupts to
prevent latching") this wouldn't be a problem. Am I wrong, or is qcom
just clearing out patches on drivers and this is the last one that needs
to be upstreamed?


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
  2019-06-10 14:51   ` Stephen Boyd
@ 2019-06-11 10:41     ` tengfeif
  2019-06-11 18:51       ` Stephen Boyd
  0 siblings, 1 reply; 8+ messages in thread
From: tengfeif @ 2019-06-11 10:41 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: Bjorn Andersson, Linus Walleij, Niklas Cassel, Andy Gross,
	David Brown, MSM, open list:GPIO SUBSYSTEM, linux-kernel

On 2019-06-10 22:51, Stephen Boyd wrote:
> Quoting Linus Walleij (2019-06-07 14:08:10)
>> On Fri, May 31, 2019 at 8:52 AM Tengfei Fan <tengfeif@codeaurora.org> 
>> wrote:
>> 
>> > The gpio interrupt status bit is getting set after the
>> > irq is disabled and causing an immediate interrupt after
>> > enablling the irq, so clear status bit on irq_unmask.
>> >
>> > Signed-off-by: Tengfei Fan <tengfeif@codeaurora.org>
>> 
>> This looks pretty serious, can one of the Qcom maintainers ACK
>> this?
>> 
>> Should it be sent to fixes and even stable?
>> 
>> Fixes: tag?
>> 
> 
> How is the interrupt status bit getting set after the irq is disabled?
> It looks like this is a level type interrupt? I thought that after
> commit b55326dc969e ("pinctrl: msm: Really mask level interrupts to
> prevent latching") this wouldn't be a problem. Am I wrong, or is qcom
> just clearing out patches on drivers and this is the last one that 
> needs
> to be upstreamed?

Your patch(commit b55326dc969e) can cover our issue, and my patch is no 
longer needed.
Your patch isn't included in our code, so I submitted this patch.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
  2019-06-11 10:41     ` tengfeif
@ 2019-06-11 18:51       ` Stephen Boyd
       [not found]         ` <671f87d6-f4a4-6d2c-967b-e1aa0677d83e@codeaurora.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Boyd @ 2019-06-11 18:51 UTC (permalink / raw)
  To: tengfeif
  Cc: Bjorn Andersson, Linus Walleij, Niklas Cassel, Andy Gross,
	David Brown, MSM, open list:GPIO SUBSYSTEM, linux-kernel

Quoting tengfeif@codeaurora.org (2019-06-11 03:41:26)
> On 2019-06-10 22:51, Stephen Boyd wrote:
> > Quoting Linus Walleij (2019-06-07 14:08:10)
> >> On Fri, May 31, 2019 at 8:52 AM Tengfei Fan <tengfeif@codeaurora.org> 
> >> wrote:
> >> 
> >> > The gpio interrupt status bit is getting set after the
> >> > irq is disabled and causing an immediate interrupt after
> >> > enablling the irq, so clear status bit on irq_unmask.
> >> >
> >> > Signed-off-by: Tengfei Fan <tengfeif@codeaurora.org>
> >> 
> >> This looks pretty serious, can one of the Qcom maintainers ACK
> >> this?
> >> 
> >> Should it be sent to fixes and even stable?
> >> 
> >> Fixes: tag?
> >> 
> > 
> > How is the interrupt status bit getting set after the irq is disabled?
> > It looks like this is a level type interrupt? I thought that after
> > commit b55326dc969e ("pinctrl: msm: Really mask level interrupts to
> > prevent latching") this wouldn't be a problem. Am I wrong, or is qcom
> > just clearing out patches on drivers and this is the last one that 
> > needs
> > to be upstreamed?
> 
> Your patch(commit b55326dc969e) can cover our issue, and my patch is no 
> longer needed.
> Your patch isn't included in our code, so I submitted this patch.

Alright cool. Sounds like this patch can be dropped then and you can
pick up the patch from upstream into your vendor kernel.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
       [not found]         ` <671f87d6-f4a4-6d2c-967b-e1aa0677d83e@codeaurora.org>
@ 2019-06-17 10:35           ` " Neeraj Upadhyay
  2019-06-17 11:50             ` Linus Walleij
  0 siblings, 1 reply; 8+ messages in thread
From: Neeraj Upadhyay @ 2019-06-17 10:35 UTC (permalink / raw)
  To: Stephen Boyd, tengfeif, Linus Walleij, bjorn.andersson
  Cc: LKML, linux-gpio, linux-arm-msm, sramana


> Quoting tengfeif@codeaurora.org (2019-06-11 03:41:26)
>> On 2019-06-10 22:51, Stephen Boyd wrote:
>> > Quoting Linus Walleij (2019-06-07 14:08:10)
>> >> On Fri, May 31, 2019 at 8:52 AM Tengfei Fan 
>> <tengfeif@codeaurora.org> >> wrote:
>> >> >> > The gpio interrupt status bit is getting set after the
>> >> > irq is disabled and causing an immediate interrupt after
>> >> > enablling the irq, so clear status bit on irq_unmask.
>> >> >
>> >> > Signed-off-by: Tengfei Fan <tengfeif@codeaurora.org>
>> >> >> This looks pretty serious, can one of the Qcom maintainers ACK
>> >> this?
>> >> >> Should it be sent to fixes and even stable?
>> >> >> Fixes: tag?
>> >> > > How is the interrupt status bit getting set after the irq is 
>> disabled?
>> > It looks like this is a level type interrupt? I thought that after
>> > commit b55326dc969e ("pinctrl: msm: Really mask level interrupts to
>> > prevent latching") this wouldn't be a problem. Am I wrong, or is qcom
>> > just clearing out patches on drivers and this is the last one that 
>> > needs
>> > to be upstreamed?
>>
>> Your patch(commit b55326dc969e) can cover our issue, and my patch is 
>> no longer needed.
>> Your patch isn't included in our code, so I submitted this patch.
>
> Alright cool. Sounds like this patch can be dropped then and you can
> pick up the patch from upstream into your vendor kernel.
>

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.

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.

This can happen for both edge and level interrupts.

Patch https://lkml.org/lkml/2019/6/17/226 tries to cover this use case. 
Can you please

provide your comments?


Thanks

Neeraj

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
  2019-06-17 10:35           ` Fwd: " Neeraj Upadhyay
@ 2019-06-17 11:50             ` Linus Walleij
  2019-06-17 13:22               ` Neeraj Upadhyay
  0 siblings, 1 reply; 8+ messages in thread
From: Linus Walleij @ 2019-06-17 11:50 UTC (permalink / raw)
  To: Neeraj Upadhyay, Hans Verkuil
  Cc: Stephen Boyd, Tengfei Fan, Bjorn Andersson, LKML,
	open list:GPIO SUBSYSTEM, MSM, sramana

On Mon, Jun 17, 2019 at 12:35 PM Neeraj Upadhyay <neeraju@codeaurora.org> 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).

> 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?

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fwd: Re: [PATCH] pinctrl: qcom: Clear status bit on irq_unmask
  2019-06-17 11:50             ` Linus Walleij
@ 2019-06-17 13:22               ` Neeraj Upadhyay
  0 siblings, 0 replies; 8+ messages in thread
From: Neeraj Upadhyay @ 2019-06-17 13:22 UTC (permalink / raw)
  To: Linus Walleij, Hans Verkuil
  Cc: Stephen Boyd, Tengfei Fan, Bjorn Andersson, LKML,
	open list:GPIO SUBSYSTEM, MSM, sramana

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@codeaurora.org> 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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-31  6:51 [PATCH] pinctrl: qcom: Clear status bit on irq_unmask Tengfei Fan
2019-06-07 21:08 ` Linus Walleij
2019-06-10 14:51   ` Stephen Boyd
2019-06-11 10:41     ` tengfeif
2019-06-11 18:51       ` Stephen Boyd
     [not found]         ` <671f87d6-f4a4-6d2c-967b-e1aa0677d83e@codeaurora.org>
2019-06-17 10:35           ` Fwd: " Neeraj Upadhyay
2019-06-17 11:50             ` Linus Walleij
2019-06-17 13:22               ` Neeraj Upadhyay

Linux-ARM-MSM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-msm/0 linux-arm-msm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-msm linux-arm-msm/ https://lore.kernel.org/linux-arm-msm \
		linux-arm-msm@vger.kernel.org linux-arm-msm@archiver.kernel.org
	public-inbox-index linux-arm-msm


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-arm-msm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox