06 Feb, 2015
40 commits
-
commit 2148f18fdb45f31ca269a7787fbc24053cd42e70 upstream.
VT switch back/forth from console to xserver (for example) has potential
to go horribly wrong if a dynamic DP MST connector ends up in the saved
modeset that is restored when switching back to fbcon.When removing a dynamic connector, don't forget to clean up the saved
state.v1: original
v2: null out set->fb if no more connectors to avoid making i915 crankyBugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1184968
Signed-off-by: Rob Clark
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 02a54164c52ed6eca3089a0d402170fbf34d6cf5 upstream.
In Dual EMAC, the default VLANs are used to segregate Rx packets between
the ports, so adding the same default VLAN to the switch will affect the
normal packet transfers. So returning error on addition of dual EMAC
default VLANs.Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to
break dual EMAC port separations.Fixes: d9ba8f9e6298 (driver: net: ethernet: cpsw: dual emac interface implementation)
Reported-by: Felipe Balbi
Signed-off-by: Mugunthan V N
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 83b0302d347a49f951e904184afe57ac3723476e upstream.
The regulator framework maintains a list of consumer regulators
for a regulator device and protects it from concurrent access using
the regulator device's mutex lock.In the case of regulator_put() the consumer is removed and regulator
device's parameters are updated without holding the regulator device's
mutex. This would lead to a race condition between the regulator_put()
and any function which traverses the consumer list or modifies regulator
device's parameters.
Fix this race condition by holding the regulator device's mutex in case
of regulator_put.Signed-off-by: Ashay Jaiswal
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 45cd15e600ec8006305ce83f62c7208c2cb7a052 upstream.
Array of platform_device_id elements should be terminated with empty
element.Fixes: 5bccae6ec458 ("rtc: s5m-rtc: add real-time clock driver for s5m8767")
Signed-off-by: Andrey Ryabinin
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit c957e8f084e0d21febcd6b8a0ea9631eccc92f36 upstream.
Once the current message is finished, the driver notifies SPI core about
this by calling spi_finalize_current_message(). This function queues next
message to be transferred. If there are more messages in the queue, it is
possible that the driver is asked to transfer the next message at this
point.When spi_finalize_current_message() returns the driver clears the
drv_data->cur_chip pointer to NULL. The problem is that if the driver
already started the next message clearing drv_data->cur_chip will cause
NULL pointer dereference which crashes the kernel like:BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
IP: [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
PGD 78bb8067 PUD 37712067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5
Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014
task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000
RIP: 0010:[] [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
RSP: 0018:ffff88007a823d08 EFLAGS: 00010202
RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430
RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a
R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98
R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000
FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0
Stack:
ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89
0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006
ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204
Call Trace:
[] giveback+0x69/0xa0 [spi_pxa2xx_platform]
[] pump_transfers+0x710/0x740 [spi_pxa2xx_platform]
[] ? pick_next_task_fair+0x744/0x830
[] tasklet_action+0xa9/0xe0
[] __do_softirq+0xee/0x280
[] run_ksoftirqd+0x20/0x40
[] smpboot_thread_fn+0xff/0x1b0
[] ? SyS_setgroups+0x150/0x150
[] kthread+0xcd/0xf0
[] ? kthread_create_on_node+0x180/0x180
[] ret_from_fork+0x7c/0xb0Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message().
Reported-by: Martin Oldfield
Signed-off-by: Mika Westerberg
Acked-by: Robert Jarzmik
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 5636d2f842c7bd7800002868ead3d6b809d385a0 upstream.
The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.This might also make GPU reset more robust in some cases, as we no longer
rely on the GART table in VRAM being preserved across the GPU
lockup/reset.v2: Add logic to radeon_gart_table_vram_pin directly instead of
reinstating radeon_gart_restore
v3: Move code after assignment of rdev->gart.table_addr so that the GART
TLB flush can work as intended, add code comment explaining why we're
doing thisBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
Reviewed-by: Christian König
Signed-off-by: Michel Dänzer
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit cb65890610dca287718a63bd8a5d9ce3dc80c3d7 upstream.
get_page_entry calculates the GART page table entry, which is just written
to the GART page table by set_page_entry.This is a prerequisite for the following fix.
Reviewed-by: Christian König
Signed-off-by: Michel Dänzer
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 496eb6fd2c3fd13f4b914e537598e5c86ce4f52a upstream.
Fixes a case where we call vmw_fifo_idle() from within a wait function with
task state !TASK_RUNNING, which is illegal.In addition, make the locking fine-grained, so that it is performed once
for every read- and write operation. This is of course more costly, but we
don't perform much register access in the timing critical paths anyway. Instead
we have the extra benefit of being sure that we don't forget the hw lock around
register accesses. I think currently the kms code was quite buggy w r t this.This fixes Red Hat Bugzilla Bug 1180796
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Signed-off-by: Greg Kroah-Hartman -
commit 766a78882ddf79b162243649d7dfdbac1fb6fb88 upstream.
Commit 9b1cc9f251 ("dm cache: share cache-metadata object across
inactive and active DM tables") mistakenly ignored the use of ERR_PTR
returns. Restore missing IS_ERR checks and ERR_PTR returns where
appropriate.Reported-by: Dan Carpenter
Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 2a7eaea02b99b6e267b1e89c79acc6e9a51cee3b upstream.
You can't modify the metadata in these modes. It's better to fail these
messages immediately than let the block-manager deny write locks on
metadata blocks. Otherwise these failed metadata changes will trigger
'needs_check' to get set in the metadata superblock -- requiring repair
using the thin_check utility.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit dcad68876c21bac709b01eda24e39d4410dc36a8 upstream.
Since commit f2c3c67f00 (merge commit that adds commit "ARM: mvebu:
completely disable hardware I/O coherency"), we disable I/O coherency
on Armada EBU platforms.However, we continue to initialize the coherency fabric, because this
coherency fabric is needed on Armada XP for inter-CPU
coherency. Unfortunately, due to this, we also continued to execute
the coherency fabric initialization code for Armada 375/38x, which
switched the PL310 into I/O coherent mode. This has the effect of
disabling the outer cache sync operation: this is needed when I/O
coherency is enabled to work around a PCIe/L2 deadlock. But obviously,
when I/O coherency is disabled, having the outer cache sync operation
is crucial.Therefore, this commit fixes the armada_375_380_coherency_init() so
that the PL310 is switched to I/O coherent mode only if I/O coherency
is enabled.Without this fix, all devices using DMA are broken on Armada 375/38x.
Signed-off-by: Thomas Petazzoni
Acked-by: Gregory CLEMENT
Tested-by: Gregory CLEMENT
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit a0b957f306fa4d0a39f4ffe5e5e25e856e6be46e upstream.
Today we expect that all the bank are enabled, and count the number of banks
used by the pinctrl based on it instead of using the last bank id enabled.So switch to it, set the chained IRQ at runtime based on enabled banks
and wait only the number of enabled gpio controllers at probe time.Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Ludovic Desroches
Acked-by: Nicolas Ferre
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 0fa7b39131576dd1baa6ca17fca53c65d7f62249 upstream.
In case userspace attempts to obtain key information for or delete a
unicast key, this is currently erroneously rejected unless the driver
sets the WIPHY_FLAG_IBSS_RSN flag. Apparently enough drivers do so it
was never noticed.Fix that, and while at it fix a potential memory leak: the error path
in the get_key() function was placed after allocating a message but
didn't free it - move it to a better place. Luckily admin permissions
are needed to call this operation.Fixes: e31b82136d1ad ("cfg80211/mac80211: allow per-station GTKs")
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit 2af81d6718f5ec92b1d787e0fe79b0d3b6f78601 upstream.
In normal cases (i.e. when we are fully associated), cfg80211 takes
care of removing all the stations before calling suspend in mac80211.But in the corner case when we suspend during authentication or
association, mac80211 needs to roll back the station states. But we
shouldn't roll back the station states in the suspend function,
because this is taken care of in other parts of the code, except for
WDS interfaces. For AP types of interfaces, cfg80211 takes care of
disconnecting all stations before calling the driver's suspend code.
For station interfaces, this is done in the quiesce code.For WDS interfaces we still need to do it here, so move the code into
a new switch case for WDS.Signed-off-by: Luciano Coelho
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit 3a5c5e81d8128a9e43abc52b75dd21d3da7a0cfc upstream.
Fix a regression introduced by commit a5e70697d0c4 ("mac80211: add radiotap flag
and handling for 5/10 MHz") where the IEEE80211_CHAN_CCK channel type flag was
incorrectly replaced by the IEEE80211_CHAN_OFDM flag. This commit fixes that by
using the CCK flag again.Fixes: a5e70697d0c4 ("mac80211: add radiotap flag and handling for 5/10 MHz")
Signed-off-by: Mathy Vanhoef
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit 3175e1dcec40fab1a444c010087f2068b6b04732 upstream.
If we start state recovery on a client that failed to initialise correctly,
then we are very likely to Oops.Reported-by: "Mkrtchyan, Tigran"
Link: http://lkml.kernel.org/r/130621862.279655.1421851650684.JavaMail.zimbra@desy.de
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit ee8a1a8b160a87dc3a9c81a86796aa4db85ea815 upstream.
We only support swap file calling nfs_direct_IO. However, application
might be able to get to nfs_direct_IO if it toggles O_DIRECT flag
during IO and it can deadlock because we grab inode->i_mutex in
nfs_file_direct_write(). So return 0 for such case. Then the generic
layer will fall back to buffer IO.Signed-off-by: Peng Tao
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 1d90d6d5522befa8efa1a7ea406be65cf865ded4 upstream.
Without this the aux port does not get detected, and consequently the touchpad
will not work.With this patch the touchpad is detected:
$ dmesg | grep -E "(SYN|i8042|serio)"
pnp 00:03: Plug and Play ACPI device, IDs SYN1d22 PNP0f13 (active)
i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126800, board id: 2863, fw id: 1473085
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6dmidecode excerpt for this laptop is:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Medion
Product Name: Akoya E7225
Version: 1.0Signed-off-by: Jochen Hein
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 47c1ffb2b6b630894e9a16442611c056ab21c057 upstream.
Add two more Fujitsu LIFEBOOK models that also ship with the Elantech
touchpad and don't work with crc_disabled to the quirk list.Signed-off-by: Rainer Koenig
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 8543cf1c247909ce85850ca6e2714adba351d6aa upstream.
LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model)
Reported-and-tested-by: Bjoern Olausson
Signed-off-by: Peter Hutterer
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 34e81ad5f0b60007c95995eb7803da7e00c6c611 upstream.
This patch solves deadlock between clock prepare mutex and regmap mutex reported
by Tomasz Figa in [1] by implementing solution from [2]: "always leave the clock
of the i2c controller in a prepared state".[1] https://lkml.org/lkml/2014/7/2/171
[2] https://lkml.org/lkml/2014/7/2/207On each i2c transfer handled by s3c24xx_i2c_xfer(), clk_prepare_enable() was
called, which calls clk_prepare() then clk_enable(). clk_prepare() takes
prepare_lock mutex before proceeding. Note that i2c transfer functions are
invoked from many places in kernel, typically with some other additional lock
held.It may happen that function on CPU1 (e.g. regmap_update_bits()) has taken a
mutex (i.e. regmap lock mutex) then it attempts i2c communication in order to
proceed (so it needs to obtain clock related prepare_lock mutex during transfer
preparation stage due to clk_prepare() call). At the same time other task on
CPU0 wants to operate on clock (e.g. to (un)prepare clock for some other reason)
so it has taken prepare_lock mutex.CPU0: CPU1:
clk_disable_unused() regulator_disable()
clk_prepare_lock() map->lock(map->lock_arg)
regmap_read() s3c24xx_i2c_xfer()
map->lock(map->lock_arg) clk_prepare_lock()Implemented solution from [2] leaves i2c clock prepared. Preparation is done in
s3c24xx_i2c_probe() function. Without this patch, it is immediately unprepared
by clk_disable_unprepare() call. I've replaced this call with clk_disable() and
I've added clk_unprepare() call in s3c24xx_i2c_remove().The s3c24xx_i2c_xfer() function now uses clk_enable() instead of
clk_prepare_enable() (and clk_disable() instead of clk_unprepare_disable()).Signed-off-by: Paul Osmialowski
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit 8a870880bd6f17b7ccef69a6432ab8df8775fcf6 upstream.
Like some other uas devices these devices hang when a report-opcodes scsi
command is send to them.BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1124119
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit bf5c4136fa5ce471bdbf4cf59a813e32755fd014 upstream.
It looks like FUA support is broken on JMicron 152d:2566 bridge:
[223159.885704] sd 7:0:0:0: [sdc] Write Protect is off
[223159.885706] sd 7:0:0:0: [sdc] Mode Sense: 47 00 10 08
[223159.885942] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA[223283.691677] sd 7:0:0:0: [sdc]
[223283.691680] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[223283.691681] sd 7:0:0:0: [sdc]
[223283.691682] Sense Key : Illegal Request [current]
[223283.691684] sd 7:0:0:0: [sdc]
[223283.691685] Add. Sense: Invalid field in cdb
[223283.691686] sd 7:0:0:0: [sdc] CDB:
[223283.691687] Write(10): 2a 08 15 d0 83 0d 00 00 01 00
[223283.691690] blk_update_request: critical target error, dev sdc, sector 2927892584This patch adds blacklist flag so that sd will not use FUA
Signed-off-by: Dmitry Nezhevenko
Cc: Phil Dibowitz
Cc: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
commit e5dff0e80463cc3fa236e898ef1491b40be70b19 upstream.
OTG device shall support this device for allowing compliance automated testing.
The modification is derived from Pavankumar and Vijayavardhans' previous work.Signed-off-by: Macpaul Lin
Cc: Pavankumar Kondeti
Cc: Vijayavardhan Vennapusa
Signed-off-by: Greg Kroah-Hartman -
commit ae43e9d05eb4bd324155292f889fbd001c4faea8 upstream.
The comment for rbd_dev_parent_get() said
* We must get the reference before checking for the overlap to
* coordinate properly with zeroing the parent overlap in
* rbd_dev_v2_parent_info() when an image gets flattened. We
* drop it again if there is no overlap.but the "drop it again if there is no overlap" part was missing from
the implementation. This lead to absurd parent_ref values for images
with parent_overlap == 0, as parent_ref was incremented for each
img_request and virtually never decremented.Fix this by leveraging the fact that refresh path calls
rbd_dev_v2_parent_info() under header_rwsem and use it for read in
rbd_dev_parent_get(), instead of messing around with atomics. Get rid
of barriers in rbd_dev_v2_parent_info() while at it - I don't see what
they'd pair with now and I suspect we are in a pretty miserable
situation as far as proper locking goes regardless.Signed-off-by: Ilya Dryomov
Reviewed-by: Josh Durgin
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit e69b8d414f948c242ad9f3eb2b7e24fba783dbbd upstream.
This effectively reverts the last hunk of 392a9dad7e77 ("rbd: detect
when clone image is flattened").The problem with parent_overlap != 0 condition is that it's possible
and completely valid to have an image with parent_overlap == 0 whose
parent state needs to be cleaned up on unmap. The next commit, which
drops the "clone image now standalone" logic, opens up another window
of opportunity to hit this, but even without it# cat parent-ref.sh
#!/bin/bash
rbd create --image-format 2 --size 1 foo
rbd snap create foo@snap
rbd snap protect foo@snap
rbd clone foo@snap bar
rbd resize --allow-shrink --size 0 bar
rbd resize --size 1 bar
DEV=$(rbd map bar)
rbd unmap $DEVleaves rbd_device/rbd_spec/etc and rbd_client along with ceph_client
hanging around.My thinking behind calling rbd_dev_parent_put() unconditionally is that
there shouldn't be any requests in flight at that point in time as we
are deep into unmap sequence. Hence, even if rbd_dev_unparent() caused
by flatten is delayed by in-flight requests, it will have finished by
the time we reach rbd_dev_unprobe() caused by unmap, thus turning
unconditional rbd_dev_parent_put() into a no-op.Fixes: http://tracker.ceph.com/issues/10352
Signed-off-by: Ilya Dryomov
Reviewed-by: Josh Durgin
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit 0767e95bb96d7fdddcd590fb809e6975d93aebc5 upstream.
When the last subscriber to a "Through" port has been removed, the
subscribed destination ports might still be active, so it would be
wrong to send "all sounds off" and "reset controller" events to them.
The proper place for such a shutdown would be the closing of the actual
MIDI port (and close_substream() in rawmidi.c already can do this).This also fixes a deadlock when dummy_unuse() tries to send events to
its own port that is already locked because it is being freed.Reported-by: Peter Billam
Signed-off-by: Clemens Ladisch
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit e6eb2eba494d6f99e69ca3c3748cd37a2544ab38 upstream.
The commit 3b8a3c010969 ("powerpc/pseries: Fix endiannes issue in RTAS
call from xmon") was fixing an endianness issue in the call made from
xmon to RTAS.However, as Michael Ellerman noticed, this fix was not complete, the
token value was not byte swapped. This lead to call an unexpected and
most of the time unexisting RTAS function, which is silently ignored by
RTAS.This fix addresses this hole.
Reported-by: Michael Ellerman
Signed-off-by: Laurent Dufour
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit e638642b08c170d2021b706f0b1c4f4ae93d8cbd upstream.
While being in an ERROR_WARNING state, and receiving further
bus error events with error counters still in the ERROR_WARNING
range of 97-127 inclusive, the state handling code erroneously
reverts back to ERROR_ACTIVE.Per the CAN standard, only revert to ERROR_ACTIVE when the
error counters are less than 96.Moreover, in certain Kvaser models, the BUS_ERROR flag is
always set along with undefined bits in the M16C status
register. Thus use bitwise operators instead of full equality
for checking that register against bus errors.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 14c10c2a1dd8eb8e00b750b521753260befa2789 upstream.
On some x86 laptops, plugging a Kvaser device again after an
unplug makes the firmware always ignore the very first command.
For such a case, provide some room for retries instead of
completely exiting the driver init code.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 3803fa6977f1de15fda4e8646c8fec97c8045cae upstream.
Send expected argument to the URB completion hander: a CAN
netdevice instead of the network interface private context
`kvaser_usb_net_priv'.This was discovered by having some garbage in the kernel
log in place of the netdevice names: can0 and can1.Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit ded5006667318c06df875609535176bd33f243a1 upstream.
Upon receiving a hardware event with the BUS_RESET flag set,
the driver kills all of its anchored URBs and resets all of
its transmit URB contexts.Unfortunately it does so under the context of URB completion
handler `kvaser_usb_read_bulk_callback()', which is often
called in an atomic context.While the device is flooded with many received error packets,
usb_kill_urb() typically sleeps/reschedules till the transfer
request of each killed URB in question completes, leading to
the sleep in atomic bug. [3]In v2 submission of the original driver patch [1], it was
stated that the URBs kill and tx contexts reset was needed
since we don't receive any tx acknowledgments later and thus
such resources will be locked down forever. Fortunately this
is no longer needed since an earlier bugfix in this patch
series is now applied: all tx URB contexts are reset upon CAN
channel close. [2]Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF
event, which is the recommended handling method advised by
the device manufacturer.[1] http://article.gmane.org/gmane.linux.network/239442
http://www.webcitation.org/6Vr2yagAQ[2] can: kvaser_usb: Reset all URB tx contexts upon channel close
889b77f7fd2bcc922493d73a4c51d8a851505815[3] Stacktrace:
[] dump_stack+0x45/0x57
[] __schedule_bug+0x41/0x4f
[] __schedule+0x5f1/0x700
[] ? _raw_spin_unlock_irqrestore+0xa/0x10
[] schedule+0x24/0x70
[] usb_kill_urb+0x65/0xa0
[] ? prepare_to_wait_event+0x110/0x110
[] usb_kill_anchored_urbs+0x48/0x80
[] kvaser_usb_unlink_tx_urbs+0x18/0x50 [kvaser_usb]
[] kvaser_usb_rx_error+0xc0/0x400 [kvaser_usb]
[] ? vprintk_default+0x1a/0x20
[] kvaser_usb_read_bulk_callback+0x4c1/0x5f0 [kvaser_usb]
[] __usb_hcd_giveback_urb+0x5e/0xc0
[] usb_hcd_giveback_urb+0x41/0x110
[] finish_urb+0x98/0x180 [ohci_hcd]
[] ? acct_account_cputime+0x17/0x20
[] ? local_clock+0x15/0x30
[] ohci_work+0x1fb/0x5a0 [ohci_hcd]
[] ? process_backlog+0xb1/0x130
[] ohci_irq+0xeb/0x270 [ohci_hcd]
[] usb_hcd_irq+0x21/0x30
[] handle_irq_event_percpu+0x43/0x120
[] handle_irq_event+0x3d/0x60
[] handle_fasteoi_irq+0x74/0x110
[] handle_irq+0x1d/0x30
[] do_IRQ+0x57/0x100
[] common_interrupt+0x6a/0x6aSigned-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit b07ef35244424cbeda9844198607c7077099c82c upstream.
Commit 6fb1ca92a640 "udf: Fix race between write(2) and close(2)"
changed the condition when preallocation is released. The idea was that
we don't want to release the preallocation for an inode on close when
there are other writeable file descriptors for the inode. However the
condition was written in the opposite way so we released preallocation
only if there were other writeable file descriptors. Fix the problem by
changing the condition properly.Fixes: 6fb1ca92a6409a9d5b0696447cd4997bc9aaf5a2
Reported-by: Fabian Frederick
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman -
commit 20602e34cd33dd452bc1836fa7c9b59978f75db0 upstream.
We should select FSR also to be driven by McBSP, not only FSX.
Signed-off-by: Peter Ujfalusi
Acked-by: Jarkko Nikula
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 7ddfdb5c5a5b51bdd2cb749d8341d763b079d520 upstream.
If asoc_simple_card_probe() fails, asoc_simple_card_unref() may be
called before dev_set_drvdata(), causing a NULL pointer dereference in
asoc_simple_card_unref():Unable to handle kernel NULL pointer dereference at virtual address 000000d4
...
PC is at asoc_simple_card_unref+0x14/0x48
LR is at asoc_simple_card_probe+0x3d4/0x40cThis typically happens because asoc_simple_card_parse_of() returns
-EPROBE_DEFER, but other failure modes are possible.
devm_snd_soc_register_card()/snd_soc_register_card() may fail either
before or after dev_set_drvdata().Pass a snd_soc_card pointer instead of a platform_device pointer to
asoc_simple_card_unref() to fix this.Note that if CONFIG_OF_DYNAMIC=n, of_node_put() is a dummy, and gcc may
optimize away the loop over card->dai_link, never actually dereferencing
card, and thus avoiding the crash...Signed-off-by: Geert Uytterhoeven
Fixes: e512e001dafa54e5 ("ASoC: simple-card: Fix the reference count of device nodes")
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit d3268a40d4b19ff7bee23f52eabbc4e96bb685e8 upstream.
In soc_new_compress() when rtd->dai_link->dynamic is set, we create the pcm
substreams with this call:ret = snd_pcm_new_internal(rtd->card->snd_card, new_name, num,
1, 0, &be_pcm);which passes 0 as capture_count leading to
be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream
being NULL, hence when trying to set rtd a few lines below we get an oops.
Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as
playback_count and capture_count to snd_pcm_new_internal().Signed-off-by: Qais Yousef
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit adc60298c80efef4c2d7a7860b91b450931a7cf8 upstream.
The xDC field should have 5 bit width according to Reference Manual.
Thus this patch fixes it.Signed-off-by: Aurelien BOUIN
Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 3a8e5019846736046c0af9dbee3f921c0456141a upstream.
The DSP programs are listed out of order.
Signed-off-by: Peter Rosin
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 22ee76daddb87f88d2336d1b4737ef27c4f307ac upstream.
wm8960 codec can't support sample rate 11250, it must be 11025.
Signed-off-by: Zidan Wang
Acked-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 9c145c56d0c8a0b62e48c8d71e055ad0fb2012ba upstream.
The stack guard page error case has long incorrectly caused a SIGBUS
rather than a SIGSEGV, but nobody actually noticed until commit
fee7e49d4514 ("mm: propagate error from stack expansion even for guard
page") because that error case was never actually triggered in any
normal situations.Now that we actually report the error, people noticed the wrong signal
that resulted. So far, only the test suite of libsigsegv seems to have
actually cared, but there are real applications that use libsigsegv, so
let's not wait for any of those to break.Reported-and-tested-by: Takashi Iwai
Tested-by: Jan Engelhardt
Acked-by: Heiko Carstens # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
