An error occurred fetching the project authors.
  1. 04 Apr, 2003 1 commit
  2. 14 Mar, 2003 1 commit
  3. 11 Jan, 2003 2 commits
  4. 27 Dec, 2002 1 commit
  5. 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
  6. 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
  7. 16 Sep, 2002 1 commit
  8. 12 Sep, 2002 1 commit
    • Jose A. Lopez's avatar
      [PATCH] usbmidi patch · 6cbd4aa9
      Jose A. Lopez authored
      I have changed the name of a local variable "l" to be "j", because with some
      fonts should be difficult to see if [1+l+i] means [2+i] or what.
      6cbd4aa9
  9. 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
  10. 18 Jun, 2002 1 commit
  11. 07 Jun, 2002 1 commit
  12. 05 Jun, 2002 1 commit