1. 04 Jan, 2006 12 commits
    • David Brownell's avatar
      [PATCH] USB: wakeup flag updates (2/3) uhci-hcd · baefbc39
      David Brownell authored
      This makes UHCI stop using the HCD glue wakeup flags to report whether
      the controller can wake the system.  The existing code was wrong anyway;
      having a PCI PM capability doesn't imply it reports PME# is supported.
      
      I skimmed Intel's ICH7 datasheet and that basically says the wakeup
      signaling gets routed only through ACPI registers.  (On the other hand,
      many VIA chips provide the PCI PM capabilities...)  I think that doing
      this correctly with UHCI is going to require the ACPI folk to associate
      the /proc/acpi/wakeup identifiers (and wakeup enable/disable flags)
      with the relevant /sys/devices/pci*/...  devices.
      
      From: David Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      baefbc39
    • David Brownell's avatar
      [PATCH] USB: wakeup flag updates (1/3) sl811-hcd · 0c8624f9
      David Brownell authored
      This makes the SL811 HCD use the driver model wakeup flags for its
      controller, not the flags in the HCD glue (which will be removed).
      
      From: David Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
       drivers/usb/host/sl811-hcd.c |    6 ++++--
       1 file changed, 4 insertions(+), 2 deletions(-)
      0c8624f9
    • David Brownell's avatar
      [PATCH] USB: ehci fix driver model wakeup flags · d97cc2f2
      David Brownell authored
      On some systems, EHCI seems to be getting IRQs too early during driver
      setup ... before the root hub is allocated, in particular, making trouble
      for any code chasing down root hub pointers!  In this case, it seems to
      be safe to just ignore the root hub setting.  Thanks to Rafael J. Wysocki
      for getting this properly tested.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d97cc2f2
    • David Brownell's avatar
      [PATCH] USB: EHCI updates (4/4) driver model wakeup flags · 2c1c3c4c
      David Brownell authored
      This teaches the EHCI driver to use the new driver model wakeup flags,
      replacing the similar ones in the HCD glue.  It also adds a workaround
      for the current glitch whereby PCI init doesn't init the wakeup flags
      from the PCI PM capabilities.  (EHCI controllers don't worry about
      legacy mode; the PCI PM capability would always do the job.)
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2c1c3c4c
    • matthieu castet's avatar
      [PATCH] USB: Eagle and ADI 930 usb adsl modem driver fix · 8d7802ed
      matthieu castet authored
      More care on loading firmware, take into account fw->size can't be zero.
      Signed-off-by: default avatarMatthieu CASTET <castet.matthieu@free.fr>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8d7802ed
    • matthieu castet's avatar
      [PATCH] USB: Eagle and ADI 930 usb adsl modem driver · b72458a8
      matthieu castet authored
      A driver for USB ADSL modems based on the ADI eagle chipset using the
      usb_atm infrastructure.
      
      The managing part was taken from bsd ueagle driver, other parts were
      written from scratch.
      
      The driver uses the in-kernel firmware loader :
      - to load  a first usb firmware when the modem is in pre-firmware state
      - to load the dsp firmware that are swapped in host memory.
      - to load CMV (configuration and management variables) when the modem
      boot. (We can't use options or sysfs for this as there many possible
      values. See
      https://mail.gna.org/public/eagleusb-dev/2005-04/msg00031.html for a
      description of some)
      - to load fpga code for 930 chipset.
      
      The device had 4 endpoints :
      * 2 for data (use by usbatm). The incoming
      endpoint could be iso or bulk. The modem seems buggy and produce lot's
      of atm errors when using it in bulk mode for speed > 3Mbps, so iso
      endpoint is need for speed > 3Mbps. At the moment iso endpoint need a
      patched usbatm library and for this reason is not included in this patch.
      
      * One bulk endpoint for uploading dsp firmware
      
      * One irq endpoint that notices the driver
          - if we need to upload a page of the dsp firmware
          - an ack for read or write CMV and the value (for the read case).
      
      If order to make the driver cleaner, we design synchronous
      (read|write)_cmv :
      -send a synchronous control message to the modem
      -wait for an ack or a timeout
      -return the value if needed.
      
      In order to run these synchronous usb messages we need a kernel thread.
      
      The driver has been tested  with sagem fast 800 modems with different
      eagle chipset revision and with ADI 930 since April 2005.
      Signed-off-by: default avatarMatthieu CASTET <castet.matthieu@free.fr>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b72458a8
    • Alan Stern's avatar
      [PATCH] USB: EHCI: fix conflation of buf == 0 with len == 0 · 6912354a
      Alan Stern authored
      When the ehci-hcd driver prepares a control URB, it tests for a
      zero-length data stage by looking at the transfer_dma value instead of
      the transfer_buffer_length.  (In fact it does this even for non-control
      URBs, which is an additional aspect of the same bug.)
      
      However, under certain circumstances it's possible for transfer_dma to
      be 0 while transfer_buffer_length is non-zero.  This can happen when a
      freshly allocated page (mapped to address 0 and marked Copy-On-Write,
      but never written to) is used as the source buffer for an OUT transfer.
      This patch (as598) fixes the problem.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6912354a
    • Olav Kongas's avatar
      [PATCH] USB: isp116x-hcd: cleanup · 959eea21
      Olav Kongas authored
      The attached patch makes a cleanup of isp116x-hcd. Most of the volume of
      the patch comes from 2 sources: moving the code around to get rid of a
      few function prototypes and reworking register dumping functions/macros.
      Among other things, switched over from using procfs to debugfs.
      
      Cleanup. The following changes were made:
      
      - Rework register dumping code so it can be used for dumping
        to both syslog and debugfs.
      - Switch from procfs to debugfs..
      - Die gracefully on Unrecoverable Error interrupt.
      - Fix memory leak in isp116x_urb_enqueue(), if HC happens to
        die in a narrow time window.
      - Fix a 'sparce' warning (unnecessary cast).
      - Report Devices Removable for root hub ports by default
        (was Devices Permanently Attached).
      - Move bus suspend/resume functions down in code to get rid of
        a few function prototypes.
      - A number of one-line cleanups.
      - Add an entry to MAINTAINERS.
      Signed-off-by: default avatarOlav Kongas <ok@artecdesign.ee>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
       MAINTAINERS                    |    6
       drivers/usb/host/isp116x-hcd.c |  429 ++++++++++++++++-------------------------
       drivers/usb/host/isp116x.h     |   83 +++++--
       3 files changed, 230 insertions(+), 288 deletions(-)
      959eea21
    • Olav Kongas's avatar
      [PATCH] USB: isp116x-hcd: support reiniting HC on resume · 535488fc
      Olav Kongas authored
      Until now the isp116x-hcd had no support to reinitialize the HC on
      resume, if the controller lost its state during suspend. This patch,
      generated against your Oct 26 git tree, adds that support. The patch is
      basically the same as the one tested by Ivan Kalatchev, who reported the
      problem, on 2.6.13.
      
      Please apply,
      
      Support reinitializing the isp116x host controller from scratch on
      resume, if the controller has lost its state.
      Signed-off-by: default avatarOlav Kongas <ok@artecdesign.ee>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      535488fc
    • David Kubicek's avatar
      [PATCH] USB: Converting cdc acm to a ring queue · 61a87adf
      David Kubicek authored
      this patch by David converts the sending queue of the CDC ACM driver
      to a queue of URBs. This is needed for quicker devices. Please apply.
      Signed-Off-By: default avatarOliver Neukum <oliver@neukum.name>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
       drivers/usb/class/cdc-acm.c |  229 ++++++++++++++++++++++++++++++--------------
       drivers/usb/class/cdc-acm.h |   33 +++++-
       2 files changed, 185 insertions(+), 77 deletions(-)
      61a87adf
    • Richard Purdie's avatar
      [PATCH] USB: Add pxa27x OHCI PM functions · 2e1dcc16
      Richard Purdie authored
      Add power management functions for the pxa27x USB OHCI host controller.
      This is a totally rewritten version of the patch by Nicolas Pitre and
      Todd Poynor which accounts for recent USB changes.
      Signed-off-by: default avatarRichard Purdie <rpurdie@rpsys.net>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2e1dcc16
    • Richard Purdie's avatar
      [PATCH] USB: pxa27x OHCI - Separate platform code from main driver · 81f280e2
      Richard Purdie authored
      To allow multiple platforms to use the PXA27x OHCI driver, the platform
      code needs to be moved into the board specific files in
      arch/arm/mach-pxa. This patch does this for mainstone and adds
      preliminary hooks to allow other boards to use the driver.
      
      This has been compile tested for mainstone and successfully run on Spitz
      (Sharp Zaurus SL-C3000) with the addition of an appropriate board
      support file.
      Signed-off-by: default avatarRichard Purdie <rpurdie@rpsys.net>
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Acked-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      81f280e2
  2. 03 Jan, 2006 2 commits
  3. 02 Jan, 2006 2 commits
    • Dag-Erling Smrgrav's avatar
      [PATCH] Avoid namespace pollution in <asm/param.h> · abe842eb
      Dag-Erling Smrgrav authored
      In commit 3D59121003721a8fad11ee72e646fd9d3076b5679c, the x86 and x86-64
      <asm/param.h> was changed to include <linux/config.h> for the
      configurable timer frequency.
      
      However, asm/param.h is sometimes used in userland (it is included
      indirectly from <sys/param.h>), so your commit pollutes the userland
      namespace with tons of CONFIG_FOO macros.  This greatly confuses
      software packages (such as BusyBox) which use CONFIG_FOO macros
      themselves to control the inclusion of optional features.
      
      After a short exchange, Christoph approved this patch
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      abe842eb
    • Benjamin Herrenschmidt's avatar
      [PATCH] powerpc: more g5 overtemp problem fix · f12f4d90
      Benjamin Herrenschmidt authored
      Some G5s still occasionally experience shutdowns due to overtemp
      conditions despite the recent fix. After analyzing logs from such
      machines, it appears that the overtemp code is a bit too quick at
      shutting the machine down when reaching the critical temperature (tmax +
      8) and doesn't leave the fan enough time to actually cool it down. This
      happens if the temperature of a CPU suddenly rises too high in a very
      short period of time, or occasionally on boot (that is the CPUs are
      already overtemp by the time the driver loads).
      
      This patches makes the code a bit more relaxed, leaving a few seconds to
      the fans to do their job before kicking the machine shutown.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f12f4d90
  4. 01 Jan, 2006 2 commits
  5. 31 Dec, 2005 3 commits
    • Linus Torvalds's avatar
      35f349ee
    • Yi Yang's avatar
      [PATCH] Fix false old value return of sysctl · 82c9df82
      Yi Yang authored
      For the sysctl syscall, if the user wants to get the old value of a
      sysctl entry and set a new value for it in the same syscall, the old
      value is always overwritten by the new value if the sysctl entry is of
      string type and if the user sets its strategy to sysctl_string.  This
      issue lies in the strategy being run twice if the strategy is set to
      sysctl_string, the general strategy sysctl_string always returns 0 if
      success.
      
      Such strategy routines as sysctl_jiffies and sysctl_jiffies_ms return 1
      because they do read and write for the sysctl entry.
      
      The strategy routine sysctl_string return 0 although it actually read
      and write the sysctl entry.
      
      According to my analysis, if a strategy routine do read and write, it
      should return 1, if it just does some necessary check but not read and
      write, it should return 0, for example sysctl_intvec.
      Signed-off-by: default avatarYi Yang <yang.y.yi@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      82c9df82
    • Linus Torvalds's avatar
      sysctl: don't overflow the user-supplied buffer with '\0' · 8febdd85
      Linus Torvalds authored
      If the string was too long to fit in the user-supplied buffer,
      the sysctl layer would zero-terminate it by writing past the
      end of the buffer. Don't do that.
      
      Noticed by Yi Yang <yang.y.yi@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8febdd85
  6. 30 Dec, 2005 5 commits
  7. 29 Dec, 2005 14 commits