linux-kernel - Re: [PATCH v3 3/3] ARM: dts: microchip: sama5d27_wlsom1: Add nvmem-layout in QSPI for EUI48 MAC Address

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: <759e4a1e-6af4-4bf9-9a95-01a7f6faaf46@microchip.com>
Date: Mon, 9 Jun 2025 09:27:20 +0000
From: <Manikandan.M@...rochip.com>
To: <tudor.ambarus@...aro.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
	<conor+dt@...nel.org>, <Nicolas.Ferre@...rochip.com>,
	<alexandre.belloni@...tlin.com>, <claudiu.beznea@...on.dev>,
	<pratyush@...nel.org>, <mwalle@...nel.org>, <miquel.raynal@...tlin.com>,
	<richard@....at>, <vigneshr@...com>, <devicetree@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<linux-mtd@...ts.infradead.org>
Subject: Re: [PATCH v3 3/3] ARM: dts: microchip: sama5d27_wlsom1: Add
 nvmem-layout in QSPI for EUI48 MAC Address

Hi Tudor,

On 09/06/25 1:47 pm, Tudor Ambarus wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 5/21/25 8:03 AM, Manikandan Muralidharan wrote:
>> Add nvmem-layout in QSPI to read the EUI48 Mac address by the
>> net drivers using the nvmem property.The offset is set to 0x0
>> since the factory programmed address is available in the
>> resource managed space and the size determine if the requested
>> address is of EUI48 (0x6) or EUI-64 (0x8) type.
>> This is useful for cases where U-Boot is skipped and the Ethernet
>> MAC address is needed to be configured by the kernel
>>
>> Signed-off-by: Manikandan Muralidharan <manikandan.m@...rochip.com>
>> ---
>>   .../boot/dts/microchip/at91-sama5d27_wlsom1.dtsi    | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
>> index b34c5072425a..be06df1b7d66 100644
>> --- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
>> +++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
>> @@ -210,6 +210,9 @@ &macb0 {
>>        #size-cells = <0>;
>>        phy-mode = "rmii";
>>
>> +     nvmem-cells = <&mac_address_eui48>;
>> +     nvmem-cell-names = "mac-address";
>> +
>>        ethernet-phy@0 {
>>                reg = <0x0>;
>>                interrupt-parent = <&pioA>;
>> @@ -238,6 +241,16 @@ qspi1_flash: flash@0 {
>>                m25p,fast-read;
>>                status = "disabled";
>>
>> +             nvmem-layout {
>> +                     compatible = "fixed-layout";
>> +                     #address-cells = <1>;
>> +                     #size-cells = <1>;
>> +
>> +                     mac_address_eui48: mac-address@0 {
>> +                             reg = <0x0 0x6>;
>> +                     };
> 
> How would this work if in the future the mchp vendor table adds some
> other info that needs to be referenced as nvmem? How do you distinguish
> the info from the table?
> Would it be possible to have some kind of address and size to reference
> the SFDP?

I was previously advised not to hardcode the offset in the Device Tree 
[1]. In the current implementation (patch 1/3), the read callback for 
the MCHP vendor table distinguishes between EUI-48 and EUI-64 MAC 
addresses based on the nvmem size, which corresponds to the size of the 
respective MAC address.

[1] --> https://lore.kernel.org/lkml/D889HZF97H8U.1UUX54BAVLAC3@kernel.org/

> 
>> +             };
>> +
>>                partitions {
>>                        compatible = "fixed-partitions";
>>                        #address-cells = <1>;
> 

-- 
Thanks and Regards,
Manikandan M.