From: Michael Walle <michael@walle.cc>
To: u-boot@lists.denx.de
Subject: [PATCH v2] drivers: net: fsl_enetc: Pass on primary MAC address to Linux
Date: Wed, 11 Dec 2019 14:20:44 +0100 [thread overview]
Message-ID: <d1af3619c74a7eec765259ee8158bb87@walle.cc> (raw)
In-Reply-To: <3ffe8d32-658b-f624-eba7-deecf7c1b6cc@gmail.com>
Am 2019-12-11 14:04, schrieb Alexandru Marginean:
> On 12/10/2019 11:47 PM, Michael Walle wrote:
>> Am 2019-12-10 15:55, schrieb Alex Marginean:
>>> Passes on the primary address used by u-boot to Linux. The code does
>>> a DT
>>> fix-up for ENETC PFs and sets the primary MAC address in IERB. The
>>> address
>>> in IERB is restored on ENETC PCI functions at FLR.
>>
>>
>> I don't get the reason why this is done in a proprietary way. What is
>> the
>> difference between any other network interface whose hardware address
>> is
>> set up in the generic u-boot code.
>
> By proprietary do you mean IERB?
I meant the fdt fixups for mac-address/local-mac-address which is not
handled in the generic u-boot code, see my previous mail.
Because if it would, then there would be no need for the board specific
code below (just the one function call actually).
> Network cards normally have a ROM which comes preset from the factory
> with default MAC addresses. At run-time drivers can use the default
> address or replace it. The MAC address in IERB is the default MAC
> address for ENETC interfaces at run-time, this address is available to
> the driver/stack after issuing an FLR and in the absence of a DT node
> for the PCI function.
> We can pass MAC addresses to Linux through DT alone, but that's more
> of a hassle if Linux decides to assign the PCI function to a guest or
> user-space app. Using the IERB values doesn't require any fix-up for
> guest DTs.
Understood.
> IERB is not actually a ROM though and we need U-Boot to set factory
> MAC addresses into IERB some time before Linux boots.
>
>> Also, shouldn't write_hwaddr callback be implemented instead of the
>> enetc_set_ierb_primary_mac()?
>
> OK, makes sense, I will move the code there.
>
-michael
next prev parent reply other threads:[~2019-12-11 13:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 14:55 [PATCH v2] drivers: net: fsl_enetc: Pass on primary MAC address to Linux Alex Marginean
2019-12-10 22:47 ` Michael Walle
2019-12-11 12:46 ` Vladimir Oltean
2019-12-11 13:16 ` Michael Walle
2019-12-11 15:37 ` Alexandru Marginean
2019-12-11 17:03 ` Michael Walle
2019-12-11 21:01 ` Alexandru Marginean
2019-12-12 12:12 ` Michael Walle
2019-12-12 14:16 ` Alexandru Marginean
2019-12-11 13:04 ` Alexandru Marginean
2019-12-11 13:20 ` Michael Walle [this message]
2020-01-27 6:02 ` Priyanka Jain
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=d1af3619c74a7eec765259ee8158bb87@walle.cc \
--to=michael@walle.cc \
--cc=u-boot@lists.denx.de \
/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