linux-kernel - Re: Exynos850 and ExynosAuto v9 pinctrl wakeup muxed interrupt

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]

Date:   Fri, 7 Jan 2022 09:16:09 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Sam Protsenko <semen.protsenko@...aro.org>
Cc:     Chanho Park <chanho61.park@...sung.com>,
        "linux-samsung-soc@...r.kernel.org" 
        <linux-samsung-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Tomasz Figa <tomasz.figa@...il.com>
Subject: Re: Exynos850 and ExynosAuto v9 pinctrl wakeup muxed interrupt

On 03/01/2022 21:59, Sam Protsenko wrote:
> On Thu, 30 Dec 2021 at 21:34, Krzysztof Kozlowski
> <krzysztof.kozlowski@...onical.com> wrote:
>>
>> Hi Chanho and Sam,
>>
>> I am slowly finishing dtschema for Samsung pinctrl drivers [1] and I
>> noticed that Exynos850 and Auto v9 do not define interrupt in pinctrl
>> node with: wakeup-interrupt-controller. This is an interrupt muxing
>> several external wakeup interrupts, e.g. EINT16 - EINT31.
>>
>> For Exynos5433 this looks like:
>> https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/exynos/exynos5433.dtsi#L857
>>
>> Missing muxed interrupt for Exynos850 and Autov9 might be fine, although
>> you should see in dmesg error log like:
>>     "irq number for muxed EINTs not found"
>>
>> Can you check that your wakeup-interrupt-controller is properly defined
>> in DTSI? If yes, I will need to include such differences in the dtschema.
>>
> 
> In case of Exynos850, no muxed interrupts exist for wakeup GPIO
> domains. Basically, "pinctrl_alive" and "pinctrl_cmgp" domains are
> wake-up capable, and they have dedicated interrupt for each particular
> GPIO pin. All those interrupts are defined in exynos850-pinctrl.dtsi
> file, in next nodes:
>   - pinctrl_alive: gpa0..gpa4 (interrupt numbers 1..36)
>   - pinctrl_cmgp: gpm0..gpm7 (interrupt numbers 39..46)
> 
> All mentioned interrupts are wakeup interrupts, and there are no muxed
> ones. So it seems like it's not possible to specify "interrupts"
> property in pinctrl nodes with wakeup-interrupt-controller. The PM is
> not enabled in Exynos850 platform yet, so I can't really test if
> interrupts I mentioned are able to wake up the system.

Thanks for confirming, I'll adjust the schema.

> 
> After adding this patch ("arm64: dts: exynos: Add missing gpm6 and
> gpm7 nodes to Exynos850"), I can't see this error message anymore:
> 
>     samsung-pinctrl 11c30000.pinctrl: irq number for muxed EINTs not found
> 
> That's because exynos_eint_wkup_init() function exits in this check:
> 
>     if (!muxed_banks) {
>         of_node_put(wkup_np);
>         return 0;
>     }
> 
> But I actually can see another error message, printed in
> exynos_eint_gpio_init() function (for wake-up capable pinctrl nodes,
> because those nodes don't have "interrupts" property now -- you
> removed those in your patch):
> 
>     samsung-pinctrl 11850000.pinctrl: irq number not available
>     samsung-pinctrl 11c30000.pinctrl: irq number not available
> 
> which in turn leads to exynos_eint_gpio_init() function to exit with
> -EINVAL code in the very beginning, and I'm not sure if it's ok? As I
> said, those errors only appear after your patch ("arm64: dts: exynos:
> drop incorrectly placed wakeup interrupts in Exynos850").

Yeah, I replied to this next to my patch. I think my patch was not
correct and you need one - exactly one - interrupt for regular GPIO
interrupts.

> 
> It raises next questions, which I'm trying to think over right now.
> Krzysztof, please let me know if you already have answers to those:
> 
> 1. Regarding "wakeup-interrupt-controller" node (and
> exynos_eint_wkup_init() function): is it ok to not have "interrupts"
> property in there? Would corresponding interrupts specified in child
> nodes (gpa0..gpa4) function as wake-up interrupts in this case? Or
> pinctrl driver should be reworked somehow?

Yes, it should be fine. The message should be changed from error to info
or even debug, maybe depending on SoC-type (so define in struct
samsung_pin_ctrl whether exynos_eint_wkup_init expects muxed wake-ip
interrupts).

> 
> 2. Regarding missing interrupts in pinctrl nodes (and corresponding
> error in exynos_eint_gpio_init() function): should it be reworked in
> some way for Exynos850? Error message seems invalid in Exynos850 case,
> and I'm not even sure if it's ok exynos_eint_gpio_init() fails. Should
> it be modified to work that error around, in case of Exynos850?
> 
> All other pinctrl nodes have a muxed interrupt (except pinctrl_aud,
> but that's probably fine).

The error message is valid - correctly points to wrong configuration.
All pinctrl nodes should have one interrupt, if they have GPIOs capable
of interrupt as a function (usually 0xf as GPIO CON register). Why
pinctrl_aud does not have it? Maybe the function EXT_INT (0xf) is not
available for its pins?

Best regards,
Krzysztof