On 4 September 2016 at 02:24, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 3 Sep 2016, Jacek Anaszewski wrote: > >> >> The remaining issue is the sysfs interface design for defining and >> >> presenting multiple USB ports. I'm still in favour of a single >> >> attribute with space separated list. This scheme is commonly used >> >> in existing interfaces. >> > >> > No such interface is needed if you do things the way I outlined above. >> > Each trigger would require the user to specify either one port, one >> > hub, or nothing at all. Multiple ports would not be used. >> >> The patch assumes that it is possible to register trigger for many >> ports. > > The patch could be changed to remove that assumption. I did this assumption for a reason. There are many devices with more than 1 USB port and these ports are handled by the same controllers, just different ports. Let me share USB details of my SmartRG SR400ac device with 2 physical USB ports: Physical USB 3.0 port is handled by following controllers and their root hub ports: 1) OHCI's port 1 2) EHCI's port 1 3) XHCI's port 1 Physical USB 2.0 port is handled by following controllers and their root hub ports: 1) OHCI's port 2 2) EHCI's port 2 This devices has 3 separated LEDs. I'll list them and tell which ports should be assigned to them: bcm53xx:green:usb3 should have assigned: 1) OHCI's port 1 2) EHCI's port 1 bcm53xx:white:usb3 should have assigned: 1) XHCI's port 1 bcm53xx:white:usb2 should have assigned: 1) OHCI's port 2 2) EHCI's port 2 As you can see, I need to specify ports precisely. Assigning a single port is not enough. Assigning whole hub is too much. So none of: > echo usb1-4.2 >/sys/class/led/foo/trigger > echo hub1-4 >/sys/class/led/foo/trigger > echo usb >/sys/class/led/foo/trigger would be sufficient here :( -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
