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 10:09:36 +0300 [thread overview]
Message-ID: <db6e69a1-ee6a-d635-c57b-1edd913fee1c@cogentembedded.com> (raw)
In-Reply-To: <56f9d1d6-1129-b526-00d2-21fd17c93368@cogentembedded.com>
26.06.2018 10:05, Nikita Yushchenko wrote:
>>>> 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?
>>
>> Ok, you are right. I misread the code. You call of_find_node_by_alias()
>> on the internal device tree, not the one the Kernel is started with, so
>> indeed eth_is_stranger() should return false.
>>
>> Nevertheless I do not like this patch very much as it adds more code to
>> a place that is already hard to understand in all of its consequences.
>>
>> I would like to explore the route that we assign these dynamic devices
>> an id that is not present in any alias node. That could be done by
>> searching for the highest alias number and give the dynamic devices one
>> number higher. Would that be doable?
>
> Dynamic device number is assigned via
> - setting id to DEVICE_ID_DYNAMIC, either by driver or by code at top of
> eth_register(),
> - replacing that with lowest currently-unused number at top of
> register_device()
>
> Probably we can add one more magic value that driver could set into
> edev->dev.id before calling eth_register(), that will be replaced with
> lowest currently-unused number that does not have aliases. However, this
> will change eth numbering in existing setups and thus can break them.
>
> Possible option could be a flag in edev that forbids setting/exporting
> ethaddr for this device. Doing so for usbnet seems safe. This will fix
> my case.
Thinking more on this, maybe cleaner is NOT to match by id of in-barebox
ethdevice when setting/exporting ethaddr by default, but explicitly
allow such matching for platforms that need it.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-06-26 7:09 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
2018-06-26 6:46 ` Sascha Hauer
2018-06-26 7:05 ` Nikita Yushchenko
2018-06-26 7:09 ` Nikita Yushchenko [this message]
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=db6e69a1-ee6a-d635-c57b-1edd913fee1c@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