From: Ian Campbell <ijc+uboot@hellion.org.uk>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] sunxi: Add support for eth1addr
Date: Thu, 30 Jun 2016 16:59:40 +0100 [thread overview]
Message-ID: <1467302380.1985.26.camel@hellion.org.uk> (raw)
In-Reply-To: <f99be5b4-dceb-15c0-ad59-fa80eb5c05d1@redhat.com>
On Thu, 2016-06-30 at 17:07 +0200, Hans de Goede wrote:
> Hi,
>
> On 30-06-16 15:52, Ian Campbell wrote:
> > On Thu, 2016-06-30 at 13:15 +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 30-06-16 12:50, Ian Campbell wrote:
> > > > On Sun, 2016-06-26 at 13:54 +0200, Hans de Goede wrote:
> > > > > Currently we will already fill ethaddr with a fixed unique
> > > > > address
> > > > > based on the SoCs serial (from the sid) to make sure that
> > > > > boards which
> > > > > use the integrated emac / gmac get a fixed mac rather then a
> > > > > random one.
> > > > >
> > > > > On some boards (observed on 2 tablets using sdio rtl8703as
> > > > > wifi chips)
> > > > > the wifi does not come with a fixed mac either, so also set
> > > > > eth1addr,
> > > > > so that dts files can set an ethernet1 alias to get mac-
> > > > > address and
> > > > > local-mac-address filled for dt nodes describing the wifi
> > > > > controller.
> > > >
> > > > This does it unconditionally, won't having eth1addr show up for
> > > > boards
> > > > which only have one network device (WIFI or otherwise) be
> > > > potentially
> > > > confusing for users? i.e. lacking it would be a sign that the
> > > > online
> > > > guide you are following might not exactly be relevant to your
> > > > board, or
> > > > people seeing it and then wasting time trying to figure out how
> > > > to use
> > > > the second device. Of secondary concern (since I think it is
> > > > far less
> > > > liklely) would be confusing some software somewhere.
> > > >
> > [...]
> > > This just sets eth1addr in the u-boot env,
> >
> > It's this which I worried might confuse people, people who notice
> > eth1addr (perhaps due to tab completion on "printenv eth"?) will
> > wonder
> > where the eth1 device is and/or why it is not working for them.
>
> People who use the u-boot cmdline at all really are experienced users
> so TBH I'm not all that worried about this.
I know that I personally once wasted quite a bit of time (on arndale,
but still) being mislead/confused by different eth*addr variables
(arndale has another possible prefix too, usbaddr IIRC, which makes it
doubly confusing) and what applies to what and when. So IME having
irrelevant envvars like that floating around in the default env really
does lead to confusion even for people who (supposedly) know what they
are doing.
Even naive users will find random guides online which don't quite apply
to their particular board (especially likely with the vast number of
sunxi variants in existence) and get lead down the wrong path (which
should be "fail early since the envvar discussed doesn't exist)
Ian.
next prev parent reply other threads:[~2016-06-30 15:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-26 11:54 [U-Boot] [PATCH] sunxi: Add support for eth1addr Hans de Goede
2016-06-30 10:50 ` Ian Campbell
2016-06-30 11:15 ` Hans de Goede
2016-06-30 13:52 ` Ian Campbell
2016-06-30 15:07 ` Hans de Goede
2016-06-30 15:59 ` Ian Campbell [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-07-09 13:05 Hans de Goede
2016-07-09 13:06 ` Hans de Goede
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=1467302380.1985.26.camel@hellion.org.uk \
--to=ijc+uboot@hellion.org.uk \
--cc=u-boot@lists.denx.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