11 Feb, 2015
12 commits
-
commit 3f5e1b4f58b7b6480cccff4bf965436102db4346 upstream.
radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from destination BO.bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464Reviewed-by: Christian König
Signed-off-by: Ilija Hadzic
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 72edd83cc9e5819ed1ee771519143d7594e059f0 upstream.
This is a workaround for RS880 and older chips which seem to have
an additional limit on the minimum PLL input frequency.v2: fix signed/unsigned warning
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=91861
https://bugzilla.kernel.org/show_bug.cgi?id=83461Signed-off-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 544143f9e01a60a93eb00ab4bfcb9bf4702a2a7d upstream.
If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it. Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.v2: handle vm_fini as well
v3: handle bo_open/close as wellBug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit b1b02fe97f75b12ab34b2303bfd4e3526d903a58 upstream.
If a non-page-aligned write is destined for a device which
is missing/faulty, we can deadlock.As the target device is missing, a read-modify-write cycle
is not possible.
As the write is not for a full-page, a recontruct-write cycle
is not possible.This should be handled by logic in fetch_block() which notices
there is a non-R5_OVERWRITE write to a missing device, and so
loads all blocks.However since commit 67f455486d2ea2, that code requires
STRIPE_PREREAD_ACTIVE before it will active, and those circumstances
never set STRIPE_PREREAD_ACTIVE.So: in handle_stripe_dirtying, if neither rmw or rcw was possible,
set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set
after a suitable delay.Fixes: 67f455486d2ea20b2d94d6adf5b9b783d079e321
Reported-by: Mikulas Patocka
Tested-by: Heinz Mauelshagen
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 3a9794d32984b67a6d8992226918618f0e51e5d5 upstream.
The following patch fixes an issue observed with 4k sector disks
where the max_hw_sectors attribute was getting set too large in
sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units
of SCSI logical blocks and queue_max_hw_sectors is in units of
512 byte blocks, on a 4k sector disk, every time we went through
sd_revalidate_disk, we were taking the current value of
queue_max_hw_sectors and increasing it by a factor of 8. Fix
this by only shifting sdkp->max_xfer_blocks.Signed-off-by: Brian King
Reviewed-by: Paolo Bonzini
Reviewed-by: Martin K. Petersen
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman -
commit a02bb401f8ae264be782ee57d98bdd99f14c8022 upstream.
For TKT238285 hardware issue which may cause txfifo store data twice can only
be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support)
Signed-off-by: Robin Gong
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 973fbce69ed8e79b5fe3ad19cfecb581a7ef8048 upstream.
devm_* API was supposed to be used only in probe function call.
Memory is allocated at 'probe' and free automatically at 'remove'.
Usage of devm_* functions outside probe sometimes leads to memory leak.
Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead.
Also add the dspi_cleanup function to free the controller data upon
cleanup.Acked-by: Stefan Agner
Signed-off-by: Bhuvanchandra DV
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream.
Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e8164882ca ("PCI: Restore detection of read-only
BARs"). Prior to 36e8164882ca, we filled in res->start; afterwards we
leave it zeroed out. The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.On Nix's system BAR 2's read-only value is 0x6200. Prior to 36e8164882ca,
we interpret that as a 512-byte BAR based on the lowest-order bit set. Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf
Reported-and-tested-by: Nix
Signed-off-by: Myron Stowe
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 19c5392eb1c1e81188e898400c0e8258827eb160 upstream.
The DesignWare PCIe MSI hardware does not support MSI-X IRQs. Setting
those up failed as a side effect of a bug which was fixed by 91f8ae823f2b
("PCI: designware: Setup and clear exactly one MSI at a time").Now that this bug is fixed, MSI-X IRQs need to be rejected explicitly;
otherwise devices trying to use them may end up with incorrectly working
interrupts.Fixes: 91f8ae823f2b ("PCI: designware: Setup and clear exactly one MSI at a time")
Signed-off-by: Lucas Stach
Signed-off-by: Bjorn Helgaas
Acked-by: Jingoo Han
Signed-off-by: Greg Kroah-Hartman -
commit b184c388f773f30b6c707d3d4599b2db80f4390c upstream.
Create default gpio base if neither device node nor
platform data is defined.Signed-off-by: Sonic Zhang
Reviewed-by: Alexandre Courbot
Tested-by: Antonio Fiol
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.Fixes: 0769746183ca ("gpiolib: add support for changing value polarity in sysfs")
Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using sysfs links")
Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
06 Feb, 2015
28 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 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 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 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
