An error occurred fetching the project authors.
- 23 Apr, 2004 2 commits
-
-
Alan Stern authored
I'm not sure what this piece of code is doing in the UHCI driver. It looks like someone envisioned queuing several URBs for the same endpoint simultaneously. Anyway, the driver can't do that and this code can never run.
-
Alan Stern authored
This patch implements the endpoint_disable method for the UHCI driver, as you requested a while back. It guarantees that during unbinding events (disconnect, configuration change, rmmod) the UHCI driver will have finished using every URB for the interface being unbound. It doesn't quite guarantee that the completion handlers will have finished running, but it would take a pretty unlikely race to violate that assumption. (I think it's the same with the OHCI and EHCI drivers.) Despite the patch numbering this one applies _after_ as249, which is a more important bugfix.
-
- 22 Apr, 2004 1 commit
-
-
Alan Stern authored
A major bug in the UHCI driver turned up recently. Thanks to a lot of help from Simone Gotti it was identified and fixed late last week. It turned out to be entirely my fault -- a previous patch had introduced two (!) errors. (A combination of carelessness and a nasty thinko, and somehow it passed the regression tests...) Anyway, it's entirely possible that many of the problems people have been seeing are caused by that bug. This patch is the solution.
-
- 31 Mar, 2004 1 commit
-
-
Alan Stern authored
This patch changes the UHCI driver's bus-release routine; now it will correctly finish all pending but not-yet-completed URBs. This fixes a reported bug, when trying to rmmod uhci-hcd while using a USB mouse under X. Also, the patch changes a variable name from ...hs... to ...fs... ("high speed" -> "full speed") -- something I accidentally omitted in an earlier patch.
-
- 25 Mar, 2004 3 commits
-
-
Alan Stern authored
This patch introduces a major simplification into the UHCI driver by replacing its multiple spinlocks with a single one. The protected area of code is slightly larger and there's more possibilities for contention on an SMP system, but I think that shouldn't be a problem. Stephen Hemminger has been kind enough to test this on his SMP computer and he hasn't encountered any difficulties.
-
Alan Stern authored
This patch simplies the way the UHCI driver handles short control transfers. When a transfer is short the HC will stop handling that endpoint, and it's necessary to get it going again so that the status stage of the control transfer can take place. Currently the driver does this by allocating a new QH for the transfer and setting its element pointer to point at the final status TD. The old QH is recycled. But it's not necessary to go to all that trouble; the element pointer in the original QH can be updated directly. Normally the element pointer is supposed to be owned by the HC, and it's not safe to just change its value since the HC may overwrite it at any time. But when a transfer is stopped because of a short packet, the current TD is marked inactive and the HC will not update the element pointer. To write an unchanged pointer value back to memory would be a waste of PCI bus cycles. Now the UHCI spec doesn't say explicitly that an HC _can't_ do this, but I've tested both Intel and VIA hardware and neither of them does. As a side effect of this change, some of the code for removing QHs can be eliminated.
-
Alan Stern authored
This patch makes some simple changes to the way the UHCI driver does short packet detection. The current implementation is incorrect in several ways: The Short-Packet-Detect flag is set for OUT transfers, which yields undefined behavior according to the UHCI spec. It's not set for URBs with URB_SHORT_NOT_OK, which is just the opposite of what we want! Those are the ones where short packets do matter. It is set for the last packet in a transfer, which causes an unnecessary pause in the data flow (except of course that the pause _is_ necessary when URB_SHORT_NOT_OK is set). The patch also implements the URB_NO_INTERRUPT flag for bulk transfers, which can help improve system performance by reducing interrupt overhead.
-
- 08 Mar, 2004 1 commit
-
-
Alan Stern authored
Some systems don't save the internal state of the UHCI registers across a PM suspend/resume cycle very well. This patch saves & restores the Frame Number and the Framelist Base Address registers (in addition to the Interrupt Enable register, which was added separately in a recent patch.)
-
- 26 Feb, 2004 5 commits
-
-
Alan Stern authored
This patch is from Stephen Hemminger. I modified it slightly to place the new elements at the end of the complete_list instead of at the front. On Tue, 24 Feb 2004, Stephen Hemminger wrote: > Since the remove_list and complete_list now use the same element for > linking, it is possible to use the list_splice inline to avoid > having to loop over all the urb's
-
Alan Stern authored
On Mon, 23 Feb 2004, Stephen Hemminger wrote: > Bulk and interrupt urb's share common irq processing, why does the > code try to obfuscate it? Quite right; this is needless complexity. (But note you left in a couple of lines that should have been deleted.)
-
Alan Stern authored
This patch changes the result code returned by the UHCI driver for a certain class of errors. Under a number of circumstances a USB device is obliged to send a response packet within a fairly short turn-around time, typically 1 - 10 microseconds depending on the bus speed. Failure to do so is a protocol error and should be reported as such, not as a timeout, which is really a higher-level concept. I believe the EHCI driver already does this. I trust nobody will object to the update this patch adds to Documentation/usb/error-codes.txt, making this more explicit. In a vaguely related change, the patch corrects the terminology in a few comments. The parts of a control transfer are called "stages", not "phases".
-
Alan Stern authored
On Mon, 23 Feb 2004, Chip Salzenberg wrote: > It works ... perfectly! I can now suspend and resume my A30 with > impunity, and the USB keyboard works fine after each resume. > > Thanks much, Alan. > > (Now if I could just get the alsa guys to fix snd-intel8x0...) This patch re-initializes the UHCI Interrupt Enable register following a PM resume. Apparently some systems clear the register during suspend, which causes obvious problems later on.
-
Alan Stern authored
On Mon, 23 Feb 2004, Stephen Hemminger wrote: > Great, the kernel with this patch ran successfully all weekend. Looks like no > more races in the unlink path. Wonderful. Thanks a lot for all your SMP testing, it's been a big help. This patch corrects an error in the dequeueing code for UHCI. Improper locking caused it to hang in the oddball case where an URB was unlinked even before it had been queued.
-
- 19 Feb, 2004 2 commits
-
-
Greg Kroah-Hartman authored
-
Alan Stern authored
The main item in this patch is the conversion of the UHCI driver from using the old usb.h logging macros to the new driver-model dev_xxx macros. There are a few other minor changes too: updated version number, author, copyright, and maintainer information, removed some unneeded error messages, added some line breaks, added a convenience macro for the device pointer.
-
- 18 Feb, 2004 1 commit
-
-
Alan Stern authored
This patch is from David Brownell. UHCI root hub updates ... minor bugfixes and cleanups, improving conformance with the USB hub specification. - UHCI doesn't support any kind of power switching; so modify the hub descriptor to stop claiming it does! Likewise fail attempts to disable power on any port. - Intel defined both overcurrent status overcurrent-change bits, but the current code only knows about one. Modify hub descriptor to report per-port overcurrent protection; and use both bits. - Modify the port status set/clear macros to know about the bits that must always be written as zero, and the write-to-clear bits. Update callers which wrote "set" instead of "clear". - Rewrote code returning port status; magic numbers are gone. - Driver can't really support 8 root hub ports; don't try. Also moves the #define DEBUG earlier so that it can kick in any of the various debug macros ... like pr_debug() and dev_dbg().
-
- 17 Feb, 2004 6 commits
-
-
Deepak Saxena authored
-
Alan Stern authored
Contrary to the UHCI specification document, in real controllers the "HC Halted" bit in the status register cannot be cleared by writing a 1. It will persist for as long as the controller is halted. Hence the bit needs to be masked away before checking whether or not the controller initiated an interrupt. Without this patch, other devices sharing the same IRQ line might not get serviced while the host controller is suspended, because the always-on status bit would cause the UHCI driver to report that it had handled the interrupt.
-
Alan Stern authored
This patch is an amalgam of 9 contributions from Stephen Hemminger. It begins the process of straightening out the use of semaphores and locking in the UHCI driver by removing unneeded irqsaves and irqrestores. It also removes an unnecessary list node and makes a couple of other small changes. clear_next_interrupt only called in IRQ context don't need irqsave/restore Since uhci_finish_completion is only called from IRQ routine, the irqsave/irqrestore is redundant and unnecessary. UHCI transfer_result is only called from IRQ context so irqsave/restore is unnecessary here. uhci_finish_urb is always called from irq so no need for irqsave/irqrestore. uhci_add_complete only called from IRQ context The complete_list element in the urb private data is redundant, since it is only used when the urb is on the complete list. And given the state transitions, an urb can't be on the complete list and any other list (remove, or urb_list). Therefore just use urb_list to link the complete_list Use list_move_tail to move between remove (or urb_list) and the complete_list. Save irq state in uhci_stop so that the irqsave/irqrestore's in all the free_pending and remove_pending code can be eliminated. Since uhci_stop now saves IRQ state, the free/remove pending routines no longer need irqsave/irqrestore.
-
Alan Stern authored
Randy, thanks for forwarding this to me. > Johannes, > > When I compile base kernel 2.6.1 with PAGE_SIZE=64KB on an IA64 > platform, there is an error. > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > drivers/built-in.o(.init.text+0x168a2): In function `uhci_hcd_init': > : undefined reference to `__you_cannot_kmalloc_that_much' > make: *** [.tmp_vmlinux1] Error 1 > > That's because ERRBUF_LEN (equal to PAGE_SIZE*8) is too long when > PAGE_SIZE=64KB. Actually, there was a similar error found by Tony. See > http://marc.theaimsgroup.com/?l=linux-ia64&m=105604765306485&w=2. > > Could you change the definition of ERRBUF_LEN to a fixed value? For > example, 32*1024? > > Yanmin Yanmin, I'm the new maintainer for the UHCI driver. Yep, that's a definite error. This will fix it. Also included in this patch: change some confusing references from "high speed" to "full speed" and add proper hyphenation.
-
Alan Stern authored
This patch evens out the distribution of interrupt transfers for the UHCI driver. It insures that no frame must handle interrupt queues for more than two different periods, thus improving the bandwidth utilization. It also simplifies the initialization code by replacing a multi-nested "if" statement with a simple bit-operation (thanks to Eric Piel for suggesting this approach).
-
Alan Stern authored
This patch removes an unneeded "status" field from the UHCI driver's URB-private data structure. The driver had been storing the status of completed URBs there rather than in the URBs themselves. This not only is wasteful of space but is also a cause of bugs, since the USB core relies on urb->status for proper synchronization with the driver. The patch also takes care of a number of small things that have been bugging me for ages: Close a small loophole by allowing an URB to be unlinked even before the uhci_urb_enqueue() procedure has started. Remove some fossil code from back when interrupt URBs were automagically resubmitted. Giveback unlinked URBs in the order they were unlinked. Don't set urb->status for dequeued URBs; the core has already set it for us. Rename uhci_remove_pending_qhs to uhci_remove_pending_urbps. (That has _really_ bothered me!)
-
- 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.
-
- 06 Feb, 2004 1 commit
-
-
Stephen Hemminger authored
The usb device member in the urb private structure is redundant, it is set but never used.
-
- 05 Feb, 2004 1 commit
-
-
Alan Stern authored
-
- 02 Feb, 2004 1 commit
-
-
Stephen Hemminger authored
Here is a revised version of the irqreturn_t propagation patch. The only difference is now ohci-hcd returns IRQ_HANDLED in the remove case.
-
- 20 Jan, 2004 1 commit
-
-
Alan Stern authored
This patch fixes a long-standing (albeit unidentified) problem in the queueing code for the UHCI HCD. The code propagates data toggle settings between messages in a queue for control transfers just the same as bulk and interrupt transfers. That is a mistake, since control messages always restart with data toggle 0. With this patch, the UHCI driver now passes test 10 (control URB queueing) in David Brownell's usbtest suite. The patch appears to change more than it really does, because it alters the indentation level of a large section of code.
-
- 29 Dec, 2003 1 commit
-
-
Linus Torvalds authored
The BIOS may have left the USB controller in some strange state, and we want to fully initialize it before we are ready to handle interrupts.
-
- 09 Oct, 2003 1 commit
-
-
David Brownell authored
This resolves a bug in osdl bugtraq (#1261) by making some more driver names match their module names. Such mismatches are bad because scripts often need to add special cases, handling multiple names for drivers.
-
- 30 Sep, 2003 1 commit
-
-
Wim Van Sebroeck authored
I saw that you also reported problems with USB/uhci-hcd on your systems. Can you test the following patch and see if it works now?
-
- 23 Sep, 2003 1 commit
-
-
Alexey Dobriyan authored
-
- 02 Sep, 2003 2 commits
-
-
Duncan Sands authored
By the way, let me explain what the problem was with uhci-hcd. The usb hardware directly accesses your computers memory. The bug is that it could still be accessing a bit of memory after uhci-hcd thought it had finished with it and freed up the memory. This bug has always existed, and I guess led to occasional mysterious data corruption, when some other part of the kernel started using that bit of memory while the usb hardware was still playing with it. You turned on the "slab debugging" option, right? With this turned on, when uhci-hcd frees the memory it gets filled with some garbage values. The usb hardware reads this garbage and barfs, giving a "process error". In short, you can also get rid of the process error messages by turning off slab debugging, then the data corruption will be silent again!
-
David Brownell authored
AFAICT this is ready for your next merge with Linus. Ben's ohci stuff was not cooked yet, seemed like the pm stuff wasn't yet supporting the hook(s) he needed. RMK had similar issues w.r.t. PM on ARM too. This patch includes: - updates from Benjamin Herrenschmidt to make usbcore behave a bit better during PM suspend (setting and checking hcd state). - related updates from me, making more paths into hcds fail when the driver is suspended. - updates based on some feedback from Alan Stern, notably including getting rid of a state we don't really need (most of the patch, by volume). - an experiment that tries to give a warning in the sadly common case of ACPI or APIC (etc) settings that need to change before USB works. Net effect is that some of the PM issues start to get resolved, maybe IRQ problems will be diagnosed quicker, and some overdue cleanup gets started.
-
- 27 Aug, 2003 1 commit
-
-
David Brownell authored
This is a straightforward change matching ones sent in for ehci (last month) and ohci (earlier this week). It abstracts the reset operation into something that's called before the pci glue does much to the hardware. It also arranges to kick the BIOS off the hardware before it resets it (not after) ... so there's no confusion at any time about what driver "owns" that hardware. (Again matching what ehci and ohci drivers do.)
-
- 22 Aug, 2003 1 commit
-
-
Greg Kroah-Hartman authored
-
- 06 Aug, 2003 1 commit
-
-
Greg Kroah-Hartman authored
This is because that field is going away shortly...
-
- 30 Jul, 2003 2 commits
-
-
Alan Stern authored
This revised patch includes the change that David Brownell asked for. It renames usb_connect() to usb_choose_address(), no longer exports the function, and adds equivalent functionality to usb_register_root_hub(). It also removes the unnecessary (and incorrect) assignment to bMaxPacketSize0.
-
Greg Kroah-Hartman authored
-
- 17 Jul, 2003 1 commit
-
-
Alan Stern authored
This patch for the UHCI driver changes the test for over current inputs, which can cause false Resume indications with some of Intel's USB controllers. Previously the code only checked for one specific controller chip, but now another one has turned up that exhibits the same flaw. It seems best just to check for Intel being the manufacturer, especially since it doesn't hurt to check for the condition when it isn't present or is only temporary.
-
- 30 Jun, 2003 1 commit
-
-
Greg Kroah-Hartman authored
-