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.