1. 20 Jan, 2010 1 commit
  2. 11 Dec, 2009 1 commit
  3. 23 Sep, 2009 4 commits
  4. 15 Jun, 2009 1 commit
  5. 07 Jan, 2009 2 commits
    • Vitaly Bordug's avatar
      USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3] · 796bcae7
      Vitaly Bordug authored
      A published errata for ppc440epx states, that when running Linux with
      both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
      error when a high-speed device is connected to the USB2.0, and
      functions normally if OHCI module is not loaded.
      There used to be recommendation to use only hi-speed or full-speed
      devices with specific conditions, when respective module was unloaded.
      Later, it was observed that ohci suspend is enough to keep things
      going, and it was turned into workaround, as explained below.
      Quote from original descriprion:
      The 440EPx USB 2.0 Host controller is an EHCI compliant controller.  In
      USB 2.0 Host controllers, each EHCI controller has one or more companion
      controllers, which may be OHCI or UHCI.  An USB 2.0 Host controller will
      contain one or more ports.  For each port, only one of the controllers
      is connected at any one time. In the 440EPx, there is only one OHCI
      companion controller, and only one USB 2.0 Host port.
      All ports on an USB 2.0 controller default to the companion
      controller.  If you load only an ohci driver, it will have control of
      the ports and any deviceplugged in will operate, although high speed
      devices will be forced to operate at full speed.  When an ehci driver
      is loaded, it explicitly takes control of the ports.  If there is a
      device connected, and / or every time there is a new device connected,
      the ehci driver determines if the device is high speed or not.  If it
      is high speed, the driver retains control of the port.  If it is not,
      the driver explicitly gives the companion controller control of the
      The is a software workaround that uses
      Initial version of the software workaround was posted to
      and later available from amcc.com:
      The patch below is generally based on the latter, but reworked to
      powerpc/of_device USB drivers, and uses a few devicetree inquiries to
      get rid of (some) hardcoded defines.
      Signed-off-by: default avatarVitaly Bordug <vitb@kernel.crashing.org>
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Vikram Pandita's avatar
      USB: Avoid 20ms delay in EHCI resume · 3a4e72cb
      Vikram Pandita authored
      For function ehci_bus_resume()
      - Added flag resume_needed
        No need to wait for 20ms if no port was suspended
      - Change mdelay to msleep
      - release and reacquire the spinlock around mdelay
      Signed-off-by: default avatarvikram pandita <vikram.pandita@ti.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  6. 17 Oct, 2008 1 commit
  7. 29 May, 2008 2 commits
  8. 29 Apr, 2008 1 commit
  9. 28 Apr, 2008 1 commit
  10. 24 Apr, 2008 5 commits
    • Alan Stern's avatar
      USB: fix compile problems in ehci-hcd · aff6d18f
      Alan Stern authored
      This patch (as1072) fixes some recently-introduced compile problems
      that show up in ehci-hcd when CONFIG_PM is turned off.
      	PORT_WAKE_BITS needs to be defined always.
      	ehci_port_power() is called during initialization by all the
      	EHCI variants other than the PCI version, in which it is
      	"defined but not used".  So add a call to it.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Alan Stern's avatar
      USB: HCDs use the do_remote_wakeup flag · 58a97ffe
      Alan Stern authored
      When a USB device is suspended, whether or not it is enabled for
      remote wakeup depends on the device_may_wakeup() setting.  The setting
      is then saved in the do_remote_wakeup flag.
      Later on, however, the device_may_wakeup() value can change because of
      user activity.  So when testing whether a suspended device is or
      should be enabled for remote wakeup, we should always test
      do_remote_wakeup instead of device_may_wakeup().  This patch (as1076)
      makes that change for root hubs in several places.
      The patch also adjusts uhci-hcd so that when an autostopped controller
      is suspended, the remote wakeup setting agrees with the value recorded
      in the root hub's do_remote_wakeup flag.
      And the patch adjusts ehci-hcd so that wakeup events on selectively
      suspended ports (i.e., the bus itself isn't suspended) don't turn on
      the PME# wakeup signal.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • David Brownell's avatar
      USB: ehci: minor cleanups · 9776afc8
      David Brownell authored
      Minor cleanups to the EHCI code:  revision history is what source
      code repositories should have.  Switch to a more standard way to
      kick in verbose debugging -- don't be EHCI-specific.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Alan Stern's avatar
      USB: remove CONFIG_USB_PERSIST setting · feccc30d
      Alan Stern authored
      This patch (as1047) removes the USB_PERSIST Kconfig option, enabling
      it permanently.  It also prevents the power/persist attribute from
      being created for hub devices; there's no point in having it since
      USB-PERSIST is always turned on for hubs.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Alan Stern's avatar
      USB: EHCI: carry out port handover during each root-hub resume · 3bb1af52
      Alan Stern authored
      This patch (as1044) causes EHCI port handover for non-high-speed
      devices to occur during every root-hub resume, not just in cases where
      the controller lost power or was reset.  This is necessary because:
      	When some machines go into suspend, they remove power from
      	on-board USB devices while retaining suspend current for USB
      	The user might well unplug a USB device while the system is
      	suspended and then plug it back in before resuming.
      A corresponding change is made to the core resume routine; now
      high-speed root hubs will always be resumed when the system wakes up,
      even if they were suspended before the system went to sleep.  If this
      weren't done then EHCI port handover wouldn't work, since it is called
      when the EHCI root hub is resumed.
      Finally, a comment is added to the hub driver explaining the khubd has
      to be freezable; if it weren't frozen then it could interfere with
      port handover.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  11. 02 Apr, 2008 1 commit
  12. 01 Feb, 2008 6 commits
  13. 19 Oct, 2007 1 commit
  14. 12 Jul, 2007 4 commits
    • Alan Stern's avatar
      USB: Don't resume root hub if the controller is suspended · cfa59dab
      Alan Stern authored
      Root hubs can't be resumed if their parent controller device is still
      suspended.  This patch (as925) adds a check for that condition in
      hcd_bus_resume() and prevents it from being treated as a fatal
      controller failure.
      ehci-hcd is updated to add the corresponding test.  Unnecessary
      debugging messages are removed from uhci-hcd and dummy-hcd.  The
      error return code from dummy-hcd is changed to -ESHUTDOWN, the same as
      the others.  ohci-hcd doesn't need any changes.
      Suspend handling in the non-PCI host drivers is somewhat hit-and-miss.
      This patch shouldn't have any effect on them.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Christian Engelmayer's avatar
      ehci-hub: improved over-current recovery · 756aa6b3
      Christian Engelmayer authored
      According to the USB Specification Revision 2.0 chapter 11.12.5
      a hub experiencing an over-current condition must place all
      affected ports in the powered-off state. It seems that some root
      hubs need port power to be cycled by software in order to get back
      to normal functionality after an over-current condition ... like
      the EHCI implementation on an MPC8343E.
      Signed-off-by: default avatarChristian Engelmayer <christian.engelmayer@frequentis.com>
      Signed-off-by: default avatarDavid Brownell <david-b@pacbell.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Alan Stern's avatar
      USB: EHCI: fix handover for designated full-speed ports · 3c519b84
      Alan Stern authored
      This patch (as895) fixes up a loose end in the port-handover code for
      the USB-Persist facility.  A special case occurs when a high-speed
      device is attached to a port which the user has designated to run at
      full-speed only; the port must be disabled before the handover can
      take place.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Alan Stern's avatar
      USB: EHCI, OHCI: handover changes · 383975d7
      Alan Stern authored
      This patch (as887) changes the way ehci-hcd and ohci-hcd handle a loss
      of VBUS power during suspend.  In order for the USB-persist facility
      to work correctly, it is necessary for low- and full-speed devices
      attached to a high-speed port to be handed back to the companion
      controller during resume processing.
      This entails three changes: adding code to ehci-hcd to perform the
      handover, removing code from ohci-hcd to turn off ports during
      root-hub reinit, and adding code to ohci-hcd to turn on ports during
      PCI controller resume.  (Other bus glue resume methods for platforms
      supporting high-speed controllers would need a similar change, if any
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  15. 27 Apr, 2007 1 commit
  16. 09 Mar, 2007 1 commit
  17. 16 Feb, 2007 1 commit
  18. 07 Feb, 2007 5 commits
  19. 01 Dec, 2006 1 commit
    • 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
      	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>