linux-toradex.git/drivers, branch v3.2.67 Linux kernel for Apalis and Colibri modules PCI: Handle read-only BARs on AMD CS553x devices 2015-02-20T00:49:42+00:00 Myron Stowe myron.stowe@redhat.com 2015-02-03T23:01:24+00:00 a758de0e272db9960c814bb031164b12e660e99c 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 <nix@esperi.org.uk> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
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 <nix@esperi.org.uk>
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
enic: fix rx skb checksum 2015-02-20T00:49:41+00:00 Govindarajulu Varadarajan _govind@gmx.com 2014-12-18T10:28:42+00:00 58aa2f36823a7db2ae0962d47ce36823cd02d035 [ Upstream commit 17e96834fd35997ca7cdfbf15413bcd5a36ad448 ] Hardware always provides compliment of IP pseudo checksum. Stack expects whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set. This causes checksum error in nf & ovs. kernel: qg-19546f09-f2: hw csum failure kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF O-------------- 3.10.0-123.8.1.el7.x86_64 #1 kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014 kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0 kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00 kernel: Call Trace: kernel: <IRQ> [<ffffffff815e237b>] dump_stack+0x19/0x1b kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40 kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70 kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20 kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100 kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4] kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0 kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch] kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack] kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40 kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4] kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0 kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40 kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140 kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40 kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380 Hardware verifies IP & tcp/udp header checksum but does not provide payload checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet. Cc: Jiri Benc <jbenc@redhat.com> Cc: Stefan Assmann <sassmann@redhat.com> Reported-by: Sunil Choudhary <schoudha@redhat.com> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com> Reviewed-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
[ Upstream commit 17e96834fd35997ca7cdfbf15413bcd5a36ad448 ]

Hardware always provides compliment of IP pseudo checksum. Stack expects
whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.

This causes checksum error in nf & ovs.

kernel: qg-19546f09-f2: hw csum failure
kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF          O--------------   3.10.0-123.8.1.el7.x86_64 #1
kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014
kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b
kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0
kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00
kernel: Call Trace:
kernel: <IRQ>  [<ffffffff815e237b>] dump_stack+0x19/0x1b
kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40
kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70
kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20
kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100
kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0
kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch]
kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140
kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380

Hardware verifies IP & tcp/udp header checksum but does not provide payload
checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.

Cc: Jiri Benc <jbenc@redhat.com>
Cc: Stefan Assmann <sassmann@redhat.com>
Reported-by: Sunil Choudhary <schoudha@redhat.com>
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Reviewed-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
tg3: tg3_disable_ints using uninitialized mailbox value to disable interrupts 2015-02-20T00:49:41+00:00 Prashant Sreedharan prashant@broadcom.com 2014-12-20T20:16:17+00:00 1da9db7a92d9bde36e4d1e3ac02eece72d078993 [ Upstream commit 05b0aa579397b734f127af58e401a30784a1e315 ] During driver load in tg3_init_one, if the driver detects DMA activity before intializing the chip tg3_halt is called. As part of tg3_halt interrupts are disabled using routine tg3_disable_ints. This routine was using mailbox value which was not initialized (default value is 0). As a result driver was writing 0x00000001 to pci config space register 0, which is the vendor id / device id. This driver bug was exposed because of the commit a7877b17a667 (PCI: Check only the Vendor ID to identify Configuration Request Retry). Also this issue is only seen in older generation chipsets like 5722 because config space write to offset 0 from driver is possible. The newer generation chips ignore writes to offset 0. Also without commit a7877b17a667, for these older chips when a GRC reset is issued the Bootcode would reprogram the vendor id/device id, which is the reason this bug was masked earlier. Fixed by initializing the interrupt mailbox registers before calling tg3_halt. Please queue for -stable. Reported-by: Nils Holland <nholland@tisys.org> Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: Prashant Sreedharan <prashant@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
[ Upstream commit 05b0aa579397b734f127af58e401a30784a1e315 ]

During driver load in tg3_init_one, if the driver detects DMA activity before
intializing the chip tg3_halt is called. As part of tg3_halt interrupts are
disabled using routine tg3_disable_ints. This routine was using mailbox value
which was not initialized (default value is 0). As a result driver was writing
0x00000001 to pci config space register 0, which is the vendor id / device id.

This driver bug was exposed because of the commit a7877b17a667 (PCI: Check only
the Vendor ID to identify Configuration Request Retry). Also this issue is only
seen in older generation chipsets like 5722 because config space write to offset
0 from driver is possible. The newer generation chips ignore writes to offset 0.
Also without commit a7877b17a667, for these older chips when a GRC reset is
issued the Bootcode would reprogram the vendor id/device id, which is the reason
this bug was masked earlier.

Fixed by initializing the interrupt mailbox registers before calling tg3_halt.

Please queue for -stable.

Reported-by: Nils Holland <nholland@tisys.org>
Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Prashant Sreedharan <prashant@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
s390/3215: fix tty output containing tabs 2015-02-20T00:49:40+00:00 Martin Schwidefsky schwidefsky@de.ibm.com 2014-08-13T10:01:30+00:00 308246b89588040ec174a48eda49549fa2fea60d commit e512d56c799517f33b301d81e9a5e0ebf30c2d1e upstream. git commit 37f81fa1f63ad38e16125526bb2769ae0ea8d332 "n_tty: do O_ONLCR translation as a single write" surfaced a bug in the 3215 device driver. In combination this broke tab expansion for tty ouput. The cause is an asymmetry in the behaviour of tty3215_ops->write vs tty3215_ops->put_char. The put_char function scans for '\t' but the write function does not. As the driver has logic for the '\t' expansion remove XTABS from c_oflag of the initial termios as well. Reported-by: Stephen Powell <zlinuxman@wowway.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit e512d56c799517f33b301d81e9a5e0ebf30c2d1e upstream.

git commit 37f81fa1f63ad38e16125526bb2769ae0ea8d332
"n_tty: do O_ONLCR translation as a single write"
surfaced a bug in the 3215 device driver. In combination this
broke tab expansion for tty ouput.

The cause is an asymmetry in the behaviour of tty3215_ops->write
vs tty3215_ops->put_char. The put_char function scans for '\t'
but the write function does not.

As the driver has logic for the '\t' expansion remove XTABS
from c_oflag of the initial termios as well.

Reported-by: Stephen Powell <zlinuxman@wowway.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer. 2015-02-20T00:49:40+00:00 Lv Zheng lv.zheng@intel.com 2014-10-29T03:33:49+00:00 bb5850b1a1c3ffd6b6f28262b934165a76cb911a commit 79149001105f18bd2285ada109f9229ea24a7571 upstream. It is reported that Samsung laptops that need to poll events are broken by the following commit: Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set The behaviors of the 2 vendor firmwares are conflict: 1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware automatically sets SCI_EVT as long as there is event queued up. 2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware returns 0 when there is no event queued up. This patch is a quick fix to distinguish the behaviors to make Acer behavior only effective for Acer EC firmware so that the breakages on Samsung EC firmware can be avoided. Fixes: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...) Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161 Reported-and-tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw : Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Kamal Mostafa <kamal@canonical.com> 
commit 79149001105f18bd2285ada109f9229ea24a7571 upstream.

It is reported that Samsung laptops that need to poll events are broken by
the following commit:
 Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

The behaviors of the 2 vendor firmwares are conflict:
 1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
         automatically sets SCI_EVT as long as there is event queued up.
 2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
            returns 0 when there is no event queued up.

This patch is a quick fix to distinguish the behaviors to make Acer
behavior only effective for Acer EC firmware so that the breakages on
Samsung EC firmware can be avoided.

Fixes: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Kamal Mostafa <kamal@canonical.com>
drm/i915: Only fence tiled region of object. 2015-02-20T00:49:39+00:00 Bob Paauwe bob.j.paauwe@intel.com 2014-12-18T17:51:26+00:00 875cf1b62db4f0cfe8c082c78f8f0bb7bb71bc9b 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 <danh@ghs.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> [bwh: Backported to 3.2: - Adjust context, indentation - Apply to both i965_write_fence_reg() and sandybridge_write_fence_reg(), which have been combined into one function upstream] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
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 <danh@ghs.com>
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - Apply to both i965_write_fence_reg() and sandybridge_write_fence_reg(),
   which have been combined into one function upstream]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
USB: Add OTG PET device to TPL 2015-02-20T00:49:39+00:00 Macpaul Lin macpaul@gmail.com 2015-01-23T06:39:02+00:00 4e5cc195ae9d82ff725e7bbd9c23a048b2fedfca 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 <macpaul@gmail.com> Cc: Pavankumar Kondeti <pkondeti@codeaurora.org> Cc: Vijayavardhan Vennapusa <vvreddy@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
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 <macpaul@gmail.com>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
Cc: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
usb-core bInterval quirk 2015-02-20T00:49:39+00:00 James P Michels III james.p.michels@gmail.com 2014-07-27T17:28:04+00:00 cca4d731e2e9ccebb069b84c8aea70f15834a203 commit cd83ce9e6195aa3ea15ab4db92892802c20df5d0 upstream. This patch adds a usb quirk to support devices with interupt endpoints and bInterval values expressed as microframes. The quirk causes the parse endpoint function to modify the reported bInterval to a standards conforming value. There is currently code in the endpoint parser that checks for bIntervals that are outside of the valid range (1-16 for USB 2+ high speed and super speed interupt endpoints). In this case, the code assumes the bInterval is being reported in 1ms frames. As well, the correction is only applied if the original bInterval value is out of the 1-16 range. With this quirk applied to the device, the bInterval will be accurately adjusted from microframes to an exponent. Signed-off-by: James P Michels III <james.p.michels@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit cd83ce9e6195aa3ea15ab4db92892802c20df5d0 upstream.

This patch adds a usb quirk to support devices with interupt endpoints
and bInterval values expressed as microframes. The quirk causes the
parse endpoint function to modify the reported bInterval to a standards
conforming value.

There is currently code in the endpoint parser that checks for
bIntervals that are outside of the valid range (1-16 for USB 2+ high
speed and super speed interupt endpoints). In this case, the code assumes
the bInterval is being reported in 1ms frames. As well, the correction
is only applied if the original bInterval value is out of the 1-16 range.

With this quirk applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.

Signed-off-by: James P Michels III <james.p.michels@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controller 2015-02-20T00:49:39+00:00 Dmitry Nezhevenko dion@dion.org.ua 2015-01-12T17:13:01+00:00 4fe697c2b34b5740118a477db535f2fb1ab24467 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 2927892584 This patch adds blacklist flag so that sd will not use FUA Signed-off-by: Dmitry Nezhevenko <dion@dion.org.ua> Cc: Phil Dibowitz <phil@ipom.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
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 2927892584

This patch adds blacklist flag so that sd will not use FUA

Signed-off-by: Dmitry Nezhevenko <dion@dion.org.ua>
Cc: Phil Dibowitz <phil@ipom.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Input: i8042 - add noloop quirk for Medion Akoya E7225 (MD98857) 2015-02-20T00:49:39+00:00 Jochen Hein jochen@jochen.org 2015-01-22T20:03:15+00:00 3668afd7d0c8c39fe19bdc67e5318461f917684a 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/input6 dmidecode excerpt for this laptop is: Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Medion Product Name: Akoya E7225 Version: 1.0 Signed-off-by: Jochen Hein <jochen@jochen.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
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/input6

dmidecode excerpt for this laptop is:

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: Medion
        Product Name: Akoya E7225
        Version: 1.0

Signed-off-by: Jochen Hein <jochen@jochen.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>