1. 25 May, 2004 8 commits
    • Alan Stern's avatar
      [PATCH] USB: Make usb_choose_configuration() a separate subroutine · 378ca813
      Alan Stern authored
      This patch creates a separate subroutine to encapsulate the work required
      in choosing an initial configuration for a device.  In my opinion that
      reflects a policy decision that should be kept apart from all the other
      work involved in creating a new device structure.  The existing code in
      usb_new_device() is simply moved into usb_choose_configuration().
      378ca813
    • Alan Stern's avatar
      [PATCH] USB: Add usb_release_address() and move usb_set_address() · ad12579b
      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().
      ad12579b
    • Alan Stern's avatar
      [PATCH] USB: Change "driverfs" to "sysfs" in usbcore · d7a3f44d
      Alan Stern authored
      Before fixing up the device locking and device reset code, I want to do
      some cleanups of the hub driver and related areas.  This is the first of a
      series of patches for that purpose.
      
      This patch changes all the occurrences of "driverfs" in usbcore to "sysfs"
      -- I just couldn't stand seeing the out-of-date name any more (and I kept
      confusing it with usbfs, don't know why).
      
      Although I did a "bk mv driverfs.c sysfs.c" when creating the patch, the
      exported patch file itself doesn't reflect that very well.  It looks like
      driverfs.c was deleted and sysfs.c created from scratch.  If you prefer, I
      can resubmit this in a slightly different form, with the file name
      unchanged so that you can issue the "bk mv" command in your repository
      after applying the patch.
      d7a3f44d
    • Alan Stern's avatar
      [PATCH] USB UHCI: allow URBs to be unlinked when IRQs don't work · 0c4391c9
      Alan Stern authored
      A lot of people with USB controllers made by VIA have been suffering from
      the fact that these controllers stop working when they receive a babble
      packet.  In particular, they stop generating interrupt requests.  Since
      the UHCI driver relies on IRQs from the controller for proper timing and
      interlocking of unlink requests, this means that those broken controllers
      will hang the UHCI driver and drivers for any device connected through it.
      
      This patch, written by Herbert Xu, gives the UCHI driver the ability to
      manage the unlink procedure using timer interrupts as well as controller
      interrupts.  (It also fixes a race in the UHCI irq handler.)  Although it
      won't prevent the VIA controllers from flaking out when they encounter
      babble, at least now users will be able to rmmod the uhci-hcd driver and
      then reload it, restoring their systems back to normal operation (until
      the next babble!).
      
      P.S.: Herbert, there's one loose end I still want to tie up.  When the
      controller isn't running (i.e., is suspended) the frame number won't
      change, but unlinks still need to work.  It's a small point, not too
      likely to come up in normal usage.  I'll fix it later on when I update the
      state-changing part of the driver.
      0c4391c9
    • Alan Stern's avatar
      [PATCH] USB: Initially read 9 bytes of config descriptor · a8a5d436
      Alan Stern authored
      This patch reads the full 9 bytes of a configuration descriptor during
      enumeration rather than just the first 8 bytes.  That's how Windows does
      it, and today I ran across a device that doesn't work properly when asked
      to send only 8 bytes worth.  I doubt very much this will cause any
      problems with currently-working devices; since the descriptor itself is 9
      bytes long and since the devices are most likely to expect a 9-byte
      request, anything that can handle an 8-byte request should have no
      difficulty.  (Also, some debugging messages have been slightly improved.)
      
      Incidentally, USB traces taken from Windows 2000 and Windows XP show that
      when those operating systems retrieve a string descriptor during
      enumeration, they do so by requesting a 255-byte transfer.  They do not
      first ask just for the initial 2 bytes (which contain the actual length)
      and then ask for the actual length, which is what we do.  Interestingly,
      back in 2.4 we _did_ do things the same as Windows.
      a8a5d436
    • Joe Nardelli's avatar
      [PATCH] USB: visor: Fix Oops on disconnect · ff9f1839
      Joe Nardelli authored
      This fixes http://bugme.osdl.org/show_bug.cgi?id=2289
      
      This patch has been tweaked by greg@kroah.com
      ff9f1839
    • Olaf Hering's avatar
      [PATCH] USB: out of bounds access in hiddev_cleanup · 3a386413
      Olaf Hering authored
      hiddev_table[] is an array of pointers.  the minor number is used as an
      offset.  hiddev minors start either with zero, or with 96.  If they start
      with 96, the offset must be reduced by HIDDEV_MINOR_BASE because only 16
      minors are available.  unplugging a hiddevice will zero data outside the
      hiddev_table array.
      
      this was spotted by Takashi Iwai.
      3a386413
    • James Lamanna's avatar
      [PATCH] USB: Fix down() in hard IRQ in powermate driver · 6dbb845a
      James Lamanna authored
      Fixes this warning:
      
      May 18 06:56:01 Knoppix kernel: Debug: sleeping function called from
      invalid context at include/asm/semaphore.h:119
      May 18 06:56:01 Knoppix kernel: in_atomic():1, irqs_disabled():0
      May 18 06:56:01 Knoppix kernel: Call Trace:
      May 18 06:56:01 Knoppix kernel:  [<c0117083>] __might_sleep+0xb2/0xd3
      May 18 06:56:01 Knoppix kernel:  [<f88b92f4>] powermate_config_complete+0x33/0x77 [powermate]
      May 18 06:56:01 Knoppix kernel:  [<c02c6760>] usb_hcd_giveback_urb+0x25/0x39
      May 18 06:56:01 Knoppix kernel:  [<c02d7194>] uhci_finish_urb+0x54/0xa1
      May 18 06:56:01 Knoppix kernel:  [<c02d7224>] uhci_finish_completion+0x43/0x55
      May 18 06:56:01 Knoppix kernel:  [<c02d737d>] uhci_irq+0xf8/0x179
      May 18 06:56:01 Knoppix kernel:  [<c02c67aa>] usb_hcd_irq+0x36/0x67
      May 18 06:56:01 Knoppix kernel:  [<c01060c6>] handle_IRQ_event+0x3a/0x64
      May 18 06:56:01 Knoppix kernel:  [<c0106479>] do_IRQ+0xb8/0x192
      May 18 06:56:01 Knoppix kernel:  [<c0104850>] common_interrupt+0x18/0x20
      
      Attached patch uses spinlocks instead of a semaphore so that we can't sleep
      when in_atomic().
      6dbb845a
  2. 24 May, 2004 12 commits
    • Thomas Wahrenbruch's avatar
      [PATCH] USB: Fix kobil_sct with uhci · 8639d2a4
      Thomas Wahrenbruch authored
      the kobil_sct didn't work with uhci hcds.
      It used usb_fill_bulk_urb instead of usb_fill_int_urb.
      The attached patch fixes this.
      
      It starts reading in open now - this gives apps (CT-API) the chance to
      detect the p'n'p string correctly.
      8639d2a4
    • Mordechai Ovits's avatar
      [PATCH] USB: add support for MS adapter to usb pegasus net driver · f1022df9
      Mordechai Ovits authored
      I took the relevant parts from the patch (not some PHY stuff that was
      irrelevant).  Attached is the patch against stock 2.6.6.
      f1022df9
    • David Brownell's avatar
      [PATCH] USB: PXA 2xx UDC and RNDIS g_ether · e6f3d6a3
      David Brownell authored
      I noticed some problems with the PXA 2xx UDC and the
      RNDIS version of the ethernet-over-usb link:
      
        - Static linking needs more than just two endpoints now
      
        - The endpoint autoconfig misbehaves (sounds like what
          Stefan reported a couple weeks ago)
      
      This patch fixes those two problems, though there are
      a couple others lurking too.
      e6f3d6a3
    • Luiz Capitulino's avatar
      [PATCH] USB: /usb/gadget/serial.c warning fix. · 7234f3cb
      Luiz Capitulino authored
       that code is generating the fallowing warning:
      
      drivers/usb/gadget/serial.c:162: warning: `debug' defined but not used
      
       When G_SERIAL_DEBUG is not defined, `debug' is not used, because
      the gs_debug() function is compiled only when G_SERIAL_DEBUG is
      defined.
      
       Thus, a solution is to define `debug' only when G_SERIAL_DEBUG
      is defined. That includes the use of `debug' as a module parameter
      (this last part I'm not sure).
      
       The patch bellow does that (compiles ok, not tested because I don't
      have that hardware):
      7234f3cb
    • Oliver Neukum's avatar
      [PATCH] USB: fix fix to kaweth.c · 461b6851
      Oliver Neukum authored
      the previous patch was buggy. The state must be set _before_ the
      condition is checked, or there's a window missing a wakeup.
      This incremental change set fixes that.
      
        - fix race condition with current->state
      461b6851
    • Oliver Neukum's avatar
      [PATCH] USB: waitqueue related problem in kaweth · b0eef108
      Oliver Neukum authored
      this was buggy for the same reason that the old msleep was buggy.
      
        - safe waiting in case we are left on other wait queues
      b0eef108
    • Oliver Neukum's avatar
      [PATCH] USB: yet another place for msleep · 662be4ac
      Oliver Neukum authored
      this is in kobil_sct.
      It uses msleep() and replaces needless GFP_ATOMICs with GFP_NOIO
      as this function can sleep.
      
        - no need for GFP_ATOMIC
        - use msleep()
      662be4ac
    • Oliver Neukum's avatar
      [PATCH] USB: clean delays for ehci · 1a9461b6
      Oliver Neukum authored
      Here's one you overlooked.
      
        - safe sleep helper
      1a9461b6
    • Martin Habets's avatar
      [PATCH] USB: usblp printer GET_DEVICE_ID fix · 83d55856
      Martin Habets authored
      There is a problem in the usblp GET_DEVICE_ID ioctl() implementation. The patch
      below (against 2.6 current) fixes the code to be according to the official usb
      printer spec.
      
      Most printers are not affected by this fix, as they use interface 0 and
      alternate 0. For those, nothing changes. But my printer/scanner uses interface
      1 for the printer.
      83d55856
    • Linus Torvalds's avatar
      Merge http://linux-sound.bkbits.net/linux-sound · 91d7f4e3
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      91d7f4e3
    • James Bottomley's avatar
      [PATCH] pa-risc: kernel/fork.c broken by the new rmap · be4284e3
      James Bottomley authored
      Any architecture (like pa-risc) that makes use of the helper function
      flush_dcache_mmap_lock() won't compile with the new rmap due to use of
      the wrong "mapping". 
      
      Trivial fix.
      be4284e3
    • Linus Torvalds's avatar
      Merge bk://linux-scsi.bkbits.net/scsi-for-linus-2.6 · dcde1f6f
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      dcde1f6f
  3. 23 May, 2004 16 commits
  4. 22 May, 2004 4 commits
    • Linus Torvalds's avatar
      Linux 2.6.7-rc1 · 86042707
      Linus Torvalds authored
      86042707
    • Roland McGrath's avatar
      [PATCH] bogus sigaltstack calls by rt_sigreturn · ce34221e
      Roland McGrath authored
      There is a longstanding bug in the rt_sigreturn system call.
      This exists in both 2.4 and 2.6, and for almost every platform.
      
      I am referring to this code in sys_rt_sigreturn (arch/i386/kernel/signal.c):
      
      	if (__copy_from_user(&st, &frame->uc.uc_stack, sizeof(st)))
      		goto badframe;
      	/* It is more difficult to avoid calling this function than to
      	   call it and ignore errors.  */
      	/*
      	 * THIS CANNOT WORK! "&st" is a kernel address, and "do_sigaltstack()"
      	 * takes a user address (and verifies that it is a user address). End
      	 * result: it does exactly _nothing_.
      	 */
      	do_sigaltstack(&st, NULL, regs->esp);
      
      As the comment says, this is bogus.  On vanilla i386 kernels, this is just
      harmlessly stupid--do_sigaltstack always does nothing and returns -EFAULT.
      
      However this code actually bites users on kernels using Ingo Molnar's 4G/4G
      address space layout changes.  There some kernel stack address might very
      well be a lovely and readable user address as well.  When that happens, we
      make a sigaltstack call with some random buffer, and then the fun begins.
      
      To my knowledge, this has produced trouble in the real world only for 4G
      i386 kernels (RHEL and Fedora "hugemem" kernels) on machines that actually
      have several GB of physical memory (and in programs that are actually using
      sigaltstack and handling a lot of signals).  However, the same clearly
      broken code has been blindly copied to most other architecture ports, and
      off hand I don't know the address space details of any other well enough to
      know if real kernel stack addresses and real user addresses are in fact
      disjoint as they are on i386 when not using the nonstandard 4GB address
      space layout.
      
      The obvious intent of the call being there in the first place is to permit
      a signal handler to diddle its ucontext_t.uc_stack before returning, and
      have this effect a sigaltstack call on the signal handler return.  This is
      not only an optimization vs doing the extra system call, but makes it
      possible to make a sigaltstack change when that handler itself was running
      on the signal stack.  AFAICT this has never actually worked before, so
      certainly noone depends on it.  But the code certainly suggests that
      someone intended at one time for that to be the behavior.  Thus I am
      inclined to fix it so it works in that way, though it has not done so before.
      It would also be reasonable enough to simply rip out the bogus call and not
      have this functionality.
      
      From the current state of code in both 2.4 and 2.6, there is no fathoming
      how this broken code came about.  It's actually much simpler to just make
      it work!  I can only presume that at some point in the past the sigaltstack
      implementation functions were different such that this made sense.  Of the
      few ports I've looked at briefly, only the ppc/pc64 porters (go paulus!)
      actually tried to understand what the i386 code was doing and implemented
      it correctly rather than just carefully transliterating the bug.
      
      The patch below fixes only the i386 and x86_64 versions.  The x86_64
      patches I have not actually tested.  I think each and every arch (except
      ppc and ppc64) need to make the corresponding fixes as well.  Note that
      there is a function to fix for each native arch, and then one for each
      emulation flavor.  The details differ minutely for getting the calls right
      in each emulation flavor, but I think that most or all of the arch's with
      biarch/emulation support have similar enough code that each emulation
      flavor's fix will look very much like the arch/x86_64/ia32/ia32_signal.c
      patch here.
      ce34221e
    • Andrew Morton's avatar
      [PATCH] partial prefetch for vma_prio_tree_next · ad9beb31
      Andrew Morton authored
      From: Rajesh Venkatasubramanian <vrajesh@umich.edu>
      
      This patch adds prefetches for walking a vm_set.list.  Adding prefetches
      for prio tree traversals is tricky and may lead to cache trashing.  So this
      patch just adds prefetches only when walking a vm_set.list.
      
      I haven't done any benchmarks to show that this patch improves performance.
       However, this patch should help to improve performance when vm_set.lists
      are long, e.g., libc.  Since we only prefetch vmas that are guaranteed to
      be used in the near future, this patch should not result in cache trashing,
      theoretically.
      
      I didn't add any NULL checks before prefetching because prefetch.h clearly
      says prefetch(0) is okay.
      ad9beb31
    • Andrew Morton's avatar
      [PATCH] rmap 40 better anon_vma sharing · 17e8935f
      Andrew Morton authored
      From: Hugh Dickins <hugh@veritas.com>
      
      anon_vma rmap will always necessarily be more restrictive about vma merging
      than before: according to the history of the vmas in an mm, they are liable to
      be allocated different anon_vma heads, and from that point on be unmergeable.
      
      Most of the time this doesn't matter at all; but in two cases it may matter.
      One case is that mremap refuses (-EFAULT) to span more than a single vma: so
      it is conceivable that some app has relied on vma merging prior to mremap in
      the past, and will now fail with anon_vma.  Conceivable but unlikely, let's
      cross that bridge if we come to it: and the right answer would be to extend
      mremap, which should not be exporting the kernel's implementation detail of
      vma to user interface.
      
      The other case that matters is when a reasonable repetitive sequence of
      syscalls and faults ends up with a large number of separate unmergeable vmas,
      instead of the single merged vma it could have.
      
      Andrea's mprotect-vma-merging patch fixed some such instances, but left other
      plausible cases unmerged.  There is no perfect solution, and the harder you
      try to allow vmas to be merged, the less efficient anon_vma becomes, in the
      extreme there being one to span the whole address space, from which hangs
      every private vma; but anonmm rmap is clearly superior to that extreme.
      
      Andrea's principle was that neighbouring vmas which could be mprotected into
      mergeable vmas should be allowed to share anon_vma: good insight.  His
      implementation was to arrange this sharing when trying vma merge, but that
      seems to be too early.  This patch sticks to the principle, but implements it
      in anon_vma_prepare, when handling the first write fault on a private vma:
      with better results.  The drawback is that this first write fault needs an
      extra find_vma_prev (whereas prev was already to hand when implementing
      anon_vma sharing at try-to-merge time).
      17e8935f