linux-kernel - Re: [PATCH v3 2/2] arm64: dts: ti: k3-am625-sk: mark MCU watchdog as reserved

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]

Date:   Wed, 9 Nov 2022 15:22:51 -0600
From:   Andrew Davis <afd@...com>
To:     Julien Panis <jpanis@...libre.com>, <nm@...com>, <vigneshr@...com>,
        <kristo@...nel.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>,
        <linux-arm-kernel@...ts.infradead.org>
CC:     <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] arm64: dts: ti: k3-am625-sk: mark MCU watchdog as
 reserved

On 11/9/22 3:30 AM, Julien Panis wrote:
> MCU wdt is typically used by M4F.
> 

See it's this "typically" part I'm concerned about.

It depends on the firmware which peripherals will be used. The firmware
doesn't communicate this to Linux, and Linux doesn't give the firmware
permissions to use one of these peripherals.

We only keep from stepping on the firmware by changing device tree to
never use peripherals that are often used by firmware, and that is not a
hardware description, nor complete when a remote core firmware can use any
device in our systems.

What happens when I change firmware? How do we power sequence this? Who
controls the clocks and clock parents if shared for this peripheral?

I'm thinking we can used something like "application nodes"[0] here. These
are basically DT nodes for a specific firmware application. The nodes
describe the firmware and all hardware it uses (in the linked example,
the remote core to run on, DMAs, SRAM, PHYs). All these devices are under
exclusive control of the application node. So while Linux will still
handle power/clock/state control, no driver will be bound. This also
handles the power sequencing question above, sub-devices need to be active
before starting the firmware, and firmware needs to go down before the
controlled peripherals.

These nodes could be loaded/unloaded as DT overlays, along with the
firmware. So resources are only "reserved" for firmware when
the firmware is actually active.

Thoughts?

Andrew

[0] https://www.spinics.net/lists/netdev/msg823883.html

> Signed-off-by: Julien Panis <jpanis@...libre.com>
> ---
>   arch/arm64/boot/dts/ti/k3-am625-sk.dts | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
> index 93a5f0817efc..089970b304cf 100644
> --- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
> @@ -503,6 +503,11 @@ &main_mcan0 {
>   	status = "disabled";
>   };
>   
> +&mcu_rti0 {
> +	/* MCU RTI0 is used by M4F firmware */
> +	status = "reserved";
> +};
> +
>   &epwm0 {
>   	status = "disabled";
>   };