linux-kernel - Re: [PATCH 2/2] ARM: dts: imx6qdl: support child mfd cells for the reset controller

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] [day] [month] [year] [list]

Message-ID: <0ac8e221-e88c-a05d-bc6f-9465783be866@pengutronix.de>
Date:   Mon, 16 Jan 2023 12:53:44 +0100
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Bastian Krause <bst@...gutronix.de>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>
Cc:     devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ARM: dts: imx6qdl: support child mfd cells for the
 reset controller

Hello Krzysztof,

On 16.01.23 11:15, Krzysztof Kozlowski wrote:
>>>> It's about syscon-reboot-mode, not syscon-reboot. Such modes are board-
>>>> not soc-specific. 
>>>
>>> syscon-reboot-mode is also mostly SoC specific. What exactly would
>>> differ on different boards? Register offsets of SoC component? Register
>>> values used by SoC power management unit?
>>
>> The modes supported. Let's say you want a bootloader mode that drops
>> the board's bootloader into a fastboot gadget mode. You'd add a
>> syscon-reboot-mode pointing at one of the non-volatile registers and
>> you would define a magic value to indicate fastboot, both in the
>> bootloader and Linux.
> 
> Bootloader and other firmware (e.g. ATF) is tightly tied to SoC, not to
> board. There might be differences between firmware used and OS (e.g.
> ChromeOS uses their own bootloader, different than Linux and Android on
> the same SoC), but again this is not board specific.

The bootloader probes from a board device tree and it also implements
initialization, update, boot and fallback logic specific to the board and
part of that is what reboot modes are supported. E.g. ST had particular
reboot modes in mind (e.g. reboot into eMMC as usb mass storage gadget),
but that's just a convention they chose for the platform, not something
inherent to the SoC.

>> In theory, the reboot mode could also talk to the bootrom[1] to change
>> the bootsource. This is also not board-agnostic, because it may not
>> make sense to have a spinor reboot mode if your board doesn't have one.
>>
>> We have this scheme for STM32MP1 already and that's why I suggested
>> Bastian to do it likewise for i.MX as he needs this functionality:
>> https://lore.kernel.org/all/20201021102855.18026-1-a.fatoum@pengutronix.de/
> 
> I don't understand why you use clearly wrong patches as examples. Bad
> patterns and bugs are not reason to use same approach.

I am trying to give you some context. It may be evident to you what's
so clearly wrong about them, but for me it worked and I am trying to
understand where you see a problem.

> The binding is wrong - you do not allow syscon-reboot-mode and if you
> ever tested your patches, you would see the errors.

I did indeed not dump the device tree after the bootloader fixed it up and
run into through the DT bindings checker. 

>> https://elixir.bootlin.com/barebox/latest/source/arch/arm/dts/stm32mp151.dtsi#L44
> 
> Whether this part is correct, tricky to say. Why these offsets are not
> valid for other board?

The offsets are valid, it may just not work. Also the user may choose to place
the reboot mode somewhere else within the syscon if the register is unused
otherwise.

Still we could probably add a reboot-mode child node to the device tree
with no extra modes and leave it disabled. That way boards can fill in the
modes they support, enable it and use it. Does this work for you?

Thanks,
Ahmad


> 
> 
> Best regards,
> Krzysztof
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |