From: Chintan Vankar <c-vankar@ti.com>
To: Andrew Davis <afd@ti.com>, Peter Rosin <peda@axentia.se>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Conor Dooley <conor+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Tero Kristo <kristo@kernel.org>,
Vignesh Raghavendra <vigneshr@ti.com>, Nishanth Menon <nm@ti.com>
Cc: <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <srk@ti.com>,
<s-vadapalli@ti.com>, <r-gunasekaran@ti.com>,
<danishanwar@ti.com>
Subject: Re: [PATCH v4 2/6] arm64: dts: ti: k3-j784s4: Add alias to MCU CPSW2G
Date: Thu, 21 Mar 2024 12:31:38 +0530 [thread overview]
Message-ID: <b2cc9610-1bc8-4ad8-bf0c-f7343ae0de75@ti.com> (raw)
In-Reply-To: <c4b91154-7a8b-4642-a642-6ae93b448115@ti.com>
On 19/03/24 21:05, Andrew Davis wrote:
> On 3/11/24 5:44 AM, Chintan Vankar wrote:
>>
>>
>> On 31/01/24 21:06, Andrew Davis wrote:
>>> On 1/31/24 4:14 AM, Chintan Vankar wrote:
>>>> Add alias for the MCU CPSW2G port to enable Linux to fetch MAC Address
>>>> for the port directly from U-Boot.
>>>
>>> Could you explain *how* this alias allows Linux to fetch a MAC
>>> address from U-Boot? Sounds like we are doing something hacky here..
>>>
>> Using "probe_daughtercards()" function U-Boot parses MAC addresses from
>> EEPROM, then it internally calls "eth_env_set_enetaddr_by_index()"
>> function which stores these MAC addresses into environment variables
>> ethaddr, eth1addr, eth2addr and so on based on number of ports.
>>
>> U-Boot loads DTB during boot process, and it calls
>> "fdt_fixup_ethernet()" function, which uses environment variables to
>> update MAC addresses of ethernet ports as specified in the aliases
>> section.
>>
>
> So maybe a better question would by why does it need to use aliases
> for this?
>
Since "probe_daughtercards()" in U-Boot is implemented in a way that
it gets the MAC addresses fromm EEPROM and "fdt_fixup_ethernet()"
function configures MAC addresses for the ethernet ports as specified
in aliases section.
>>> Why can't Linux fetch the MAC from efuses the same way U-Boot does,
>>
>> Linux can fetch the MAC address from efuses if "ti,syscon-efuse"
>> property is enabled.
>>
>
> Then let's do it this way always.
>
Yes, Linux reads MAC addresses from efuse this way only, but the
functionality of Linux getting the MAC addresses from EEPROM is
not implemented.
>>> what happens if I don't use U-Boot to boot?
>>
>> If you don't use U-Boot to boot then the equivalent of
>> "probe_daughtercards()" has to be implemented which is currently
>> missing.
>>
>
> Or we just let Linux fetch it instead of implementing that function
> in all the possible bootloaders. This would also remove a DTB fixup.
> Those fixups should be avoided if at all possible.
>
Yes, we can let Linux fetch MAC addresses, but right now the Ethernet
driver in Linux can only fetch MAC addresses from "EFUSE" and not from
"EEPROM", and since the functionality to fetch MAC addresses from
"EEPROM" is implemented in U-Boot we are utilizing it.
> Andrew
>
>>>
>>> Andrew
>>>
>>>> ---
>>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> index f34b92acc56d..b74f7d3025de 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> @@ -27,6 +27,7 @@ aliases {
>>>> mmc1 = &main_sdhci1;
>>>> i2c0 = &wkup_i2c0;
>>>> i2c3 = &main_i2c0;
>>>> + ethernet0 = &mcu_cpsw_port1;
>>>> };
>>>> memory@80000000 {
next prev parent reply other threads:[~2024-03-21 7:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 10:14 [PATCH v4 0/6] Add CPSW2G and CPSW9G nodes for J784S4 Chintan Vankar
2024-01-31 10:14 ` [PATCH v4 1/6] arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl Chintan Vankar
2024-01-31 10:14 ` [PATCH v4 2/6] arm64: dts: ti: k3-j784s4: Add alias to MCU CPSW2G Chintan Vankar
2024-01-31 15:36 ` Andrew Davis
2024-03-11 10:44 ` Chintan Vankar
2024-03-19 15:35 ` Andrew Davis
2024-03-21 7:01 ` Chintan Vankar [this message]
2024-01-31 10:14 ` [PATCH v4 3/6] arm64: dts: ti: k3-j784s4-main: Add CPSW2G and CPSW9G nodes Chintan Vankar
2024-01-31 10:14 ` [PATCH v4 4/6] arm64: dts: ti: k3-j784s4: Add Main CPSW2G node Chintan Vankar
2024-01-31 15:41 ` Andrew Davis
2024-01-31 10:14 ` [PATCH v4 5/6] arm64: dts: ti: k3-j784s4: Add overlay to enable QSGMII mode with CPSW9G Chintan Vankar
2024-01-31 15:50 ` Andrew Davis
2024-03-11 10:49 ` Chintan Vankar
2024-01-31 10:14 ` [PATCH v4 6/6] arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII mode Chintan Vankar
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=b2cc9610-1bc8-4ad8-bf0c-f7343ae0de75@ti.com \
--to=c-vankar@ti.com \
--cc=afd@ti.com \
--cc=conor+dt@kernel.org \
--cc=danishanwar@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kristo@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=peda@axentia.se \
--cc=r-gunasekaran@ti.com \
--cc=robh+dt@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=srk@ti.com \
--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;
as well as URLs for NNTP newsgroup(s).