On Sat, 24 Nov 2012, Andy Green wrote: > If we're just looking at fixing the current "magic regulator name" > scheme of "hsusb0" so that it can work with abstract devices like any > hub / port, we could invert what my original "device path" scheme did. > > So instead of having a parser (which boiled down quite small, but is > complicated by usb%d being the same for different usb drivers), we could > just add a helper function that walks the device parents to generate a > string representing the device instance. Like > > int device_path_generate(struct device *device, char *name, int len); > > if you called it from the hub driver's probe function (or anything > else's probe function) with the new hub device pointer, it might fill > name with "ehci1/usbhub1-1/1-1.1" or somesuch. It's not that simple. In your example, the very same device might show up, after rebooting, as "ehci2/usbhub2-1/2-1.1". Even if a more or less stable name for the controller is used, the bus-number parts of the name (the '2's in this example) are always subject to change. The device_path_generate routine would have to possess special knowledge about the USB subsystem's naming scheme to generate a truly stable name. Presumably the same would hold for other subsystems too. Alan Stern -- 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
