[PATCH 2/3] OMAP2+ devices add mac address allocation register api

[tony@atomide.com (Tony Lindgren)]

* Arnd Bergmann <arnd@arndb.de> [120629 06:50]:
> On Friday 29 June 2012, Tony Lindgren wrote:
> > * Andy Green <andy.green@linaro.org> [120629 03:12]:
> > > >2. Is this really how we want to pass the board generated mac addresses
> > > >    and other dynamically generated data to the drivers that are device
> > > >    tree based?
> > > 
> > > The issue is that both these busses have an async probe, in the case
> > > of USB stack the maintainer was not interested last year in adding
> > > platform data.  Maybe it changed but that's my understanding.
> > 
> > OK, I'd like to hear Arnds comments on the #2 above too as this is
> > a more generic issue.
> 
> In case we have a device tree, we should just be using the USB binding
> to find the specific device node, and add the property there. Then
> the device driver can use of_get_mac_address() on the usb device itself.

But would you generate the mac address then in the bootloader already?
 
> I'm not sure what it takes to add the link for the device node in the
> usb probing code, but my feeling is that it's not too hard.
> 
> Right now, USB is probed entirely without DT, so the patch is about
> the best we can do.

Right, but that still assumes a static mac from the bootloader unless
we do a generic driver as below? Or do you have some other ideas?
 
> > > >3. What about mac address in board-generic.c when booting panda with
> > > >    device tree?
> > > 
> > > I don't mind adapting it for that case.
> > 
> > Just to try to think about some alternatives, how about something like
> > this: This all could be a driver called soft-mac or something that does
> > what your patches are doing. Except then it would be completely generic
> > and would be able to take device names and mac addresses from platform
> > data or from devicetree.
> 
> That driver would be completely generic to all platforms, but be
> very specific to finding the mac address of a device, as opposed to
> other properties.
> 
> I suspect that if we do that, we will still need a way to bind a
> device_node to a usb device for the purpose of finding other
> properties, such as external regulators or clocks that are connected
> to a hardwired USB device.

Yes that generic driver could be gind to a usb device and we could
use deferred probe to wait for the mac address to be available.
 
> Normally USB tends to just work because the device is expected to
> be hot-pluggable anyway. If the USB device is soldered to the
> board, the hardware designers can take some shortcuts

But that too still depends on the order of loading of the multiple
host controller modules. Beagle has both EHCI and musb.

Regards,

Tony