[U-Boot] [PATCH 01/20] dm: net: Support usbethaddr environment variable

[Simon Glass]

Hi Joe,

On 20 July 2015 at 12:10, Joe Hershberger <joe.hershberger at gmail.com> wrote:
> Hi Simon,
>
> On Mon, Jul 20, 2015 at 8:56 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Joe,
>>
>> On 8 July 2015 at 15:07, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Joe,
>>>
>>> On 8 July 2015 at 14:43, Joe Hershberger <joe.hershberger at gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Wed, Jul 8, 2015 at 3:31 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>> +Hans
>>>>>
>>>>> Hi Joe,
>>>>>
>>>>> On 7 July 2015 at 22:04, Joe Hershberger <joe.hershberger at gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Tue, Jul 7, 2015 at 9:53 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>>>> For USB Ethernet devices we need to use the usbethaddr environment variable
>>>>>>> (instead of ethaddr) the Ethernet hardware address. Add this to the uclass
>>>>>>> so that it happens automatically.
>>>>>>
>>>>>> I have always thought that this approach of having a separate prefix
>>>>>> for usbethaddr was a smelly hack. Are we sure we want to propagate it
>>>>>> here? Can we not just use dev->seq? It should already be unique in the
>>>>>> DM, right? I was really looking forward to that all going away.
>>>>>
>>>>> Ah, OK, sorry. Do you think we need a way of specifying the eth
>>>>> interface # as we do with aliases at present? We did have one but Han
>>>>> has just removed it :-)
>>>>
>>>> Can you reference where this happened. A quick search didn't turn it up for me.
>>>>
>>>>> Otherwise we'll just end up counting up from the last 'fixed' ethernet
>>>>> interface. Maybe that is good enough.
>>>>
>>>> That's probably good enough, but some may prefer more explicit control.
>>>
>>> The thread is here:
>>>
>>> http://patchwork.ozlabs.org/patch/485637/
>>>
>>> Before, we could I think add USB devices to the device tree and give
>>> them a specific number (although I never actually tested it), but that
>>> won't work now.
>>
>> What are you thoughts on this? I'd like to bring this series in soon
>> (the parts without rpi anyway).
>
> I don't mind just having "one past wired Eth" as the starting point.
> If someone cares about specifying it in the device tree that can be
> added later without redoing what you are adding here, right?

OK I'll go with that,

Regards,
Simon