From: Robin Murphy <robin.murphy@arm.com>
To: Mason <slash.tmp@free.fr>
Cc: Mark Rutland <mark.rutland@arm.com>,
DT <devicetree@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Kevin Hilman <khilman@kernel.org>,
netdev <netdev@vger.kernel.org>,
Thibaud Cornic <thibaud_cornic@sigmadesigns.com>,
Uwe Kleine-Konig <u.kleine-koenig@pengutronix.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Initializing MAC address at run-time
Date: Wed, 18 Jan 2017 15:35:09 +0000 [thread overview]
Message-ID: <f902209c-268b-5abe-4527-c8d0e56bce79@arm.com> (raw)
In-Reply-To: <20170118144528.GH3231@leverpostej>
On 18/01/17 14:45, Mark Rutland wrote:
> On Wed, Jan 18, 2017 at 03:03:57PM +0100, Mason wrote:
>> Hello,
>>
>> When my system boots up, eth0 is given a seemingly random MAC address.
>>
>> [ 0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38
>> [ 0.957334] nb8800 26000.ethernet eth0: MAC address 6e:f1:48:de:d6:c4
>>
>>
>> The DT node for eth0 is:
>>
>> eth0: ethernet@26000 {
>> compatible = "sigma,smp8734-ethernet";
>> reg = <0x26000 0x800>;
>> interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&clkgen SYS_CLK>;
>> };
>>
>> Documentation/devicetree/bindings/net/ethernet.txt mentions
>> - local-mac-address: array of 6 bytes, specifies the MAC address that was
>> assigned to the network device;
>>
>> And indeed, if I define this property, eth0 ends up with the MAC address
>> I specify in the device tree. But of course, I don't want all my boards
>> to share the same MAC address. Every interface has a unique MAC address.
>>
>> In fact, the boot loader (not Uboot, a custom non-DT boot loader) stores
>> the MAC address somewhere in MMIO space, in some weird custom format.
>>
>> So, at init, I can find the MAC address, and dynamically insert the
>> "local-mac-address" property in the eth0 node.
>
> To me it sounds very convoluted to do this from the kernel, to pass
> information back to itself. I don't think this is the best way to handle
> this.
>
>> Is there another (better) way to do this?
>>
>> I'll post my code below, for illustration purpose.
>>
>> Mark suggested this can be done from user-space, but I can't do that,
>> because I'm using an NFS rootfs, so I need the network before I even
>> have a user-space. And the DHCP server is configured to serve different
>> root filesystems, based on the MAC address.
>
> That's not quite what I said. I asked whether your information was
> coming from userspace or from a kernel driver.
>
> My suggestion was that this should be done in the probe path somehow,
> by describing the relationship between the ethernet controller and the
> device containing the MAC information.
>
> e.g. on the ethernet device, have a phandle (and perhaps some other
> args) describinng the device containing the MAC, and how to extract it.
>
> That way, in the ethernet probe path we can go and look up the MAC
> address from the provider of that information.
See Documentation/devicetree/bindings/mfd/syscon.txt and
bindings/drivers with syscon dependencies. Essentially, you would use a
syscon node to describe "somewhere in MMIO space", then your ethernet
driver probe routine simply grabs the regmap, pulls out the MAC and goes
from there.
Be warned that the above represents the totality of my technical
knowledge on the subject ;) My experience is in hacking up DTs for
drivers which already use this mechanism, rather than in implementing it.
Robin.
>> I need to do something similar with the NAND partitions. The boot loader
>> stores the partition offsets somewhere, and I need to pass this info
>> to the NAND framework, so I assumed that inserting the corresponding
>> properties at run-time was the correct way to do it.
>
> I would say similar could happen here.
>
> Thanks,
> Mark.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
next prev parent reply other threads:[~2017-01-18 15:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 14:03 Initializing MAC address at run-time Mason
[not found] ` <e083ed68-0e8e-380e-23bd-5ad387c88575-GANU6spQydw@public.gmane.org>
2017-01-18 14:45 ` Mark Rutland
2017-01-18 15:35 ` Robin Murphy [this message]
2017-01-18 18:54 ` Uwe Kleine-König
2017-01-19 15:31 ` Mason
2017-01-19 16:26 ` Uwe Kleine-König
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=f902209c-268b-5abe-4527-c8d0e56bce79@arm.com \
--to=robin.murphy@arm.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.org \
--cc=slash.tmp@free.fr \
--cc=thibaud_cornic@sigmadesigns.com \
--cc=u.kleine-koenig@pengutronix.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;
as well as URLs for NNTP newsgroup(s).