mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <sha@pengutronix.de>
To: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>,
	barebox@lists.infradead.org,
	Renaud Barbier <renaud.barbier@ge.com>,
	Chris Healy <cphealy@gmail.com>
Subject: Re: [PATCH] net: avoid assigning ethaddr to wrong devices
Date: Tue, 26 Jun 2018 08:00:34 +0200	[thread overview]
Message-ID: <20180626060034.75o36ndv2bdawwk2@pengutronix.de> (raw)
In-Reply-To: <1ef31458-200c-b132-5b86-fabdc92a810d@cogentembedded.com>

On Tue, Jun 26, 2018 at 08:42:37AM +0300, Nikita Yushchenko wrote:
> 
> 
> 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?

It's PowerPC hardware which on barebox is not probed from devicetree, so
indeed there is no device node.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

  reply	other threads:[~2018-06-26  6:00 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 [this message]
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
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=20180626060034.75o36ndv2bdawwk2@pengutronix.de \
    --to=sha@pengutronix.de \
    --cc=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=cphealy@gmail.com \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=renaud.barbier@ge.com \
    /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