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
