All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fenglin Wu <quic_fenglinw@quicinc.com>
To: Stephen Boyd <sboyd@kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Cc: <collinsd@codeaurora.org>, <subbaram@codeaurora.org>,
	Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Subject: Re: [RESEND PATCH v1 1/9] spmi: pmic-arb: add a print in cleanup_irq
Date: Mon, 18 Oct 2021 08:16:52 +0800	[thread overview]
Message-ID: <456da380-e613-14dc-6e42-5d6350dc2389@quicinc.com> (raw)
In-Reply-To: <83fa65c8-3442-ee26-22ed-e26b013cca14@quicinc.com>


On 10/15/2021 9:27 AM, Fenglin Wu wrote:
>
> On 10/15/2021 9:09 AM, Stephen Boyd wrote:
>> Quoting Fenglin Wu (2021-10-13 19:26:55)
>>> On 10/14/2021 3:35 AM, Stephen Boyd wrote:
>>>> Quoting Fenglin Wu (2021-10-12 21:15:42)
>>>>> On 10/13/2021 1:46 AM, Stephen Boyd wrote:
>>>>>> Quoting Fenglin Wu (2021-09-16 23:32:56)
>>>>>>> From: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
>>>>>>>
>>>>>>> The cleanup_irq() was meant to clear and mask interrupts that were
>>>>>>> left enabled in the hardware but there was no interrupt handler
>>>>>>> registered for it. Add an error print when it gets invoked.
>>>>>> Why? Don't we get the genirq spurious irq message in this scenario?
>>>>> Thanks for reviewing the change.
>>>>>
>>>>> No, there is no existing message printed out in this special case 
>>>>> ( IRQ
>>>>> fired for not registered interrupt).
>>>> Ah I see so the irq doesn't have a flow handler? Shouldn't you call
>>>> handle_bad_irq() in this case so we get a irq descriptor print?
>>> In such case, the irq number is not valid and there won't be a valid
>>> irq_desc, hence it's not possible to call handle_bad_irq() here.
>> I mean handle_bad_irq() on the irqdesc for the spmi pmic arb chained
>> irq. Because things are not good with the chained irq.
> Okay, how about this, Update periph_interrupt() function with a return
> value, and return -EINVAL once an invalid IRQ is detected. In
> pmic_arb_chained_irq(), call handle_bad_irq() if periph_interrupt()
> returned -EINVAL.
Combined with your comments in "[PATCH v1 3/9] spmi: pmic-arb:check apid
againstlimits before calling irq handler",it seemslike that it can be
a independentpatch for handling spuriousinterrupt, something like this
in my mind:

diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index 295e19f..bd01ad4 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -504,10 +504,10 @@ static void cleanup_irq(struct spmi_pmic_arb 
*pmic_arb, u16 apid, int id)
                                 irq_mask, ppid);
  }

-static void periph_interrupt(struct spmi_pmic_arb *pmic_arb, u16 apid)
+static int periph_interrupt(struct spmi_pmic_arb *pmic_arb, u16 apid)
  {
         unsigned int irq;
-       u32 status, id;
+       u32 status, id, handled = 0;
         u8 sid = (pmic_arb->apid_data[apid].ppid >> 8) & 0xF;
         u8 per = pmic_arb->apid_data[apid].ppid & 0xFF;

@@ -522,7 +522,10 @@ static void periph_interrupt(struct spmi_pmic_arb 
*pmic_arb, u16 apid)
                         continue;
                 }
                 generic_handle_irq(irq);
+               handled++;
         }
+
+       return (handled == 0) ? -EINVAL : 0;
  }

  static void pmic_arb_chained_irq(struct irq_desc *desc)
@@ -533,7 +536,7 @@ static void pmic_arb_chained_irq(struct irq_desc *desc)
         int first = pmic_arb->min_apid >> 5;
         int last = pmic_arb->max_apid >> 5;
         u8 ee = pmic_arb->ee;
-       u32 status, enable;
+       u32 status, enable, handled = 0;
         int i, id, apid;

         chained_irq_enter(chip, desc);
@@ -548,10 +551,14 @@ static void pmic_arb_chained_irq(struct irq_desc 
*desc)
                         enable = readl_relaxed(
ver_ops->acc_enable(pmic_arb, apid));
                         if (enable & SPMI_PIC_ACC_ENABLE_BIT)
- periph_interrupt(pmic_arb, apid);
+                               if (periph_interrupt(pmic_arb, apid) == 0)
+ handled++;
                 }
         }

+       if (handled == 0)
+               handle_bad_irq(desc);
+
         chained_irq_exit(chip, desc);
  }

Is this what you expected? The original patch is only for printing a 
debug message when any
sub-irq is detected as enabled but not registered, some other sub-IRQ 
maybe still valid and
be handled after that, which means the chained-irq may still be a good 
one.Should I keep
the original patch unchanged and submit a separate one to handle the 
spuriousinterrupt?



  reply	other threads:[~2021-10-18  0:16 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17  6:32 [RESEND PATCH v1 0/9] A bunch of fix and optimization patches in spmi-pmic-arb.c Fenglin Wu
2021-09-17  6:32 ` [RESEND PATCH v1 1/9] spmi: pmic-arb: add a print in cleanup_irq Fenglin Wu
2021-10-12 17:46   ` Stephen Boyd
2021-10-13  4:15     ` Fenglin Wu
2021-10-13 19:35       ` Stephen Boyd
2021-10-14  2:26         ` Fenglin Wu
2021-10-15  1:09           ` Stephen Boyd
2021-10-15  1:27             ` Fenglin Wu
2021-10-18  0:16               ` Fenglin Wu [this message]
2021-09-17  6:32 ` [RESEND PATCH v1 2/9] spmi: pmic-arb: do not ack and clear peripheral interrupts " Fenglin Wu
2021-09-17  6:32 ` [RESEND PATCH v1 3/9] spmi: pmic-arb: check apid against limits before calling irq handler Fenglin Wu
2021-10-12 18:02   ` Stephen Boyd
2021-10-13  5:31     ` Fenglin Wu
2021-10-13 19:25       ` Stephen Boyd
2021-10-14  3:11         ` Fenglin Wu
2021-10-15  1:15           ` Stephen Boyd
2021-10-15  1:54             ` Fenglin Wu
2021-09-17  6:32 ` [RESEND PATCH v1 4/9] spmi: pmic-arb: add support to dispatch interrupt based on IRQ status Fenglin Wu
2021-09-17  6:33 ` [RESEND PATCH v1 5/9] spmi: pmic-arb: correct duplicate APID to PPID mapping logic Fenglin Wu
2021-10-12 17:44   ` Stephen Boyd
2021-10-13  5:37     ` Fenglin Wu
2021-09-17  6:33 ` [RESEND PATCH v1 6/9] spmi: pmic-arb: block access for invalid PMIC arbiter v5 SPMI writes Fenglin Wu
2021-09-17  6:33 ` [RESEND PATCH v1 7/9] spmi: pmic-arb: support updating interrupt type flags Fenglin Wu
2021-10-12 17:42   ` Stephen Boyd
2021-10-13  6:27     ` Fenglin Wu
2021-10-13 19:37       ` Stephen Boyd
2021-10-14  3:17         ` Fenglin Wu
2021-09-17  6:33 ` [RESEND PATCH v1 8/9] spmi: pmic-arb: make interrupt support optional Fenglin Wu
2021-10-12 17:41   ` Stephen Boyd
2021-10-13  8:36     ` Fenglin Wu
2021-10-13 19:38       ` Stephen Boyd
2021-10-14  3:20         ` Fenglin Wu
2021-10-15  1:17           ` Stephen Boyd
2021-10-15  1:30             ` Fenglin Wu
2021-09-17  6:33 ` [RESEND PATCH v1 9/9] spmi: pmic-arb: increase SPMI transaction timeout delay Fenglin Wu
  -- strict thread matches above, loose matches on Subject: below --
2021-09-01  8:18 [RESEND PATCH v1 0/9] A bunch of fix and optimization patches in spmi-pmic-arb.c Fenglin Wu
2021-09-01  8:18 ` [RESEND PATCH v1 1/9] spmi: pmic-arb: add a print in cleanup_irq Fenglin Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=456da380-e613-14dc-6e42-5d6350dc2389@quicinc.com \
    --to=quic_fenglinw@quicinc.com \
    --cc=adharmap@codeaurora.org \
    --cc=collinsd@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=subbaram@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.