From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Tue, 21 Jul 2015 15:25:37 -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 20 July 2015 at 12:10, Joe Hershberger wrote: > Hi Simon, > > On Mon, Jul 20, 2015 at 8:56 AM, Simon Glass wrote: >> 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). > > 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