From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 20 Jul 2015 07:56:15 -0600 Subject: [U-Boot] [PATCH 01/20] dm: net: Support usbethaddr environment variable In-Reply-To: References: <1436324032-17931-1-git-send-email-sjg@chromium.org> <1436324032-17931-2-git-send-email-sjg@chromium.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Joe, On 8 July 2015 at 15:07, Simon Glass wrote: > Hi Joe, > > On 8 July 2015 at 14:43, Joe Hershberger wrote: >> Hi Simon, >> >> On Wed, Jul 8, 2015 at 3:31 PM, Simon Glass wrote: >>> +Hans >>> >>> Hi Joe, >>> >>> On 7 July 2015 at 22:04, Joe Hershberger wrote: >>>> Hi Simon, >>>> >>>> On Tue, Jul 7, 2015 at 9:53 PM, Simon Glass 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). Regards, Simon