[PATCH v5 05/20] Input: axp20x-pek: Bail out if AXP has no interrupt line connected
Andre Przywara
andre.przywara at arm.com
Thu Jan 28 06:11:28 EST 2021
On Wed, 27 Jan 2021 11:42:15 -0800
Dmitry Torokhov <dmitry.torokhov at gmail.com> wrote:
Hi Dmitry,
thanks for your feedback!
> On Wed, Jan 27, 2021 at 05:24:45PM +0000, Andre Przywara wrote:
> > On at least one board (Orangepi Zero2) the AXP305 PMIC does not have its
> > interrupt line connected to the CPU (mostly because the H616 SoC does
> > not feature an NMI pin anymore).
> > After allowing the AXP driver to proceed without an "interrupts"
> > property [1], the axp20x-pek driver crashes with a NULL pointer
> > dereference (see below).
> >
> > Check for the regmap_irqc member to be not NULL before proceeding with
> > probe. This gets normally filled by the call to regmap_add_irq_chip(),
> > which we allow to skip now, when the DT node lacks an interrupt
> > property.
>
> No, the driver is not the right place to patch this; regmap should be
> fixed so it does not crash instead.
I am not sure this is the right approach, those regmap functions look
more like an internal interface to me, with lots of wrapper functions
happily dereferencing pointers and reaching into structs. Moving
NULL checks into those does not sound like the right thing. CC:ing Mark
for more opinions on this.
A more general solution would be to not instantiate this driver here
at all, when we don't have an interrupt line.
However at the moment the AXP MFD driver uses a const struct to hold
all MFD cells, so there is no easy way of omitting the power key
device dynamically. And even then it would hard code the requirement
for an interrupt into the MFD driver, when this could be considered an
implementation detail of the axp20x-pek driver.
That's why I came up with this patch here, which was the easiest and
cleanest: This driver *requires* a valid regmap_irqc, so it should
verify this at probe time, kind of like a normal driver would bail out
if no IRQ line could be reserved.
Let me know what you think!
Cheers,
Andre
More information about the linux-arm-kernel
mailing list