From: <Manikandan.M@microchip.com>
To: <mwalle@kernel.org>, <tudor.ambarus@linaro.org>,
<robh@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<Nicolas.Ferre@microchip.com>, <alexandre.belloni@bootlin.com>,
<claudiu.beznea@tuxon.dev>, <pratyush@kernel.org>,
<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
<devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v3 3/3] ARM: dts: microchip: sama5d27_wlsom1: Add nvmem-layout in QSPI for EUI48 MAC Address
Date: Thu, 12 Jun 2025 03:33:42 +0000 [thread overview]
Message-ID: <7c373149-53b9-4488-a8d0-e5560cdee7e0@microchip.com> (raw)
In-Reply-To: <DAJJ1UHCLV0M.2GGHO5PDRWMYH@kernel.org>
Hi Michael,
On 11/06/25 1:01 pm, Michael Walle wrote:
> Hi,
>
> On Mon Jun 9, 2025 at 11:27 AM CEST, Manikandan.M 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@microchip.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 {
>
> IMHO this should be "sfdp {".
>
>>>> + compatible = "fixed-layout";
>
> Please read my feedback on the first version again..
>
> For the DT maintainers. The SFDP is a small table based content that
> provide basic information about the flash. There are standard tables
> which are specified by the JEDEC standard and there are vendor
> tables, most of the time without proper documentation (or none at
> all).
>
> Somehow we need to specify at what table we want to look at. I'd
> like to see a binding which can potentially expose anything inside
> the SFDP.
>
> So I've suggested to use "compatible = jedec,sfdp-vendor-table-NNNN"
> where NNNN is the table parameter id. Additionally, the standard ids
> could have names like "jedec,sfdp-bfpt" (basic flash parameter table).
>
> So in your case that would be:
>
> flash {
> sfdp {
> mac_address: table-1 {
> compatible = "jedec,sfdp-idNNNN";
> };
> };
Should the nvmem-layout be included as a child node under sfdp {}, or
should it be implemented as a separate vendor-specific driver to handle
the changes introduced in patch 1/3 ?
> };
>
> I don't know what NNNN is. Could you please provide a dump of the
> sfdp of your flash.
Please find the entire SFDP data of SST26VF064BEUI flash in Table 11.1
of 11.0 APPENDIX
https://ww1.microchip.com/downloads/aemDocuments/documents/MPD/ProductDocuments/DataSheets/SST26VF064BEUI-Data-Sheet-DS20006138.pdf
The vendor parameter ID is 'BF' if I am not wrong.
>
> -michael
>
>>>> + #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.
next prev parent reply other threads:[~2025-06-12 3:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 7:03 [PATCH v3 0/3] Read MAC Address from SST vendor specific SFDP region Manikandan Muralidharan
2025-05-21 7:03 ` [PATCH v3 1/3] mtd: spi-nor: sfdp: parse SFDP SST vendor map and register EUI addresses into NVMEM framework Manikandan Muralidharan
2025-06-07 11:01 ` Claudiu Beznea
2025-06-09 8:04 ` Tudor Ambarus
2025-06-11 6:49 ` Michael Walle
2025-05-21 7:03 ` [PATCH v3 2/3] ARM: dts: microchip: sama5d27_wlsom1: update the QSPI partitions using "fixed-partition" binding Manikandan Muralidharan
2025-06-07 11:02 ` Claudiu Beznea
2025-05-21 7:03 ` [PATCH v3 3/3] ARM: dts: microchip: sama5d27_wlsom1: Add nvmem-layout in QSPI for EUI48 MAC Address Manikandan Muralidharan
2025-06-09 8:17 ` Tudor Ambarus
2025-06-09 9:27 ` Manikandan.M
2025-06-11 7:31 ` Michael Walle
2025-06-12 3:33 ` Manikandan.M [this message]
2025-06-12 6:17 ` Michael Walle
2025-06-16 6:43 ` Manikandan.M
2025-05-21 12:56 ` [PATCH v3 0/3] Read MAC Address from SST vendor specific SFDP region Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c373149-53b9-4488-a8d0-e5560cdee7e0@microchip.com \
--to=manikandan.m@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®