Re: [RESEND PATCH v1 3/9] spmi: pmic-arb: check apid against limits before calling irq handler

[Fenglin Wu]

On 10/15/2021 9:15 AM, Stephen Boyd wrote:
> Quoting Fenglin Wu (2021-10-13 20:11:40)
> > On 10/14/2021 3:25 AM, Stephen Boyd wrote:
> > > Quoting Fenglin Wu (2021-10-12 22:31:22)
> > > > On 10/13/2021 2:02 AM, Stephen Boyd wrote:
> > > > > Quoting Fenglin Wu (2021-09-16 23:32:58)
> > > > > > From: David Collins <collinsd@xxxxxxxxxxxxxx>
> > > > > >
> > > > > > Check that the apid for an SPMI interrupt falls between the
> > > > > > min_apid and max_apid that can be handled by the APPS processor
> > > > > > before invoking the per-apid interrupt handler:
> > > > > > periph_interrupt().
> > > > > >
> > > > > > This avoids an access violation in rare cases where the status
> > > > > > bit is set for an interrupt that is not owned by the APPS
> > > > > > processor.
> > > > > >
> > > > > > Signed-off-by: David Collins <collinsd@xxxxxxxxxxxxxx>
> > > > > > Signed-off-by: Fenglin Wu <quic_fenglinw@xxxxxxxxxxx>
> > > > > > ---
> > > > > Fixes? BTW, a lot of these patches are irqchip specific. It would be
> > > > > good to get review from irqchip maintainers. Maybe we should split the
> > > > > irqchip driver off via the auxiliary bus so that irqchip maintainers can
> > > > > review. Please Cc them on irqchip related patches.
> > > > >
> > > > > IRQCHIP DRIVERS
> > > > > M:      Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > > > > M:      Marc Zyngier <maz@xxxxxxxxxx>
> > > > Sure, copied Thomas and Marc for code review.
> > > > This is a fix to avoid the register access violation in a case that an
> > > > interrupt is fired in a PMIC module which is not owned by APPS
> > > > processor.
> > > Got it.
> > >
> > > > > >     drivers/spmi/spmi-pmic-arb.c | 6 ++++++
> > > > > >     1 file changed, 6 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
> > > > > > index 4d7ad004..c4adc06 100644
> > > > > > --- a/drivers/spmi/spmi-pmic-arb.c
> > > > > > +++ b/drivers/spmi/spmi-pmic-arb.c
> > > > > > @@ -535,6 +535,12 @@ static void pmic_arb_chained_irq(struct irq_desc *desc)
> > > > > >                            id = ffs(status) - 1;
> > > > > >                            status &= ~BIT(id);
> > > > > >                            apid = id + i * 32;
> > > > > > +                       if (apid < pmic_arb->min_apid
> > > > > > +                           || apid > pmic_arb->max_apid) {
> > > > > The || goes on the line above. What about making a local variable for
> > > > > first and last and then shifting by 5 in the loop?
> > > > >
> > > > > int first = pmic_arb->min_apid;
> > > > > int last = pmic_arb->max_apid;
> > > > >
> > > > > for (i = first >> 5; i <= last >> 5; i++)
> > > > >
> > > > >         if (apid < first || apid > last)
> > > > ACK, will update it following this.
> > > > > > +                               WARN_ONCE(true, "spurious spmi irq received for apid=%d\n",
> > > > > > +                                       apid);
> > > > > Is there any way to recover from this? Or once the mapping is wrong
> > > > > we're going to get interrupts that we don't know what to do with
> > > > > forever?
> > > > This is a rare case that the unexpected interrupt is fired in a module
> > > > not owned by APPS process, so the interrupt itself is not expected hence
> > > > no need to recover from this but just bail out to avoid following register
> > > > access violation.
> > > And then the irq stops coming? It feels like a misconfiguration in the
> > > firmware that we're trying to hide, hence the WARN_ONCE(). Can we
> > > somehow silence irqs that aren't owned by the APPS when this driver
> > > probes so that they can't even happen after probe?
> > Actually this is a rarely happened case that couldn't be reproduced easily
> > and consistently for further debug. I agreed this should be caused by HW
> > misconfiguration or even some unknown HW bug that it would send out SPMI
> > interrupt messages with incorrect APID, but we have never had any chance
> > to find out the root cause. The patch here simply checked the APID and
> > bail out if it's not in the valid range, it won't cause anything bad but
> > improves the SW robustness. After that, the IRQ won't be triggered again
> > because the latched status in PMIC is not cleared. Also, because of the
> > access restriction to the registers corresponding to this APID, there is
> > nothing we can do from APPS processor side to keep it silent.
> This patch seems like a band-aid for an issue that isn't fully
> understood. I suppose it's good that the irq will stay asserted forever
> and then it won't happen again until it gets cleared by some other
> processor in the SoC. Instead of the WARN_ONCE() can we track if any irq
> is handled when the chained irq is raised, and if nothing is handled
> then call handle_bad_irq() on the chained descriptor? Take a look at
> pinctrl-msm.c to see how they handled spurious irqs that aren't actually
> directed at the APPS processor. We should do something similar here.
Sure, I will do it that way.