On Sat, May 12, 2012 at 05:39:52PM +0200, Bjørn Mork wrote: > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > On Fri, May 11, 2012 at 02:21:07PM +0200, Bjørn Mork wrote: > >> This enables the current list of dynamic IDs to be read out through > >> either new_id or remove_id. > >> > >> Signed-off-by: Bjørn Mork <bjorn@xxxxxxx> > >> --- > >> > >> > BTW, another wishlist item is the ability to view the dynamic > >> > device list. Any objections against providing a read method > >> > for the new_id (and maybe also remove_id) file? > >> > >> So, how about something like this? Bad idea? Good idea? > > > > Great idea! > > > >> The background for this is not only my failing memory, but that there > >> are userspace tools (usb_modeswitch is one example) which will add > >> device IDs to drivers on behalf of the user. Being able to read out > >> the list is very useful in such cases. > > > > I agree, I like this a lot. I'll try to test it out on Monday and see > > how it goes. At first glance, it looks good to me, but we will need > > a Documentation/ABI/ file update as well to show the format of what we > > are printing out. > > Is something like this sufficient, or should the dates be updated? That's fine, no need to update the dates. I think the whole date thing was a bad idea in the first place, along with the kernel version, hindsight is a wonderful thing... > diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb > index 7c22a53..e2a3839 100644 > --- a/Documentation/ABI/testing/sysfs-bus-usb > +++ b/Documentation/ABI/testing/sysfs-bus-usb > @@ -135,6 +135,17 @@ Description: > for the device and attempt to bind to it. For example: > # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id > > + Reading from this file will list all dynamically added > + device IDs in the same format, with one entry per > + line. For example: > + # cat /sys/bus/usb/drivers/foo/new_id > + 8086 10f5 > + dead beef 06 > + f00d cafe > + > + The list will be truncated at PAGE_SIZE bytes due to > + sysfs restrictions. > + > What: /sys/bus/usb-serial/drivers/.../new_id > Date: October 2011 > Contact: linux-usb@xxxxxxxxxxxxxxx > @@ -157,6 +168,10 @@ Description: > match the driver to the device. For example: > # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id > > + Reading from this file will list the dynamically added > + device IDs, exactly like reading from the entry > + "/sys/bus/usb/drivers/.../new_id" > + > What: /sys/bus/usb/device/.../avoid_reset_quirk > Date: December 2009 > Contact: Oliver Neukum <oliver@xxxxxxxxxx> > > > Note that the above was based on this minor adjustment to reflect the > possible bInterfaceClass input as well: > > > diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c > index cf26fa1..61f4b7e 100644 > --- a/drivers/usb/core/driver.c > +++ b/drivers/usb/core/driver.c > @@ -88,8 +88,13 @@ static ssize_t show_dynids(struct device_driver *driver, char *buf) > size_t count = 0; > > list_for_each_entry(dynid, &usb_drv->dynids.list, node) > - count += scnprintf(&buf[count], PAGE_SIZE - count, "%04x %04x\n", > - dynid->id.idVendor, dynid->id.idProduct); > + if (dynid->id.bInterfaceClass != 0) > + count += scnprintf(&buf[count], PAGE_SIZE - count, "%04x %04x %02x\n", > + dynid->id.idVendor, dynid->id.idProduct, > + dynid->id.bInterfaceClass); > + else > + count += scnprintf(&buf[count], PAGE_SIZE - count, "%04x %04x\n", > + dynid->id.idVendor, dynid->id.idProduct); > return count; > } Looks goood. > Reading the documentation I also realized that the usb-serial new_id > should include the same output as well, to keep the functionality in > sync. Which I guess means that show_dynids() should be exported (after > proper renaming) so that it can be called from drivers/usb/serial/bus.c. Sounds reasonable. Perhaps rename it to have a usb_* prefix to keep the global namespace sane? > I'll clean all this up and submit as a two patch series. Wonderful, thanks for doing this. greg k-h -- 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
