during make modules_install:
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.5.2-dj4; fi
depmod: *** Unresolved symbols in
/lib/modules/2.5.2-dj4/kernel/drivers/net/sis900.o
depmod: crc32_be_Rb7b61546
depmod: *** Unresolved symbols in
/lib/modules/2.5.2-dj4/kernel/drivers/usb/hid.o
depmod: usb_make_path
depmod: *** Unresolved symbols in
/lib/modules/2.5.2-dj4/kernel/drivers/usb/usbkbd.o
depmod: usb_make_path
depmod: *** Unresolved symbols in
/lib/modules/2.5.2-dj4/kernel/drivers/usb/usbmouse.o
depmod: usb_make_path
make: *** [_modinst_post] Error 1
My .config is attached.
Torrey
On Tue, Jan 22, 2002 at 04:12:30PM -0800, Torrey Hoffman wrote:
>
> depmod: *** Unresolved symbols in
> /lib/modules/2.5.2-dj4/kernel/drivers/usb/hid.o
> depmod: usb_make_path
> depmod: *** Unresolved symbols in
> /lib/modules/2.5.2-dj4/kernel/drivers/usb/usbkbd.o
> depmod: usb_make_path
> depmod: *** Unresolved symbols in
> /lib/modules/2.5.2-dj4/kernel/drivers/usb/usbmouse.o
> depmod: usb_make_path
> make: *** [_modinst_post] Error 1
Looks like you need to add a:
EXPORT_SYMBOL(usb_make_path);
to the usb.c file.
Vojtech, is this a USB function that you want added to usb.c?
Didn't you (or someone else) propose a function like this in the past?
thanks,
greg k-h
On Tue, Jan 22, 2002 at 08:54:05PM -0800, Greg KH wrote:
> On Tue, Jan 22, 2002 at 04:12:30PM -0800, Torrey Hoffman wrote:
> >
> > depmod: *** Unresolved symbols in
> > /lib/modules/2.5.2-dj4/kernel/drivers/usb/hid.o
> > depmod: usb_make_path
> > depmod: *** Unresolved symbols in
> > /lib/modules/2.5.2-dj4/kernel/drivers/usb/usbkbd.o
> > depmod: usb_make_path
> > depmod: *** Unresolved symbols in
> > /lib/modules/2.5.2-dj4/kernel/drivers/usb/usbmouse.o
> > depmod: usb_make_path
> > make: *** [_modinst_post] Error 1
>
> Looks like you need to add a:
> EXPORT_SYMBOL(usb_make_path);
> to the usb.c file.
Correct.
> Vojtech, is this a USB function that you want added to usb.c?
Yes, please. This will change later when Pat Mochels devicefs kicks in,
but for the time being, it'd be very useful.
> Didn't you (or someone else) propose a function like this in the past?
I'm not sure, I may have proposed it. I'm not sure of the outcome
either. The input subsystem needs to use the bus topology for matching
the devices - there is no other way to differentiate between two
identical USB mice.
Do you think it could be added?
--
Vojtech Pavlik
SuSE Labs
On Wed, Jan 23, 2002 at 09:44:14AM +0100, Vojtech Pavlik wrote:
> On Tue, Jan 22, 2002 at 08:54:05PM -0800, Greg KH wrote:
> > Vojtech, is this a USB function that you want added to usb.c?
>
> Yes, please. This will change later when Pat Mochels devicefs kicks in,
> but for the time being, it'd be very useful.
Here's a patch against 2.5.3-pre3, does it look ok to you (I fixed the
potential memory leak in the second kmalloc call from what was in
2.5.2-dj4)?
greg k-h
diff -Nru a/drivers/usb/usb.c b/drivers/usb/usb.c
--- a/drivers/usb/usb.c Wed Jan 23 13:20:28 2002
+++ b/drivers/usb/usb.c Wed Jan 23 13:20:28 2002
@@ -2513,6 +2513,49 @@
return err;
}
+/**
+ * usb_make_path - returns device path in the hub tree
+ * @dev: the device whose path is being constructed
+ * @buf: where to put the string
+ * @size: how big is "buf"?
+ *
+ * Returns length of the string (>= 0) or out of memory status (< 0).
+ */
+int usb_make_path(struct usb_device *dev, char *buf, size_t size)
+{
+ struct usb_device *pdev = dev->parent;
+ char *tmp;
+ char *port;
+ int i;
+
+ if (!(port = kmalloc(size, GFP_KERNEL)))
+ return -ENOMEM;
+ if (!(tmp = kmalloc(size, GFP_KERNEL))) {
+ kfree(port);
+ return -ENOMEM;
+ }
+
+ *port = 0;
+
+ while (pdev) {
+ for (i = 0; i < pdev->maxchild; i++)
+ if (pdev->children[i] == dev)
+ break;
+
+ if (pdev->children[i] != dev)
+ return -1;
+
+ strcpy(tmp, port);
+ snprintf(port, size, strlen(port) ? "%d.%s" : "%d", i + 1, tmp);
+
+ dev = pdev;
+ pdev = dev->parent;
+ }
+
+ snprintf(buf, size, "usb%d:%s", dev->bus->busnum, port);
+ return strlen(buf);
+}
+
/*
* By the time we get here, the device has gotten a new device ID
* and is in the default state. We need to identify the thing and
@@ -2762,5 +2805,6 @@
EXPORT_SYMBOL(usb_set_configuration);
EXPORT_SYMBOL(usb_set_interface);
+EXPORT_SYMBOL(usb_make_path);
EXPORT_SYMBOL(usb_devfs_handle);
MODULE_LICENSE("GPL");
diff -Nru a/include/linux/usb.h b/include/linux/usb.h
--- a/include/linux/usb.h Wed Jan 23 13:20:28 2002
+++ b/include/linux/usb.h Wed Jan 23 13:20:28 2002
@@ -881,6 +881,7 @@
char *buf, size_t size);
extern int usb_set_configuration(struct usb_device *dev, int configuration);
extern int usb_set_interface(struct usb_device *dev, int ifnum, int alternate);
+extern int usb_make_path(struct usb_device *dev, char *buf, size_t size);
/*
* timeouts, in seconds, used for sending/receiving control messages
On Wed, Jan 23, 2002 at 01:24:36PM -0800, Greg KH wrote:
> On Wed, Jan 23, 2002 at 09:44:14AM +0100, Vojtech Pavlik wrote:
> > On Tue, Jan 22, 2002 at 08:54:05PM -0800, Greg KH wrote:
> > > Vojtech, is this a USB function that you want added to usb.c?
> >
> > Yes, please. This will change later when Pat Mochels devicefs kicks in,
> > but for the time being, it'd be very useful.
>
> Here's a patch against 2.5.3-pre3, does it look ok to you (I fixed the
> potential memory leak in the second kmalloc call from what was in
> 2.5.2-dj4)?
Oops, more memory leak fixes:
> diff -Nru a/drivers/usb/usb.c b/drivers/usb/usb.c
> --- a/drivers/usb/usb.c Wed Jan 23 13:20:28 2002
> +++ b/drivers/usb/usb.c Wed Jan 23 13:20:28 2002
> @@ -2513,6 +2513,49 @@
> return err;
> }
>
> +/**
> + * usb_make_path - returns device path in the hub tree
> + * @dev: the device whose path is being constructed
> + * @buf: where to put the string
> + * @size: how big is "buf"?
> + *
> + * Returns length of the string (>= 0) or out of memory status (< 0).
> + */
> +int usb_make_path(struct usb_device *dev, char *buf, size_t size)
> +{
> + struct usb_device *pdev = dev->parent;
> + char *tmp;
> + char *port;
> + int i;
> +
> + if (!(port = kmalloc(size, GFP_KERNEL)))
> + return -ENOMEM;
> + if (!(tmp = kmalloc(size, GFP_KERNEL))) {
> + kfree(port);
> + return -ENOMEM;
> + }
> +
> + *port = 0;
> +
> + while (pdev) {
> + for (i = 0; i < pdev->maxchild; i++)
> + if (pdev->children[i] == dev)
> + break;
> +
> + if (pdev->children[i] != dev)
> + return -1;
Should be:
if (pdev->children[i] != dev) {
kfree(port);
kfree(tmp);
return -ENODEV;
}
> +
> + strcpy(tmp, port);
> + snprintf(port, size, strlen(port) ? "%d.%s" : "%d", i + 1, tmp);
> +
> + dev = pdev;
> + pdev = dev->parent;
> + }
> +
> + snprintf(buf, size, "usb%d:%s", dev->bus->busnum, port);
And add:
kfree(port);
kfree(tmp);
> + return strlen(buf);
> +}
Does that look better?
thanks,
greg k-h
On Wed, Jan 23, 2002 at 02:22:51PM -0800, Greg KH wrote:
> On Wed, Jan 23, 2002 at 01:24:36PM -0800, Greg KH wrote:
> > On Wed, Jan 23, 2002 at 09:44:14AM +0100, Vojtech Pavlik wrote:
> > > On Tue, Jan 22, 2002 at 08:54:05PM -0800, Greg KH wrote:
> > > > Vojtech, is this a USB function that you want added to usb.c?
> > >
> > > Yes, please. This will change later when Pat Mochels devicefs kicks in,
> > > but for the time being, it'd be very useful.
> >
> > Here's a patch against 2.5.3-pre3, does it look ok to you (I fixed the
> > potential memory leak in the second kmalloc call from what was in
> > 2.5.2-dj4)?
Yes, this is perfect. *shiver* I can't believe I made the code so leaky.
Sorry for that, it's a copy-paste problem.
Thanks for fixing it.
> Oops, more memory leak fixes:
>
> > diff -Nru a/drivers/usb/usb.c b/drivers/usb/usb.c
> > --- a/drivers/usb/usb.c Wed Jan 23 13:20:28 2002
> > +++ b/drivers/usb/usb.c Wed Jan 23 13:20:28 2002
> > @@ -2513,6 +2513,49 @@
> > return err;
> > }
> >
> > +/**
> > + * usb_make_path - returns device path in the hub tree
> > + * @dev: the device whose path is being constructed
> > + * @buf: where to put the string
> > + * @size: how big is "buf"?
> > + *
> > + * Returns length of the string (>= 0) or out of memory status (< 0).
> > + */
> > +int usb_make_path(struct usb_device *dev, char *buf, size_t size)
> > +{
> > + struct usb_device *pdev = dev->parent;
> > + char *tmp;
> > + char *port;
> > + int i;
> > +
> > + if (!(port = kmalloc(size, GFP_KERNEL)))
> > + return -ENOMEM;
> > + if (!(tmp = kmalloc(size, GFP_KERNEL))) {
> > + kfree(port);
> > + return -ENOMEM;
> > + }
> > +
> > + *port = 0;
> > +
> > + while (pdev) {
> > + for (i = 0; i < pdev->maxchild; i++)
> > + if (pdev->children[i] == dev)
> > + break;
> > +
> > + if (pdev->children[i] != dev)
> > + return -1;
>
> Should be:
> if (pdev->children[i] != dev) {
> kfree(port);
> kfree(tmp);
> return -ENODEV;
> }
>
> > +
> > + strcpy(tmp, port);
> > + snprintf(port, size, strlen(port) ? "%d.%s" : "%d", i + 1, tmp);
> > +
> > + dev = pdev;
> > + pdev = dev->parent;
> > + }
> > +
> > + snprintf(buf, size, "usb%d:%s", dev->bus->busnum, port);
>
> And add:
> kfree(port);
> kfree(tmp);
>
> > + return strlen(buf);
> > +}
>
>
> Does that look better?
>
> thanks,
>
> greg k-h
--
Vojtech Pavlik
SuSE Labs
On Wed, Jan 23, 2002 at 11:47:14PM +0100, Vojtech Pavlik wrote:
>
> Yes, this is perfect. *shiver* I can't believe I made the code so leaky.
> Sorry for that, it's a copy-paste problem.
> Thanks for fixing it.
No problem, I'll send it out in my next round of patches.
greg k-h
> > > Vojtech, is this a USB function that you want added to usb.c?
> >
> > Yes, please. This will change later when Pat Mochels devicefs kicks in,
What's the story on "driverfs" happening, by the way? Last I knew, the
PCI bits weren't yet ready.
> > but for the time being, it'd be very useful.
>
> +int usb_make_path(struct usb_device *dev, char *buf, size_t size)
I don't think that patch is necessary. It's simpler to just
strncpy (buf, dev->devpath, min_t(size_t, size, sizeof dev->devpath));
Use like you'd use pci_dev->slot_name ... no mallocation necessary.
It's just the path from root hub down to device, /2/1/7 and so on: the
physical path, which stays the same so long as you don't recable your
tree of USB devices and hubs.
I'd expect the typical "driverfs" path for a USB device to be the
path for the root hub (normally a PCI slot like 00:0f.3) followed by
what "devpath" now shows.
- Dave
On Wed, Jan 23, 2002 at 04:46:13PM -0800, David Brownell wrote:
> > > > Vojtech, is this a USB function that you want added to usb.c?
> > >
> > > Yes, please. This will change later when Pat Mochels devicefs kicks in,
>
> What's the story on "driverfs" happening, by the way? Last I knew, the
> PCI bits weren't yet ready.
I'm not absolutely sure about the status of the PCI support, but it
should be close to working. Anyway, the driverfs infrastructure itself
is in place in 2.5, so even if the PCI part wasn't there, still we can
convert USB and Input to it.
> > > but for the time being, it'd be very useful.
> >
> > +int usb_make_path(struct usb_device *dev, char *buf, size_t size)
>
> I don't think that patch is necessary. It's simpler to just
>
> strncpy (buf, dev->devpath, min_t(size_t, size, sizeof dev->devpath));
>
> Use like you'd use pci_dev->slot_name ... no mallocation necessary.
> It's just the path from root hub down to device, /2/1/7 and so on: the
> physical path, which stays the same so long as you don't recable your
> tree of USB devices and hubs.
>
> I'd expect the typical "driverfs" path for a USB device to be the
> path for the root hub (normally a PCI slot like 00:0f.3) followed by
> what "devpath" now shows.
Ahh, I see. This "devpath" entry wasn't available at the time I wrote
the 'usb_make_path' function. This is of course much better. What's not
very convenient for me right now is that it uses slashes instead of
dots, which the input subsystem uses for delimiting busses from each
other, like:
isa0060/serio0/input0 - AT keyboard
pci0:7.3/usb1:2.2/input0 - USB keboard
Using slashes in place of the dots would make it quite a mess. The
slashes are probably there because of usbdevfs, right?
Note that the PCI "slot_name" doesn't use slashes ...
--
Vojtech Pavlik
SuSE Labs
On Thu, Jan 24, 2002 at 10:01:54AM +0100, Vojtech Pavlik wrote:
> > What's the story on "driverfs" happening, by the way? Last I knew, the
> > PCI bits weren't yet ready.
> I'm not absolutely sure about the status of the PCI support, but it
> should be close to working. Anyway, the driverfs infrastructure itself
> is in place in 2.5, so even if the PCI part wasn't there, still we can
> convert USB and Input to it.
>From pre4 changelog:
- Patrick Mochel: devicefs updates, add PCI devices into the hierarchy
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Quoth "Vojtech Pavlik" <[email protected]>:
> On Wed, Jan 23, 2002 at 04:46:13PM -0800, David Brownell wrote:
> > What's the story on "driverfs" happening, by the way? Last I knew, the
> > PCI bits weren't yet ready.
>
> I'm not absolutely sure about the status of the PCI support, but it
> should be close to working. Anyway, the driverfs infrastructure itself
> is in place in 2.5, so even if the PCI part wasn't there, still we can
> convert USB and Input to it.
Since all the USB HCDs use PCI, I think the 2.5.3-pre4 updates
(well timed :) are necessary to convert USB: HCDs first, then the
hub driver, then input. Or at least, that's how I understand things
right now -- I was waiting for a "finished" example to read! :)
> > strncpy (buf, dev->devpath, min_t(size_t, size, sizeof dev->devpath));
> >
> > Use like you'd use pci_dev->slot_name ... no mallocation necessary.
> > It's just the path from root hub down to device, /2/1/7 and so on: the
> > physical path, which stays the same so long as you don't recable your
> > tree of USB devices and hubs.
> >
> > I'd expect the typical "driverfs" path for a USB device to be the
> > path for the root hub (normally a PCI slot like 00:0f.3) followed by
> > what "devpath" now shows.
>
> Ahh, I see. This "devpath" entry wasn't available at the time I wrote
> the 'usb_make_path' function. This is of course much better. What's not
> very convenient for me right now is that it uses slashes instead of
> dots, which the input subsystem uses for delimiting busses from each
> other, like:
>
> isa0060/serio0/input0 - AT keyboard
> pci0:7.3/usb1:2.2/input0 - USB keboard
>
> Using slashes in place of the dots would make it quite a mess. The
> slashes are probably there because of usbdevfs, right?
Driverfs -- since the hubs are part of the device hierarchy,
which shows up in the filesystem. Also that's what the code
it replaced did (in the hub driver). Maybe it should change
to use driverfs directly... :)
- Dave
> Note that the PCI "slot_name" doesn't use slashes ...
>
> --
> Vojtech Pavlik
> SuSE Labs
On Thu, Jan 24, 2002 at 07:27:41AM -0800, David Brownell wrote:
> Quoth "Vojtech Pavlik" <[email protected]>:
> > On Wed, Jan 23, 2002 at 04:46:13PM -0800, David Brownell wrote:
> > > What's the story on "driverfs" happening, by the way? Last I knew, the
> > > PCI bits weren't yet ready.
> >
> > I'm not absolutely sure about the status of the PCI support, but it
> > should be close to working. Anyway, the driverfs infrastructure itself
> > is in place in 2.5, so even if the PCI part wasn't there, still we can
> > convert USB and Input to it.
>
> Since all the USB HCDs use PCI, I think the 2.5.3-pre4 updates
> (well timed :) are necessary to convert USB: HCDs first, then the
> hub driver, then input. Or at least, that's how I understand things
> right now -- I was waiting for a "finished" example to read! :)
> > > strncpy (buf, dev->devpath, min_t(size_t, size, sizeof dev->devpath));
> > >
> > > Use like you'd use pci_dev->slot_name ... no mallocation necessary.
> > > It's just the path from root hub down to device, /2/1/7 and so on: the
> > > physical path, which stays the same so long as you don't recable your
> > > tree of USB devices and hubs.
> > >
> > > I'd expect the typical "driverfs" path for a USB device to be the
> > > path for the root hub (normally a PCI slot like 00:0f.3) followed by
> > > what "devpath" now shows.
> >
> > Ahh, I see. This "devpath" entry wasn't available at the time I wrote
> > the 'usb_make_path' function. This is of course much better. What's not
> > very convenient for me right now is that it uses slashes instead of
> > dots, which the input subsystem uses for delimiting busses from each
> > other, like:
> >
> > isa0060/serio0/input0 - AT keyboard
> > pci0:7.3/usb1:2.2/input0 - USB keboard
> >
> > Using slashes in place of the dots would make it quite a mess. The
> > slashes are probably there because of usbdevfs, right?
>
> Driverfs -- since the hubs are part of the device hierarchy,
> which shows up in the filesystem. Also that's what the code
> it replaced did (in the hub driver). Maybe it should change
> to use driverfs directly... :)
Ok, now that we have driverfs PCI in place, I'll keep usb_make_path for
a while not to break input, and once both hcds and hubs are converted,
I'll convert input.
--
Vojtech Pavlik
SuSE Labs