An error occurred fetching the project authors.
- 14 Jul, 2004 2 commits
-
-
Alan Stern authored
This patch adds a pointer to the hub's usb_device into the usb_hub private structure. It's a small change, and permits a small amount of simplification in a few spots, i.e., avoid calling interface_to_usbdev(). This doesn't really do much in itself, but it's a prerequisite for the next patch. (A situation arises where we can't use the interface pointer to find the usb_device because the interface might not exist.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alan Stern authored
This is a rerun of as278, updated to match the current source. It changes the hub driver, replacing calls to synchronous usb_unlink_urb() with usb_kill_urb() and removing the machinery formerly needed to synchronize the status URB handler with the rest of the driver. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 30 Jun, 2004 1 commit
-
-
Mika Kukkonen authored
-
- 23 Jun, 2004 1 commit
-
-
Alan Stern authored
This patch implements the missing functionality necessary to get device resets working fully. It adds a bit-array of ports with logical connect-changes pending to the hub structure, so that the hub driver can recognize that these ports should be treated as though they had disconnected and re-connected. This is how we will handle devices that "morph" (i.e., change their descriptors) following a reset, as might happen with a firmware upload. There is also a lot of additional kerneldoc and a few small changes to some log messages. An important restriction is that usb_reset_device() will refuse to work if the device is suspended. Trying to reset a suspended device leads to several problems, not least of which is that the device's parent hub might be suspended as well. With this patch the device reset code is pretty much complete. However it won't always work correctly until the device locking is straightened out. That's coming up next. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 17 Jun, 2004 1 commit
-
-
Alan Stern authored
This patch adds a bit-array to the hub driver's private data structure, used for storing the contents of the hub's interrupt status message. That message indicates which ports have events pending (and whether the hub itself has events pending). By only polling the status of the ports listed in the bit-array we can save a fair amount of overhead in hub communication. (The #error test added to hub.h is a little awkward, but it's purely precautionary -- it won't matter until someone decides to support hubs with more than 31 ports!) Also included in the patch, since this seemed the perfect opportunity for it, is Byron's suggestion for handling hub events in the order in which they were received. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 14 Jun, 2004 2 commits
-
-
Alan Stern authored
This patch removes the private semaphore used by the hub driver, and uses the regular "serialize" semaphore instead. This will satisfy the general locking requirements for adding and removing devices attached to the hub. The only tricky aspect is that now the hub event handler must take a reference to the hub device while waiting to acquire the semaphore, in case the hub is disconnected during the wait. The patch also replaces a few occurrences of spin_lock_irqsave() in regions where interrupts are known to be enabled with spin_lock_irq(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alan Stern authored
This patch repairs a bug introduced by an earlier patch: The TT initialization code was moved to _after_ the TT's first use. The patch simply puts the code back the way it used to be. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 11 Jun, 2004 1 commit
-
-
Alan Stern authored
This patch implements something we've been lacking for a long time: a way to mark devices as USB_STATE_NOTATTACHED as soon as we know that they're gone. The usb_device->state member is no longer protected by the ->serialize semaphore; instead there's a new private spinlock. Usbcore routines should no longer set ->state directly; instead they should use the new utility routine usb_set_device_state(). There are protections against changing states while devices are being added or removed. Change assignments to udev->state into calls of usb_set_device_state(). Add new private device_state_lock to the hub driver, along with usb_set_device_state() and recursively_mark_NOTATTACHED(). Acquire the new spinlock while adding or removing children[] pointers. When disabling a port that has a child device, mark the child as NOTATTACHED. You mentioned once having tried to do something like this and running into trouble. Take a good look and let me know if you see any difficulties here. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 09 Jun, 2004 2 commits
-
-
Alan Stern authored
After my last few changesets there were a few small items that needed to be tidied up. Update kerneldoc to reflect the actual operation of usb_disconnect() and usb_new_device(). The new locking requirements are listed too, though they aren't all implemented yet. Fulfill the new locking requirement in hcd_panic(). Remove unneeded local variables to conserve stack space in usb_disconnect(), which calls itself recursively. In hub_port_connect_change(), store the parent's children[] pointer as late as possible and don't lock the new device until then (that's when it becomes globally accessible). This will minimize the time that the not-fully-configured device structure is visible to other parts of the kernel. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alan Stern authored
There are a few places where the code enumerates through all the USB devices on all the buses, starting with each bus's root hub and working down. However a bus does not always have a root hub, and the code does not check that the root_hub pointer is non-NULL. This patch fixes the problem, using the usb_bus_list_lock semaphore to synchronize access when root hubs are added or removed. In addition it seemed like a good idea to minimize the time that a non-fully-configured root hub is accessible through the bus's pointer. So this patch delays setting the pointer and holds usb_bus_list_lock while configuring a root hub. It turned out that a bunch of things needed to be changed for all this to work: Check for NULL root_hub pointer in usb_device_read() and usb_find_device(). Pass the root-hub device as a separate argument to hcd_register_root(). Make usb_register_root_hub() acquire the usb_bus_list_lock and set the bus->root_hub pointer. For consistency's sake, move the place where the children[] pointer to a non-root-hub device gets stored as close as possible to where usb_new_device() is called. Make usb_disconnect() acquire the usb_bus_list_lock when removing a root hub. Change usb_hcd_pci_remove() and the non-PCI host drivers so that they call usb_disconnect() with a pointer to the bus's root_hub pointer, not a pointer to a temporary variable. Change all the host controller drivers not to store the root_hub pointer in the bus structure but instead to pass it as a new argument to hcd_register_root(). I made some attempt to update the hc_sl811 driver along with the rest, but it's pretty clear that driver won't work in the current framework. Among other things, it never reads the root hub's device descriptor. To what extent is the driver really supported? Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 07 Jun, 2004 3 commits
-
-
Alan Stern authored
The hub driver is very careless about returning resources when an error occurs while installing a new device. This patch attempts to put some order back into the situation. Details: Since usb_new_device() allocates neither the device structure nor the device address, it shouldn't release either one. Because usb_new_device() no longer releases the device structure, usb_register_root_hub() doesn't need to take an extra reference to it. Since the device address selection and TT setup code is used only for new devices, not ones being reset, move that code from hub_port_init() to hub_port_connect_change(). By the same token, hub_port_init() doesn't have to release the device address or the device structure. Just to make things look better, move the failure code in hub_port_init() to the end of the routine. And when disabling endpoint 0, disable both the IN and OUT parts of the endpoint. In hub_port_connect_change(), make all the failure paths execute the same code so that resources are always released. These resources comprise: the pointer from the parent to the new child device, the HCD state for ep0, the device's address, and the device structure itself -- in short, everything that's set up before calling usb_new_device(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alan Stern authored
This patch adds checking for the SET-FEATURE request that actually does a port reset. Without the check, the hub driver just assumes that the port reset command actually was transferred okay. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Greg Kroah-Hartman authored
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 04 Jun, 2004 3 commits
-
-
Alan Stern authored
This patch includes the algorithmic changes I would like to see in hub_port_debounce(). They are: Increase the total timeout period from 400 ms to 1500 ms. Check the port's connect-changed status during the polling loop. Return as soon as the connection has been stable for the required time, even if it has been stably _dis_-connected. (The current code waits for the full timeout period if there isn't a connection.) In previous emails I have responded to all the concerns raised by others about these changes, and I can't imagine how they could cause any trouble. Increasing the total timeout won't affect people with properly functioning hardware. Their connections will quickly stabilize and the routine will return just as before. People with flaky hardware that takes a long time to settle down will now be able to use their devices. Checking the connect-changed status during the polling loop will make the test more conservative. The code will be able to detect transient disconnections that it would have missed before, and it won't return until the connection really _is_ stable. Furthermore, this makes the test compliant with the USB specification, which requires the stability timer to be restarted whenever a connection change occurs. Returning early for disconnections is a simple optimization. It's more important now that the total timeout length is 1.5 seconds rather than 0.4 seconds. I urge you to apply this patch and for people to try it out. If there do turn out to be problems... the patch is very small, well-contained, and easy to revert. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alan Stern authored
Since my previous suggestions for changes to hub_port_debounce() encountered so much resistance, this patch makes some fairly superficial improvements to the code while leaving the logic of the algorithm almost completely intact. The only behavioral change is that it actually requests the port status at the start, rather than assuming the status is not CONNECTED. Changes include: Vastly improved comments that are now unambiguous and accurately descriptive of the code. Local variables changed to more sensible names. The stability period is now reported in milliseconds rather than a meaningless poll count. The sleep interval is moved from the start of the loop to the end, so that the first time through we read the port status immediately. If the connection has not stabilized after the total timeout expires, -ETIMEDOUT is returned rather than whatever the current connect status happens to be. If the connection does stabilize then the port status is returned so that hub_port_connect_change() will have an up-to-date value for the status rather than relying on the pre-debounce value. The changes I wanted to make but other people were worried about are included as comments. A later (small) patch will uncomment them for testing. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alan Stern authored
This patch makes the hub driver debounce all connection changes. Right now the driver only does so if the status happens to be CONNECTED at one particular instant. However, the whole point of debouncing is that the connection is subject to transient interruptions until it has stabilized; hence deciding whether to debounce based on a single initial test defeats the entire purpose. There are some additional smaller changes that go along with the major one: Comments added to hub_port_connect_change() detailing the conditions under which it will be called. Don't clear the port's connect-changed feature if it wasn't set. Skip debouncing if there wasn't a physical connection change but only a logical port-enable change (or a firmware-download- induced device morph -- not yet implemented). Clear all the hub status change indicators in hub_events() before handling a connect change. This will reduce syslog clutter from status change bits that remain set while khubd is busy taking care of a new device. The patch includes no changes to the debounce routine itself. Please apply. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 02 Jun, 2004 2 commits
-
-
Alan Stern authored
This patch moves usb_new_device(), usb_disconnect(), usb_choose_address(), and usb_release_address() from usb.c to hub.c. As a side benefit, choose_address() and release_address() can now become static. The other two can't, because they have to be exported for use by HCD's when registering/unregistering root hubs. Some other features of the patch: The usb_snddefctrl() and usb_rcvdefctrl() macros have been removed, since only one of them was used and only in one spot. The comment about configuration choice needing to interact with hub power budgeting has been moved in accordance with David's wish. usb_new_device() checks to make sure a configuration could be chosen and logs a warning if no choice was made. Following Linus's preference, the #ifdef preprocessor stuff has been removed from around the calls the show_string routine. It is now defined as a non-inline routine when debugging is enabled and as an inline no-op otherwise (the compiler will optimize away the useless tests). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alan Stern authored
Greg: This patch takes care of some small miscellaneous items in hub.c: Move the definition of CONFIG to the right place; Print the proper value for submission status in the error log; Remove an unused list of all hubs; Remove some unneeded braces; Kill an accidentally-resurrected comment. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 28 May, 2004 1 commit
-
-
Alan Stern authored
This patch changes the return codes used by hub_port_wait_reset(), hub_port_reset(), and hub_port_debounce() in hub.c. I couldn't stand the {-1=error, 0=okay, 1=disconnect} scheme; the meanings seemed arbitrary and I constantly forgot which number stood for what status. The revised code uses normal negative error codes, including -ENOTCONN to indicate device disconnected, or 0 for success. Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 25 May, 2004 2 commits
-
-
Alan Stern authored
As part of the cleanup effort, I wanted to name all the variables in hub.c uniformly. Currently there are different names for the same thing in different routines, and the same names are used for different things -- it's impossible to keep things straight. I also wanted to step away from the deplorable practice of naming everything "dev". It is not an exaggeration that up until relatively recently one of the drivers (not the hub driver, fortunately!) contained a line which looked basically like this: dev->dev.dev = &intf->dev; If you can make sense out of that, you're a better code reader than I am! Ranting aside, this patch institutes the following name scheme for local variables in hub.c: hub: struct usb_hub hdev: hub's corresponding struct usb_device hub_dev: hub interface's embedded struct device udev: general struct usb_device There are a couple of genuine code changes hidden in there too. Just trivial things, like creating a local hub_dev variable for use in place of &hub->intf->dev.
-
Alan Stern authored
This patch adds usb_release_address() as a complement to usb_choose_address(), to centralize the work required when freeing an allocated device address. It also moves the usb_set_address() routine from usb.c to hub.c -- which is the only place it is ever used -- and renames it to hub_set_address().
-
- 18 May, 2004 1 commit
-
-
Greg Kroah-Hartman authored
-
- 17 May, 2004 1 commit
-
-
Oliver Neukum authored
this makes the core use the new safe waiting helper. - remove wait_ms from hub driver
-
- 11 May, 2004 1 commit
-
-
David Brownell authored
This goes with the OHCI anti-deadlock patch, and is what ensures that when a root hub loses power during suspend, khubd can turn port power back on so devices can enumerate.
-
- 05 May, 2004 1 commit
-
-
Alan Stern authored
This patch imports the changes that David Brownell has made to the device-reset functions in his gadget-2.6 tree. Once these ongoing troubling questions about locking are settled, I'll add support for the "descriptors changed" case.
-
- 28 Apr, 2004 1 commit
-
-
David Brownell authored
> 2) An undefined 'hubstatus' variable in drivers/usb/core/hub.c: > > CC drivers/usb/core/hub.o > drivers/usb/core/hub.c: In function `hub_port_connect_change': > drivers/usb/core/hub.c:1343: error: `hubstatus' undeclared (first use in this function) > drivers/usb/core/hub.c:1343: error: (Each undeclared identifier is reported only once > drivers/usb/core/hub.c:1343: error: for each function it appears in.) > make[3]: *** [drivers/usb/core/hub.o] Error 1 > > As a total shot in the dark, the following fixes the build (I've no clue > if it is the right fix): Yes, it's the right fix. Greg, please merge the attached patch, which will be needed on any big-endian system.
-
- 23 Apr, 2004 2 commits
-
-
David Brownell authored
This goes on top of the other enumeration patch I just sent, to handle some dubious and/or broken hub configurations better. Make khubd handle some cases better: - Track power budget for bus-powered hubs. This version only warns when the budgets are exceeded. Eventually, the budgets should help prevent such errors. - Rejects illegal USB setup: two consecutive bus powered hubs would exceed the voltage drop budget, causing much flakiness. - For hosts with high speed hubs, warn when devices are hooked up to full speed hubs if they'd be faster on a high speed one. - For hubs that don't do power switching, don't try to use it - For hubs that aren't self-powered, don't report local power status
-
David Brownell authored
This is an update to some patches from the December/January timeframe, which will help sort out some of the mess for drivers that need to use the reset logic. It's one of the last significant patches in my gadget-2.6 tree that haven't yet been merged into the main kernel tree. More refactoring of the enumeration code paths: * The first half of usb_new_device() becomes the second half of a new hub_port_init() routine (resets, sets address, gets descriptor) * The middle chunk of hub_port_connect_change() becomes the first half of that new hub_port_init() routine. * Khubd uses that new routine in hub_port_connect_change(). * Now usb_new_device() cleans up better after faults, and has a more useful locking policy (caller owns dev->serialize). * Has related minor cleanups including commenting some of the curious request sequences coming from khubd. Refactoring means a lot of the current usb_reset_device() logic won't need to stay an imperfect clone of the enumeration code ... soon, it can just call hub_port_init(). Even without touching usb_reset_device(), this eliminates a deadlock. Previously, address0_sem was used both during probe and during reset, so probe routines can't implement DFU firmware download (involves a reset; DFU also uncovers other problems) or safely recover from probe faults by resetting (usb-storage can try that). Now that lock is no longer held during probe(); so those deadlocks are gone. (And some drivers, like at76c503, can start to remove ugly workarounds.)
-
- 19 Apr, 2004 1 commit
-
-
Andrew Morton authored
From: Nigel Cunningham <ncunningham@users.sourceforge.net> A few weeks ago, Pavel and I agreed that PF_IOTHREAD should be renamed to PF_NOFREEZE. This reflects the fact that some threads so marked aren't actually used for IO while suspending, but simply shouldn't be frozen. This patch, against 2.6.5 vanilla, applies that change. In the refrigerator calls, the actual value doesn't matter (so long as it's non-zero) and it makes more sense to use PF_FREEZE so I've used that.
-
- 02 Apr, 2004 1 commit
-
-
David Brownell authored
The per-port LEDs on the most USB 2.0 hubs are programmable. And the USB spec describes some ways to use them, blinking to alert users about hardware (amber) or software (green) problems. This patch is the infrastructure for that blinking. And if you should happen to "modprobe usbcore blinkenlights", the LEDs will cycle through all the ports ... which is not a USB-standard mode, but it can certainly handy be handy as a system heartbeat visible across the room.
-
- 30 Mar, 2004 1 commit
-
-
David Brownell authored
I've posted all these before, the only notable change is treating that one gphoto2 case as warn-and-continue rather than return-with-failure. usb_set_configuration() cleanup * Remove it from the USB kernel driver API. No drivers need it now, and the sysadmin can change bConfigurationValue using sysfs (say, when hotplugging an otherwise problematic device). * Simpler/cleaner locking: caller must own dev->serialize. * Access from usbfs now uses usb_reset_configuration() sometimes, preventing sysfs thrash, and warns about some dangerous usage (which gphoto2 and other programs may be relying on). (This is from Alan Stern, but I morphed an error return into a warning.) * Prevent a couple potential "no configuration" oopses. (Alan's?) * Remove one broken call from usbcore, in the "device morphed" path of usb_reset_device(). This should be more polite now, hanging that one device rather than khubd.
-
- 25 Mar, 2004 1 commit
-
-
David Brownell authored
Some boot-time messages were obnoxiously long because they used "old-style" diagnostics. OSDL bugid 481 Get rid of most remaining "old style" diagnostics from usbcore. Most messages use driver model style diagnostics. Messages that don't have an associated device use the standard kernel printk wrappers and label themselves as from "usbcore". (Except that there's no such wrapper for KERN_ERR.) This doesn't touch usbfs, "config.c" (Alan's patches do this), or usb_reset_device() (needs a more substantial overhaul). Or any other USB drivers (notably HID).
-
- 03 Mar, 2004 1 commit
-
-
Alan Stern authored
This patch continues the work of as209 by converting the rest of usbcore to use cur_altsetting in place of act_altsetting. The changes required are fairly small, just in the sysfs attributes and hub configuration.
-
- 18 Feb, 2004 1 commit
-
-
David Brownell authored
[USB] hub driver turns on multi-TT mode This turns on the multi-tt mode in hubs that support it; the Cypress "TetraHub" products are appearing at retail now, complete with some of the first Mini-B connectors I've seen shipping. This will be important for hooking up lots of full speed isochronous devices (audio, video, etc).
-
- 09 Feb, 2004 1 commit
-
-
David Brownell authored
This patch starts dis-entangling some of the enumeration logic by moving initialization code into the usb_alloc_dev() constructor. Some call signatures changed; a usbcore-internal declaration was moved in <linux/usb.h> to a more appropriate location. With the driver model init now more centralized, it's safer to use driver model calls (including dev_info) a lot earlier, so the "new device at address N" message now does that. It also reports the device speed, which may not be evident otherwise.
-
- 29 Jan, 2004 1 commit
-
-
Kevin Owen authored
I have a patch for a typo in the 2.6.0 kernel, drivers/usb/core/hub.c, in hub_clear_tt_buffer, the value USB_DIR_IN | USB_RECIP_OTHER is used for bmRequestType, when section 11.24.2 of the spec says it should really be USB_RT_PORT, or 00100011b. After limited testing, this change exhibited better recovery from TT errors, here's the patch :
-
- 26 Jan, 2004 1 commit
-
-
Alan Stern authored
-
- 09 Dec, 2003 2 commits
-
-
Herbert Xu authored
This patch was integrated by you in 2.4 six months ago. Unfortunately it never got into 2.5. Without it you can end up with crashes such as http://bugs.debian.org/218670
-
Alan Stern authored
-
- 08 Dec, 2003 1 commit
-
-
Alan Stern authored
It improves synchronization with hub_irq() and guarantees that the hub disconnect() routine doesn't exit until the URB's completion routine has finished.
-