Am Mon, 19 Jan 2009 06:11:33 +0300 schrieb "Alexey Klimov" <klimov.li...@gmail.com>:
> On Mon, Jan 19, 2009 at 6:09 AM, Alexey Klimov > <klimov.li...@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.li...@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 <c...@trexity.de> wrote: > >> > > > >> > > > Am Fri, 16 Jan 2009 02:47:50 -0200 > >> > > > schrieb Mauro Carvalho Chehab <mche...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html