| Message ID | 1232331915.4762.5.camel@tux.localhost (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
Am Mon, 19 Jan 2009 05:25:15 +0300 schrieb Alexey Klimov <klimov.linux@gmail.com>: > On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote: > > On Sat, 17 Jan 2009 19:09:51 +0100 > > Carsten Meier <cm@trexity.de> wrote: > > > > > Am Fri, 16 Jan 2009 02:47:50 -0200 > > > schrieb Mauro Carvalho Chehab <mchehab@infradead.org>: > > > > > > > For usb devices, usb_make_path() provide a canonical name for > > > > the device. For PCI ones, we have pci_name() for the same > > > > function. in the case of pci devices, I suspect that all use > > > > pci_name(). We just need to use usb_make_path() at the usb > > > > ones. > > > > > > I looked at the sources for what string gets generated for > > > bus_info by usb_make_path(). If it gets used by pvrusb2, my > > > problems are solved, because it is constant across > > > standby-wake-up-cycles. The pvrusb2's implementation currently > > > delivers "usb 7-2 address 6" here. "address 6" corresponds to > > > devnum which gets constantly increased, which results in always > > > changing strings here. Sorry for my unneccessary complaints. > > > > Mike, Thierry, Jean-Francois, Laurent and others: > > > > IMO, we should patch all usb drivers to use usb_make_path(). It > > will be more transparent to userspace, if all drivers provide the > > bus_info using the same notation. Comments? > > I did this thing to dsbr100.c usb radio driver: > > diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c > --- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34 > 2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.c Mon Jan > 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@ > static int vidioc_querycap(struct file *file, void *priv, > struct v4l2_capability *v) > { > + struct dsbr100_device *radio = video_drvdata(file); > + > strlcpy(v->driver, "dsbr100", sizeof(v->driver)); > strlcpy(v->card, "D-Link R-100 USB FM Radio", > sizeof(v->card)); > - sprintf(v->bus_info, "USB"); > + usb_make_path(radio->usbdev, v->bus_info, > sizeof(v->bus_info)); > + printk(KERN_INFO "%s\n", v->bus_info); > v->version = RADIO_VERSION; > v->capabilities = V4L2_CAP_TUNER; > return 0; > > And get such dmesg messages for different usb ports: > > usb-0000:00:1d.2-2 > > usb-0000:00:1d.0-1 > > Looks okay to my eyes or may be i missed something. Anyway it's more > useful than just simple "USB" string. > > Do you get the same string if you unplug and then replug the same device to the same port? If not, I have the same problems than before, otherwise I'll be happy with it. Regards, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2009-01-19 at 03:55 +0100, Carsten Meier wrote: > Am Mon, 19 Jan 2009 05:25:15 +0300 > schrieb Alexey Klimov <klimov.linux@gmail.com>: > > > On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote: > > > On Sat, 17 Jan 2009 19:09:51 +0100 > > > Carsten Meier <cm@trexity.de> wrote: > > > > > > > Am Fri, 16 Jan 2009 02:47:50 -0200 > > > > schrieb Mauro Carvalho Chehab <mchehab@infradead.org>: > > > > > > > > > For usb devices, usb_make_path() provide a canonical name for > > > > > the device. For PCI ones, we have pci_name() for the same > > > > > function. in the case of pci devices, I suspect that all use > > > > > pci_name(). We just need to use usb_make_path() at the usb > > > > > ones. > > > > > > > > I looked at the sources for what string gets generated for > > > > bus_info by usb_make_path(). If it gets used by pvrusb2, my > > > > problems are solved, because it is constant across > > > > standby-wake-up-cycles. The pvrusb2's implementation currently > > > > delivers "usb 7-2 address 6" here. "address 6" corresponds to > > > > devnum which gets constantly increased, which results in always > > > > changing strings here. Sorry for my unneccessary complaints. > > > > > > Mike, Thierry, Jean-Francois, Laurent and others: > > > > > > IMO, we should patch all usb drivers to use usb_make_path(). It > > > will be more transparent to userspace, if all drivers provide the > > > bus_info using the same notation. Comments? > > > > I did this thing to dsbr100.c usb radio driver: > > > > diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c > > --- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34 > > 2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.c Mon Jan > > 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@ > > static int vidioc_querycap(struct file *file, void *priv, > > struct v4l2_capability *v) > > { > > + struct dsbr100_device *radio = video_drvdata(file); > > + > > strlcpy(v->driver, "dsbr100", sizeof(v->driver)); > > strlcpy(v->card, "D-Link R-100 USB FM Radio", > > sizeof(v->card)); > > - sprintf(v->bus_info, "USB"); > > + usb_make_path(radio->usbdev, v->bus_info, > > sizeof(v->bus_info)); > > + printk(KERN_INFO "%s\n", v->bus_info); > > v->version = RADIO_VERSION; > > v->capabilities = V4L2_CAP_TUNER; > > return 0; > > > > And get such dmesg messages for different usb ports: > > > > usb-0000:00:1d.2-2 > > > > usb-0000:00:1d.0-1 > > > > Looks okay to my eyes or may be i missed something. Anyway it's more > > useful than just simple "USB" string. > > > Do you get the same string if you unplug and then replug the same > device to the same port? If not, I have the same problems than before, > otherwise I'll be happy with it. To be sure that i did that you want me to: i plug device in, run application that use it, close application, unplug device, and then plug device in (and i didn't reload the kernel module during this), run app again.. Yes, i have the same string in this case. btw, kernel 2.6.29-rc2.
Am Mon, 19 Jan 2009 06:11:33 +0300 schrieb "Alexey Klimov" <klimov.linux@gmail.com>: > On Mon, Jan 19, 2009 at 6:09 AM, Alexey Klimov > <klimov.linux@gmail.com> wrote: > > On Mon, 2009-01-19 at 03:55 +0100, Carsten Meier wrote: > >> Am Mon, 19 Jan 2009 05:25:15 +0300 > >> schrieb Alexey Klimov <klimov.linux@gmail.com>: > >> > >> > On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote: > >> > > On Sat, 17 Jan 2009 19:09:51 +0100 > >> > > Carsten Meier <cm@trexity.de> wrote: > >> > > > >> > > > Am Fri, 16 Jan 2009 02:47:50 -0200 > >> > > > schrieb Mauro Carvalho Chehab <mchehab@infradead.org>: > >> > > > > >> > > > > For usb devices, usb_make_path() provide a canonical name > >> > > > > for the device. For PCI ones, we have pci_name() for the > >> > > > > same function. in the case of pci devices, I suspect that > >> > > > > all use pci_name(). We just need to use usb_make_path() at > >> > > > > the usb ones. > >> > > > > >> > > > I looked at the sources for what string gets generated for > >> > > > bus_info by usb_make_path(). If it gets used by pvrusb2, my > >> > > > problems are solved, because it is constant across > >> > > > standby-wake-up-cycles. The pvrusb2's implementation > >> > > > currently delivers "usb 7-2 address 6" here. "address 6" > >> > > > corresponds to devnum which gets constantly increased, which > >> > > > results in always changing strings here. Sorry for my > >> > > > unneccessary complaints. > >> > > > >> > > Mike, Thierry, Jean-Francois, Laurent and others: > >> > > > >> > > IMO, we should patch all usb drivers to use usb_make_path(). It > >> > > will be more transparent to userspace, if all drivers provide > >> > > the bus_info using the same notation. Comments? > >> > > >> > I did this thing to dsbr100.c usb radio driver: > >> > > >> > diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c > >> > --- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34 > >> > 2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.c Mon > >> > Jan 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@ > >> > static int vidioc_querycap(struct file *file, void *priv, > >> > struct v4l2_capability *v) > >> > { > >> > + struct dsbr100_device *radio = video_drvdata(file); > >> > + > >> > strlcpy(v->driver, "dsbr100", sizeof(v->driver)); > >> > strlcpy(v->card, "D-Link R-100 USB FM Radio", > >> > sizeof(v->card)); > >> > - sprintf(v->bus_info, "USB"); > >> > + usb_make_path(radio->usbdev, v->bus_info, > >> > sizeof(v->bus_info)); > >> > + printk(KERN_INFO "%s\n", v->bus_info); > >> > v->version = RADIO_VERSION; > >> > v->capabilities = V4L2_CAP_TUNER; > >> > return 0; > >> > > >> > And get such dmesg messages for different usb ports: > >> > > >> > usb-0000:00:1d.2-2 > >> > > >> > usb-0000:00:1d.0-1 > >> > > >> > Looks okay to my eyes or may be i missed something. Anyway it's > >> > more useful than just simple "USB" string. > >> > > >> Do you get the same string if you unplug and then replug the same > >> device to the same port? If not, I have the same problems than > >> before, otherwise I'll be happy with it. > > > > To be sure that i did that you want me to: i plug device in, run > > application that use it, close application, unplug device, and then > > plug device in (and i didn't reload the kernel module during this), > > run app again.. > > > > Yes, i have the same string in this case. btw, kernel 2.6.29-rc2. > > Oh, i forget to tell you that it was the same usb port and the same > usb device. :) > > Yes, that's what I meant. :) Userspace-land would be very happy if usb_make_path() is used by all usb-device-drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Mon, 19 Jan 2009 04:25:54 +0100 schrieb Carsten Meier <cm@trexity.de>: > Am Mon, 19 Jan 2009 06:11:33 +0300 > schrieb "Alexey Klimov" <klimov.linux@gmail.com>: > > > On Mon, Jan 19, 2009 at 6:09 AM, Alexey Klimov > > <klimov.linux@gmail.com> wrote: > > > On Mon, 2009-01-19 at 03:55 +0100, Carsten Meier wrote: > > >> Am Mon, 19 Jan 2009 05:25:15 +0300 > > >> schrieb Alexey Klimov <klimov.linux@gmail.com>: > > >> > > >> > On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote: > > >> > > On Sat, 17 Jan 2009 19:09:51 +0100 > > >> > > Carsten Meier <cm@trexity.de> wrote: > > >> > > > > >> > > > Am Fri, 16 Jan 2009 02:47:50 -0200 > > >> > > > schrieb Mauro Carvalho Chehab <mchehab@infradead.org>: > > >> > > > > > >> > > > > For usb devices, usb_make_path() provide a canonical name > > >> > > > > for the device. For PCI ones, we have pci_name() for the > > >> > > > > same function. in the case of pci devices, I suspect that > > >> > > > > all use pci_name(). We just need to use usb_make_path() > > >> > > > > at the usb ones. > > >> > > > > > >> > > > I looked at the sources for what string gets generated for > > >> > > > bus_info by usb_make_path(). If it gets used by pvrusb2, my > > >> > > > problems are solved, because it is constant across > > >> > > > standby-wake-up-cycles. The pvrusb2's implementation > > >> > > > currently delivers "usb 7-2 address 6" here. "address 6" > > >> > > > corresponds to devnum which gets constantly increased, > > >> > > > which results in always changing strings here. Sorry for my > > >> > > > unneccessary complaints. > > >> > > > > >> > > Mike, Thierry, Jean-Francois, Laurent and others: > > >> > > > > >> > > IMO, we should patch all usb drivers to use usb_make_path(). > > >> > > It will be more transparent to userspace, if all drivers > > >> > > provide the bus_info using the same notation. Comments? > > >> > > > >> > I did this thing to dsbr100.c usb radio driver: > > >> > > > >> > diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c > > >> > --- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34 > > >> > 2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.c Mon > > >> > Jan 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@ > > >> > static int vidioc_querycap(struct file *file, void *priv, > > >> > struct v4l2_capability *v) > > >> > { > > >> > + struct dsbr100_device *radio = video_drvdata(file); > > >> > + > > >> > strlcpy(v->driver, "dsbr100", sizeof(v->driver)); > > >> > strlcpy(v->card, "D-Link R-100 USB FM Radio", > > >> > sizeof(v->card)); > > >> > - sprintf(v->bus_info, "USB"); > > >> > + usb_make_path(radio->usbdev, v->bus_info, > > >> > sizeof(v->bus_info)); > > >> > + printk(KERN_INFO "%s\n", v->bus_info); > > >> > v->version = RADIO_VERSION; > > >> > v->capabilities = V4L2_CAP_TUNER; > > >> > return 0; > > >> > > > >> > And get such dmesg messages for different usb ports: > > >> > > > >> > usb-0000:00:1d.2-2 > > >> > > > >> > usb-0000:00:1d.0-1 > > >> > > > >> > Looks okay to my eyes or may be i missed something. Anyway it's > > >> > more useful than just simple "USB" string. > > >> > > > >> Do you get the same string if you unplug and then replug the same > > >> device to the same port? If not, I have the same problems than > > >> before, otherwise I'll be happy with it. > > > > > > To be sure that i did that you want me to: i plug device in, run > > > application that use it, close application, unplug device, and > > > then plug device in (and i didn't reload the kernel module during > > > this), run app again.. > > > > > > Yes, i have the same string in this case. btw, kernel 2.6.29-rc2. > > > > Oh, i forget to tell you that it was the same usb port and the same > > usb device. :) > > > > > Yes, that's what I meant. :) Userspace-land would be very happy if > usb_make_path() is used by all usb-device-drivers. Hi, now I want to translate bus_info into a sysfs-path to obtain device-info like serial numbers. Given a device reports "usb-0000:00:1d.2-2" as bus_info, then the device-info is located under "/sys/bus/usb/devices/2-2", which is a symlink to the appropriate /sys/devices/ directory, right? All I have to do is to compare the first 4 chars of bus_info against "usb-", get the chars after "." and append it to "/sys/bus/usb/devices/" to obatin a sysfs-path, right? Is there a more elegant solution or already a function for this? Can the "." appear more than once before the last one? Thaks, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Carsten, On Wednesday 21 January 2009, Carsten Meier wrote: > > now I want to translate bus_info into a sysfs-path to obtain > device-info like serial numbers. Given a device reports > "usb-0000:00:1d.2-2" as bus_info, then the device-info is located > under "/sys/bus/usb/devices/2-2", which is a symlink to the > appropriate /sys/devices/ directory, right? I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the PCI bus path of your USB controller, and the last digit after the dash is the USB device path. > All I have to do is to compare the first 4 chars of bus_info against > "usb-", get the chars after "." and append it to > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > Is there a more elegant solution or already a function for this? Can > the "." appear more than once before the last one? Probably not before, but definitely after. Root hubs get a USB device path set to '0'. Every other device is numbered according to the hub port number it is connected to. If you have an external hub connected on port 2 of your root hub, and have a webcam connected to port 3 of the external hub, usb_make_path() will return "usb-0000:00:1d.2-2.3". Cheers, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Thu, 22 Jan 2009 00:20:00 +0100 schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > Hi Carsten, > > On Wednesday 21 January 2009, Carsten Meier wrote: > > > > now I want to translate bus_info into a sysfs-path to obtain > > device-info like serial numbers. Given a device reports > > "usb-0000:00:1d.2-2" as bus_info, then the device-info is located > > under "/sys/bus/usb/devices/2-2", which is a symlink to the > > appropriate /sys/devices/ directory, right? > > I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the PCI > bus path of your USB controller, and the last digit after the dash is > the USB device path. > > > All I have to do is to compare the first 4 chars of bus_info against > > "usb-", get the chars after "." and append it to > > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > > > Is there a more elegant solution or already a function for this? Can > > the "." appear more than once before the last one? > > Probably not before, but definitely after. > > Root hubs get a USB device path set to '0'. Every other device is > numbered according to the hub port number it is connected to. If you > have an external hub connected on port 2 of your root hub, and have a > webcam connected to port 3 of the external hub, usb_make_path() will > return "usb-0000:00:1d.2-2.3". > > Cheers, > > Laurent Pinchart Hi, On my machine, my pvrusb2 (connected directly to my mini-pc) shows up under "/sys/bus/usb/devices/7-2/" which is a symbolic link to "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" I can't test for the new bus_info-string, because it's not fixed yet in the driver. But if I got it correctly it should be "usb-0000:00:1d.7-7.2" ? Then I've to simply take the string after the last dash, replace "." by "-" and append it to "/sys/bus/usb/devices/" for a sysfs-path? Regards, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 22 January 2009, Carsten Meier wrote: > Am Thu, 22 Jan 2009 00:20:00 +0100 > > schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > > Hi Carsten, > > > > On Wednesday 21 January 2009, Carsten Meier wrote: > > > now I want to translate bus_info into a sysfs-path to obtain > > > device-info like serial numbers. Given a device reports > > > "usb-0000:00:1d.2-2" as bus_info, then the device-info is located > > > under "/sys/bus/usb/devices/2-2", which is a symlink to the > > > appropriate /sys/devices/ directory, right? > > > > I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the PCI > > bus path of your USB controller, and the last digit after the dash is > > the USB device path. > > > > > All I have to do is to compare the first 4 chars of bus_info against > > > "usb-", get the chars after "." and append it to > > > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > > > > > Is there a more elegant solution or already a function for this? Can > > > the "." appear more than once before the last one? > > > > Probably not before, but definitely after. > > > > Root hubs get a USB device path set to '0'. Every other device is > > numbered according to the hub port number it is connected to. If you > > have an external hub connected on port 2 of your root hub, and have a > > webcam connected to port 3 of the external hub, usb_make_path() will > > return "usb-0000:00:1d.2-2.3". > > > > Cheers, > > > > Laurent Pinchart > > Hi, > > On my machine, my pvrusb2 (connected directly to my mini-pc) shows up > under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of your USB host controller (1d.7). Here's an example of what I get on my computer: /sys/bus/usb/devices/4-2 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-2 > I can't test for the new bus_info-string, because it's not fixed yet in > the driver. But if I got it correctly it should be > "usb-0000:00:1d.7-7.2" ? I think you will get usb-0000:00:1d.7-2 > Then I've to simply take the string after the last dash, replace "." by "-" > and append it to "/sys/bus/usb/devices/" for a sysfs-path? Unfortunately the mapping is not that direct. The part before the last dash identifies the USB host controller. The part after the last dash identifies the device path related to the controller, expressed as a combination of port numbers. The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in this case 7) that is not present in usb_make_path()'s output. To find the sysfs path of your USB peripheral, you will have to find out which bus number the bus name (0000:00:1d.7) corresponds to. You might be able to find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and comparing the link's target with the bus name. Best regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Thu, 22 Jan 2009 16:57:36 +0100 schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > On Thursday 22 January 2009, Carsten Meier wrote: > > Am Thu, 22 Jan 2009 00:20:00 +0100 > > > > schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > > > Hi Carsten, > > > > > > On Wednesday 21 January 2009, Carsten Meier wrote: > > > > now I want to translate bus_info into a sysfs-path to obtain > > > > device-info like serial numbers. Given a device reports > > > > "usb-0000:00:1d.2-2" as bus_info, then the device-info is > > > > located under "/sys/bus/usb/devices/2-2", which is a symlink to > > > > the appropriate /sys/devices/ directory, right? > > > > > > I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the > > > PCI bus path of your USB controller, and the last digit after the > > > dash is the USB device path. > > > > > > > All I have to do is to compare the first 4 chars of bus_info > > > > against "usb-", get the chars after "." and append it to > > > > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > > > > > > > Is there a more elegant solution or already a function for > > > > this? Can the "." appear more than once before the last one? > > > > > > Probably not before, but definitely after. > > > > > > Root hubs get a USB device path set to '0'. Every other device is > > > numbered according to the hub port number it is connected to. If > > > you have an external hub connected on port 2 of your root hub, > > > and have a webcam connected to port 3 of the external hub, > > > usb_make_path() will return "usb-0000:00:1d.2-2.3". > > > > > > Cheers, > > > > > > Laurent Pinchart > > > > Hi, > > > > On my machine, my pvrusb2 (connected directly to my mini-pc) shows > > up under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > > "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th > function of your USB host controller (1d.7). > > Here's an example of what I get on my computer: > > /sys/bus/usb/devices/4-2 > -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-2 > > > I can't test for the new bus_info-string, because it's not fixed > > yet in the driver. But if I got it correctly it should be > > "usb-0000:00:1d.7-7.2" ? > > I think you will get usb-0000:00:1d.7-2 > > > Then I've to simply take the string after the last dash, replace > > "." by "-" and append it to "/sys/bus/usb/devices/" for a > > sysfs-path? > > Unfortunately the mapping is not that direct. The part before the > last dash identifies the USB host controller. The part after the last > dash identifies the device path related to the controller, expressed > as a combination of port numbers. > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus > number (in this case 7) that is not present in usb_make_path()'s > output. > > To find the sysfs path of your USB peripheral, you will have to find > out which bus number the bus name (0000:00:1d.7) corresponds to. You > might be able to find that by checking each usb[0-9]+ links > in /sys/bus/usb/devices and comparing the link's target with the bus > name. > > Best regards, > > Laurent Pinchart Hi Laurent, could you please post what your video-device reports for bus_info together with the /sys/bus/usb-path where it shows up and the location where the symlink points to? This thing makes me going nuts... :( Thanks, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Laurent Pinchart a écrit : > On Thursday 22 January 2009, Carsten Meier wrote: >> Am Thu, 22 Jan 2009 00:20:00 +0100 >> >> schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: >>> Hi Carsten, >>> >>> On Wednesday 21 January 2009, Carsten Meier wrote: >>>> now I want to translate bus_info into a sysfs-path to obtain >>>> device-info like serial numbers. Given a device reports >>>> "usb-0000:00:1d.2-2" as bus_info, then the device-info is located >>>> under "/sys/bus/usb/devices/2-2", which is a symlink to the >>>> appropriate /sys/devices/ directory, right? >>> I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the PCI >>> bus path of your USB controller, and the last digit after the dash is >>> the USB device path. >>> >>>> All I have to do is to compare the first 4 chars of bus_info against >>>> "usb-", get the chars after "." and append it to >>>> "/sys/bus/usb/devices/" to obatin a sysfs-path, right? >>>> >>>> Is there a more elegant solution or already a function for this? Can >>>> the "." appear more than once before the last one? >>> Probably not before, but definitely after. >>> >>> Root hubs get a USB device path set to '0'. Every other device is >>> numbered according to the hub port number it is connected to. If you >>> have an external hub connected on port 2 of your root hub, and have a >>> webcam connected to port 3 of the external hub, usb_make_path() will >>> return "usb-0000:00:1d.2-2.3". >>> >>> Cheers, >>> >>> Laurent Pinchart >> Hi, >> >> On my machine, my pvrusb2 (connected directly to my mini-pc) shows up >> under "/sys/bus/usb/devices/7-2/" which is a symbolic link to >> "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of > your USB host controller (1d.7). > > Here's an example of what I get on my computer: > > /sys/bus/usb/devices/4-2 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-2 > >> I can't test for the new bus_info-string, because it's not fixed yet in >> the driver. But if I got it correctly it should be >> "usb-0000:00:1d.7-7.2" ? > > I think you will get usb-0000:00:1d.7-2 > >> Then I've to simply take the string after the last dash, replace "." by "-" >> and append it to "/sys/bus/usb/devices/" for a sysfs-path? > > Unfortunately the mapping is not that direct. The part before the last dash > identifies the USB host controller. The part after the last dash identifies > the device path related to the controller, expressed as a combination of port > numbers. > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in > this case 7) that is not present in usb_make_path()'s output. > > To find the sysfs path of your USB peripheral, you will have to find out which > bus number the bus name (0000:00:1d.7) corresponds to. You might be able to > find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and > comparing the link's target with the bus name. > To ease this processing, using libsysfs can be a good idea... On my system, the documentation of libsysfs is here: /usr/doc/sysfsutils-2.1.0/libsysfs.txt Knowing the bus-id, it won't be hard to look at it in data structures. Just my 2 cents. Regard, Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Thu, 22 Jan 2009 16:57:36 +0100 schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > On Thursday 22 January 2009, Carsten Meier wrote: > > Am Thu, 22 Jan 2009 00:20:00 +0100 > > > > schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > > > Hi Carsten, > > > > > > On Wednesday 21 January 2009, Carsten Meier wrote: > > > > now I want to translate bus_info into a sysfs-path to obtain > > > > device-info like serial numbers. Given a device reports > > > > "usb-0000:00:1d.2-2" as bus_info, then the device-info is > > > > located under "/sys/bus/usb/devices/2-2", which is a symlink to > > > > the appropriate /sys/devices/ directory, right? > > > > > > I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the > > > PCI bus path of your USB controller, and the last digit after the > > > dash is the USB device path. > > > > > > > All I have to do is to compare the first 4 chars of bus_info > > > > against "usb-", get the chars after "." and append it to > > > > "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > > > > > > > Is there a more elegant solution or already a function for > > > > this? Can the "." appear more than once before the last one? > > > > > > Probably not before, but definitely after. > > > > > > Root hubs get a USB device path set to '0'. Every other device is > > > numbered according to the hub port number it is connected to. If > > > you have an external hub connected on port 2 of your root hub, > > > and have a webcam connected to port 3 of the external hub, > > > usb_make_path() will return "usb-0000:00:1d.2-2.3". > > > > > > Cheers, > > > > > > Laurent Pinchart > > > > Hi, > > > > On my machine, my pvrusb2 (connected directly to my mini-pc) shows > > up under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > > "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th > function of your USB host controller (1d.7). > > Here's an example of what I get on my computer: > > /sys/bus/usb/devices/4-2 > -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-2 > > > I can't test for the new bus_info-string, because it's not fixed > > yet in the driver. But if I got it correctly it should be > > "usb-0000:00:1d.7-7.2" ? > > I think you will get usb-0000:00:1d.7-2 > > > Then I've to simply take the string after the last dash, replace > > "." by "-" and append it to "/sys/bus/usb/devices/" for a > > sysfs-path? > > Unfortunately the mapping is not that direct. The part before the > last dash identifies the USB host controller. The part after the last > dash identifies the device path related to the controller, expressed > as a combination of port numbers. > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus > number (in this case 7) that is not present in usb_make_path()'s > output. > > To find the sysfs path of your USB peripheral, you will have to find > out which bus number the bus name (0000:00:1d.7) corresponds to. You > might be able to find that by checking each usb[0-9]+ links > in /sys/bus/usb/devices and comparing the link's target with the bus > name. > > Best regards, > > Laurent Pinchart Hi, I'll scan the link-targets of /sys/bus/usb/devices/usb[0-9] and compare them against the bus name. Now I've the problem of extracting the right path component of the link-target to compare with. E.g. /sys/bus/usb/devices/usb7 points to ../../../devices/pci0000:00/0000:00:1d.7/usb7 . My plan is to check the bus name against the component before last and then extract the bus num from the last component's digit. Now again a question: Does this always work or is there probably another parent directory for usb7 in the global devices-directory? Thanks again... Regards, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Thu, 22 Jan 2009 22:12:08 +0100 schrieb Thierry Merle <thierry.merle@free.fr>: > Laurent Pinchart a écrit : > > On Thursday 22 January 2009, Carsten Meier wrote: > >> Am Thu, 22 Jan 2009 00:20:00 +0100 > >> > >> schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > >>> Hi Carsten, > >>> > >>> On Wednesday 21 January 2009, Carsten Meier wrote: > >>>> now I want to translate bus_info into a sysfs-path to obtain > >>>> device-info like serial numbers. Given a device reports > >>>> "usb-0000:00:1d.2-2" as bus_info, then the device-info is located > >>>> under "/sys/bus/usb/devices/2-2", which is a symlink to the > >>>> appropriate /sys/devices/ directory, right? > >>> I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the > >>> PCI bus path of your USB controller, and the last digit after the > >>> dash is the USB device path. > >>> > >>>> All I have to do is to compare the first 4 chars of bus_info > >>>> against "usb-", get the chars after "." and append it to > >>>> "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > >>>> > >>>> Is there a more elegant solution or already a function for this? > >>>> Can the "." appear more than once before the last one? > >>> Probably not before, but definitely after. > >>> > >>> Root hubs get a USB device path set to '0'. Every other device is > >>> numbered according to the hub port number it is connected to. If > >>> you have an external hub connected on port 2 of your root hub, > >>> and have a webcam connected to port 3 of the external hub, > >>> usb_make_path() will return "usb-0000:00:1d.2-2.3". > >>> > >>> Cheers, > >>> > >>> Laurent Pinchart > >> Hi, > >> > >> On my machine, my pvrusb2 (connected directly to my mini-pc) shows > >> up under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > >> "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" > > > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th > > function of your USB host controller (1d.7). > > > > Here's an example of what I get on my computer: > > > > /sys/bus/usb/devices/4-2 > > -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-2 > > > >> I can't test for the new bus_info-string, because it's not fixed > >> yet in the driver. But if I got it correctly it should be > >> "usb-0000:00:1d.7-7.2" ? > > > > I think you will get usb-0000:00:1d.7-2 > > > >> Then I've to simply take the string after the last dash, replace > >> "." by "-" and append it to "/sys/bus/usb/devices/" for a > >> sysfs-path? > > > > Unfortunately the mapping is not that direct. The part before the > > last dash identifies the USB host controller. The part after the > > last dash identifies the device path related to the controller, > > expressed as a combination of port numbers. > > > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus > > number (in this case 7) that is not present in usb_make_path()'s > > output. > > > > To find the sysfs path of your USB peripheral, you will have to > > find out which bus number the bus name (0000:00:1d.7) corresponds > > to. You might be able to find that by checking each usb[0-9]+ links > > in /sys/bus/usb/devices and comparing the link's target with the > > bus name. > > > To ease this processing, using libsysfs can be a good idea... > On my system, the documentation of libsysfs is here: > /usr/doc/sysfsutils-2.1.0/libsysfs.txt > Knowing the bus-id, it won't be hard to look at it in data structures. > Just my 2 cents. Hi, I already looked at it, but it doesn't help very much if you don't know how sysfs is organized in detail. The sysfs-reference at http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/ also doesn't help very much as it only gives a brief overview. Regards, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 22 Jan 2009 22:12:08 +0100 Thierry Merle <thierry.merle@free.fr> wrote: > Laurent Pinchart a écrit : > > On Thursday 22 January 2009, Carsten Meier wrote: > >> Am Thu, 22 Jan 2009 00:20:00 +0100 > >> > >> schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > >>> Hi Carsten, > >>> > >>> On Wednesday 21 January 2009, Carsten Meier wrote: > >>>> now I want to translate bus_info into a sysfs-path to obtain > >>>> device-info like serial numbers. Given a device reports > >>>> "usb-0000:00:1d.2-2" as bus_info, then the device-info is located > >>>> under "/sys/bus/usb/devices/2-2", which is a symlink to the > >>>> appropriate /sys/devices/ directory, right? > >>> I'm afraid not. In the above bus_info value, 0000:00:1d.2 is the PCI > >>> bus path of your USB controller, and the last digit after the dash is > >>> the USB device path. > >>> > >>>> All I have to do is to compare the first 4 chars of bus_info against > >>>> "usb-", get the chars after "." and append it to > >>>> "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > >>>> > >>>> Is there a more elegant solution or already a function for this? Can > >>>> the "." appear more than once before the last one? > >>> Probably not before, but definitely after. > >>> > >>> Root hubs get a USB device path set to '0'. Every other device is > >>> numbered according to the hub port number it is connected to. If you > >>> have an external hub connected on port 2 of your root hub, and have a > >>> webcam connected to port 3 of the external hub, usb_make_path() will > >>> return "usb-0000:00:1d.2-2.3". > >>> > >>> Cheers, > >>> > >>> Laurent Pinchart > >> Hi, > >> > >> On my machine, my pvrusb2 (connected directly to my mini-pc) shows up > >> under "/sys/bus/usb/devices/7-2/" which is a symbolic link to > >> "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" > > > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of > > your USB host controller (1d.7). > > > > Here's an example of what I get on my computer: > > > > /sys/bus/usb/devices/4-2 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-2 > > > >> I can't test for the new bus_info-string, because it's not fixed yet in > >> the driver. But if I got it correctly it should be > >> "usb-0000:00:1d.7-7.2" ? > > > > I think you will get usb-0000:00:1d.7-2 > > > >> Then I've to simply take the string after the last dash, replace "." by "-" > >> and append it to "/sys/bus/usb/devices/" for a sysfs-path? > > > > Unfortunately the mapping is not that direct. The part before the last dash > > identifies the USB host controller. The part after the last dash identifies > > the device path related to the controller, expressed as a combination of port > > numbers. > > > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in > > this case 7) that is not present in usb_make_path()'s output. > > > > To find the sysfs path of your USB peripheral, you will have to find out which > > bus number the bus name (0000:00:1d.7) corresponds to. You might be able to > > find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and > > comparing the link's target with the bus name. > > > To ease this processing, using libsysfs can be a good idea... > On my system, the documentation of libsysfs is here: > /usr/doc/sysfsutils-2.1.0/libsysfs.txt > Knowing the bus-id, it won't be hard to look at it in data structures. > Just my 2 cents. Hi Thierry, It may be a good idea to add some code at the v4l2-apps dir for retrieving the sysfs place. Maybe we may add it at qv4l2 and at v4l2-ctl. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Tue, 27 Jan 2009 10:56:35 -0200 schrieb Mauro Carvalho Chehab <mchehab@infradead.org>: > On Thu, 22 Jan 2009 22:12:08 +0100 > Thierry Merle <thierry.merle@free.fr> wrote: > > > Laurent Pinchart a écrit : > > > On Thursday 22 January 2009, Carsten Meier wrote: > > >> Am Thu, 22 Jan 2009 00:20:00 +0100 > > >> > > >> schrieb Laurent Pinchart <laurent.pinchart@skynet.be>: > > >>> Hi Carsten, > > >>> > > >>> On Wednesday 21 January 2009, Carsten Meier wrote: > > >>>> now I want to translate bus_info into a sysfs-path to obtain > > >>>> device-info like serial numbers. Given a device reports > > >>>> "usb-0000:00:1d.2-2" as bus_info, then the device-info is > > >>>> located under "/sys/bus/usb/devices/2-2", which is a symlink > > >>>> to the appropriate /sys/devices/ directory, right? > > >>> I'm afraid not. In the above bus_info value, 0000:00:1d.2 is > > >>> the PCI bus path of your USB controller, and the last digit > > >>> after the dash is the USB device path. > > >>> > > >>>> All I have to do is to compare the first 4 chars of bus_info > > >>>> against "usb-", get the chars after "." and append it to > > >>>> "/sys/bus/usb/devices/" to obatin a sysfs-path, right? > > >>>> > > >>>> Is there a more elegant solution or already a function for > > >>>> this? Can the "." appear more than once before the last one? > > >>> Probably not before, but definitely after. > > >>> > > >>> Root hubs get a USB device path set to '0'. Every other device > > >>> is numbered according to the hub port number it is connected > > >>> to. If you have an external hub connected on port 2 of your > > >>> root hub, and have a webcam connected to port 3 of the external > > >>> hub, usb_make_path() will return "usb-0000:00:1d.2-2.3". > > >>> > > >>> Cheers, > > >>> > > >>> Laurent Pinchart > > >> Hi, > > >> > > >> On my machine, my pvrusb2 (connected directly to my mini-pc) > > >> shows up under "/sys/bus/usb/devices/7-2/" which is a symbolic > > >> link to "../../../devices/pci0000:00/0000:00:1d.7/usb7/7-2" > > > > > > You're just lucky that USB bus 7 (usb7/7) is connected to the 7th > > > function of your USB host controller (1d.7). > > > > > > Here's an example of what I get on my computer: > > > > > > /sys/bus/usb/devices/4-2 > > > -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-2 > > > > > >> I can't test for the new bus_info-string, because it's not fixed > > >> yet in the driver. But if I got it correctly it should be > > >> "usb-0000:00:1d.7-7.2" ? > > > > > > I think you will get usb-0000:00:1d.7-2 > > > > > >> Then I've to simply take the string after the last dash, replace > > >> "." by "-" and append it to "/sys/bus/usb/devices/" for a > > >> sysfs-path? > > > > > > Unfortunately the mapping is not that direct. The part before the > > > last dash identifies the USB host controller. The part after the > > > last dash identifies the device path related to the controller, > > > expressed as a combination of port numbers. > > > > > > The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB > > > bus number (in this case 7) that is not present in > > > usb_make_path()'s output. > > > > > > To find the sysfs path of your USB peripheral, you will have to > > > find out which bus number the bus name (0000:00:1d.7) corresponds > > > to. You might be able to find that by checking each usb[0-9]+ > > > links in /sys/bus/usb/devices and comparing the link's target > > > with the bus name. > > > > > To ease this processing, using libsysfs can be a good idea... > > On my system, the documentation of libsysfs is here: > > /usr/doc/sysfsutils-2.1.0/libsysfs.txt > > Knowing the bus-id, it won't be hard to look at it in data > > structures. Just my 2 cents. > > Hi Thierry, > > It may be a good idea to add some code at the v4l2-apps dir for > retrieving the sysfs place. Maybe we may add it at qv4l2 and at > v4l2-ctl. > > Cheers, > Mauro Hi, here is code which I've written for it. It is in C++ with Boost, but adaption to C shouldn't be hard. It's not extensively tested and put into the public domain. #include <stdexcept> #include <string> #include <boost/lexical_cast.hpp> #include <cstdio> extern "C" { #include <sysfs/libsysfs.h> } bool obtain_usb_sysfs_path( const char *busname, const char *usbpath, string &sysfspath_out) { bool rc = false; ::sysfs_device *usbctl = NULL; ::sysfs_bus *usb = NULL; try { // open usb host controller usbctl = ::sysfs_open_device("pci", busname); if(!usbctl) throw runtime_error( "Unable to open usb host controller"); // find matching usb bus usb = ::sysfs_open_bus("usb"); if(!usb) throw runtime_error("Unable to open usb"); ::dlist *usbdevs = ::sysfs_get_bus_devices(usb); if(!usbdevs) throw runtime_error("Unable to get usb devices"); ::sysfs_device *usbdev = NULL; dlist_for_each_data( usbdevs, usbdev, struct sysfs_device) { // compare pathes of usb host controller and // parent of enumerated usb devices ::sysfs_device *pdev = ::sysfs_get_device_parent(usbdev); if(!pdev) continue; if(strcmp(usbctl->path, pdev->path) == 0) break; } ::sysfs_close_device(usbctl); usbctl = NULL; // assemble usb device path if(usbdev) { ::sysfs_attribute *busnumattr = ::sysfs_get_device_attr(usbdev, "busnum"); if(!busnumattr) throw runtime_error( "Unable to get usb bus number"); string str(busnumattr->value, busnumattr->len); unsigned int busnum; if(sscanf(str.c_str(), "%u", &busnum) != 1) throw runtime_error( "Unable to parse usb bus number"); sysfspath_out = usbdev->path; sysfspath_out += '/'; sysfspath_out += lexical_cast<string>(busnum); sysfspath_out += '-'; sysfspath_out += usbpath; rc = true; } ::sysfs_close_bus(usb); usb = NULL; } catch(...) { if(usb) ::sysfs_close_bus(usb); if(usbctl) ::sysfs_close_device(usbctl); throw; } return rc; } Maybe it is of use for one or another. Cheers, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Carsten, On Tue, 27 Jan 2009 14:56:26 +0100 Carsten Meier <cm@trexity.de> wrote: > > Hi Thierry, > > > > It may be a good idea to add some code at the v4l2-apps dir for > > retrieving the sysfs place. Maybe we may add it at qv4l2 and at > > v4l2-ctl. > > > > Cheers, > > Mauro > > Hi, > > here is code which I've written for it. It is in C++ with Boost, but > adaption to C shouldn't be hard. It's not extensively tested and put > into the public domain. Thank you for your code. I've converted it to C, and improved it to work also with PCI and PCIe devices. I've made it available at: http://linuxtv.org/hg/v4l-dvb/rev/6e636c8969e8 (and two subsequent patches improving it a little bit) > Maybe it is of use for one or another. For now, it is a separate small application. This makes easy for scripts to use it. It will output both the "raw" data returned by VIDIOC_QUERYCAP and their sysfs path: For a USB device: device = /dev/video0 bus info = usb-0000:00:1d.7-1 sysfs path = /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1 For a PCI device: device = /dev/video0 bus info = PCI:0000:01:02.0 sysfs path = /sys/devices/pci0000:00/0000:00:1e.0/0000:01:02.0 It works even with devices with internal PCI bridges, like this one: device = /dev/video4 bus info = PCI:0000:02:0f.0 sysfs path = /sys/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/0000:02:0f.0 device = /dev/video3 bus info = PCI:0000:02:0e.0 sysfs path = /sys/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/0000:02:0e.0 device = /dev/video2 bus info = PCI:0000:02:0d.0 sysfs path = /sys/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/0000:02:0d.0 device = /dev/video1 bus info = PCI:0000:02:0c.0 sysfs path = /sys/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/0000:02:0c.0 I tested here with bttv (a board with 4 bttv chips), saa7134, uvcvideo and em28xx. It should work fine also with other devices. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c --- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34 2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.c Mon Jan 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@ static int vidioc_querycap(struct file *file, void *priv, struct v4l2_capability *v) { + struct dsbr100_device *radio = video_drvdata(file); + strlcpy(v->driver, "dsbr100", sizeof(v->driver)); strlcpy(v->card, "D-Link R-100 USB FM Radio", sizeof(v->card)); - sprintf(v->bus_info, "USB"); + usb_make_path(radio->usbdev, v->bus_info, sizeof(v->bus_info)); + printk(KERN_INFO "%s\n", v->bus_info); v->version = RADIO_VERSION; v->capabilities = V4L2_CAP_TUNER; return 0;