UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: Bump ABI

Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
UBUNTU: [debian] Remove dangling symlink from headers package

BugLink: http://bugs.launchpad.net/bugs/1112442

Signed-off-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
[PATCH] UBUNTU: SAUCE: xen/pv-spinlock: Never enable interrupts in xen_spin_lock_slow()

The pv-ops spinlock code for Xen will call xen_spin_lock_slow()
if a lock cannot be obtained quickly by normal spinning. The
slow variant will put the VCPU onto a waiters list, then
enable interrupts (which are event channel messages in this
case) and calls a hypervisor function that is supposed to return
when the lock is released.

Using a test case which has a lot of threads running that cause
a high utilization of this spinlock code, it is observed that
the VCPU which is the first one on the waiters list seems to be
doing other things (no trace of the hv call on the stack) while
the waiters list still has it as the head. So other VCPUs which
try to acquire the lock are stuck in the hv call forever. And
that sooner than later end up in some circular locking.

By testing I can see this gets avoided when the interrupts remain
disabled for the duration of the poll_irq hypercall.

Xen PVM is the only affected setup because that is the only
one using the special spinlock api call which passes on the
flags as they were before (which is used to decide whether
interrupts get re-enabled in the Xen code).
KVM maps that call to the variant which will not look at the
previous state of interrupts and thus never re-enables them.

BugLink: http://bugs.launchpad.net/bugs/1011792

[v2: limited changes and reworded commit message]
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: d-i: Add mellanox ethernet drivers to nic-modules

BugLink: http://bugs.launchpad.net/bugs/1015339
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
usb: gadget: dummy: fix enumeration with g_multi

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 1d16638e3b9cc195bac18a8fcbca748f33c1bc24 upstream.

If we do have endpoints named like "ep-a" then bEndpointAddress is
counted internally by the gadget framework.

If we do have endpoints named like "ep-1" then bEndpointAddress is
assigned from the digit after "ep-".

If we do have both, then it is likely that after we used up the
"generic" endpoints we will use the digits and thus assign one
bEndpointAddress to multiple endpoints.

This theory can be proofed by using the completely enabled g_multi.
Without this patch, the mass storage won't enumerate and times out
because it shares endpoints with RNDIS.

This patch also adds fills up the endpoints list so we have in total
endpoints 1 to 15 in + out available while some of them are restricted
to certain types like BULK or ISO. Without this change the nokia gadget
won't load because the system does not provide enough (BULK) endpoints
but it did before ep-a - ep-f were removed.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
usb: musb: core: print new line in the driver banner again

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 2ac788f705e5118dd45204e7a5bc8d5bb6873835 upstream.

Commit 5c8a86e10a7c164f44537fabdc169fd8b4e7a440 (usb: musb: drop unneeded
musb_debug trickery) erroneously removed '\n' from the driver's banner.
Concatenate all the banner substrings while adding it back...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
virtio-blk: Don't free ida when disk is in use

BugLink: http://bugs.launchpad.net/bugs/1117693

commit f4953fe6c4aeada2d5cafd78aa97587a46d2d8f9 upstream.

When a file system is mounted on a virtio-blk disk, we then remove it
and then reattach it, the reattached disk gets the same disk name and
ids as the hot removed one.

This leads to very nasty effects - mostly rendering the newly attached
device completely unusable.

Trying what happens when I do the same thing with a USB device, I saw
that the sd node simply doesn't get free'd when a device gets forcefully
removed.

Imitate the same behavior for vd devices. This way broken vd devices
simply are never free'd and newly attached ones keep working just fine.

Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
mac80211: use del_timer_sync for final sta cleanup timer deletion

BugLink: http://bugs.launchpad.net/bugs/1117693

commit a56f992cdabc63f56b4b142885deebebf936ff76 upstream.

This is a very old bug, but there's nothing that prevents the
timer from running while the module is being removed when we
only do del_timer() instead of del_timer_sync().

The timer should normally not be running at this point, but
it's not clearly impossible (or we could just remove this.)

Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
xhci: Handle HS bulk/ctrl endpoints that don't NAK.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream.

A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK.  If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).

The xHCI code to compute the NAK interval does not handle the special
case of zero properly.  The current code unconditionally subtracts one
from bInterval and uses it as an exponent.  This causes a very large
bInterval to be used, and warning messages like these will be printed:

usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes

This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.

This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".

Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Handle auto-transition from hot to warm reset.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 1c7439c61fa6516419c32a9824976334ea969d47 upstream.

USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset.  In that case, the warm reset change bit
will be set, and the link state change bit may also be set.  Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs.  If these bits are not cleared, we may lose port change events
from the roothub.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Ignore xHCI Reset Device status.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 8b8132bc3d1cc3d4c0687e4d638a482fa920d98a upstream.

When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host.  The xHC then updates its internal
representation of the USB device to the 'Default' device state.  If the
device was already in the Default state, the xHC will complete the
command with an error status.

If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.

For example, usb_reset_and_verify_device calls into hub_port_init in a
loop.  Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers.  Then the port will be disabled, but the udev will remain in
tact.  usb_reset_and_verify_device will call into hub_port_init again.

On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command.  This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail.  The port will be disabled, and
the device won't be able to enumerate.

Fix this by ignoring the return value of the HCD reset_device callback.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Allow USB 3.0 ports to be disabled.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 41e7e056cdc662f704fa9262e5c6e213b4ab45dd upstream.

If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port.  Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects.  To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.

The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes.  We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect.  However,
external USB 3.0 hubs don't need this code.  They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set.  Therefore it doesn't make sense to
put this code in the USB core.

This patch is part of a series to fix several reports of infinite loops
on device enumeration failure.  This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller.  The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.

This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Increase reset timeout.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 77c7f072c87fa951e9a74805febf26466f31170c upstream.

John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete.  The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Ignore port state until reset completes.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 4f43447e62b37ee19c82a13f72f35b1ca60a74d3 upstream.

The port reset code bails out early if the current connect status is
cleared (device disconnected).  If we're issuing a hot reset, it may
also look at the link state before the reset is finished.

Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state, the port connection bit retains the
value from the previous state.  Therefore we can't trust it until the
reset finishes.  Also, the xHCI spec section 4.19.1.2.5 says software
shall ignore the link state while the port is resetting, as it can be in
an unknown state.

The port state during reset is also unknown for USB 2.0 hubs.  The hub
sends a reset signal by driving the bus into an SE0 state.  This
overwhelms the "connect" signal from the device, so the port can't tell
whether anything is connected or not.

Fix the port reset code to ignore the port link state and current
connect bit until the reset finishes, and USB_PORT_STAT_RESET is
cleared.

Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case,
because it's redundant.  When the warm reset finishes, the port reset
bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set.
Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit
in the code to deal with the finished reset.

This patch should be backported to all stable kernels.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Handle warm reset failure on empty port.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 65bdac5effd15d6af619b3b7218627ef4d84ed6a upstream.

An empty port can transition to either Inactive or Compliance Mode if a
newly connected USB 3.0 device fails to link train.  In that case, we
issue a warm reset.  Some devices, such as John's Roseweil eusb3
enclosure, slip back into Compliance Mode after the warm reset.

The current warm reset code does not check for device connect status on
warm reset completion, and it incorrectly reports the warm reset
succeeded.  This causes the USB core to attempt to send a Set Address
control transfer to a port in Compliance Mode, which will always fail.

Make hub_port_wait_reset check the current connect status and link state
after the warm reset completes.  Return a failure status if the device
is disconnected or the link state is Compliance Mode or SS.Inactive.

Make hub_events disable the port if warm reset fails.  This will disable
the port, and then bring it back into the RxDetect state.  Make the USB
core ignore the connect change until the device reconnects.

Note that this patch does NOT handle connected devices slipping into the
Inactive state very well.  This is a concern, because devices can go
into the Inactive state on U1/U2 exit failure.  However, the fix for
that case is too large for stable, so it will be submitted in a separate
patch.

This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
reset logic"

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
xhci: Avoid "dead ports", add roothub port polling.

BugLink: http://bugs.launchpad.net/bugs/1117693

commit c52804a472649b2e5005342308739434cbd51119 upstream.

The USB core hub thread (khubd) is designed with external USB hubs in
mind.  It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.

The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits.  When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event.  If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.

This means that the hub code may lose port status changes because of
race conditions between clearing change bits.  The user sees this as a
"dead port" that doesn't react to device connects.

The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.

We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's.  Instead, stop the port polling timer, and
unconditionally restart it when the host resumes.  If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.

This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
ASoC: wm5100: Remove DSP B and left justified formats

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 5f960294e2031d12f10c8488c3446fecbf59628d upstream.

These are not supported

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
mwifiex: handle association failure case correctly

BugLink: http://bugs.launchpad.net/bugs/1117693

commit b7097eb75fa11c302dcdec83f1dbfa874e0af0d1 upstream.

Currently even if association is failed "iw link" shows some
information about connected BSS and "Tx timeout" error is seen in
dmesg log.

This patch fixes below issues in the code to handle assoc failure
case correctly.
1) "status" variable in mwifiex_wait_queue_complete() is not
correctly updated. Hence driver doesn't inform cfg80211 stack
about association failure.
2) During association network queues are stopped but carrier is
not cleared, which gives Tx timeout error in failure case

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
mwifiex: check wait_event_interruptible return value

BugLink: http://bugs.launchpad.net/bugs/1117693

commit 9c969d8ccb1e17bd20742f4ac9f00c1a64487234 upstream.

wait_event_interruptible function returns -ERESTARTSYS if it's
interrupted by a signal. Driver should check the return value
and handle this case properly.

In mwifiex_wait_queue_complete() routine, as we are now checking
wait_event_interruptible return value, the condition check is not
required. Also, we have removed mwifiex_cancel_pending_ioctl()
call to avoid a chance of sending second command to FW by other path
as soon as we clear current command node. FW can not handle two
commands simultaneously.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>