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.
