Re: [PATCH] net: avoid assigning ethaddr to wrong devices

[Nikita Yushchenko <nikita.yoush@cogentembedded.com>]

25.06.2018 15:34, Sascha Hauer wrote:
> Hi Nikita,
> 
> On Fri, Jun 22, 2018 at 07:30:12PM +0300, Nikita Yushchenko wrote:
>> 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?
Maybe support for that hardware should be fixed (i.e. appropriate node
and/or alias added to device tree used for that hardware by barebox)?

Nikita

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox