An error occurred fetching the project authors.
  1. 29 May, 2003 2 commits
  2. 19 May, 2003 1 commit
  3. 04 Apr, 2003 1 commit
  4. 25 Mar, 2003 1 commit
  5. 21 Mar, 2003 1 commit
  6. 19 Mar, 2003 1 commit
    • Oleg Drokin's avatar
      [PATCH] USB: Memleak in drivers/usb/hub.c::usb_reset_device · 401abfce
      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:
      401abfce
  7. 14 Mar, 2003 1 commit
  8. 06 Mar, 2003 1 commit
    • David Brownell's avatar
      [PATCH] USB: track usb ch9 device state · b3dca131
      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.
      b3dca131
  9. 26 Feb, 2003 1 commit
  10. 11 Feb, 2003 1 commit
    • Linus Torvalds's avatar
      Sanitize kernel daemon signal handling and process naming. · 43fea1be
      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.
      43fea1be
  11. 13 Jan, 2003 1 commit
  12. 11 Jan, 2003 1 commit
  13. 07 Jan, 2003 1 commit
  14. 30 Dec, 2002 1 commit
  15. 27 Dec, 2002 2 commits
  16. 19 Dec, 2002 1 commit
    • David Brownell's avatar
      [PATCH] usbcore: rm hub oops, message cleanups, unlink · 399b19dc
      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".
      399b19dc
  17. 17 Dec, 2002 1 commit
    • David Brownell's avatar
      [PATCH] hub driver uses dev_info(), less log clutter · 52dc29e6
      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.
      52dc29e6
  18. 10 Dec, 2002 1 commit
  19. 02 Dec, 2002 1 commit
    • David S. Miller's avatar
      [PATCH] kbd_pt_regs · 4a7e8594
      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.
      4a7e8594
  20. 29 Oct, 2002 2 commits
    • David Brownell's avatar
      [PATCH] USB: clean up usb structures some more · 63bc762f
      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.
      63bc762f
    • Josh Myer's avatar
      [PATCH] Eliminate Old Prototypes from 2.5.44 · bc2c10df
      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.
      bc2c10df
  21. 25 Oct, 2002 1 commit
    • David Brownell's avatar
      [PATCH] rm "automagic resubmit" for usb interrupt transfers · e9c72b55
      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'.
      e9c72b55
  22. 13 Oct, 2002 1 commit
    • Art Haas's avatar
      [PATCH] C99 designated initializers for drivers/usb · 53333cc1
      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.
      53333cc1
  23. 11 Oct, 2002 1 commit
    • Adam J. Richter's avatar
      [PATCH] linux-2.5.41/drivers/usb/core/hub.c called down() from interrupt context · 0c9fd8bb
      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.
      0c9fd8bb
  24. 08 Oct, 2002 1 commit
  25. 01 Oct, 2002 1 commit
    • Ingo Molnar's avatar
      [PATCH] Workqueue Abstraction · 6ed12ff8
      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.
      6ed12ff8
  26. 30 Sep, 2002 2 commits
    • David Brownell's avatar
      [PATCH] usbcore misc cleanup · 846f917c
      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.
      846f917c
    • Greg Kroah-Hartman's avatar
      0dfd9af4
  27. 16 Sep, 2002 1 commit
  28. 18 Aug, 2002 1 commit
    • David Brownell's avatar
      [PATCH] misc usbcore cleanups · 7d822283
      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
      7d822283
  29. 01 Aug, 2002 2 commits
    • Pavel Machek's avatar
      [PATCH] swsusp: Vojtech pointed error in usb/hub.c · 4306e20b
      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).
      4306e20b
    • David Brownell's avatar
      [PATCH] USB: driverfs paths · 347563f5
      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.
      347563f5
  30. 19 Jul, 2002 1 commit
    • Rusty Russell's avatar
      [PATCH] drivers/usb/* designated initializer rework · cfe2b798
      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.
      cfe2b798
  31. 18 Jul, 2002 1 commit
  32. 05 Jul, 2002 1 commit
    • David Brownell's avatar
      [PATCH] usb driverfs, +misc · dcc98433
      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)
      dcc98433
  33. 29 May, 2002 1 commit
    • Pavel Machek's avatar
      [PATCH] swsusp: cleanup · d72fb463
      Pavel Machek authored
       - use list_for_each in head_of_free_region
       - cleanups from 2.4
       - fix for usb
       - kill broken queueing
      d72fb463
  34. 22 May, 2002 1 commit
  35. 11 May, 2002 1 commit
    • David Brownell's avatar
      [PATCH] -- hub/tt error recovery · c37126dd
      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
      c37126dd