[U-Boot] [PATCH] sunxi: Add support for eth1addr

[Hans de Goede]

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.

> The rest of what you say regarding how this goes on to interact with
> Linux makes sense to me, although even then having an eth1addr which
> does't correspond to the MAC used by the device under Linux (because it
> is burnt in and therefore eth1addr is ignored) still seems potentially
> confusing to me.
>
> I see at least some platforms use a CONFIG_HAS_ETH1 to control this. It
> could also perhaps be gated on the DTB used by u-boot itself by looking
> at the mac-address for the ethernet1 alias (and ethernet2 too I
> suppose).

Adding a Kconfig option just to have a cleaner u-boot env seems a bit
like overkill to me, and parsing the dtb even more so.

Regards,

Hans