linux.git/drivers, branch v3.18.4

drm/i915: Kill check_power_well() calls

2015-01-27T16:29:46+00:00

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 +0300

    drm/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

vhost-scsi: Add missing virtio-scsi -> TCM attribute conversion

2015-01-27T16:29:45+00:00

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

target: Drop arbitrary maximum I/O size limit

2015-01-27T16:29:45+00:00

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

iio: ad799x: Fix ad7991/ad7995/ad7999 config setup

2015-01-27T16:29:45+00:00

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

bus: omap_l3_noc: Correct returning IRQ_HANDLED unconditionally in the irq handler

2015-01-27T16:29:44+00:00

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

bus: omap_l3_noc: Add resume hook to restore context

2015-01-27T16:29:44+00:00

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

Input: I8042 - add Acer Aspire 7738 to the nomux list

2015-01-27T16:29:44+00:00

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

Input: i8042 - reset keyboard to fix Elantech touchpad detection

2015-01-27T16:29:43+00:00

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

Input: elantech - support new ICs types for version 4

2015-01-27T16:29:43+00:00

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

can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels

2015-01-27T16:29:43+00:00

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