From: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
To: Sascha Hauer <sha@pengutronix.de>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>,
barebox@lists.infradead.org, Chris Healy <cphealy@gmail.com>
Subject: Re: [PATCH] net: avoid assigning ethaddr to wrong devices
Date: Tue, 26 Jun 2018 09:04:02 +0300 [thread overview]
Message-ID: <ed26a296-8bf4-f328-c900-2606be033506@cogentembedded.com> (raw)
In-Reply-To: <20180626060034.75o36ndv2bdawwk2@pengutronix.de>
>>>> It can happen that device tree contains ethernetN alias pointing to
>>>> valid device, but that device is not supported by [running instance of]
>>>> barebox. Then ethN remains unassigned, and can be later captured by
>>>> dynamically registered device such as usbnet.
>>>>
>>>> For such "stranger" device, ethaddr preconfigured for ethN should not be
>>>> assigned. Also, ethaddr of such device should not be written to
>>>> ethernetN node of device tree passed to kernel being booted.
>>>>
>>>
>>> There's only one usecase for matching edev->dev.id against the ethernetx
>>> alias which has been introduced with:
>>>
>>> | commit a78431c7fc42193be252417bf06f7cc61765a51e
>>> | Author: Renaud Barbier <renaud.barbier@ge.com>
>>> | Date: Wed Sep 4 08:37:03 2013 +0200
>>> |
>>> | net, of: fixup MAC address by alias
>>> |
>>> | If a network device has not been registered from the devicetree, we may
>>> | still find it by its alias in the devicetree. This way also platform based
>>> | network devices can obtain a valid MAC address in the devicetree.
>>> |
>>> | Signed-off-by: Renaud Barbier <renaud.barbier@ge.com>
>>> | Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>
>>> Your eth_is_stranger() returns true for the devices that Renaud wanted
>>> to support, so instead of applying your patch we could equally well
>>> revert that from Renaud.
>>>
>>> I don't have a good idea right now how to fix this. Maybe we have to
>>> make sure that ethernet devices from dynamic buses never get an id
>>> asigned that is also present in the aliases node.
>>
>> eth_is_stranger() for ethN returns true only if ethernetN alias exists
>> AND ethN either does not have device tree node, or has node different
>> from what is pointed by alias.
>>
>> My assumption was that if under linux ethdevice is configured via device
>> tree node with ethernetX alias, then under barebox it should also be
>> configured via device tree node with same alias.
>>
>> You mean, there is hardware that breaks this assumption?
>> Which hardware it is?
>
> It's PowerPC hardware which on barebox is not probed from devicetree, so
> indeed there is no device node.
But if no device tree, then
alias = of_find_node_by_alias(of_get_root_node(), eth);
should return NULL, and eth_is_stranger() should return false, thus
making my patch no-op?
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-06-26 6:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-22 16:30 Nikita Yushchenko
2018-06-25 12:34 ` Sascha Hauer
2018-06-26 5:42 ` Nikita Yushchenko
2018-06-26 6:00 ` Sascha Hauer
2018-06-26 6:04 ` Nikita Yushchenko [this message]
2018-06-26 6:46 ` Sascha Hauer
2018-06-26 7:05 ` Nikita Yushchenko
2018-06-26 7:09 ` Nikita Yushchenko
2018-06-26 7:24 ` Sascha Hauer
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=ed26a296-8bf4-f328-c900-2606be033506@cogentembedded.com \
--to=nikita.yoush@cogentembedded.com \
--cc=andrew.smirnov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=cphealy@gmail.com \
--cc=sha@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