06 Feb, 2015
40 commits
-
commit a4dba130891271084344c12537731542ec77cb85 upstream.
Introduce an arch specific function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).No change of behaviour for x86.
Signed-off-by: Stefano Stabellini
Reviewed-by: David Vrabel
Reviewed-by: Catalin Marinas
Acked-by: Ian Campbell
Acked-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit d6ad36913083d683aad4e02e53580c995f1a6ede upstream.
Commit 0b46b8a718c6 (clocksource: arch_timer: Fix code to use physical
timers when requested) introduces the use of physical counters in the
ARM architected timer driver. However, he arm64 kernel uses CNTVCT in
VDSO. When booting in EL2, the kernel switches to the physical timers to
make things easier for KVM but it continues to use the virtual counter
both in user and kernel. While in such scenario CNTVCT == CNTPCT (since
CNTVOFF is initialised by the kernel to 0), we want to spot firmware
bugs corrupting CNTVOFF early (which would affect CNTVCT).Signed-off-by: Catalin Marinas
Tested-by: Yingjoe Chen
Cc: Daniel Lezcano
Signed-off-by: Arnd Bergmann
Fixes: 0b46b8a718c6 ("clocksource: arch_timer: Fix code to use physical
timers when requested")
Cc: Ian Campbell
Signed-off-by: Mark Rutland
Signed-off-by: Greg Kroah-Hartman -
commit 7ffd7b4e169d619e66928fe5d997723f2c6f1056 upstream.
Put controller into init mode in network stop to end pending transmissions. The
issue is observed in cases when transmitted frame is not acked.Signed-off-by: Viktor Babrian
Cc: linux-stable
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 8414947a2018a98cf3adc975dc279f41ba30ab11 upstream.
If a touchpad reports the F11 data40 register then this indicates that the touchpad reports
additional ACM (Accidental Contact Mitigation) data after the F11 data in the HID attention
report. These additional bytes shift the position of the F30 button data causing the driver
to incorrectly report button state when this functionality is present. This patch accounts
for the additional data in the report.Fixes:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398533Signed-off-by: Andrew Duggan
Signed-off-by: Jiri Kosina
Cc: Joseph Salisbury
Signed-off-by: Greg Kroah-Hartman -
commit 98b008dff8452653909d9263efda925873e8d8bb upstream.
This patch fixes a systematic crash in rapl_scale()
due to an invalid pointer.The bug was introduced by commit:
89cbc76768c2 ("x86: Replace __get_cpu_var uses")
The fix is simple. Just put the parenthesis where it needs
to be, i.e., around rapl_pmu. To my surprise, the compiler
was not complaining about passing an integer instead of a
pointer.Reported-by: Vince Weaver
Tested-by: Vince Weaver
Fixes: 89cbc76768c2 ("x86: Replace __get_cpu_var uses")
Signed-off-by: Stephane Eranian
Signed-off-by: Peter Zijlstra (Intel)
Cc: Arnaldo Carvalho de Melo
Cc: cl@linux.com
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/20150122203834.GA10228@thinkpad
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit ef454caeb740ee4e1b89aeb7f7692d5ddffb6830 upstream.
Intel Airmont supports the same architectural and non-architectural
performance monitoring events as Silvermont.Signed-off-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Cc: Arnaldo Carvalho de Melo
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1421913053-99803-1-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 0346dadbf041a2606bcb5bd27828b0d105897f4a upstream.
Commit e61734c55c24 ("cgroup: remove cgroup->name") added two extra
newlines to memcg oom kill log messages. This makes dmesg hard to read
and parse. The issue affects 3.15+.Example:
Task in /t <<< extra #1
killed as a result of limit of /t
<<< extra #2
memory: usage 102400kB, limit 102400kB, failcnt 274712Remove the extra newlines from memcg oom kill messages, so the messages
look like:Task in /t killed as a result of limit of /t
memory: usage 102400kB, limit 102400kB, failcnt 240649Fixes: e61734c55c24 ("cgroup: remove cgroup->name")
Signed-off-by: Greg Thelen
Acked-by: Michal Hocko
Acked-by: Johannes Weiner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 14bf61ffe6ac54afcd1e888a4407fe16054483db upstream.
Currently ->get_dqblk() and ->set_dqblk() use struct fs_disk_quota which
tracks space limits and usage in 512-byte blocks. However VFS quotas
track usage in bytes (as some filesystems require that) and we need to
somehow pass this information. Upto now it wasn't a problem because we
didn't do any unit conversion (thus VFS quota routines happily stuck
number of bytes into d_bcount field of struct fd_disk_quota). Only if
you tried to use Q_XGETQUOTA or Q_XSETQLIM for VFS quotas (or Q_GETQUOTA
/ Q_SETQUOTA for XFS quotas), you got bogus results. Hardly anyone
tried this but reportedly some Samba users hit the problem in practice.
So when we want interfaces compatible we need to fix this.We bite the bullet and define another quota structure used for passing
information from/to ->get_dqblk()/->set_dqblk. It's somewhat sad we have
to have more conversion routines in fs/quota/quota.c and another copying
of quota structure slows down getting of quota information by about 2%
but it seems cleaner than overloading e.g. units of d_bcount to bytes.Reviewed-by: Christoph Hellwig
Signed-off-by: Jan Kara
Signed-off-by: Greg Kroah-Hartman -
commit 13f3fbe827d09e3182023c8c54058cbf97aa146e upstream.
commit 6dda730e55f412a6dfb181cae6784822ba463847
Author: Jani Nikula
Date: Tue Jun 24 18:27:40 2014 +0300drm/i915: respect the VBT minimum backlight brightness
introduced a bug which resulted in inconsistent brightness levels on
different machines. If a suspended was entered with the screen off some
machines would resume with the screen at minimum brightness and others
at maximum brightness.The following commands can be used to produce this behavior.
xset dpms force off
sleep 1
sudo systemctl suspend
(resume ...)The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled. If it is zero,
it is set to the maximum level. Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero. Also, expand the comparison for
the possible case when the level is less than the minimum.Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit f48a01651b1758550c4d3ee65ec726dfa0658780 upstream.
Commit 82460d972 ("drm/i915: Rework ppgtt init to no require an aliasing
ppgtt") introduced a regression on Broadwell, triggering the following
IOMMU fault at startup:vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
dmar: DRHD: handling fault status reg 2
dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000
DMAR:[fault reason 23] Unknown
fbcon: inteldrmfb (fb0) is primary deviceFurther commentary from Daniel:
I sugggested this change to David after staring at the offending patch
for a while. I have no idea and theory whatsoever why this would upset
the gpu less than the other way round. But it seems to work. David
promised to chase hw people a bit more to get a more meaningful answer.Wrt the comment that this deletes: I've done some digging and afaict
loading context before ppgtt enable was once required before our recent
restructuring of the context/ppgtt init code: Before that context sw
setup (i.e. allocating the default context) and hw setup was smashed
together. Also the setup of the default context was the bit that
actually allocated the aliasing ppgtt structures. Which is the reason
for the context before ppgtt depency.Or was, since with all the untangling there's no no real depency any
more (functional, who knows what the hw is doing), so the comment is
just stale.Signed-off-by: David Woodhouse
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 6b96d705f3cf435b0b8835b12c9742513c77fed6 upstream.
BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
Let's fix it and at least allow VGA to work on this units.v2: forgot ammend and v1 doesn't compile
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
Cc: Xion Zhang
Cc: Guo Jinxian
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.
When creating a fence for a tiled object, only fence the area that
makes up the actual tiles. The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles. The extra space is considered
un-tiled and now behaves as if it was a linear object.Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena
Signed-off-by: Bob Paauwe
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
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
