lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1371650753-11452-1-git-send-email-rogerq@ti.com>
Date:	Wed, 19 Jun 2013 17:05:47 +0300
From:	Roger Quadros <rogerq@...com>
To:	<stern@...land.harvard.edu>, <tony@...mide.com>
CC:	<balbi@...com>, <ruslan.bilovol@...com>,
	<linux-usb@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	Roger Quadros <rogerq@...com>
Subject: [RFC PATCH 0/6] Suspend USB Host controller on bus suspend

Hi,

This series attempts to suspend the OMAP EHCI host controller on USB
Bus suspend. This will cause its parent, the OMAP USB Host Module as well
as the USB TLL Module to be put in suspend and hence allow the USB power domain
to be put in a lower power state. Then we no longer prevent the rest of the OMAP
SoC from entering lower power states like RETention or OFF mode when
USB (or system) is suspended. This was one of the main reason why EHCI_OMAP
is still not enabled in OMAP2 defconfig.

In order for remote wakeup or hub events (connect/disconnect) to be detected
while in suspend, we need to rely on the IO daisy chaining mechanism on OMAP.
This is nothing but configuring a pin to be wakeup capable and triggering an
interrupt on any pin activity while the hardware module or the entire SoC is
in sleep state. For this to work, we rely on the wakeup feature added to the
omap-pinctrl-single driver in [1]. This takes care of routing IO pad wakeup
interrupt to the right driver's interrupt handler (i.e. ehci_irq in our case).

The pin state information for DEFAULT and IDLE is specified for the omap3beagle-xm
board in patch 5. So this is tested only on omap3beagle-xm board.

As the omap-ehci controller driver needs to do some additional work to put
itself into suspend/resume and make sure it is resumed to process an interrupt,
we need to be able to override irq, bus_suspend, and bus_resume handlers. This
provision is done in patch 3.

Patch 2 uses pinctrl framework to toggle USB host pins from DEFAULT state
when active to IDLE state with wakeups enabled while in suspend.

Patch 5 implements the suspend feature in ehci-omap driver and ensures that
we don't loose events while in suspend.

Please let me know what you think about it. I'm not 100% confident about
tackling interrupt when the device is runtime suspended in patch 5. Please
let me know if a race condition is possible here.

[1] - OMAP pinctrl wakeup support
http://thread.gmane.org/gmane.linux.ports.arm.omap/99010/focus=99041

cheers,
-roger

Roger Quadros (6):
  mfd: omap-usb-host: move initialization to module_init()
  mfd: omap-usb-host: Put pins in IDLE state on suspend
  USB: ehci: allow controller drivers to override irq &
    bus_suspend/resume
  USB: ehci-omap: Suspend the controller during bus suspend
  ARM: dts: omap3beagle-xm: Add idle state pins for USB host
  ARM: OMAP3: Enable Hardware Save and Restore for USB Host

 arch/arm/boot/dts/omap3-beagle-xm.dts       |   29 ++++++++--
 arch/arm/mach-omap2/powerdomains3xxx_data.c |    8 +--
 drivers/mfd/omap-usb-host.c                 |   56 +++++++++++++++---
 drivers/mfd/omap-usb-tll.c                  |    8 +--
 drivers/usb/host/ehci-hcd.c                 |    9 +++-
 drivers/usb/host/ehci-hub.c                 |    6 +-
 drivers/usb/host/ehci-omap.c                |   82 +++++++++++++++++++++++++++
 drivers/usb/host/ehci.h                     |    6 ++
 8 files changed, 172 insertions(+), 32 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ