linux-kernel - Re: [PATCH] of/irq: Don't ignore interrupt-controller when interrupt-map failed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+qyER34Q1s3farhX=2=QAic24v1-T0nC+Ln0C5Un81rQ@mail.gmail.com>
Date:   Fri, 12 Nov 2021 08:57:13 -0600
From:   Rob Herring <robh@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org,
        Christian Zigotzky <chzigotzky@...osoft.de>,
        Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH] of/irq: Don't ignore interrupt-controller when
 interrupt-map failed

On Fri, Nov 12, 2021 at 8:37 AM Marc Zyngier <maz@...nel.org> wrote:
>
> Since 041284181226 ("of/irq: Allow matching of an interrupt-map local
> to an interrupt controller"), the irq code favors using an interrupt-map
> over a interrupt-controller property if both are available, while the
> earlier behaviour was to ignore the interrupt-map altogether.
>
> However, we now end-up with the opposite behaviour, which is to
> ignore the interrupt-controller property even if the interrupt-map
> fails to match its input. This new behaviour breaks the AmigaOne
> X1000 machine, which ships with an extremely "creative" (read:
> broken) device tree.
>
> Fix this by allowing the interrupt-controller property to be selected
> when interrupt-map fails to match anything.
>
> Fixes: 041284181226 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller")
> Reported-by: Christian Zigotzky <chzigotzky@...osoft.de>
> Signed-off-by: Marc Zyngier <maz@...nel.org>
> Link: https://lore.kernel.org/r/78308692-02e6-9544-4035-3171a8e1e6d4@xenosoft.de
> Cc: Rob Herring <robh@...nel.org>
> Cc: Bjorn Helgaas <bhelgaas@...gle.com>
> ---
>  drivers/of/irq.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 32be5a03951f..508fb1717de3 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -161,9 +161,10 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
>                  * if it is then we are done, unless there is an
>                  * interrupt-map which takes precedence.
>                  */
> +               bool intc = of_property_read_bool(ipar, "interrupt-controller");
> +
>                 imap = of_get_property(ipar, "interrupt-map", &imaplen);
> -               if (imap == NULL &&
> -                   of_property_read_bool(ipar, "interrupt-controller")) {
> +               if (imap == NULL && intc) {
>                         pr_debug(" -> got it !\n");
>                         return 0;
>                 }
> @@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
>
>                         pr_debug(" -> imaplen=%d\n", imaplen);
>                 }
> -               if (!match)
> +               if (!match) {
> +                       if (intc) {
> +                               pr_debug("%pOF interrupt-map failed, using interrupt-controller\n", ipar);

Let's make this a WARN for !IS_ENABLED(CONFIG_PASEMI). (whatever the
right kconfig symbol is).

> +                               return 0;
> +                       }
> +
>                         goto fail;
> +               }
>
>                 /*
>                  * Successfully parsed an interrrupt-map translation; copy new
> --
> 2.30.2
>