[PATCH] Moving spinlock to struct usb_hcd
Hi,
This is an attempt to move the hcd_urb_list_lock to struct usb_hcd.
The lock is taken on functions that try to add/delete/use urb against a
given hcd. I have not seen any association of an urb with multiple hcds.
Hence I thought this can be moved within usb_hcd. This should help
reduce contention to usb during high load where i/o is happening to
multiple hcds. I am also trying to see if hcd_root_hub_lock can also be
moved to usb_hcd. Any comments on this? I have done some testing with
this patch and it seems to be holding fine. If this looks ok I will
submit the lock statistics before and after the change.
Thanks,
-Romit
---
drivers/usb/core/hcd.c | 24 +++-
drivers/usb/core/hcd.h |1 +
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index d5ed3fa..6eb0f45 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -98,9 +98,6 @@ EXPORT_SYMBOL_GPL (usb_bus_list_lock);
/* used for controlling access to virtual root hubs */
static DEFINE_SPINLOCK(hcd_root_hub_lock);
-/* used when updating an endpoint's URB list */
-static DEFINE_SPINLOCK(hcd_urb_list_lock);
-
/* wait queue for synchronous unlinks */
DECLARE_WAIT_QUEUE_HEAD(usb_kill_urb_queue);
@@ -1000,7 +997,7 @@ int usb_hcd_link_urb_to_ep(struct usb_hcd *hcd,
struct urb *urb)
{
int rc = 0;
- spin_lock(&hcd_urb_list_lock);
+ spin_lock(&hcd->hcd_urb_list_lock);
/* Check that the URB isn't being killed */
if (unlikely(urb->reject)) {
@@ -1033,7 +1030,7 @@ int usb_hcd_link_urb_to_ep(struct usb_hcd *hcd,
struct urb *urb)
goto done;
}
done:
- spin_unlock(&hcd_urb_list_lock);
+ spin_unlock(&hcd->hcd_urb_list_lock);
return rc;
}
EXPORT_SYMBOL_GPL(usb_hcd_link_urb_to_ep);
@@ -1106,9 +1103,9 @@ EXPORT_SYMBOL_GPL(usb_hcd_check_unlink_urb);
void usb_hcd_unlink_urb_from_ep(struct usb_hcd *hcd, struct urb *urb)
{
/* clear all state linking urb to this dev (and hcd) */
- spin_lock(&hcd_urb_list_lock);
+ spin_lock(&hcd->hcd_urb_list_lock);
list_del_init(&urb->urb_list);
- spin_unlock(&hcd_urb_list_lock);
+ spin_unlock(&hcd->hcd_urb_list_lock);
}
EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
@@ -1311,7 +1308,7 @@ void usb_hcd_flush_endpoint(struct usb_device
*udev,
hcd = bus_to_hcd(udev->bus);
/* No more submits can occur */
- spin_lock_irq(&hcd_urb_list_lock);
+ spin_lock_irq(&hcd->hcd_urb_list_lock);
rescan:
list_for_each_entry (urb, &ep->urb_list, urb_list) {
int is_in;
@@ -1320,7 +1317,7 @@ rescan:
continue;
usb_get_urb (urb);
is_in = usb_urb_dir_in(urb);
- spin_unlock(&hcd_urb_list_lock);
+ spin_unlock(&hcd->hcd_urb_list_lock);
/* kick hcd */
unlink1(hcd, urb, -ESHUTDOWN);
@@ -1345,14 +1342,14 @@ rescan:
usb_put_urb (urb);
/* list contents may have changed */
- spin_lock(&hcd_urb_list_lock);
+ spin_lock(&hcd->hcd_urb_list_lock);
goto rescan;
}
- spin_unlock_irq(&hcd_urb_list_lock);
+ spin_unlock_irq(&hcd->hcd_urb_list_lock);
/* Wait until the endpoint queue is completely empty */
while (!list_empty (&ep->urb_list)) {
- spin_lock_irq(&hcd_urb_list_lock);
+ spin_lock_irq(&hcd->hcd_urb_list_lock);
/* The list may have changed while we acquired the spinlock */
urb = NULL;
@@ -1361,7 +1358,7 @@ rescan:
urb_list);
usb_get_urb (urb);
}
- spin_unlock_irq(&hcd_urb_list_lock);
+ spin_unlock_irq(&hcd->hcd_urb_list_lock);
if (urb) {
usb_kill_urb (urb);
@@ -1618,6 +1615,7 @@ struct usb_hcd *usb_create_hcd (const struct
hc_driver *driver,
dev_dbg (dev, "hcd alloc failed\n");
return NULL;
}
+ spin_lock_init(&hcd->hcd_urb_list_lock);
dev_set_drvdata(dev, hcd);
kref_init(&hcd->kref);
diff --git a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h
index 98e2419..e23ff45 100644
--- a/drivers/usb/core/hcd.h
+++ b/drivers/usb/core/hcd.h
@@ -128,6 +128,7 @@ struct usb_hcd {
* input size of periodic table to an interrupt scheduler.
* (ohci 32, uhci 1024, ehci 256/512/1024).
*/
+ spinlock_t hcd_urb_list_lock;
/* The HC driver's private data is stored at the end of
* this structure.
--
1.4.4.2
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using a "real" vendor id for root hubs
On Fri, 25 Jan 2008, David Brownell wrote: > On Friday 25 January 2008, Greg KH wrote: > > Right now we use a "fake" vendor and product id for root hubs in the > > kernel. However, I'm happy to announce that the Linux Foundation has > > joined the USB-IF and gotten an "official" usb vendor id assigned to it. > > > > I'm still working on setting up the infrastructure for how to assign > > product ids out of this numberspace, > > The ones NetChip gave me are allocated by me, and stored in > the usb.ids file. That's probably not the answer you're after > (and you'll have 2^12 times as many to worry about), but I > do think they should be listed that way. > > > > but someone mentioned the other day > > that we should probably use the first id for our root hubs within the > > kernel. > > > > Does anyone have an objection to me making that change? > > Nah -- go for it! Does anyone happen to know what numbers Windows uses for its root hubs? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using a "real" vendor id for root hubs
On Fri, Jan 25, 2008 at 09:44:32PM +0100, Oliver Neukum wrote: > Am Freitag, 25. Januar 2008 17:58:56 schrieben Sie: > > Right now we use a "fake" vendor and product id for root hubs in the > > kernel. However, I'm happy to announce that the Linux Foundation has > > joined the USB-IF and gotten an "official" usb vendor id assigned to it. > > > > I'm still working on setting up the infrastructure for how to assign > > product ids out of this numberspace, but someone mentioned the other day > > that we should probably use the first id for our root hubs within the > > kernel. > > > > Does anyone have an objection to me making that change? > > What's the benefit? You'll break all scripts that look for 0:0 to identify > a root hub. We have scripts that do that? Where? You should be looking at the bus id and level and other stuff for that I would hope, not the vendor and product id. At least that's the way the scripts I've written over the years do it :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using a "real" vendor id for root hubs
On Friday 25 January 2008, Greg KH wrote: > > > > The ones NetChip gave me are allocated by me, and stored in > > the usb.ids file. That's probably not the answer you're after > > (and you'll have 2^12 times as many to worry about), but I > > do think they should be listed that way. > > In reading the USB-IF adopters agreement, NetChip could get in big > trouble for giving you those ids, which is one reason I got the Linux > Foundation to join the group. Odd; more vendors than NetChip have ways to hand out small numbers of IDs to people developing products using their chips. On the other hand, if USB-IF doesn' *want* USB products to be developed ... - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using a "real" vendor id for root hubs
On Fri, Jan 25, 2008 at 11:02:24AM -0800, David Brownell wrote: > On Friday 25 January 2008, Greg KH wrote: > > Right now we use a "fake" vendor and product id for root hubs in the > > kernel. However, I'm happy to announce that the Linux Foundation has > > joined the USB-IF and gotten an "official" usb vendor id assigned to it. > > > > I'm still working on setting up the infrastructure for how to assign > > product ids out of this numberspace, > > The ones NetChip gave me are allocated by me, and stored in > the usb.ids file. That's probably not the answer you're after > (and you'll have 2^12 times as many to worry about), but I > do think they should be listed that way. In reading the USB-IF adopters agreement, NetChip could get in big trouble for giving you those ids, which is one reason I got the Linux Foundation to join the group. > > but someone mentioned the other day > > that we should probably use the first id for our root hubs within the > > kernel. > > > > Does anyone have an objection to me making that change? > > Nah -- go for it! Ok, will do. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
ACKed-by: Matthew Dharm <[EMAIL PROTECTED]> Matt On Fri, Jan 25, 2008 at 11:12:21AM -0600, James Bottomley wrote: > On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote: > > On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote: > > > Greg KH wrote: > > > > I just am worried that we are > > > > now suddenly keeping access from the last sector for devices that > > > > currently did work just fine. > > > > > > This new workaround doesn't prevent access to the last sector. It only > > > breaks up a multi-sector access which would also reach the last sector > > > into several (two? I'm too lazy to look back in the mail thread) > > > accesses, in order to access the last sector in a dedicated > > > single-sector access. > > > > > > So that's very differently to the fix-capacity workaround. The > > > fix-capacity workaround manipulates the READ CAPACITY parameter data. > > > Therefore the fix-capacity workaround is unsafe for non-buggy devices. > > > > > > The last-sector-(access-)bug workaround _only_ modifies the command > > > stream which is sent to the device. A dangerous command is replaced by > > > equivalent safe commands. These commands are luckily safe for _all_ > > > devices, buggy and non-buggy ones. The only cost of this workaround is > > > (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for > > > accesses which reach the last sector. > > > > Ok, thanks for explaining it better. I have no objection to this change > > anymore. > > So, for forms sake to take this through the SCSI tree I need at least > one USB person to ack it ... > > James > -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgp2JcUXGwDbZ.pgp Description: PGP signature
Re: using a "real" vendor id for root hubs
On Friday 25 January 2008, Greg KH wrote: > Right now we use a "fake" vendor and product id for root hubs in the > kernel. However, I'm happy to announce that the Linux Foundation has > joined the USB-IF and gotten an "official" usb vendor id assigned to it. > > I'm still working on setting up the infrastructure for how to assign > product ids out of this numberspace, The ones NetChip gave me are allocated by me, and stored in the usb.ids file. That's probably not the answer you're after (and you'll have 2^12 times as many to worry about), but I do think they should be listed that way. > but someone mentioned the other day > that we should probably use the first id for our root hubs within the > kernel. > > Does anyone have an objection to me making that change? Nah -- go for it! - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: mark USB drivers as being GPL only
FYI, this is a patch that will be sent out in the next round to Linus
for inclusion in 2.6.25.
If anyone has any objections about it, please let me know.
thanks,
greg k-h
From: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Subject: USB: mark USB drivers as being GPL only
Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL. This patch moves the USB apis to enforce that decision.
There are no known closed source USB drivers in the wild, so this patch
should cause no problems.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
Documentation/feature-removal-schedule.txt | 16 ---
drivers/usb/core/driver.c | 10 ++--
drivers/usb/core/file.c|4 -
drivers/usb/core/hcd-pci.c | 10 ++--
drivers/usb/core/hcd.c | 18
drivers/usb/core/hub.c |5 +-
drivers/usb/core/message.c | 32 +-
drivers/usb/core/urb.c | 15 +++
drivers/usb/core/usb.c | 62 -
9 files changed, 61 insertions(+), 111 deletions(-)
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -156,22 +156,6 @@ Who: Arjan van de Ven <[EMAIL PROTECTED]
---
-What: USB driver API moves to EXPORT_SYMBOL_GPL
-When: February 2008
-Files: include/linux/usb.h, drivers/usb/core/driver.c
-Why: The USB subsystem has changed a lot over time, and it has been
- possible to create userspace USB drivers using usbfs/libusb/gadgetfs
- that operate as fast as the USB bus allows. Because of this, the USB
- subsystem will not be allowing closed source kernel drivers to
- register with it, after this grace period is over. If anyone needs
- any help in converting their closed source drivers over to use the
- userspace filesystems, please contact the
- [EMAIL PROTECTED] mailing list, and the developers
- there will be glad to help you out.
-Who: Greg Kroah-Hartman <[EMAIL PROTECTED]>
-
-
What: vm_ops.nopage
When: Soon, provided in-kernel callers have been converted
Why: This interface is replaced by vm_ops.fault, but it has been around
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -325,7 +325,7 @@ int usb_driver_claim_interface(struct us
return retval;
}
-EXPORT_SYMBOL(usb_driver_claim_interface);
+EXPORT_SYMBOL_GPL(usb_driver_claim_interface);
/**
* usb_driver_release_interface - unbind a driver from an interface
@@ -370,7 +370,7 @@ void usb_driver_release_interface(struct
iface->needs_remote_wakeup = 0;
usb_pm_unlock(udev);
}
-EXPORT_SYMBOL(usb_driver_release_interface);
+EXPORT_SYMBOL_GPL(usb_driver_release_interface);
/* returns 0 if no match, 1 if match */
int usb_match_device(struct usb_device *dev, const struct usb_device_id *id)
@@ -542,7 +542,7 @@ const struct usb_device_id *usb_match_id
return NULL;
}
-EXPORT_SYMBOL_GPL_FUTURE(usb_match_id);
+EXPORT_SYMBOL_GPL(usb_match_id);
static int usb_device_match(struct device *dev, struct device_driver *drv)
{
@@ -745,7 +745,7 @@ int usb_register_driver(struct usb_drive
return retval;
}
-EXPORT_SYMBOL_GPL_FUTURE(usb_register_driver);
+EXPORT_SYMBOL_GPL(usb_register_driver);
/**
* usb_deregister - unregister a USB interface driver
@@ -769,7 +769,7 @@ void usb_deregister(struct usb_driver *d
usbfs_update_special();
}
-EXPORT_SYMBOL_GPL_FUTURE(usb_deregister);
+EXPORT_SYMBOL_GPL(usb_deregister);
#ifdef CONFIG_PM
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -204,7 +204,7 @@ int usb_register_dev(struct usb_interfac
exit:
return retval;
}
-EXPORT_SYMBOL(usb_register_dev);
+EXPORT_SYMBOL_GPL(usb_register_dev);
/**
* usb_deregister_dev - deregister a USB device's dynamic minor.
@@ -245,4 +245,4 @@ void usb_deregister_dev(struct usb_inter
intf->minor = -1;
destroy_usb_class();
}
-EXPORT_SYMBOL(usb_deregister_dev);
+EXPORT_SYMBOL_GPL(usb_deregister_dev);
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -144,7 +144,7 @@ int usb_hcd_pci_probe (struct pci_dev *d
dev_err (&dev->dev, "init %s fail, %d\n", pci_name(dev), retval);
return retval;
}
-EXPORT_SYMBOL (usb_hcd_pci_probe);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_probe);
/* may be called without controller electrically present */
@@ -179,7 +179,7 @@ void usb_hcd_pci_remove (struct pci_dev
usb_put_hcd (hcd);
pci_disable_device(dev);
}
-EXPORT_SYMBOL (usb_hcd_pci_remove);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_remove);
#ifdef CONFIG_PM
@@ -314,7 +314,7 @@ done:
return retval;
}
-EXPORT_SYMBOL (usb_hcd_pci_suspend);
+EXPORT_SYMBOL_GPL(usb_hcd_pci_suspend);
/**
* usb_hcd_pci_
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
On Thu, 2008-01-24 at 09:21 -0800, Greg KH wrote: > On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote: > > Greg KH wrote: > > > I just am worried that we are > > > now suddenly keeping access from the last sector for devices that > > > currently did work just fine. > > > > This new workaround doesn't prevent access to the last sector. It only > > breaks up a multi-sector access which would also reach the last sector > > into several (two? I'm too lazy to look back in the mail thread) > > accesses, in order to access the last sector in a dedicated > > single-sector access. > > > > So that's very differently to the fix-capacity workaround. The > > fix-capacity workaround manipulates the READ CAPACITY parameter data. > > Therefore the fix-capacity workaround is unsafe for non-buggy devices. > > > > The last-sector-(access-)bug workaround _only_ modifies the command > > stream which is sent to the device. A dangerous command is replaced by > > equivalent safe commands. These commands are luckily safe for _all_ > > devices, buggy and non-buggy ones. The only cost of this workaround is > > (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for > > accesses which reach the last sector. > > Ok, thanks for explaining it better. I have no objection to this change > anymore. So, for forms sake to take this through the SCSI tree I need at least one USB person to ack it ... James - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query usb_kill_urb()
On Fri, 25 Jan 2008, Pandita, Vikram wrote: > usb_kill_urb() ensures that URB is unlinked and callback is called. > > My question is, what happens to the URB that is already scheduled by > underlying HCD and getting processed, and usb_kill_urb() is called? It's the same as when usb_unlink_urb() is called: The URB is cancelled. > What will be returned by completion handler for such an URB if it was > bulk IN and bulk OUT URB? Completion handlers always return void. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Problem with NEC PCI USB 72010 (linux 2.6.23.8)
We have actually determined the problem with our board... and it was much simplier than expected. a) some initialization code was doing the wrong thing to some configuration space registers b) the root 8548 PCI registers were being overwritten by some process that disabled memory accesses for this bus I now have it working very nicely...except for a small problem that I am trying to solve right now... Tom Ps: to answer your question about the 48MHZ Clock - the EXT2 register (0xe0 offset) in the PCI configuration space for the EHCI host controller has a bit selection for 30MHZ vs. 48Mhz. There is an app note about this (can't seem to find the notation that indicates this specific part will 'freeze' if this is NOT set before starting memory accesses... I've added a quirk for this in our custom BSP to make sure this is set correctly... -Original Message- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 6:08 PM To: Morrison, Tom Cc: linux-usb@vger.kernel.org Subject: Re: Problem with NEC PCI USB 72010 (linux 2.6.23.8) On Wednesday 16 January 2008, Morrison, Tom wrote: > Hi, > > I tried to look through archives - and I did not see the exact problem > that I am experiencing in there (although there might be some very > similar ones): Summarizing: both EHCI and OHCI controllers got fatal error IRQs. Those are the type of errors that *typically* indicate DMA problems, like talking to invalid DMA addresses. OHCI gets that as soon as it tries to start ... EHCI gets it on the first request it submits. How do they get invalid addresses? Sometimes it's hardware problems. Sometimes their dma descriptors get overwritten by other drivers, or management of the DMA mappings is broken on that system. And the "restart OHCI" logic seems to need a way to stop restarting when it keeps getting errors... Since OHCI fails so quickly, that might be the best place to start. There's an internal "verbose" debug option; turn it on by hand, along with CONFIG_USB_DEBUG, and you'll get more info when the module loads. Some of it should become informative. > Also, this is my first post to the linux-usb groups and I tried to read > all the FAQs and hopefully I have all the information required to at > least give me some suggestions as to where to look next Thank you! :) However you omitted relevant CONFIG_* data for EHCI + OHCI. There were some endianness options for EHCI that could maybe kick in there. If so, make sure the EHCI is treated as little-endian. Likewise with OHCI. (They're both on PCI, so the OS should view them as little endian.) > OK, the details: > > CPU: MPC8548E (with PCI1 & PCI Express support) So -- PowerPC? Big Endian? > USB Chip (per subject line): > - NEC 720101 > - Port 1 connected to external USB connector > - Ports 2-5 are not connected to anything & are > 'logically disconnected" in hub driver. What do you mean by that? Custom patch? The OHCI driver has a mechanism whereby it can be told that the "real" number of ports is less than what the hardware says ... to cope with cases where e.g. port 1 is bonded out but not port 2. Maybe EHCI should have something similar. > EHCI Driver > > Kernel: linux-2.6.23.8 (with one quirk found for this chip - >to select 48MHZ clock (it hung otherwise)). Again, what do you mean by that? Another custom patch? I don't recall any clock selection options. Normally I'd expect a discrete crystal dedicated to that controller. But it'd also be practical to have an external clockgen chip that needs to be told to feed 48 MHz to that chip. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Query usb_kill_urb()
usb_kill_urb() ensures that URB is unlinked and callback is called. My question is, what happens to the URB that is already scheduled by underlying HCD and getting processed, and usb_kill_urb() is called? What will be returned by completion handler for such an URB if it was bulk IN and bulk OUT URB? Regards, Vikram - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using a "real" vendor id for root hubs
Am Freitag, 25. Januar 2008 17:58:56 schrieben Sie: > Right now we use a "fake" vendor and product id for root hubs in the > kernel. However, I'm happy to announce that the Linux Foundation has > joined the USB-IF and gotten an "official" usb vendor id assigned to it. > > I'm still working on setting up the infrastructure for how to assign > product ids out of this numberspace, but someone mentioned the other day > that we should probably use the first id for our root hubs within the > kernel. > > Does anyone have an objection to me making that change? What's the benefit? You'll break all scripts that look for 0:0 to identify a root hub. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: multiple devices for one USB interface - possible?
Am Dienstag, 22. Januar 2008 19:36:45 schrieben Sie: > > I guess so, because what I'm trying to do is merely just to expose some > > of the device's (interrupt) endpoints as separate character device files > > under /dev. The "real" communication is thus moved to a user space app / > > lib which handles the control of the device with simple read() and > > write() calls to the various characters device files. Works fine so for > > one endpoint, but as said, due to the limitation of struct > > usb_interface (being limited to just one minor per USB interface), I > > could not simply add another usb_register_dev() call to create further > > character devices for the other endpoints of same USB interface. > > Then why not just use usbfs/libusb directly? That sounds like it would > work for you, and no kernel driver is needed at all. Because I don't want to. ;) No, there are couple reasons for doing it as a kernel module. For example I planned to use it in an slim embedded device which only runs one single app directly from the kernel's init, with everything statically compiled in and the kernel module will be small anyway, so it avoids some intricacies. I used the misc interface now. I also had a look at the usbfs2 code, which is pretty much what I feared I have to code, but the downside would be wasting of a major just for that single device driver, so the misc interface is just perfect. > > If I'd provide a patch, replacing the scalar member of struct > > usb_interface by a list of minors instead, would that a have a chance to > > be applied to the upstream kernel? Or is there probably a good reason for > > keeping it a scalar? > > Yes, we need to keep it on a per-interface level because that is what > drivers bind to, not individual endpoints, or endpoint pairs. I don't quite get why this couldn't be accomplished with a list as well, but at least I haven't wasted time for a patch that would be rejected anyway. :) Thanks for all the tips, helped me a lot! CU Christian - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9815] New: Unable to mount ipod
> On Fri, 25 Jan 2008 08:34:00 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9815 > >Summary: Unable to mount ipod >Product: Other >Version: 2.5 > KernelVersion: 2.6.24 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Latest working kernel version: > Earliest failing kernel version: 2.6.23 > Distribution: Debian > Hardware Environment: > Software Environment: > Problem Description: Cannot mount ipod or an external hard disk > > When I connect my ipod, > I cannot mount it and I get the same error I was getting earlier. > > Jan 25 15:50:04 brahman kernel: usb 1-2: new high speed USB device using > ehci_hcd and address 94 > Jan 25 15:50:04 brahman kernel: usb 1-2: configuration #1 chosen from 1 choice > Jan 25 15:50:04 brahman kernel: usb-storage: USB Mass Storage device detected > Jan 25 15:50:04 brahman kernel: usb-storage: -- associate_dev > Jan 25 15:50:04 brahman kernel: usb-storage: Vendor: 0x05ac, Product: 0x1209, > Revision: 0x0001 > Jan 25 15:50:04 brahman kernel: usb-storage: Interface Subclass: 0x06, > Protocol: 0x50 > Jan 25 15:50:04 brahman kernel: usb-storage: Transport: Bulk > Jan 25 15:50:04 brahman kernel: usb-storage: Protocol: Transparent SCSI > Jan 25 15:50:04 brahman kernel: scsi874 : SCSI emulation for USB Mass Storage > devices > Jan 25 15:50:04 brahman kernel: usb-storage: *** thread sleeping. > Jan 25 15:50:04 brahman kernel: usb-storage: device found at 94 > Jan 25 15:50:04 brahman kernel: usb 1-2: USB disconnect, address 94 > Jan 25 15:50:04 brahman kernel: usb-storage: storage_disconnect() called > Jan 25 15:50:04 brahman kernel: usb-storage: usb_stor_stop_transport called > Jan 25 15:50:04 brahman kernel: usb-storage: waiting for device to settle > before scanning > Jan 25 15:50:04 brahman kernel: usb-storage: -- usb_stor_release_resources > Jan 25 15:50:04 brahman kernel: usb-storage: -- sending exit command to thread > Jan 25 15:50:04 brahman kernel: usb-storage: *** thread awakened. > Jan 25 15:50:04 brahman kernel: usb-storage: -- exiting > Jan 25 15:50:04 brahman kernel: usb-storage: -- dissociate_dev > Jan 25 15:50:04 brahman kernel: usb 1-2: new high speed USB device using > ehci_hcd and address 95 > Jan 25 15:50:05 brahman kernel: usb 1-2: configuration #1 chosen from 1 choice > Jan 25 15:50:05 brahman kernel: usb-storage: USB Mass Storage device detected > Jan 25 15:50:05 brahman kernel: usb-storage: -- associate_dev > Jan 25 15:50:05 brahman kernel: usb-storage: Vendor: 0x05ac, Product: 0x1209, > Revision: 0x0001 > Jan 25 15:50:05 brahman kernel: usb-storage: Interface Subclass: 0x06, > Protocol: 0x50 > Jan 25 15:50:05 brahman kernel: usb-storage: Transport: Bulk > Jan 25 15:50:05 brahman kernel: usb-storage: Protocol: Transparent SCSI > Jan 25 15:50:05 brahman kernel: scsi875 : SCSI emulation for USB Mass Storage > devices > Jan 25 15:50:05 brahman kernel: usb-storage: *** thread sleeping. > Jan 25 15:50:05 brahman kernel: usb-storage: device found at 95 > Jan 25 15:50:05 brahman kernel: usb-storage: waiting for device to settle > before scanning > Jan 25 15:50:05 brahman kernel: usb 1-2: USB disconnect, address 95 > Jan 25 15:50:05 brahman kernel: usb-storage: storage_disconnect() called > Jan 25 15:50:05 brahman kernel: usb-storage: usb_stor_stop_transport called > Jan 25 15:50:05 brahman kernel: usb-storage: -- usb_stor_release_resources > Jan 25 15:50:05 brahman kernel: usb-storage: -- sending exit command to thread > Jan 25 15:50:05 brahman kernel: usb-storage: *** thread awakened. > Jan 25 15:50:05 brahman kernel: usb-storage: -- exiting > Jan 25 15:50:05 brahman kernel: usb-storage: -- dissociate_dev > > Incidentally, I can mount my pen drive of 1 GB capacity. But, > I was not able to mount an external hard disk. > > Steps to reproduce: > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9813] New: usb mouse broken on X20 (intermittent)
> On Fri, 25 Jan 2008 07:16:49 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9813 > >Summary: usb mouse broken on X20 (intermittent) >Product: Drivers >Version: 2.5 > KernelVersion: 2.6.24 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: USB > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > > > Latest working kernel version: > Earliest failing kernel version: > Distribution: Debian > Hardware Environment: IBM Thinkpad X20 > Software Environment: > Problem Description: > > On my Thinkpad X20, frequently after booting my usb mouse responds in a > very sluggish and jumpy manner, making it basically unuseable. At the > same time, the stick mouse (which I hate using) works normally. > > This has been going on for a while, at least the last couple of kernels. > > Sometimes I can restore function by unplugging and replugging the USB > mouse, but not reliably, and even then, after replugging it will not > respond at all for some great length of time until some unknown event > causes it to come to life. > > Steps to reproduce: > > -- Package-specific info: > ** Version: > Linux version 2.6.23-1-686 (Debian 2.6.23-2) ([EMAIL PROTECTED]) (gcc version > 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)) #1 SMP Fri Dec 21 13:57:07 UTC > 2007 > > ** cmdline: > root=/dev/hda2 ro resume=/dev/hda4 > ** Not tainted > > ** Kernel log: > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected > Floppy drive(s): fd0 is 1.44M > FDC 0 is a National Semiconductor PC87306 > ACPI: PCI Interrupt :00:08.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> > IRQ 11 > firewire_ohci: Added fw-ohci device :00:08.2, OHCI version 1.0 > PIIX4: IDE controller at PCI slot :00:07.1 > PIIX4: chipset revision 1 > PIIX4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0x1808-0x180f, BIOS settings: hdc:pio, hdd:pio > Probing IDE interface ide0... > usb 1-1: new full speed USB device using uhci_hcd and address 2 > hda: IC25N030ATCS04-0, ATA DISK drive > Marking TSC unstable due to: possible TSC halt in C2. > Time: acpi_pm clocksource has been installed. > Clocksource tsc unstable (delta = -1880422397 ns) > hda: selected mode 0x42 > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > SCSI subsystem initialized > libata version 2.21 loaded. > hda: max request size: 128KiB > hda: 58605120 sectors (30005 MB) w/1768KiB Cache, CHS=62016/15/63, UDMA(33) > hda: cache flushes not supported > hda: hda1 hda2 hda3 hda4 > hda3: bad subpartition - ignored > > > usb 1-1: configuration #1 chosen from 1 choice > Attempting manual resume > hub 1-1:1.0: USB hub found > hub 1-1:1.0: 2 ports detected > usb 1-1.2: new low speed USB device using uhci_hcd and address 3 > usb 1-1.2: configuration #1 chosen from 1 choice > input: PC Speaker as /class/input/input1 > pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 > Yenta: CardBus bridge found at :00:08.0 [1014:0184] > Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > Socket status: 3410 > Yenta: CardBus bridge found at :00:08.1 [1014:0184] > Linux agpgart interface v0.102 > Yenta: ISA IRQ mask 0x04b8, PCI irq 11 > Socket status: 3006 > Real Time Clock Driver v1.12ac > pccard: PCMCIA card inserted into slot 0 > agpgart: Detected an Intel 440BX Chipset. > agpgart: AGP aperture is 64M @ 0xf800 > piix4_smbus :00:07.3: Found :00:07.3 device > piix4_smbus :00:07.3: IBM system detected; this module may corrupt your > serial eeprom! Refusing to load module! > piix4_smbus: probe of :00:07.3 failed with error -1 > IBM TrackPoint firmware: 0x0e, buttons: 3/3 > input: TPPS/2 IBM TrackPoint as /class/input/input2 > input: Power Button (FF) as /class/input/input3 > ACPI: Power Button (FF) [PWRF] > input: Lid Switch as /class/input/input4 > ACPI: Lid Switch [LID] > input: Sleep Button (CM) as /class/input/input5 > ACPI: Sleep Button (CM) [SLPB] > pnp: Device 00:0c activated. > parport_pc 00:0c: reported by Plug and Play ACPI > parport0: PC-style at 0x3bc, irq 7 [PCSPP,TRISTATE] > input: Video Bus as /class/input/input6 > ACPI: Video Device [VID] (multi-head: yes rom: no post: no) > ACPI: AC Adapter [AC] (on-line) > cs: IO port probe 0x100-0x3af: clean. > cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 > cs: IO port probe 0x820-0x8ff: clean. > cs: IO port probe 0xc00-0xcf7: clean. > cs: IO port probe 0xa00-0xaff: clean. > cs: IO port probe 0x100-0x3af: clean. > cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 > cs: IO port probe 0x820-0x8ff: clean. > cs: IO port probe 0xc00-0xcf7: clean
using a "real" vendor id for root hubs
Right now we use a "fake" vendor and product id for root hubs in the kernel. However, I'm happy to announce that the Linux Foundation has joined the USB-IF and gotten an "official" usb vendor id assigned to it. I'm still working on setting up the infrastructure for how to assign product ids out of this numberspace, but someone mentioned the other day that we should probably use the first id for our root hubs within the kernel. Does anyone have an objection to me making that change? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[EMAIL PROTECTED]: USB VendorID=0x0000]
Hi all, I have a report here of a device in the wild that is using a USB vendor id of 0x. From everything I can tell, this _could_ be a valid vendor id, but I'm pretty sure that it isn't :) Here's the bug report, does anyone have an idea of what we should do here? At first glance, we should probably fix the scripts/mod/file2alias.c code that does the following in do_usb_entry_multi(): /* * Some modules (visor) have empty slots as placeholder for * run-time specification that results in catch-all alias */ if (!(id->idVendor | id->bDeviceClass | id->bInterfaceClass)) return; And check both that idVendor and idProduct are 0x before falling out. Does anyone see a problem with that? thanks, greg k-h - Forwarded message from Janusz <[EMAIL PROTECTED]> - Date: Fri, 11 Jan 2008 12:27:42 +0100 From: Janusz <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: USB VendorID=0x Hello ! I'd like kindly ask to help me with modyfiying USB driver for the LCD display avaialbe with GMC chassis. The problem I have (and I think the biggest) is that device is presented on USB bus as: vendorid=0x, productid=0xff02. Macro USB_DEVICE strips 0x from MODULE_DEVICE_TABLE and kernel doesn't recognize this device (it isn't exported to modules.usbmap, too). Could you tell me that to do with it (on M$ it works !) ? Maybe some temporary fix ... Thanks in advance and best regards Janusz -- Stworz najlepsza modelke na swiecie! Sprawdz >>> http://link.interia.pl/f1cc4 - End forwarded message - - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.24-rc8] usb: ehci, remove false clear-reset path
On Thu, 24 Jan 2008, David Brownell wrote: > Some of the "EHCI ports reset forever" problems may be explained by > code paths which wrongly flagged resets as complete. This removes > two such paths; the ehci_hub_status_data() path should be the only one > to have an effect, since it was already properly flagged on the other > path. (Issue noted by Minhyoung Kim <[EMAIL PROTECTED]>.) > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > --- > Worth having some testing on this ... I'm not sure when that test > got into the hub_status_data() call, there's a chance it's working > around some other problem. It's already in there as of the earliest version in a Git repository (2.5.early from back in 2002). You should note that if a disconnect or a connect-status-change is detected during a reset (possible but unlikely since the reset signal overrides the levels used for detecting disconnects), the hub driver exits early -- it does not wait for the reset to complete. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.24-rc8] usb: ehci, remove false clear-reset path
On Friday 25 January 2008, Alan Stern wrote: > On Thu, 24 Jan 2008, David Brownell wrote: > > > Some of the "EHCI ports reset forever" problems may be explained by > > code paths which wrongly flagged resets as complete. This removes > > two such paths; the ehci_hub_status_data() path should be the only one > > to have an effect, since it was already properly flagged on the other > > path. (Issue noted by Minhyoung Kim <[EMAIL PROTECTED]>.) > > > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > --- > > Worth having some testing on this ... I'm not sure when that test > > got into the hub_status_data() call, there's a chance it's working > > around some other problem. > > It's already in there as of the earliest version in a Git repository > (2.5.early from back in 2002). Right. I didn't feel like going back to the BK history, but presumably that would help. > You should note that if a disconnect or a connect-status-change is > detected during a reset (possible but unlikely since the reset signal > overrides the levels used for detecting disconnects), the hub driver > exits early -- it does not wait for the reset to complete. So long as it eventually retrieves port status, the reset should complete. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
