[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260113162927.hmf5dnkm44kyefpt@stained>
Date: Tue, 13 Jan 2026 10:29:27 -0600
From: Nishanth Menon <nm@...com>
To: "Padhi, Beleswar" <b-padhi@...com>
CC: <andersson@...nel.org>, <mathieu.poirier@...aro.org>, <robh@...nel.org>,
<krzk+dt@...nel.org>, <conor+dt@...nel.org>, <vigneshr@...com>,
<kristo@...nel.org>, <afd@...com>, <u-kumar1@...com>, <hnagalla@...com>,
<linux-remoteproc@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 2/3] arm64: dts: ti:
k3-{j784s4-j742s2/j721s2}-mcu-wakeup: Add HSM M4F node
On 21:34-20260113, Padhi, Beleswar wrote:
[...]
> > > + reg-names = "sram0_0", "sram0_1", "sram1";
> > > + resets = <&k3_reset 304 1>;
> > > + firmware-name = "hsm.bin";
> > I am not a fan of putting firmware-name in SoC.dtsi - esp when it is
> > reserved,
>
>
> I thought the opposite way. Since it is reserved (and not a general purpose
> remote core), it is unlikely boards out there are going to use a separate
Fair enough.. I see that the base firmware name is in SoC.dtsi on a per
SoC basis. Agreed that exception can be an override if required
(unlikely in this case). Please document that rationale in the commit
message.
Since we just have a single HSM in each of the SoCs, am62p-hsm-m4f-fw
j722s-hsm-m4f-fw etc in SoC.dtsi would make sense.. just dont do a
generic hsm.bin kind of deal.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
Powered by blists - more mailing lists