On Friday 19 June 2009, Alan Stern wrote: > On Fri, 19 Jun 2009, Frans Pop wrote: > > > I also don't > > > see any reason to include the E: line for endpoint 0; the only > > > useful information it contains is the maxpacket size, and that is > > > already present on the D: line. > > > > Well, on my system I have a device (docking station USB hub) that > > shows different max packet size for the device and endpoint 0: > > T: Bus=1 Lev=1 Prnt=1 Port=1 Dev#=48 Spd=480 MxCh=4 > > D: Ver=2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs=1 > > P: Vendor=0424 ProdID=2504 Rev=0.1 > > C: #Ifs=1 Cfg#=1 Atr=e0 MxPwr=2mA > > E: Ad=00(both) Atr=00(Control) MxPS=0040 Ivl=0ms > > I: If#=00 Alt=1 #EPs=01 Cls=09(hub ) Sub=00 Prot=02 Driver=hub > > E: Ad=81(in) Atr=03(Interrupt) MxPS=0001 Ivl=256ms > > Oops. That might be considered a bug in sysfs. Evidently the > wMaxPacketSize attribute shows the size in hex, instead of decimal. > Either sysfs has to be changed or else the script has to do the > conversion. > > I favor changing sysfs; seeing a packet size in hex doesn't make much > sense. On the other hand, to work with earlier versions of the kernel > the script will have do the conversion anyway -- and it will have to > check the kernel version to see whether or not the conversion is > needed. I guess you can't win... Maybe we can support both cases without a kernel version test. Something like: maxps=`cat $eppath/wMaxPacketSize` if `echo $maxps | grep -Eq "^[0-9a-fA-F]{4}$"`; then maxps=`printf "%i\n" 0x$maxps` fi That assumes that there are no actual max packet sizes >=1000. If there are, then this could be an option: maxps=`cat $eppath/wMaxPacketSize` if `echo $maxps | grep -Eq "^0[0-9a-fA-F]{3}$"`; then maxps=`printf "%i\n" 0x$maxps` fi That assumes there are no max packet sizes >=0x1000 (>=4096). Is either of those assumptions valid in practice? The values I see on my system are quite small. A quick google seems to indicate that USB 3 has a maximum of 1024, so the second option would work for the foreseeable future. At some point this workaround could be replaced by a kernel version test, or just dropped. I see that /proc/bus/usb/devices also omits the E: line for endpoint 0, so with the above explained I see no problems with dropping it. Is it possible there are multiple endpoints on the device level (as opposed to on the interfaces level)? I.e, is it safe to just remove the entire 'for endpoint in ep_??' loop in print_device()? BTW, are there plans to include this script in some source repository somewhere? Cheers, FJP -- 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