From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Green Subject: Re: RFC: Platform data for onboard USB assets Date: Fri, 18 Mar 2011 20:02:23 +0000 Message-ID: <4D83BA4F.8050301@linaro.org> References: <4D83A25C.804@ti.com> <20110318182518.GA2271@opensource.wolfsonmicro.com> Reply-To: andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110318182518.GA2271-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mark Brown Cc: David Anders , Arnd Bergmann , Greg KH , Grant Likely , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , Nicolas Pitre , Linux USB list , lkml List-Id: devicetree@vger.kernel.org On 03/18/2011 06:25 PM, Somebody in the thread at some point said: Hi - >> if you grep in drivers/net you will find a wide range of network >> devices that use the random_ether_addr() function: > > This is a slightly different case to the one where device tree is most > useful which is the case where there is a MAC assigned to the system but > it's been stored in an alternative location and needs to be programmed > into the NIC by software. From an earlier discussion in IRC, I know David's point is the presence of so many calls to random_ether_addr() suggests the "crap, there is no EEPROM" state can be reached by all those drivers. In which case, they are all potential consumers of a MAC "stored in an alternative location and needs to be programmed into the NIC by software" solution, which he also thinks is needed. -Andy -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html