1. 12 Oct, 2007 2 commits
    • Alan Stern's avatar
      USB: mutual exclusion for EHCI init and port resets · 32fe0198
      Alan Stern authored
      
      
      This patch (as999) fixes a problem that sometimes shows up when host
      controller driver modules are loaded in the wrong order.  If ehci-hcd
      happens to initialize an EHCI controller while the companion OHCI or
      UHCI controller is in the middle of a port reset, the reset can fail
      and the companion may get very confused.  The patch adds an
      rw-semaphore and uses it to keep EHCI initialization and port resets
      mutually exclusive.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarDavid Brownell <david-b@pacbell.net>
      Cc: David Miller <davem@davemloft.net>
      Cc: Dely L Sy <dely.l.sy@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      32fe0198
    • Alan Stern's avatar
      USB: make HCDs responsible for managing endpoint queues · e9df41c5
      Alan Stern authored
      
      
      This patch (as954) implements a suggestion of David Brownell's.  Now
      the host controller drivers are responsible for linking and unlinking
      URBs to/from their endpoint queues.  This eliminates the possiblity of
      strange situations where usbcore thinks an URB is linked but the HCD
      thinks it isn't.  It also means HCDs no longer have to check for URBs
      being dequeued before they were fully enqueued.
      
      In addition to the core changes, this requires changing every host
      controller driver and the root-hub URB handler.  For the most part the
      required changes are fairly small; drivers have to call
      usb_hcd_link_urb_to_ep() in their urb_enqueue method,
      usb_hcd_check_unlink_urb() in their urb_dequeue method, and
      usb_hcd_unlink_urb_from_ep() before giving URBs back.  A few HCDs make
      matters more complicated by the way they split up the flow of control.
      
      In addition some method interfaces get changed.  The endpoint argument
      for urb_enqueue is now redundant so it is removed.  The unlink status
      is required by usb_hcd_check_unlink_urb(), so it has been added to
      urb_dequeue.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: David Brownell <david-b@pacbell.net>
      CC: Olav Kongas <ok@artecdesign.ee>
      CC: Tony Olech <tony.olech@elandigitalsystems.com>
      CC: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e9df41c5
  2. 21 Aug, 2007 1 commit
    • Linus Torvalds's avatar
      Revert "USB: EHCI cpufreq fix" · 8eb891fc
      Linus Torvalds authored
      This reverts commit 196705c9
      
      .  It was
      reported to cause a regression by Daniel Exner, and Arjan van de Ven
      points out that we actually already have infrastructure in place for
      setting limits on acceptable DMA latency that would be the much more
      correct fix for the problem with some Broadcom EHCI controllers.
      
      Fixed up trivial conflicts due to the changes to support big-endian host
      controller descriptors in drivers/usb/host/{ehci-sched.c,ehci.h}.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8eb891fc
  3. 12 Jul, 2007 7 commits
  4. 08 May, 2007 1 commit
  5. 11 Apr, 2007 1 commit
    • Alan Stern's avatar
      EHCI: fix remote wakeup regression in 2.6.21-rc · 61e8b858
      Alan Stern authored
      
      
      There is one significant difference between the behavior of root hubs
      (as embodied in host controller hardware) and external hubs: When a
      remote-wakeup signal is received, an external hub sends an interrupt
      message at the _end_ of the resume sequence but a root hub generates
      and interrupt at the _beginning_ of the resume sequence.  The host
      system must poll for the end of the sequence.
      
      When ehci-hcd was converted to interrupt-driven operation instead of
      using polling, the remaining need for this particular poll was
      overlooked.  This patch (as894) fixes the problem.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      61e8b858
  6. 16 Feb, 2007 2 commits
  7. 15 Feb, 2007 1 commit
  8. 07 Feb, 2007 4 commits
  9. 01 Dec, 2006 2 commits
    • Alan Stern's avatar
      EHCI: Fix root-hub and port suspend/resume problems · 8c03356a
      Alan Stern authored
      
      
      This patch (as738b) fixes numerous problems in the controller/root-hub
      suspend/resume/remote-wakeup support in ehci-hcd:
      
      	The bus_resume() routine should wake up only the ports that
      	were suspended by bus_suspend().  Ports that were already
      	suspended should remain that way.
      
      	The interrupt mask is used to detect loss of power in the
      	bus_resume() routine (if the mask is 0 then power was lost).
      	However bus_suspend() always sets the mask to 0.  Instead the
      	mask should retain its normal value, with port-change-detect
      	interrupts disabled if remote wakeup is turned off.
      
      	The interrupt mask should be reset to its correct value at the
      	end of bus_resume() regardless of whether power was lost.
      
      	bus_resume() reinitializes the operational registers if power
      	was lost.  However those registers are not in the aux power
      	well, hence they can lose their values whenever the controller
      	is put into D3.  They should always be reinitialized.
      
      	When a port-change interrupt occurs and the root hub is
      	suspended, the interrupt handler should request a root-hub
      	resume instead of starting up the controller all by itself.
      
      	There's no need for the interrupt handler to request a
      	root-hub resume every time a suspended port sends a
      	remote-wakeup request.
      
      	The pci_resume() method doesn't need to check for connected
      	ports when deciding whether or not to reset the controller.
      	It can make that decision based on whether Vaux power was
      	maintained.
      
      	Even when the controller does not need to be reset,
      	pci_resume() must undo the effect of pci_suspend() by
      	re-enabling the interrupt mask.
      
      	If power was lost, pci_resume() must not call ehci_run().
      	At this point the root hub is still supposed to be suspended,
      	not running.  It's enough to rewrite the command register and
      	set the configured_flag.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8c03356a
    • David Brownell's avatar
      USB: add ehci_hcd.ignore_oc parameter · 93f1a47c
      David Brownell authored
      
      
      Certain boards seem to like to issue false overcurrent notifications, for
      example on ports that don't have anything connected to them.  This looks
      like a hardware error, at the level of noise to those ports' overcurrent
      input signals (or non-debounced VBUS comparators).  This surfaces to users
      as truly massive amounts of syslog spam from khubd (which is appropriate
      for real hardware problems, except for the volume from multiple ports).
      
      Using this new "ignore_oc" flag helps such systems work more sanely, by
      preventing such indications from getting to khubd (and spam syslog).  The
      downside is of course that true overcurrent errors will be masked; they'll
      appear as spontaneous disconnects, without the diagnostics that will let
      users troubleshoot issues like short circuited cables.
      
      Note that the bulk of these reports seem to be with VIA southbridges, but
      I think some were with Intel ones.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      93f1a47c
  10. 17 Oct, 2006 1 commit
  11. 05 Oct, 2006 1 commit
    • David Howells's avatar
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      David Howells authored
      
      
      Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
      of passing regs around manually through all ~1800 interrupt handlers in the
      Linux kernel.
      
      The regs pointer is used in few places, but it potentially costs both stack
      space and code to pass it around.  On the FRV arch, removing the regs parameter
      from all the genirq function results in a 20% speed up of the IRQ exit path
      (ie: from leaving timer_interrupt() to leaving do_IRQ()).
      
      Where appropriate, an arch may override the generic storage facility and do
      something different with the variable.  On FRV, for instance, the address is
      maintained in GR28 at all times inside the kernel as part of general exception
      handling.
      
      Having looked over the code, it appears that the parameter may be handed down
      through up to twenty or so layers of functions.  Consider a USB character
      device attached to a USB hub, attached to a USB controller that posts its
      interrupts through a cascaded auxiliary interrupt controller.  A character
      device driver may want to pass regs to the sysrq handler through the input
      layer which adds another few layers of parameter passing.
      
      I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
      main part of the code on FRV and i386, though I can't test most of the drivers.
      I've also done partial conversion for powerpc and MIPS - these at least compile
      with minimal configurations.
      
      This will affect all archs.  Mostly the changes should be relatively easy.
      Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
      
      	struct pt_regs *old_regs = set_irq_regs(regs);
      
      And put the old one back at the end:
      
      	set_irq_regs(old_regs);
      
      Don't pass regs through to generic_handle_irq() or __do_IRQ().
      
      In timer_interrupt(), this sort of change will be necessary:
      
      	-	update_process_times(user_mode(regs));
      	-	profile_tick(CPU_PROFILING, regs);
      	+	update_process_times(user_mode(get_irq_regs()));
      	+	profile_tick(CPU_PROFILING);
      
      I'd like to move update_process_times()'s use of get_irq_regs() into itself,
      except that i386, alone of the archs, uses something other than user_mode().
      
      Some notes on the interrupt handling in the drivers:
      
       (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
           the input_dev struct.
      
       (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
           something different depending on whether it's been supplied with a regs
           pointer or not.
      
       (*) Various IRQ handler function pointers have been moved to type
           irq_handler_t.
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      (cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
  12. 27 Sep, 2006 3 commits
  13. 02 Aug, 2006 1 commit
  14. 12 Jul, 2006 1 commit
  15. 30 Jun, 2006 1 commit
  16. 21 Jun, 2006 2 commits
  17. 20 Mar, 2006 2 commits
  18. 04 Jan, 2006 3 commits
  19. 24 Nov, 2005 2 commits
    • David Brownell's avatar
      [PATCH] USB: EHCI updates split init/reinit logic for resume · 18807521
      David Brownell authored
      
      
      Moving the PCI-specific parts of the EHCI driver into their own file
      created a few issues ... notably on resume paths which (like swsusp)
      require re-initializing the controller.  This patch:
      
       - Splits the EHCI startup code into run-once HCD setup code and
         separate "init the hardware" reinit code.  (That reinit code is
         a superset of the "early usb handoff" code.)
      
       - Then it makes the PCI init code run both, and the resume code only
         run the reinit code.
      
       - It also removes needless pci wrappers around EHCI start/stop methods.
      
       - Removes a byteswap issue that would be seen on big-endian hardware.
      
      The HCD glue still doesn't actually provide a good way to do all this
      run-one init stuff in one place though.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      18807521
    • David Brownell's avatar
      [PATCH] USB: EHCI updates · f03c17fc
      David Brownell authored
      
      
      This fixes some bugs in EHCI suspend/resume that joined us over the past
      few releases (as usbcore, PCI, pmcore, and other components evolved):
      
        - Removes suspend and resume recursion from the EHCI driver, getting
          rid of the USB_SUSPEND special casing.
      
        - Updates the wakeup mechanism to work again; there's a newish usbcore
          call it needs to use.
      
        - Provide simpler tests for "do we need to restart from scratch", to
          address another case where PCI Vaux was lost.  (In this case it was
          restoring a swsusp snapshot, but there could be others.)
      
      Un-exports a symbol that was temporarily exported.
      
      A notable change from previous version is that this doesn't move
      the spinlock init, so there's still a resume/reinit path bug.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f03c17fc
  20. 28 Oct, 2005 2 commits
    • Matt Porter's avatar
      [PATCH] EHCI, split out PCI glue · 7ff71d6a
      Matt Porter authored
      
      
      This splits BIOS and PCI specific support out of ehci-hcd.c into
      ehci-pci.c.  It follows the model already used in the OHCI driver
      so support for non-PCI EHCI controllers can be more easily added.
      Signed-off-by: default avatarMatt Porter <mporter@kernel.crashing.org>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
       drivers/usb/host/ehci-hcd.c |  543 ++++++--------------------------------------
       drivers/usb/host/ehci-pci.c |  414 +++++++++++++++++++++++++++++++++
       drivers/usb/host/ehci.h     |    1
       3 files changed, 492 insertions(+), 466 deletions(-)
      7ff71d6a
    • David Brownell's avatar
      [PATCH] remove usb_suspend_device() parameter · 390a8c34
      David Brownell authored
      
      
      This patch removes the extra usb_suspend_device() parameter.  The original
      reason to pass that parameter was so that this routine could suspend any
      active children.  A previous patch removed that functionality ... leaving
      no reason to pass the parameter.  A close analogy is pci_set_power_state,
      which doesn't need a pm_message_t either.
      
      On the internal code path that comes through the driver model, the parameter
      is now used to distinguish cases where USB devices need to "freeze" but not
      suspend.   It also checks for an error case that's accessible through sysfs:
      attempting to suspend a device before its interfaces (or for hubs, ports).
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
       drivers/usb/core/hub.c         |   34 +++++++++++++++++++++-------------
       drivers/usb/core/usb.c         |   23 +++++++++++++++++++++--
       drivers/usb/host/ehci-hcd.c    |    2 +-
       drivers/usb/host/isp116x-hcd.c |    2 +-
       drivers/usb/host/ohci-pci.c    |    2 +-
       include/linux/usb.h            |    2 +-
       6 files changed, 46 insertions(+), 19 deletions(-)
      390a8c34