Hi Arnd, >>> b) We need to add a way to attach a device_node to an sdio_func, >>> so that a function driver can find additional DT properties. >>> This part should be relatively simple once (a) is done and >>> should only need a little code but no new binding. The code >>> would be similar to what we do for amba, i2c or spi devices. >> >> This isn't actually needed for this functionality, but might be needed >> for other things... >> > > There is at least one sdio driver (cw1200) that needs to get > a MAC address from DT and has the same kind of hack that > you mention to work around it at the moment (actually worse, > it's not even using auxdata). The MAC address is certainly > a property of the device, not the host. This is of course > the same problem that we have on various development boards > with USB ethernet controllers lacking an EEPROM. there are plenty of these devices. It is not just Ethernet or WiFi. You can add Bluetooth devices addresses to this as well. The Nokia N900 drivers for example. Even the Nexus 4 devices are in this boat as well. The addresses are either stored in some magic place or plain simple on the host filesystem. Maybe this whole magic persistent IEEE addresses thing need its own subsystem. So drivers needing an address can just request it from the subsystem and the subsystem deals with the nasty storage details on how to get the addresses into the kernel in the first place. Currently it is a big mess. I have seen nasty workaround with delayed initialization from probe or other crazy sysfs settings to just make this work. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
