linux-kernel - Re: [PATCH] gpio: mpc8xxx: Don't overwrite default irq_set

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: <81c15c43b1d1228a0d015f232ce7ec46@walle.cc>
Date:   Tue, 19 Nov 2019 11:10:14 +0100
From:   Michael Walle <michael@...le.cc>
To:     olteanv@...il.com
Cc:     bgolaszewski@...libre.com, linus.walleij@...aro.org,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        vladimir.oltean@....com
Subject: Re: [PATCH] gpio: mpc8xxx: Don't overwrite default irq_set_type
 callback

> The per-SoC devtype structures can contain their own callbacks that
> overwrite mpc8xxx_gpio_devtype_default.
> 
> The clear intention is that mpc8xxx_irq_set_type is used in case the 
> SoC
> does not specify a more specific callback. But what happens is that if
> the SoC doesn't specify one, its .irq_set_type is de-facto NULL, and
> this overwrites mpc8xxx_irq_set_type to a no-op. This means that the
> following SoCs are affected:
> 
> - fsl,mpc8572-gpio
> - fsl,ls1028a-gpio
> - fsl,ls1088a-gpio
> 
> On these boards, the irq_set_type does exactly nothing, and the GPIO
> controller keeps its GPICR register in the hardware-default state. On
> the LS1028A, that is ACTIVE_BOTH, which means 2 interrupts are raised
> even if the IRQ client requests LEVEL_HIGH. Another implication is that
> the IRQs are not checked (e.g. level-triggered interrupts are not
> rejected, although they are not supported).
> 
> Fixes: 82e39b0d8566 ("gpio: mpc8xxx: handle differences between 
> incarnations at a single place")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Tested-by: Michael Walle <michael@...le.cc>