On Friday 29 June 2012, Tony Lindgren wrote: > * Andy Green <andy.green@xxxxxxxxxx> [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. 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. > > >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. 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 Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
