On Friday 29 June 2012, Tony Lindgren wrote: > * Arnd Bergmann <arnd@xxxxxxxx> [120629 06:50]: > > 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. > > But would you generate the mac address then in the bootloader already? Good question. I think we definitely want to have the option of overiding the mac address from the boot loader or a predefined device tree blob. IMHO the precedence should be a) mac-address property from DT if set b) hardcoded address from device EEPROM if present c) platform-provided address, if supported by platform d) random_ether_addr() A lot of devices already provide the mac address in the device tree, wherever that comes from. Ideally that would always be possible but never necessary. > > 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? The boot loader could theoretically have the same algorithm that Andy's patch implements, unless it is configured to something else by the user. In many cases, you don't want the boot loader to be that smart, but sometimes it is the right solution. > > 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. In the device tree, we can uniquely identify the USB hosts, that is not a problem here. The problem exists only if you base your path on the linux specific name for the devices. It's definitely ugly to rely on that, but I think we can actually guarantee that it's stable as long as we enforce in the Kconfig/Kbuild that the controller that has the ethernet device is always built-in on Panda and comes before the other one if both are built-in. I would much prefer not to have to rely on those things, but I believe it is actually guaranteed at the moment for the cases that matter. While you could have both controllers as loadable modules and load them in reverse order that would also imply that you cannot actually boot from the network, so you know that you have a file system on which you can set the mac address of the device using udev, before you start using networking. 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
