An error occurred fetching the project authors.
- 29 May, 2003 2 commits
-
-
Arnaldo Carvalho de Melo authored
-
Oliver Neukum authored
if we fail with -ENOMEM, we should do it before the device must be reparsed.
-
- 19 May, 2003 1 commit
-
-
Walter Harms authored
-
- 04 Apr, 2003 1 commit
-
-
Oliver Neukum authored
- mutual exclusion between reset() and probe()
-
- 25 Mar, 2003 1 commit
-
-
Oliver Neukum authored
- memory allocation in block io error code path with GFP_KERNEL
-
- 21 Mar, 2003 1 commit
-
-
David Brownell authored
More uniformity-in-diagnostics work, and don't emit a error message in one known non-error case.
-
- 19 Mar, 2003 1 commit
-
-
Oleg Drokin authored
Hello! On Fri, Mar 14, 2003 at 11:37:19AM -0800, Greg KH wrote: > > There seems to be a memleak in drivers/usb/hub.c::usb_reset_device() > > on error exit path. See the patch. > > Found with help of smatch + enhanced unfree script. > And yes, as David said, there is another kind of error in this area for > 2.5. Patches to clean that up would be appreciated. Ok, I guess something like that should work:
-
- 14 Mar, 2003 1 commit
-
-
Steven Cole authored
This spelling and typo cleanup patch was reviewed by Mike Hayes and Jared Daniel J. Smith.
-
- 06 Mar, 2003 1 commit
-
-
David Brownell authored
This patch merges the USB state definitions from the ARM Linux code (inside the sa1100 driver) and uses them to track what can be done with the device. That replaces the recently added "udev->present" flag with a more complete/standard state model. There are a few changes that might affect behavior if things start to go really haywire: - usb_set_address() and usb_set_configuration(), used while enumerating, handle some unlikely cases more correctly: don't allow setting address to zero (undefined behavior), and do allow un-configuring (config 0). (Adds a FIXME for an existing set-configuration bug too.) - usb_disconnect() flags the state change earlier (as soon as it's known). - usb_submit_urb() works in the states where messaging is allowed, and also enforces the "unless configured, only control traffic is legal" rule. - usb_unlink_urb() doesn't care any more about that state. (There seemed to be agreement that it must not matter.) This will help with some further cleanups in the complex of issues relating to driver removal, device removal, config changing (with driver unbind and rebind), reset, and so on.
-
- 26 Feb, 2003 1 commit
-
-
Greg Kroah-Hartman authored
-
- 11 Feb, 2003 1 commit
-
-
Linus Torvalds authored
Add a name argument to daemonize() (va_arg) to avoid all the kernel threads having to duplicate the name setting over and over again. Make daemonize() disable all signals by default, and add a "allow_signal()" function to let daemons say they explicitly want to support a signal. Make flush_signal() take the signal lock, so that callers do not need to.
-
- 13 Jan, 2003 1 commit
-
-
Greg Kroah-Hartman authored
-
- 11 Jan, 2003 1 commit
-
-
Greg Kroah-Hartman authored
-
- 07 Jan, 2003 1 commit
-
-
Greg Kroah-Hartman authored
-
- 30 Dec, 2002 1 commit
-
-
Greg Kroah-Hartman authored
-
- 27 Dec, 2002 2 commits
-
-
Greg Kroah-Hartman authored
This was done to make the next reference count patch easier, and because almost everyone was already calling usb_put_dev() anyway...
-
Greg Kroah-Hartman authored
change dev_set_drvdata() and dev_get_drvdata() to usb_set_intfdata() and usb_get_intfdata()
-
- 19 Dec, 2002 1 commit
-
-
David Brownell authored
These changes are unrelated except I ran into them all at once: - Fixes an oops from a partial hub_configure() clean; let hub_disconnect() do the whole thing, simpler. - Since I was there, modify that routine's err() messages to use dev_err(). Then eliminate a redundant diagnostic in hub_probe(), and merge the "bad descriptor" cases into one diagnostic. Saves a few hundred rodata bytes, and the messages now say what hub's involved. - Unlink fixes: if lower level code reports a submit error, make sure the urb gets unlinked from the device's urb_list; and report "it's already being unlinked" as -EBUSY so callers can do something smarter than wonder "what did I do wrong".
-
- 17 Dec, 2002 1 commit
-
-
David Brownell authored
This patch converts most common hub diagnostics to use the device model diagnostic macros ... not all, someone should reduce the number of err() strings for "bogus hub" cases, and ideally streamline some of the dozen or so "here's what's special about this new hub" dbg() messages. So the messages become more useful: they id the port (and implicitly the device) involved, using a kernel-wide standard convention. Size overhead is smaller too. For folk running with USB debugging enabled, it also cuts the useless chatter on connections by deleting the per-poll success messages and a partial dup message when things change. And it deletes a newish diagnostic on a (non-hub) unlink path. It also makes Pete's new debounce message use the right port number -- one-based, not zero-based. My main issue with this patch is that it doesn't change more messages, but it seems reasonable to merge it anyway.
-
- 10 Dec, 2002 1 commit
-
-
Pete Zaitcev authored
I was getting annoyed that nobody fixed the obviously broken debounce loop, so I had to go ahead and fix that.
-
- 02 Dec, 2002 1 commit
-
-
David S. Miller authored
Hey guys, I really want to kill this thing. The only way to do that is to actually pass the pt_regs all the way down from the interrupt source. It would be a three step process: 1) Add pt_regs arg to serio_interrupt and serio->dev->interrupt() Update all serio->dev drivers and serio_interrupt() invokers. I've done this in the patch below. We must handle pt_regs being NULL, f.e. when the event is via a tty ldisc or a timer for which there is no "pt_regs" context to obtain. 2) At the input layer, push 'regs' down via input_event() into the handlers. Patch below does this as well. 3) Final step to complete this, convert USB to pass the pt_regs that the host controller interrupt receives down to the URB callbacks. This itself was also a multistep process: a) pass regs down from generic host controller layer to hcd driver b) pass regs from hcd driver into urb handler EHCI is problematic here, as it does the URB work in a tasklet :( we need to decide whether we can move the normal URB completion back into the hw interrupt handler or not I think it should be done, I'd basically have my thumbs up my butt if I didn't have Alt-SYSRQ-p register dumps available and that is what EHCI+usbkbd is currently. UHCI and OHCI both complete urbs in hw IRQ context so they are just fine. c) update urb handlers to take the regs arg, make hcd drivers pass it on in I was really bored, so this was also done in the patch below :) We get a USB cleanup for free because of this, a lot of people were defining their own ugly typedefs for what should be usb_complete_t so I fixed that up :-) I also caught a lot of usb_fill_*() call sites casting the completion function pointer to usb_complete_t so the compiler wouldn't help us find necessary fixup if we changed the args again :-( I think I got them all, someone bored should grep the tree for usb_complete_t and fixup any remaining spots where it is used in a cast. I tried to enable as many drivers as possible in a test build but it is possible I did miss a few obscure USB configs. So why do I want to kill kbd_pt_regs so badly? Well, first of all I have to walk through all kinds of hoops on sparc64 to update kbd_pt_regs properly on the USB controller interrupt and I've had a few cases where I had trouble tracking down some kernel bug because kbd_pt_regs could easily be inaccurate if another interrupt came in right after the keyboard USB one. Right now, kbd_pt_regs is not updated at all for USB keyboards on x86 rendering SYSRQ register dumps non-existent in such configurations. This forces it to happen, and because the regs are passed in the context in which the URB completes, it will always be accurate (it will even work properly if I have 5 USB keyboards :-) While doing this, I also noticed a bunch of ancient keyboard drivers in 2.5.x under drivers/char that need to be converted or deleted. They were still calling handle_scancode() !!! :-) drivers/tc has few as well. There is also a stray handle_scancode() reference in a include/asm-parisc/keyboard.h comment I tested this on sparc64 with an OHCI attached USB keyboard, and register dumping works fine etc. Here is just the USB bits.
-
- 29 Oct, 2002 2 commits
-
-
David Brownell authored
This patch splits up the usb structures to have two structs, "usb_XXX_descriptor" with just the descriptor, and "usb_host_XXX" (or something similar) to wrap it and add the "extra" pointers plus the array of related descriptors that the host parsed during enumeration. (2 or 3 words extra in each"usb_host_XXX".) This further matches the "on the wire" data and enables the gadget drivers to share the same header file. Covers all the linux/drivers/usb/* and linux/sound/usb/* stuff, but not a handful of other drivers (bluetooth, iforce, hisax, irda) that are out of the usb tree and will likely be affected.
-
Josh Myer authored
Attached patch is the result of: dignity:~/src/linux-2.5.44 $ for x in `rgrep -l "FILL_.*URB" *`; do cp -v $x $x.backup; cat $x.backup | perl -pe 's/FILL_CONTROL_URB/usb_fill_control_urb/g; s/FILL_BULK_URB/usb_fill_bulk_urb/g; s/FILL_INT_URB/usb_fill_int_urb/g;' > $x; done and a manual removal of the define's in usb.h.
-
- 25 Oct, 2002 1 commit
-
-
David Brownell authored
Here's that promised patch to remove the problematic "automagic resubmit" mode from the API for interrupt transfers. It covers the core (including main HCDs) and a few essential drivers. All urbs now obey a simple rule: submit them once, then wait for some completion callback. Or unlink the urb if you're impatient, canceling the i/o request (which may have been partially completed). Bulk and interrupt transfers now behave the same at the API level, except that only interrupt transfers have bandwidth failure modes. Previously, interrupt transfers were different from bulk transfers in several ways that made limited sense. The only thing that's supposed to be special is achieving service latency guarantees by using the reserved periodic bandwidth. But there were a lot of other restrictions, plus HCD-dependent behaviors/bugs. Doing something like sending a 97 byte message to a device portably was a thing of pain, since the low-level "one packet per interval" rule was pushed up to drivers instead of being handled inside HCDs like it is for bulk, and sending a final "short" packet meant an urb unlink/relink. (Fixing this required UHCI to use a queue of TDs, like EHCI and OHCI; fixed by 2.5.44, and a small change in this patch. I'm not sure the unlink/relink issues have ever been really addressed.) Neither 1-msec transfer intervals nor USB 2.0 "high bandwidth" mode can reliably be serviced without a multi-buffered queue of interrupt transfers. (Comes almost for free with TD queueing; as of 2.5.44 all HCDs should do this.) And then there's "automagic resubmission", which made HCDs keep urbs during their complete() callbacks in a rather curious state ... half-owned by HCD, half-owned by device driver, not exactly linked but maybe not unlinked either. Bug-prone, and hard to test. So that's all gone now! This particular patch - updates the main hcds to use normal urb-completion logic for interrupt transfers, nothing special. (*) - makes usbcore (hub and root hub drivers) expect that, and removes an old kernel 2.3 "urb state confusion" workaround. (urb->dev is no longer nulled to distinguish unlinked urbs, since there's no longer a "half-in/half-out" state.) also the relevent kerneldoc is updated. - enables the 'usbtest' support for interrupt transfers, in both queued and non-queued modes. (but I haven't made time to test this ... the hcds "should" be fine since they use the same code now for bulk and interrupt, and bulk checked out.) - teaches hid-core, usbkbd, and usbmouse how to resubmit interrupt transfers explicitly. usb keyboards/mice work, but some less-common HID devices won't. - updated usb/net drivers (catc, kaweth, pegasus, rtl8150) But it doesn't update all device drivers that use interrupt transfers. The failure mode for un-converted drivers will be that interrupts after the first one get lost, and the fix for those drivers will be simple (see what the drivers here do). (*) It doesn't touch non-{E,O,U}HCI HCDs, like the SL-811HS, since those changes will require hardware as well as some quality time with 'usbtest'.
-
- 13 Oct, 2002 1 commit
-
-
Art Haas authored
Hi. Here's a set of three patches for switching ... drivers/usb/serial/io_ti.c drivers/usb/net/usbnet.c drivers/usb/core/hub.c ... to use C99 named initializers. The patches are all against 2.5.42.
-
- 11 Oct, 2002 1 commit
-
-
Adam J. Richter authored
On second thought after reading Oliver Neukum's question about "shaving off a cycle or two", here is version of my fix for down() being called from interrupt context that uses unlikely() to get the speed advantage that would be available from BUG_ON(), while still ensuring that the condition is executed even if assertions are compiled out.
-
- 08 Oct, 2002 1 commit
-
-
Dave Jones authored
-
- 01 Oct, 2002 1 commit
-
-
Ingo Molnar authored
This is the next iteration of the workqueue abstraction. The framework includes: - per-CPU queueing support. on SMP there is a per-CPU worker thread (bound to its CPU) and per-CPU work queues - this feature is completely transparent to workqueue-users. keventd automatically uses this feature. XFS can now update to work-queues and have the same per-CPU performance as it had with its per-CPU worker threads. - delayed work submission there's a new queue_delayed_work(wq, work, delay) function and a new schedule_delayed_work(work, delay) function. The later one is used to correctly fix former tq_timer users. I've reverted those changes in 2.5.40 that changed tq_timer uses to schedule_work() - eg. in the case of random.c or the tty flip queue it was definitely the wrong thing to do. delayed work means a timer embedded in struct work_struct. I considered using split struct work_struct and delayed_work_struct types, but lots of code actively uses task-queues in both delayed and non-delayed mode, so i went for the more generic approach that allows both methods of work submission. Delayed timers do not cause any other overhead in the normal submission path otherwise. - multithreaded run_workqueue() implementation the run_workqueue() function can now be called from multiple contexts, and a worker thread will only use up a single entryy - this property is used by the flushing code, and can potentially be used in the future to extend the number of per-CPU worker threads. - more reliable flushing there's now a 'pending work' counter, which is used to accurately detect when the last work-function has finished execution. It's also used to correctly flush against timed requests. I'm not convinced whether the old keventd implementation got this detail right. - i switched the arguments of the queueing function(s) per Jeff's suggestion, it's more straightforward this way. Driver fixes: i have converted almost every affected driver to the new framework. This cleaned up tons of code. I also fixed a number of drivers that were still using BHs (these drivers did not compile in 2.5.40). while this means lots of changes, it might ease the QA decision whether to put this patch into 2.5. The pach converts roughly 80% of all tqueue-using code to workqueues - and all the places that are not converted to workqueues yet are places that do not compile in vanilla 2.5.40 anyway, due to unrelated changes. I've converted a fair number of drivers that do not compile in 2.5.40, and i think i've managed to convert every driver that compiles under 2.5.40.
-
- 30 Sep, 2002 2 commits
-
-
David Brownell authored
This has minor usbcore cleanups: DOC: - the changes passing a usb_interface to driver probe() and disconnect() weren't reflected in their adjacent docs. likewise they still said it was possible to get a null usb_device_id (no more). - the (root) hub API restrictions from rmk's ARM patch weren't flagged - mention the non-dma-coherent cache issue for usb_buffer_alloc() - mention disconnect() cleanup issue with usb_{control,bulk}_msg() [ you can't cancel those urbs from disconnect() ] CODE - make driver ioctl() use 'usb_interface' too ... this update also resolves an old 'one instance per device' bad assumption - module locking on driver->ioctl() was goofy, kept BKL way too long and didn't try_inc_mod_count() like the rest of usbcore - hcd unlink code treated iso inappropriately like interrupt; only interrupt still wants that automagic mode - move iso init out of ohci into shared submit_urb logic - remove interrupt transfer length restriction; hcds that don't handle packetization (just like bulk :) should be updated, but device drivers won't care for now.
-
Greg Kroah-Hartman authored
-
- 16 Sep, 2002 1 commit
-
-
Greg Kroah-Hartman authored
-
- 18 Aug, 2002 1 commit
-
-
David Brownell authored
Another cleanup patch: - removes more usbcore-internal symbols from sight of device drivers * some are only for the uhci driver * most are shared just a bit more widely - DEVNUM_ROUND_ROBIN is no longer an internal option - usb_root_hub_string() gone, per the FIXME - various kerneldoc fixes and updates - uses legal value (en-us) for root hub strings - hub driver only shows port fixed/removable for compound devices
-
- 01 Aug, 2002 2 commits
-
-
Pavel Machek authored
We do not want threads exiting because of suspend, so refrigerator should be just before test for signals pending (so it has chance to kill them).
-
David Brownell authored
I noticed a minor goof, basically an open issue coming home to roost. For the root hub, usb_device->devpath was "/" so it caused problems using devpath when constructing names for interfaces. Driverfs doesn't reject it, but of course the resulting directory names can't be used... This patch (untested, but compiles) should make devpath in that case be "0" ... which can't collide with any path through hub ports (first port == "1") so it's possible to use driverfs paths again.
-
- 19 Jul, 2002 1 commit
-
-
Rusty Russell authored
Name: Designated initializers for drivers/usb Author: Rusty Russell Status: Trivial D: The old form of designated initializers are obsolete: we need to D: replace them with the ISO C forms before 2.6. Gcc has always supported D: both forms anyway.
-
- 18 Jul, 2002 1 commit
-
-
Oliver Neukum authored
This is a merge of a bunch of SMP and locking fixes for the USB code that Oliver has sent me (greg k-h) over the past few weeks.
-
- 05 Jul, 2002 1 commit
-
-
David Brownell authored
This fixes a couple issues I noted when I finally spent some time looking at the first version of driverfs support for usb: - "name" fields (really descriptions) aren't very useful. * for devices, they always said "USB device 0000:0000" --> Now they'll only say that when there's nothing better to be said ... --> ... and it's really device 0000:0000! It was using device descriptor fields before they were fetched from the device. --> Uses product and/or manufacturer strings, which most devices have, much like PCI uses the PCI ID database (when it's compiled in) * for interfaces, it was "figure out some name..." --> Now it combines the strings used in the usb_make_path() call with interface number --> Or in the remote chance a device provides an interface string, that's preferred. --> In general, I think the driver for each interface is best suited to describe it; I modified the hub driver to do so. - "bus_id" field * For hub ports, it was wasting code: we know the port already, no need to search for it. Plus, it used 0-index ids not the 1-index ones matching physical labels on hubs, and other user-visible diagnostics. * For interfaces, it mixed the device address with the interface number ... producing unstable IDs that were moreover rather cryptic. Changed: "if0" now, using the interface ID (not index). * For busses, left "usb_bus" alone ... :) - Adds two files exposing current configuration (for devices) and altsetting (for interfaces). - I was getting a useless diagnostic from the hub driver, now it's less useless (it fully identifies the hub)
-
- 29 May, 2002 1 commit
-
-
Pavel Machek authored
- use list_for_each in head_of_free_region - cleanups from 2.4 - fix for usb - kill broken queueing
-
- 22 May, 2002 1 commit
-
-
Greg Kroah-Hartman authored
-
- 11 May, 2002 1 commit
-
-
David Brownell authored
This patch adds missing functionality to the transaction translator support for USB 2.0 hubs: - moves the 'struct usb_tt' definition to "hub.h" from <linux/usb.h> - adds state to it as neeed for some control/bulk error recovery - teaches the hub driver how to use that state (via keventd) - adds a call letting HCDs trigger that recovery
-