30 Jan, 2015
30 commits
-
commit 5c0b8e0de76a86edb99e46612fd9d341b4c4fa0a upstream.
This patch fixes the big endian mode issue with function
xgene_ahci_read_id.Signed-off-by: Suman Tripathi
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.
DMA mapped IO should be unmapped on the error path in probe() and
unconditionally on remove().Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
Signed-off-by: Andy Shevchenko
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.
EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.Fix this by putting the inversion at the correct position again.
Acked-by: Kukjin Kim
Reported-by: GP Orcullo
Reviewed-by: Doug Anderson
Signed-off-by: Tobias Jakobi
Signed-off-by: Daniel Lezcano
Signed-off-by: Greg Kroah-Hartman -
commit 91d1179212161f220938198b742c328ad38fd0a3 upstream.
This patch makes the bitmask for AIC_SRCTYPE consistent
with that of its valid values, and prevents the priority
field at bits 2:0 from being clobbered by an incorrect
AND with the AIC_SRCTYPE mask.Signed-off-by: Gavin Li
Acked-by: Boris Brezillon
Acked-by: Nicolas Ferre
Link: https://lkml.kernel.org/r/1420598843-8409-1-git-send-email-gavinli@thegavinli.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman -
commit 38bdf45f4aa5cb6186d50a29e6cbbd9d486a1519 upstream.
On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.As a minimal fix for stable, don't use window 13. A full fix will
follow later.Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver")
Reviewed-by: Thomas Petazzoni
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit 4b149e417463bbb6d1d9b805f729627ca2b54495 upstream.
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Tested-by: Aaro Koskinen
Tested-by: Tony Lindgren
Signed-off-by: Felipe Balbi
Link: https://lkml.kernel.org/r/1420576688-10604-1-git-send-email-balbi@ti.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman -
commit a59db67656021fa212e9b95a583f13c34eb67cd9 upstream.
Introduce a new variable to count the number of allocated migration
structures. The existing variable cache->nr_migrations became
overloaded. It was used to:i) track of the number of migrations in flight for the purposes of
quiescing during suspend.ii) to estimate the amount of background IO occuring.
Recent discard changes meant that REQ_DISCARD bios are processed with
a migration. Discards are not background IO so nr_migrations was not
incremented. However this could cause quiescing to complete early.(i) is now handled with a new variable cache->nr_allocated_migrations.
cache->nr_migrations has been renamed cache->nr_io_migrations.
cleanup_migration() is now called free_io_migration(), since it
decrements that variable.Also, remove the unused cache->next_migration variable that got replaced
with with prealloc_structs a while ago.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 9b1cc9f251affdd27f29fe46d0989ba76c33faf6 upstream.
If a DM table is reloaded with an inactive table when the device is not
suspended (normal procedure for LVM2), then there will be two dm-bufio
objects that can diverge. This can lead to a situation where the
inactive table uses bufio to read metadata at the same time the active
table writes metadata -- resulting in the inactive table having stale
metadata buffers once it is promoted to the active table slot.Fix this by using reference counting and a global list of cache metadata
objects to ensure there is only one metadata object per metadata device.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 6cf11ee6300f38b7cfc43af9b7be2afaa5e05869 upstream.
The locking scheme inside the vb2 thread is unsafe when stopping the
thread. In particular kthread_stop was called *after* internal data
structures were cleaned up instead of doing that before. In addition,
internal vb2 functions were called after threadio->stop was set to
true and vb2_internal_streamoff was called. This is also not allowed.All this led to a variety of race conditions and kernel warnings and/or
oopses.Fixed by moving the kthread_stop call up before the cleanup takes
place, and by checking threadio->stop before calling internal vb2
queuing operations.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 721f3223f26bbe81c7e55f84188e74d99df50a16 upstream.
Unconditionally attaching Si2161/Si2165 demod driver
breaks Hauppauge WinTV Starburst.
So create own card entry for this.Add card name comments to the subsystem ids.
This fixes a regression introduced in 3.17 by
36efec48e2e6016e05364906720a0ec350a5d768 ([media] cx23885: Add si2165 support for HVR-5500)Signed-off-by: Matthias Schwarzott
Tested-by: Antti Palosaari
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 6cdb08172bc89f0a39e1643c5e7eab362692fd1b upstream.
Fixes a race condition in abort handling that was injected
when multiple interrupt support was added. When only a single
interrupt is present, the adapter guarantees it will send
responses for aborted commands prior to the response for the
abort command itself. With multiple interrupts, these responses
generally come back on different interrupts, so we need to
ensure the abort thread waits until the aborted command is
complete so we don't perform a double completion. This race
condition was being hit frequently in environments which
were triggering command timeouts, which was resulting in
a double completion causing a kernel oops.Signed-off-by: Brian King
Reviewed-by: Wendy Xiong
Tested-by: Wendy Xiong
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman -
commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream.
Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets. I've also been able to
confirm this behavior on multiple systems. The device never returns from
reset and attempts to access config space of the device after reset result
in hangs. Blacklist bus reset for the device to avoid this issue.[bhelgaas: This regression appeared in v3.14. Andreas bisected it to
425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.][bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Reported-by: Andreas Hartmann
Tested-by: Andreas Hartmann
Signed-off-by: Alex Williamson
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit f331a859e0ee5a898c1f47596eddad4c4f02d657 upstream.
Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset. We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset. This is too much to ask for some devices.Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Signed-off-by: Alex Williamson
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 0f7e7aee2f37119a32e6e8b63250922442528961 upstream.
Add pci_bus_clip_resource(). If a PCI-PCI bridge window overlaps an
upstream bridge window but is not completely contained by it, this clips
the downstream window so it fits inside the upstream one.No functional change (this adds the function but no callers).
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 8505e729a2f6eb0803ff943a15f133dd10afff3a upstream.
Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.This is for scenarios like this:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch. That is a problem because Linux doesn't
always assign things optimally. For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration. Of
course, it's possible that devices below 00:01.0 will no longer fit. If
that's the case, we'll have to reassign things. But that's a separate
problem.[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit 3f2f4dc456e9f80849b99d79600a7257690ca4b1 upstream.
pci_setup_bridge_io(), pci_setup_bridge_mmio(), and
pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges.
Previously they accepted a pointer to the pci_bus of the secondary bus,
then looked up the bridge leading to that bus. Pass the bridge directly,
which will make it more convenient for future callers.No functional change.
[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman -
commit d8a74e186949e1a2c2f1309212478b0659bf9225 upstream.
This was accidently lost in 76a0df859def.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 5615f890bc6babdc2998dec62f3552326d06eb7b upstream.
This adds a quirks list to fix stability problems with
certain SI boards.bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 4369a69ec6ab86821352bd753c68af5880f87956 upstream.
Disable dpm on certain problematic boards rather than
disabling dpm for the entire chip family since most
boards work fine.https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534
https://bugzilla.kernel.org/show_bug.cgi?id=83731Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 226e5ae9e5f9108beb0bde4ac69f68fe6210fed9 upstream.
If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared
if the mutex debugging is enabled which introduces a race in our
mutex_is_locked_by() - i.e. we may inspect the old owner value before it
is acquired by the new task.This is the root cause of this error:
# diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
# index 5cf6731..3ef3736 100644
# --- a/kernel/locking/mutex-debug.c
# +++ b/kernel/locking/mutex-debug.c
# @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex *lock)
# DEBUG_LOCKS_WARN_ON(lock->owner != current);
#
# DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
# - mutex_clear_owner(lock);
# }
#
# /*
# * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
# * mutexes so that we can do it here after we've verified state.
# */
# + mutex_clear_owner(lock);
# atomic_set(&lock->count, 1);
# }Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 48bf5b2d00bfeb681f6500c626189c7cd2c964d2 upstream.
Like Ivybridge, we have reports that we get random hangs when flipping
with multiple pipes. Extendcommit 2a92d5bca1999b69c78f3c3e97b5484985b094b9
Author: Chris Wilson
Date: Tue Jul 8 10:40:29 2014 +0100drm/i915: Disable RCS flips on Ivybridge
to also apply to Haswell.
Reported-and-tested-by: Scott Tsai
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream.
It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().This problem is hard to reproduce making this patch hard to verify, but this
fix will prevent the race.I have not been able to reproduce the problem, but here is a crash dump from
a 2.6.32 kernel.On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE:
crash> struct ata_port.hsm_task_state ffff881c1121c000
hsm_task_state = 0Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(),
which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value.PID: 11053 TASK: ffff8816e846cae0 CPU: 0 COMMAND: "sshd"
#0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b
#1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92
#2 [ffff88008ba03a90] oops_end at ffffffff8152b510
#3 [ffff88008ba03ac0] die at ffffffff81010e0b
#4 [ffff88008ba03af0] do_trap at ffffffff8152ad74
#5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95
#6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b
[exception RIP: ata_sff_hsm_move+317]
RIP: ffffffff813a77ad RSP: ffff88008ba03ca0 RFLAGS: 00010097
RAX: 0000000000000000 RBX: ffff881c1121dc60 RCX: 0000000000000000
RDX: ffff881c1121dd10 RSI: ffff881c1121dc60 RDI: ffff881c1121c000
RBP: ffff88008ba03d00 R8: 0000000000000000 R9: 000000000000002e
R10: 000000000001003f R11: 000000000000009b R12: ffff881c1121c000
R13: 0000000000000000 R14: 0000000000000050 R15: ffff881c1121dd78
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd
#8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e
#9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0 -
commit 72dd299d5039a336493993dcc63413cf31d0e662 upstream.
Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101
"Since commit 8a4aeec8d "libata/ahci: accommodate tag ordered
controllers" the access to the harddisk on the first SATA-port is
failing on its first access. The access to the harddisk on the
second port is working normal.When reverting the above commit, access to both harddisks is working
fine again."Maintain tag ordered submission as the default, but allow sata_sil24 to
continue with the old behavior.Cc: Tejun Heo
Reported-by: Ronny Hegewald
Signed-off-by: Dan Williams
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit b166010f6afbadb896efa37ff85eb681a8f89392 upstream.
sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver")
Signed-off-by: Roger Tseng
[Lee: Removed newly unused variable]
Signed-off-by: Lee Jones
Signed-off-by: Greg Kroah-Hartman -
commit f29ae369a412942e81035984fa3d7a22ddf91fcb upstream.
If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Signed-off-by: Felipe Balbi
Signed-off-by: Lee Jones
Signed-off-by: Greg Kroah-Hartman -
commit 773328da243978bebac82bf4c45604281edb6975 upstream.
STATUS register can be modified by the HW, so we
should bypass cache because of that.In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Signed-off-by: Felipe Balbi
Signed-off-by: Lee Jones
Signed-off-by: Greg Kroah-Hartman -
commit db93facfb0ef542aa5d8079e47580b3e669a4d82 upstream.
This patch is to fix two deadlock cases.
Deadlock 1:
CPU #1
pinctrl_register-> pinctrl_get ->
create_pinctrl
(Holding lock pinctrl_maps_mutex)
-> get_pinctrl_dev_from_devname
(Trying to acquire lock pinctrldev_list_mutex)
CPU #0
pinctrl_unregister
(Holding lock pinctrldev_list_mutex)
-> pinctrl_put ->> pinctrl_free ->
pinctrl_dt_free_maps -> pinctrl_unregister_map
(Trying to acquire lock pinctrl_maps_mutex)Simply to say
CPU#1 is holding lock A and trying to acquire lock B,
CPU#0 is holding lock B and trying to acquire lock A.Deadlock 2:
CPU #3
pinctrl_register-> pinctrl_get ->
create_pinctrl
(Holding lock pinctrl_maps_mutex)
-> get_pinctrl_dev_from_devname
(Trying to acquire lock pinctrldev_list_mutex)
CPU #2
pinctrl_unregister
(Holding lock pctldev->mutex)
-> pinctrl_put ->> pinctrl_free ->
pinctrl_dt_free_maps -> pinctrl_unregister_map
(Trying to acquire lock pinctrl_maps_mutex)
CPU #0
tegra_gpio_request
(Holding lock pinctrldev_list_mutex)
-> pinctrl_get_device_gpio_range
(Trying to acquire lock pctldev->mutex)Simply to say
CPU#3 is holding lock A and trying to acquire lock D,
CPU#2 is holding lock B and trying to acquire lock A,
CPU#0 is holding lock D and trying to acquire lock B.Signed-off-by: Jim Lin
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit bcd53f858d87f52843cc87764b283999126a50d6 upstream.
Timur reports that this code crashes if nfunctions is 0. Fix the
loop iteration to only consider valid elements of the functions
array.Reported-by: Timur Tabi
Cc: Pramod Gurav
Cc: Bjorn Andersson
Cc: Ivan T. Ivanov
Cc: Andy Gross
Fixes: 327455817a92 "pinctrl: qcom: Add support for reset for apq8064"
Signed-off-by: Stephen Boyd
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 6cfda7fbebe8a4fd33ea5722fa0212f98f643c35 upstream.
During the CAN FD standardization process within the ISO it turned out that
the failure detection capability has to be improved.The CAN in Automation organization (CiA) defined the already implemented CAN
FD controllers as 'non-ISO' and the upcoming improved CAN FD controllers as
'ISO' compliant. See at http://www.can-cia.com/index.php?id=1937Finally there will be three types of CAN FD controllers in the future:
1. ISO compliant (fixed)
2. non-ISO compliant (fixed, like the M_CAN IP v3.0.1 in m_can.c)
3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK USB FD)So the current M_CAN driver for the M_CAN IP v3.0.1 has to expose its non-ISO
implementation by setting the CAN_CTRLMODE_FD_NON_ISO ctrlmode at startup.
As this bit cannot be switched at configuration time CAN_CTRLMODE_FD_NON_ISO
must not be set in ctrlmode_supported of the current M_CAN driver.Signed-off-by: Oliver Hartkopp
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 9b1087aa5e86448fe6ad40a58964e35f3ba423d5 upstream.
When changing flags in the CAN drivers ctrlmode the provided new content has to
be checked whether the bits are allowed to be changed. The bits that are to be
changed are given as a bitfield in cm->mask. Therefore checking against
cm->flags is wrong as the content can hold any kind of values.The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
detected command line options. To be robust against bogus user space
applications additionally sanitize the provided flags with the provided mask.Cc: Wolfgang Grandegger
Signed-off-by: Oliver Hartkopp
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman
28 Jan, 2015
10 commits
-
commit 7f1241ed1a06b4846ad7a2a57eb088b757e58e16 upstream.
pps_{lock,unlock}() call intel_display_power_{get,put}() outside
pps_mutes to avoid deadlocks with the power_domain mutex. In theory
during aux transfers we should usually have the relevant power domain
references already held by some higher level code, so this should not
result in much overhead (exception being userspace i2c-dev access).
However thanks to the check_power_well() calls in
intel_display_power_{get/put}() we end up doing a few Punit reads for
each aux transfer. Obviously doing this for each byte transferred via
i2c-over-aux is not a good idea.I can't think of a good way to keep check_power_well() while eliminating
the overhead, so let's just remove check_power_well() entirely.Fixes a driver init time regression introduced by:
commit 773538e86081d146e0020435d614f4b96996c1f9
Author: Ville Syrjälä
Date: Thu Sep 4 14:54:56 2014 +0300drm/i915: Reset power sequencer pipe tracking when disp2d is off
Credit goes to Jani for figuring this out.
v2: Add the regression note in the commit message.
Cc: Egbert Eich
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201
Tested-by: Wendy Wang
Signed-off-by: Ville Syrjälä
[Jani: s/intel_runtime_pm.c/intel_pm.c/g and wiggle for 3.18]
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 46243860806bdc2756f3ce8ac86b4d7c616bcd6c upstream.
While looking at hch's recent conversion to drop the MSG_*_TAG
definitions, I noticed a long standing bug in vhost-scsi where
the VIRTIO_SCSI_S_* attribute definitions where incorrectly
being passed directly into target_submit_cmd_map_sgls().This patch adds the missing virtio-scsi to TCM/SAM task attribute
conversion.Cc: Christoph Hellwig
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 046ba64285a4389ae5e9a7dfa253c6bff3d7c341 upstream.
This patch drops the arbitrary maximum I/O size limit in sbc_parse_cdb(),
which currently for fabric_max_sectors is hardcoded to 8192 (4 MB for 512
byte sector devices), and for hw_max_sectors is a backend driver dependent
value.This limit is problematic because Linux initiators have only recently
started to honor block limits MAXIMUM TRANSFER LENGTH, and other non-Linux
based initiators (eg: MSFT Fibre Channel) can also generate I/Os larger
than 4 MB in size.Currently when this happens, the following message will appear on the
target resulting in I/Os being returned with non recoverable status:SCSI OP 28h with too big sectors 16384 exceeds fabric_max_sectors: 8192
Instead, drop both [fabric,hw]_max_sector checks in sbc_parse_cdb(),
and convert the existing hw_max_sectors into a purely informational
attribute used to represent the granuality that backend driver and/or
subsystem code is splitting I/Os upon.Also, update FILEIO with an explicit FD_MAX_BYTES check in fd_execute_rw()
to deal with the one special iovec limitiation case.v2 changes:
- Drop hw_max_sectors check in sbc_parse_cdb()Reported-by: Lance Gropper
Reported-by: Stefan Priebe
Cc: Christoph Hellwig
Cc: Martin K. Petersen
Cc: Roland Dreier
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit 2eacc608b3bf3519fc353c558454873f4589146d upstream.
The ad7991/ad7995/ad7999 does not have a configuration register like the
other devices that can be written and read. The configuration is written as
part of the conversion sequence.Fixes: 0f7ddcc1bff1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe")
Signed-off-by: Lars-Peter Clausen
Tested-by: Mike Looijmans
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit c4cf0935a2d8fe6d186bf4253ea3c4b4a8a8a710 upstream.
Correct returning IRQ_HANDLED unconditionally in the irq handler.
Return IRQ_NONE for some interrupt which we do not expect to be
handled in this handler. This prevents kernel stalling with back
to back spurious interrupts.Fixes: 2722e56de6 ("OMAP4: l3: Introduce l3-interconnect error handling driver")
Acked-by: Nishanth Menon
Signed-off-by: Keerthy
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 61b43d4e919e8fa5e10c77ee32ba328da07e0264 upstream.
On certain SoCs such as AM437x SoC, L3_noc error registers are
maintained in power domain such as per domain which looses context as part
of low power state such as RTC+DDR mode. On these platforms when we
mask interrupts which we cannot handle, the source of these interrupts
still remain on resume, however, the flag mux registers now contain
their reset value (unmasked) - this breaks the system with infinite
interrupts since we do not these interrupts to take place ever again.To handle this: restore the masking of interrupts which we have
already recorded in the system as ones we cannot handle.Fixes: 2100b595b7 ("bus: omap_l3_noc: ignore masked out unclearable targets")
Acked-by: Nishanth Menon
Signed-off-by: Keerthy
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit 9333caeaeae4f831054e0e127a6ed3948b604d3e upstream.
When KBC is in active multiplexing mode the touchpad on this laptop does
not work.Reported-by: Bilal Koc
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 148e9a711e034e06310a8c36b64957934ebe30f2 upstream.
On some laptops, keyboard needs to be reset in order to successfully detect
touchpad (e.g., some Gigabyte laptop models with Elantech touchpads).
Without resettin keyboard touchpad pretends to be completely dead.Based on the original patch by Mateusz Jończyk this version has been
expanded to include DMI based detection & application of the fix
automatically on the affected models of laptops. This has been confirmed to
fix problem by three users already on three different models of laptops.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331
Signed-off-by: Srihari Vijayaraghavan
Acked-by: Mateusz Jończyk
Tested-by: Srihari Vijayaraghavan
Tested by: Zakariya Dehlawi
Tested-by: Guillaum Bouchard
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 810aa0918b2b032684c8cad13f73d6ba37ad11c0 upstream.
This change allows the driver to recognize newer Elantech touchpads.
Signed-off-by: Yi ju Hong
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
commit 5e7e6e0c9b47a45576c38b4a72d67927a5e049f7 upstream.
Recent Leaf firmware versions (>= 3.1.557) do not allow to send
commands for non-existing channels. If a command is sent for a
non-existing channel, the firmware crashes.Reported-by: Christopher Storah
Signed-off-by: Olivier Sobrie
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman
