mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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:05:30 +0300	[thread overview]
Message-ID: <56f9d1d6-1129-b526-00d2-21fd17c93368@cogentembedded.com> (raw)
In-Reply-To: <20180626064618.j6mjqjpmff46hqwd@pengutronix.de>

>>> 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.

Nikita

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

  reply	other threads:[~2018-06-26  7:05 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 [this message]
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=56f9d1d6-1129-b526-00d2-21fd17c93368@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