Pull driver core updates from Greg Kroah-Hartman:
 "Here's the driver core, and other driver subsystems, pull request for
  the 3.5-rc1 merge window.

  Outside of a few minor driver core changes, we ended up with the
  following different subsystem and core changes as well, due to
  interdependancies on the driver core:
   - hyperv driver updates
   - drivers/memory being created and some drivers moved into it
   - extcon driver subsystem created out of the old Android staging
     switch driver code
   - dynamic debug updates
   - printk rework, and /dev/kmsg changes

  All of this has been tested in the linux-next releases for a few weeks
  with no reported problems.

  Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"

Fix up conflicts in drivers/extcon/extcon-max8997.c where git noticed
that a patch to the deleted drivers/misc/max8997-muic.c driver needs to
be applied to this one.

* tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (90 commits)
  uio_pdrv_genirq: get irq through platform resource if not set otherwise
  memory: tegra{20,30}-mc: Remove empty *_remove()
  printk() - isolate KERN_CONT users from ordinary complete lines
  sysfs: get rid of some lockdep false positives
  Drivers: hv: util: Properly handle version negotiations.
  Drivers: hv: Get rid of an unnecessary check in vmbus_prep_negotiate_resp()
  memory: tegra{20,30}-mc: Use dev_err_ratelimited()
  driver core: Add dev_*_ratelimited() family
  Driver Core: don't oops with unregistered driver in driver_find_device()
  printk() - restore prefix/timestamp printing for multi-newline strings
  printk: add stub for prepend_timestamp()
  ARM: tegra30: Make MC optional in Kconfig
  ARM: tegra20: Make MC optional in Kconfig
  ARM: tegra30: MC: Remove unnecessary BUG*()
  ARM: tegra20: MC: Remove unnecessary BUG*()
  printk: correctly align __log_buf
  ARM: tegra30: Add Tegra Memory Controller(MC) driver
  ARM: tegra20: Add Tegra Memory Controller(MC) driver
  printk() - restore timestamp printing at console output
  printk() - do not merge continuation lines of different threads
  ...

When CONFIG_PM=n, make sure that the usb_[unlocked_][en/dis]able_lpm
declarations are visible in include/linux/usb.h, and exported from
drivers/usb/core/hub.c.

Before this patch, if CONFIG_USB_SUSPEND was turned off, it would cause
build errors:

drivers/usb/core/hub.c: In function 'usb_disable_lpm':
drivers/usb/core/hub.c:3394:2: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/hub.c: At top level:
drivers/usb/core/hub.c:3424:6: warning: conflicting types for 'usb_enable_lpm' [enabled by default]
drivers/usb/core/hub.c:3394:2: note: previous implicit declaration of 'usb_enable_lpm' was here
drivers/usb/core/driver.c: In function 'usb_probe_interface':
drivers/usb/core/driver.c:339:2: error: implicit declaration of function 'usb_unlocked_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/driver.c:364:3: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c: In function 'usb_set_interface':
drivers/usb/core/message.c:1314:2: error: implicit declaration of function 'usb_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1323:3: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1368:2: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Chen Peter-B29397 <B29397@freescale.com>

There exist races in devio.c, below is one case,
and there are similar races in destroy_async()
and proc_unlinkurb().  Remove these races.

 cancel_bulk_urbs()        async_completed()
-------------------                -----------------------
 spin_unlock(&ps->lock);

                           list_move_tail(&as->asynclist,
		                    &ps->async_completed);

                           wake_up(&ps->wait);

                           Lead to free_async() be triggered,
                           then urb and 'as' will be freed.

 usb_unlink_urb(as->urb);
 ===> refer to the freed 'as'

Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oncaphillis <oncaphillis@snafu.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There are several places where the USB core needs to disable USB 3.0
Link PM:
 - usb_bind_interface
 - usb_unbind_interface
 - usb_driver_claim_interface
 - usb_port_suspend/usb_port_resume
 - usb_reset_and_verify_device
 - usb_set_interface
 - usb_reset_configuration
 - usb_set_configuration

Use the new LPM disable/enable functions to temporarily disable LPM
around these critical sections.

We need to protect the critical section around binding and unbinding USB
interface drivers.  USB drivers may want to disable hub-initiated USB
3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI
driver will install.  We need to disable LPM completely until the driver
is bound to the interface, and the driver has a chance to enable
whatever alternate interface setting it needs in its probe routine.
Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values.

We also need to disable LPM in usb_driver_claim_interface,
because drivers like usbfs can bind to an interface through that
function.  Note, there is no way currently for userspace drivers to
disable hub-initiated USB 3.0 LPM.  Revisit this later.

When a driver is unbound, the U1/U2 timeouts may change because we are
unbinding the last driver that needed hub-initiated USB 3.0 LPM to be
disabled.

USB LPM must be disabled when a USB device is going to be suspended.
The USB 3.0 spec does not define a state transition from U1 or U2 into
U3, so we need to bring the device into U0 by disabling LPM before we
can place it into U3.  Therefore, call usb_unlocked_disable_lpm() in
usb_port_suspend(), and call usb_unlocked_enable_lpm() in
usb_port_resume().  If the port suspend fails, make sure to re-enable
LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will
not be called on a failed port suspend.

USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB
device-initiated LPM is enabled) across device suspend.  Therefore,
disable LPM before the device will be reset in
usb_reset_and_verify_device(), and re-enable LPM after the reset is
complete and the configuration/alt settings are re-installed.

The calculated U1/U2 timeout values are heavily dependent on what USB
device endpoints are currently enabled.  When any of the enabled
endpoints on the device might change, due to a new configuration, or new
alternate interface setting, we need to first disable USB 3.0 LPM, add
or delete endpoints from the xHCI schedule, install the new interfaces
and alt settings, and then re-enable LPM.  Do this in usb_set_interface,
usb_reset_configuration, and usb_set_configuration.

Basically, there is a call to disable and then enable LPM in all
functions that lock the bandwidth_mutex.  One exception is
usb_disable_device, because the device is disconnecting or otherwise
going away, and we should not care about whether USB 3.0 LPM is enabled.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

There are various functions within the USB core that will need to
disable USB 3.0 link power states.  For example, when a USB device
driver is being bound to an interface, we need to disable USB 3.0 LPM
until we know if the driver will allow hub-initiated LPM transitions.
Another example is when the USB core is switching alternate interface
settings.  The USB 3.0 timeout values are dependent on what endpoints
are enabled, so we want to ensure that LPM is disabled until the new alt
setting is fully installed.

Multiple functions need to disable LPM, and those functions can even be
nested.  For example, usb_bind_interface() could disable LPM, and then
call into the driver probe function, which may attempt to switch to a
different alt setting.  Therefore, we need to keep a count of the number
of functions that require LPM to be disabled at any point in time.

Introduce two new USB core API calls, usb_disable_lpm() and
usb_enable_lpm().  These functions increment and decrement a new
variable in the usb_device, lpm_disable_count.  If usb_disable_lpm()
fails, it will call usb_enable_lpm() in order to balance the
lpm_disable_count.

These two new functions must be called with the bandwidth_mutex locked.
If the bandwidth_mutex is not already held by the caller, it should
instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
the bandwidth_mutex before calling usb_disable_lpm() and
usb_enable_lpm(), respectively.

Introduce a new variable (timeout) in the usb3_lpm_params structure to
keep track of the currently enabled U1/U2 timeout values.  When
usb_disable_lpm() is called, and the USB device has the U1 or U2
timeouts set to a non-zero value (meaning either device-initiated or
hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
state of the lpm_disable_count.  We want to ensure that all callers can
be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.

Otherwise the following scenario could occur:

1. Driver A is being bound to interface 1.  usb_probe_interface()
disables LPM.  Driver A doesn't care if hub-initiated LPM is enabled, so
even though usb_disable_lpm() fails, the probe of the driver continues,
and the bandwidth mutex is dropped.

2. Meanwhile, Driver B is being bound to interface 2.
usb_probe_interface() grabs the bandwidth mutex and calls
usb_disable_lpm().  That call should attempt to disable LPM, even
though the lpm_disable_count is set to 1 by Driver A.

For usb_enable_lpm(), we attempt to enable LPM only when the
lpm_disable_count is zero.  If some step in enabling LPM fails, it will
only have a minimal impact on power consumption, and all USB device
drivers should still work properly.  Therefore don't bother to return
any error codes.

Don't enable device-initiated LPM if the device is unconfigured.  The
USB device will only accept the U1/U2_ENABLE control transfers in the
configured state.  Do enable hub-initiated LPM in that case, since
devices are allowed to accept the LGO_Ux link commands in any state.

Don't enable or disable LPM if the device is marked as not being LPM
capable.  This can happen if:
 - the USB device doesn't have a SS BOS descriptor,
 - the device's parent hub has a zeroed bHeaderDecodeLatency value, or
 - the xHCI host doesn't support LPM.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

There are several different exit latencies associated with coming out of
the U1 or U2 lower power link state.

Device Exit Latency (DEL) is the maximum time it takes for the USB
device to bring its upstream link into U0.  That can be found in the
SuperSpeed Extended Capabilities BOS descriptor for the device.  The
time it takes for a particular link in the tree to exit to U0 is the
maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL.

Hubs introduce a further delay that effects how long it takes a child
device to transition to U0.  When a USB 3.0 hub receives a header
packet, it takes some time to decode that header and figure out which
downstream port the packet was destined for.  If the port is not in U0,
this hub header decode latency will cause an additional delay for
bringing the child device to U0.  This Hub Header Decode Latency is
found in the USB 3.0 hub descriptor.

We can use DEL and the header decode latency, along with additional
latencies imposed by each additional hub tier, to figure out the exit
latencies for both host-initiated and device-initiated exit to U0.

The Max Exit Latency (MEL) is the worst-case time it will take for a
host-initiated exit to U0, based on whether U1 or U2 link states are
enabled.  The ping or packet must traverse the path to the device, and
each hub along the way incurs the hub header decode latency in order to
figure out which device the transfer was bound for.  We say worst-case,
because some hubs may not be in the lowest link state that is enabled.
See the examples in section C.2.2.1.

Note that "HSD" is a "host specific delay" that the power appendix
architect has not been able to tell me how to calculate.  There's no way
to get HSD from the xHCI registers either, so I'm simply ignoring it.

The Path Exit Latency (PEL) is the worst-case time it will take for a
device-initiate exit to U0 to place all the links from the device to the
host into U0.

The System Exit Latency (SEL) is another device-initiated exit latency.
SEL is useful for USB 3.0 devices that need to send data to the host at
specific intervals.  The device may send an NRDY to indicate it isn't
ready to send data, then put its link into a lower power state.  If it
needs to have that data transmitted at a specific time, it can use SEL
to back calculate when it will need to bring the link back into U0 to
meet its deadlines.

SEL is the worst-case time from the device-initiated exit to U0, to when
the device will receive a packet from the host controller.  It includes
PEL, the time it takes for an ERDY to get to the host, a host-specific
delay for the host to process that ERDY, and the time it takes for the
packet to traverse the path to the device.  See Figure C-2 in the USB
3.0 bus specification.

Note: I have not been able to get good answers about what the
host-specific delay to process the ERDY should be.  The Intel HW
developers say it will be specific to the platform the xHCI host is
integrated into, and they say it's negligible.  Ignore this too.

Separate from these four exit latencies are the U1/U2 timeout values we
program into the parent hubs.  These timeouts tell the hub to attempt to
place the device into a lower power link state after the link has been
idle for that amount of time.

Create two arrays (one for U1 and one for U2) to store mel, pel, sel,
and the timeout values.  Store the exit latency values in nanosecond
units, since that's the smallest units used (DEL is in us, but the Hub
Header Decode Latency is in ns).

If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS
descriptor, it's highly unlikely it will be able to handle LPM requests
properly.  So it's best to disable LPM for devices that don't have this
descriptor, and any children beneath it, if it's a USB 3.0 hub.  Warn
users when that happens, since it means they have a non-compliant USB
3.0 device or hub.

This patch assumes a simplified design where links deep in the tree will
not have U1 or U2 enabled unless all their parent links have the
corresponding LPM state enabled.  Eventually, we might want to allow a
different policy, and we can revisit this patch when that happens.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>

Refactor the code that sets the usb_device flag to indicate the device
support link power management (lpm_capable).  The current code sets
lpm_capable unconditionally if the USB devices have a USB 2.0 Extended
Capabilities Descriptor.  USB 3.0 devices can also have that descriptor,
but the xHCI driver code that uses lpm_capable will not run the USB 2.0
LPM test for devices under the USB 3.0 roothub.  Therefore, it's fine
only set lpm_capable for high speed devices in this refactoring.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

The BOS descriptor is normally fetched and stored in the usb_device->bos
during enumeration.  USB 3.0 roothubs don't undergo enumeration, but we
need them to have a BOS descriptor, since each xHCI host has a different
U1 and U2 exit latency.  Make sure to fetch the BOS descriptor for USB
3.0 roothubs.  It will be freed when the roothub usb_device is released.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>

USB2 LPM is disabled when device begin to suspend and enabled after device
is resumed. That's because USB spec does not define the transition from
U1/U2 state to U3 state.

If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM
is disabled in this situation. Enable USB2 LPM if port suspend fails.

This patch should be backported to kernels as old as 3.2, that contain
the commit 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM".

Signed-off-by: Andiry Xu <andiry.xu@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

Commit da0af6e ("usb: Bind devices to ACPI devices when possible") really
tries to force-bind devices even when impossible, unlike what it says in
the subject.

CONFIG_ACPI is not an indication that ACPI tables are actually present, nor
is an indication that any USB relevant information is present in them. There
is no reason to fail the creation of a USB bus if it can't bind it to
ACPI device during initialization.

On systems with CONFIG_ACPI set but without ACPI tables it would cause a
boot panic.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>