24 Mar, 2011
40 commits
-
commit ccd32e735de7a941906e093f8dca924bb05c5794 upstream.
An integer overflow occurs in the calculation of RHlinear when the
relative humidity is greater than around 30%. The consequence is a subtle
(but noticeable) error in the resulting humidity measurement.Signed-off-by: Vivien Didelot
Signed-off-by: Jean Delvare
Cc: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream.
The latest binutils (2.21.0.20110302/Ubuntu) breaks the build
yet another time, under CONFIG_XEN=y due to a .size directive that
refers to a slightly differently named (hence, to the now very
strict and unforgiving assembler, non-existent) symbol.[ mingo:
This unnecessary build breakage caused by new binutils
version 2.21 gets escallated back several kernel releases spanning
several years of Linux history, affecting over 130,000 upstream
kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially
affecting all major Linux distro kernel configs).Git annotate tells us that this slight debug symbol code mismatch
bug has been introduced in 2008 in commit 3d75e1b8:3d75e1b8 (Jeremy Fitzhardinge 2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
The 'bug' is just a slight assymetry in ENTRY()/END()
debug-symbols sequences, with lots of assembly code between the
ENTRY() and the END():ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs)
...
END(do_hypervisor_callback)Human reviewers almost never catch such small mismatches, and binutils
never even warned about it either.This new binutils version thus breaks the Xen build on all upstream kernels
since v2.6.27, out of the blue.This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels
impossible on such binutils, for a bisection window of over hundred
thousand historic commits. (!)This is a major fail on the side of binutils and binutils needs to turn
this show-stopper build failure into a warning ASAP. ]Signed-off-by: Alexander van Heukelum
Cc: Jeremy Fitzhardinge
Cc: Jan Beulich
Cc: H.J. Lu
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: "H. Peter Anvin"
Cc: Kees Cook
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream.
During redetection of a SDIO card, a request for a new card RCA
was submitted to the card, but was then overwritten by the old RCA.
This caused the card to be deselected instead of selected when using
the incorrect RCA. This bug's been present since the "oldcard"
handling was introduced in 2.6.32.Signed-off-by: Stefan Nilsson XK
Reviewed-by: Ulf Hansson
Reviewed-by: Pawel Wieczorkiewicz
Signed-off-by: Linus Walleij
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 5fd11c0754fa069b6aba64b65734aa2fb193552d upstream.
Signed-off-by: Manoj Iyer
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit 6ced9e6b3901af4ab6ac0a11231402c888286ea6 upstream.
The struct i2c_board_info member holding the name is "type", not
"name".Signed-off-by: Roman Fietze
Signed-off-by: Jean Delvare
Signed-off-by: Greg Kroah-Hartman -
commit 9804c9eaeacfe78651052c5ddff31099f60ef78c upstream.
The CHECK_IRQ_PER_CPU is wrong, it should be checking
irq_to_desc(irq)->status not just irq.Signed-off-by: Thomas Gleixner
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit c600636bd560b04973174caa5e349a72bce51637 upstream.
A HW limitation was recently discovered where the last buffer in a DDP offload
cannot be a full buffer size in length. Fix the issue with a work around by
adding another buffer with size = 1.Signed-off-by: Amir Hanania
Tested-by: Ross Brattain
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman -
commit 96cc637235892a102fb829218adac048bd730ab7 upstream.
This change fixes VM pool allocation issues based on MAC address filtering,
as well as limits the scope of VF access to promiscuous mode.Signed-off-by: Alexander Duyck
Acked-by: Greg Rose
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman -
commit 4981d01eada5354d81c8929d5b2836829ba3df7b upstream.
According to intel CPU manual, every time PGD entry is changed in i386 PAE
mode, we need do a full TLB flush. Current code follows this and there is
comment for this too in the code.But current code misses the multi-threaded case. A changed page table
might be used by several CPUs, every such CPU should flush TLB. Usually
this isn't a problem, because we prepopulate all PGD entries at process
fork. But when the process does munmap and follows new mmap, this issue
will be triggered.When it happens, some CPUs keep doing page faults:
http://marc.info/?l=linux-kernel&m=129915020508238&w=2
Reported-by: Yasunori Goto
Tested-by: Yasunori Goto
Reviewed-by: Rik van Riel
Signed-off-by: Shaohua Li
Cc: Mallick Asit K
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: linux-mm
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 723aae25d5cdb09962901d36d526b44d4be1051c upstream.
Mike Galbraith reported finding a lockup ("perma-spin bug") where the
cpumask passed to smp_call_function_many was cleared by other cpu(s)
while a cpu was preparing its call_data block, resulting in no cpu to
clear the last ref and unlock the block.Having cpus clear their bit asynchronously could be useful on a mask of
cpus that might have a translation context, or cpus that need a push to
complete an rcu window.Instead of adding a BUG_ON and requiring yet another cpumask copy, just
detect the race and handle it.Note: arch_send_call_function_ipi_mask must still handle an empty
cpumask because the data block is globally visible before the that arch
callback is made. And (obviously) there are no guarantees to which cpus
are notified if the mask is changed during the call; only cpus that were
online and had their mask bit set during the whole call are guaranteed
to be called.Reported-by: Mike Galbraith
Reported-by: Jan Beulich
Acked-by: Jan Beulich
Signed-off-by: Milton Miller
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 45a5791920ae643eafc02e2eedef1a58e341b736 upstream.
Paul McKenney's review pointed out two problems with the barriers in the
2.6.38 update to the smp call function many code.First, a barrier that would force the func and info members of data to
be visible before their consumption in the interrupt handler was
missing. This can be solved by adding a smp_wmb between setting the
func and info members and setting setting the cpumask; this will pair
with the existing and required smp_rmb ordering the cpumask read before
the read of refs. This placement avoids the need a second smp_rmb in
the interrupt handler which would be executed on each of the N cpus
executing the call request. (I was thinking this barrier was present
but was not).Second, the previous write to refs (establishing the zero that we the
interrupt handler was testing from all cpus) was performed by a third
party cpu. This would invoke transitivity which, as a recient or
concurrent addition to memory-barriers.txt now explicitly states, would
require a full smp_mb().However, we know the cpumask will only be set by one cpu (the data
owner) and any preivous iteration of the mask would have cleared by the
reading cpu. By redundantly writing refs to 0 on the owning cpu before
the smp_wmb, the write to refs will follow the same path as the writes
that set the cpumask, which in turn allows us to keep the barrier in the
interrupt handler a smp_rmb instead of promoting it to a smp_mb (which
will be be executed by N cpus for each of the possible M elements on the
list).I moved and expanded the comment about our (ab)use of the rcu list
primitives for the concurrent walk earlier into this function. I
considered moving the first two paragraphs to the queue list head and
lock, but felt it would have been too disconected from the code.Cc: Paul McKinney
Signed-off-by: Milton Miller
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit e6cd1e07a185d5f9b0aa75e020df02d3c1c44940 upstream.
Peter pointed out there was nothing preventing the list_del_rcu in
smp_call_function_interrupt from running before the list_add_rcu in
smp_call_function_many.Fix this by not setting refs until we have gotten the lock for the list.
Take advantage of the wmb in list_add_rcu to save an explicit additional
one.I tried to force this race with a udelay before the lock & list_add and
by mixing all 64 online cpus with just 3 random cpus in the mask, but
was unsuccessful. Still, inspection shows a valid race, and the fix is
a extension of the existing protection window in the current code.Reported-by: Peter Zijlstra
Signed-off-by: Milton Miller
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit d7433142b63d727b5a217c37b1a1468b116a9771 upstream.
(crossport of 1f7bebb9e911d870fa8f997ddff838e82b5715ea
by Andreas Schlick )When ext3_dx_add_entry() has to split an index node, it has to ensure that
name_len of dx_node's fake_dirent is also zero, because otherwise e2fsck
won't recognise it as an intermediate htree node and consider the htree to
be corrupted.Signed-off-by: Eric Sandeen
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman -
commit 58d406ed6a5f1ca4bc1dba5390b718c67847fa5f upstream.
Some versions of grep don't treat '\s' properly. When building perf on such
systems and using a kernel tarball the perf version is unable to be determined
from the main kernel Makefile and the user is left with a version of '..'.
Replacing the use of '\s' with '[[:space:]]', which should work in all grep
versions, gives a usable version number.Reported-by: Tapan Dhimant
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Tapan Dhimant
Cc: linux-kernel@vger.kernel.org
LKML-Reference:
Signed-off-by: Josh Hunt
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 upstream.
Events on POWER7 can roll back if a speculative event doesn't
eventually complete. Unfortunately in some rare cases they will
raise a performance monitor exception. We need to catch this to
ensure we reset the PMC. In all cases the PMC will be 256 or less
cycles from overflow.Signed-off-by: Anton Blanchard
Signed-off-by: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream.
We toggle the state from start and stop callbacks but actually
don't check it when the event triggers. Do it so that
these callbacks actually work.Signed-off-by: Frederic Weisbecker
Cc: Arnaldo Carvalho de Melo
Cc: Paul Mackerras
Cc: Stephane Eranian
Signed-off-by: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 91b2f482e62ad0d444222253026a5cbca28c4ab9 upstream.
Fix the mistakenly inverted check of events state.
Signed-off-by: Frederic Weisbecker
Signed-off-by: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Paul Mackerras
Cc: Stephane Eranian
LKML-Reference:
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 8e26de238fd794c8ea56a5c98bf67c40cfeb051d upstream.
RPC task RPC_TASK_QUEUED bit is set must be checked before trying to wake up
task rpc_killall_tasks() because task->tk_waitqueue can not be set (equal to
NULL).
Also, as Trond Myklebust mentioned, such approach (instead of checking
tk_waitqueue to NULL) allows us to "optimise away the call to
rpc_wake_up_queued_task() altogether for those
tasks that aren't queued".Here is an example of dereferencing of tk_waitqueue equal to NULL:
CPU 0 CPU 1 CPU 2
-------------------- --------------------- --------------------------
nfs4_run_open_task
rpc_run_task
rpc_execute
rpc_set_active
rpc_make_runnable
(waiting)
rpc_async_schedule
nfs4_open_prepare
nfs_wait_on_sequence
nfs_umount_begin
rpc_killall_tasks
rpc_wake_up_task
rpc_wake_up_queued_task
spin_lock(tk_waitqueue == NULL)
BUG()
rpc_sleep_on
spin_lock(&q->lock)
__rpc_sleep_on
task->tk_waitqueue = qSigned-off-by: Stanislav Kinsbursky
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit e020c6800c9621a77223bf2c1ff68180e41e8ebf upstream.
This fixes a race in which the task->tk_callback() puts the rpc_task
to sleep, setting a new callback. Under certain circumstances, the current
code may end up executing the task->tk_action before it gets round to the
callback.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit ed0f36bc5719b25659b637f80ceea85494b84502 upstream.
The use of blk_execute_rq_nowait() implies __blk_put_request() is needed
in stpg_endio() rather than blk_put_request() -- blk_finish_request() is
called with queue lock already held.Signed-off-by: Joseph Gruher
Signed-off-by: Ilgu Hong
Signed-off-by: Mike Snitzer
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit efed5f26664f93991c929d5bb343e65f900d72bc upstream.
Clear input settings before initialization.
Signed-off-by: Przemyslaw Bruski
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit f164753a263bfd2daaf3e0273b179de7e099c57d upstream.
SDPIF status retrieval always returned the default settings instead of
the actual ones.Signed-off-by: Przemyslaw Bruski
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 4c1847e884efddcc3ede371f7839e5e65b25c34d upstream.
SPDIF status mask creation was incorrect.
Signed-off-by: Przemyslaw Bruski
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 98d21df431ad55281e1abf780f8d51e3391900b2 upstream.
loopback_pos_update() can be called in the timer callback, thus the lock
held should be irq-safe. Otherwise you'll get AB/BA deadlock together
with substream->self_group.lock.Reported-and-tested-by: Knut Petersen
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 4a122c10fbfe9020df469f0f669da129c5757671 upstream.
The user-supplied index into the adapters array needs to be checked, or
an out-of-bounds kernel pointer could be accessed and used, leading to
potentially exploitable memory corruption.Signed-off-by: Dan Rosenberg
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 0f12a4e29368a9476076515881d9ef4e5876c6e2 upstream.
Commit 280c73d ("PCI: centralize the capabilities code in
pci-sysfs.c") changed the initialisation of the "rom" and "vpd"
attributes, and made the failure path for the "vpd" attribute
incorrect. We must free the new attribute structure (attr), but
instead we currently free dev->vpd->attr. That will normally be NULL,
resulting in a memory leak, but it might be a stale pointer, resulting
in a double-free.Found by inspection; compile-tested only.
Signed-off-by: Ben Hutchings
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit 87e3dc3855430bd254370afc79f2ed92250f5b7c upstream.
Some broken BIOSes on ICH4 chipset report an ACPI region which is in
conflict with legacy IDE ports when ACPI is disabled. Even though the
regions overlap, IDE ports are working correctly (we cannot find out
the decoding rules on chipsets).So the only problem is the reported region itself, if we don't reserve
the region in the quirk everything works as expected.This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO
which is 0x1000. Some regions might be (and are by a fast google
query) below this border, but the only difference is that they won't
be reserved anymore. They should still work though the same as before.The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl):
pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f]At 0x0100 a 128 bytes long ACPI region is reported in the quirk for
ICH4. ata_piix then fails to find disks because the IDE legacy ports
are zeroed:
ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007])References: https://bugzilla.novell.com/show_bug.cgi?id=558740
Signed-off-by: Jiri Slaby
Cc: Bjorn Helgaas
Cc: "David S. Miller"
Cc: Thomas Renninger
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit cdb9755849fbaf2bb9c0a009ba5baa817a0f152d upstream.
Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN
and GPIO_EN bits are set to 1. Add checks for these bits into the
quirks prior to the region creation.While at it, name the constants by macros.
Signed-off-by: Jiri Slaby
Cc: Bjorn Helgaas
Cc: "David S. Miller"
Cc: Thomas Renninger
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit b99af4b002e4908d1a5cdaf424529bdf1dc69768 upstream.
Revert commit 7eb93b175d4de9438a4b0af3a94a112cb5266944
Author: Yu Zhao
Date: Fri Apr 3 15:18:11 2009 +0800PCI: SR-IOV quirk for Intel 82576 NIC
If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash
BAR and program the SR-IOV BARs to use the old Flash Memory Space.Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet
section 7.9.2.14.2 for details.
http://download.intel.com/design/network/datashts/82576_Datasheet.pdfSigned-off-by: Yu Zhao
Signed-off-by: Jesse BarnesThis quirk was added before SR-IOV was in production and now all machines that
originally had this issue alreayd have bios updates to correct the issue. The
quirk itself is no longer needed and in fact causes bugs if run. Remove it.Signed-off-by: Jesse Brandeburg
CC: Yu Zhao
CC: Jesse Barnes
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit 270fdc0748bd3f7b625caff985f2fcf8e2185ec7 upstream.
As reported on http://ubuntuforums.org/showthread.php?t=1594007 the
PKB-1700 needs same special handling as WKB-2000. This change is
originally based on patch posted by user asmoore82 on the Ubuntu
forums.Signed-off-by: Herton Ronaldo Krzesinski
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 2d9ca4e9f393d81d8f37ed37505aecbf3a5e1bd6 upstream.
The magic trackpad and mouse both report touch orientation in opposite
direction to the bcm5974 driver and what is written in
Documents/input/multi-touch-protocol.txt. This patch reverts the
direction, so that all in-kernel devices with this feature behave the
same way.Since no known application has been utilizing this information yet, it
seems appropriate also for stable.Cc: Michael Poole
Signed-off-by: Henrik Rydberg
Acked-by: Chase Douglas
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 584c0c4c359bdac37d94157f8d7fc513d26c8328 upstream.
Currently some special handling for the unusual case like dual-ADCs
or a single-input-src is done in the tree-parse time in
set_capture_mixer(). But this setup could be overwritten by static
init verbs.This patch moves the initialization into the init phase so that
such input-src setup won't be lost.Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 094a42452abd5564429045e210281c6d22e67fca upstream.
When the mux for digital mic is different from the mux for other mics,
the current auto-parser doesn't handle them in a right way but provides
only one mic. This patch fixes the issue.Signed-off-by: Vitaliy Kulikov
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 0a3fabe30e1a3b2037a12b863b8c45fffce38ee9 upstream.
Do not initialize again the what has already been initialized as
multi outs, as this breaks surround speakers.Tested-by: Bartłomiej Żogała
Signed-off-by: David Henningsson
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
[This needs to be applied to 2.6.37 only. The bug in question was
inadvertently fixed by a series of cleanups in 2.6.38, but the patches
in question are too large to be backported. This patch is a minimal fix
that serves the same purpose.]When we decode a filename followed by an 8-byte cookie, we need to
consider the fact that the filename and cookie are 32-bit word aligned.
Presently, we may end up copying insufficient amounts of data when
xdr_inline_decode() needs to invoke xdr_copy_to_scratch to deal
with a page boundary.The following patch fixes the issue by first decoding the filename, and
then decoding the cookie.Reported-by: Neil Brown
Signed-off-by: Trond Myklebust
Reviewed-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 500132a0f26ad7d9916102193cbc6c1b1becb373 upstream.
Use the Mult and bMaxBurst values from the endpoint companion
descriptor to calculate the max length of an isoc transfer.Add USB_SS_MULT macro to access Mult field of bmAttributes, at
Sarah's suggestion.This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
those were the first kernels to have isochronous support for SuperSpeed
devices.Signed-off-by: Paul Zimmerman
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman -
commit 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 upstream.
When an endpoint stalls, we need to update the xHCI host's internal
dequeue pointer to move it past the stalled transfer. This includes
updating the cycle bit (TRB ownership bit) if we have moved the dequeue
pointer past a link TRB with the toggle cycle bit set.When we're trying to find the new dequeue segment, find_trb_seg() is
supposed to keep track of whether we've passed any link TRBs with the
toggle cycle bit set. However, this while loop's bodywhile (cur_seg->trbs > trb ||
&cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {Will never get executed if the ring only contains one segment.
find_trb_seg() will return immediately, without updating the new cycle
bit. Since find_trb_seg() has no idea where in the segment the TD that
stalled was, make the caller, xhci_find_new_dequeue_state(), check for
this special case and update the cycle bit accordingly.This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp
Tested-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit bf161e85fb153c0dd5a95faca73fd6a9d237c389 upstream.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp
Tested-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 9b37596a2e860404503a3f2a6513db60c296bfdc upstream.
The hcd->state variable is a disaster. It's not clearly owned by
either usbcore or the host controller drivers, and they both change it
from time to time, potentially stepping on each other's toes. It's
not protected by any locks. And there's no mechanism to prevent it
from going through an invalid transition.This patch (as1451) takes a first step toward fixing these problems.
As it turns out, usbcore uses hcd->state for essentially only two
things: checking whether the controller's root hub is running and
checking whether the controller has died. Therefore the patch adds
two new atomic bitflags to the hcd structure, to store these pieces of
information. The new flags are used only by usbcore, and a private
spinlock prevents invalid combinations (a dead controller's root hub
cannot be running).The patch does not change the places where usbcore sets hcd->state,
since HCDs may depend on them. Furthermore, there is one place in
usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
interrupt handler can implicitly indicate that the controller died by
setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a
big improvement over the current code.The patch makes one other change. The hcd_bus_suspend() and
hcd_bus_resume() routines now check first whether the host controller
has died; if it has then they return immediately without calling the
HCD's bus_suspend or bus_resume methods.This fixes the major problem reported in Bugzilla #29902: The system
fails to suspend after a host controller dies during system resume.Signed-off-by: Alan Stern
Tested-by: Alex Terekhov
Signed-off-by: Greg Kroah-Hartman
