In drivers/usb/core/usb.c the routine usb_alloc_dev() will
set the devpath for the root hub to "/".
Then usb_find_drivers() constructs a filename used by driverfs
using
sprintf (&interface->dev.bus_id[0], "%s-%s:%d",
dev->bus->bus_name, dev->devpath,
interface->altsetting->bInterfaceNumber);
This leads to filenames like "00:07.2-/:0" with embedded '/'.
Andries
On Sun, Aug 04, 2002 at 08:58:23PM +0200, [email protected] wrote:
> In drivers/usb/core/usb.c the routine usb_alloc_dev() will
> set the devpath for the root hub to "/".
> Then usb_find_drivers() constructs a filename used by driverfs
> using
>
> sprintf (&interface->dev.bus_id[0], "%s-%s:%d",
> dev->bus->bus_name, dev->devpath,
> interface->altsetting->bInterfaceNumber);
>
> This leads to filenames like "00:07.2-/:0" with embedded '/'.
Fix is already in Linus's tree, thanks to David Brownell:
http://linus.bkbits.net:8080/linux-2.5/[email protected]
Original patch sent to linux-usb-devel for this is at:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=102831350007377&w=2
thanks,
greg k-h
> Fix is already in Linus's tree, thanks to David Brownell
Good!
For myself I had made the fix with * instead of /.
But yes, 0 is unambiguous.
Another problem that I see under not yet determined circumstances
is "Too many links" when I do "cat product" or "cat manufacturer"
for some USB device in the devicefs tree.
This -EMLINK smells like some random negative number.
Now usb_string() in usb/core/message.c can return an error,
but routines like show_product() and show_manufacturer()
in usb/core/usb.c blindly do
len = usb_string(...);
buf[len] = '\n';
buf[len+1] = 0x00;
return len+1;
so that in case of an error some random memory is corrupted.
In other words: everywhere the return value of usb_string()
must be checked.
Andries
[Concerning the -EMLINK, I bet that usb_string() returned -EPIPE
which is -32, so that here -31, that is, -EMLINK, is returned.]