Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Mon, 19 Jan 2009 04:25:54 +0100
schrieb Carsten Meier <cm@xxxxxxxxxx>:

> Am Mon, 19 Jan 2009 06:11:33 +0300
> schrieb "Alexey Klimov" <klimov.linux@xxxxxxxxx>:
> 
> > On Mon, Jan 19, 2009 at 6:09 AM, Alexey Klimov
> > <klimov.linux@xxxxxxxxx> 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@xxxxxxxxx>:
> > >>
> > >> > 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@xxxxxxxxxx> wrote:
> > >> > >
> > >> > > > Am Fri, 16 Jan 2009 02:47:50 -0200
> > >> > > > schrieb Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx>:
> > >> > > >
> > >> > > > > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux