linux-stable.git/drivers/ata/libata-core.c, branch linux-4.1.y

libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDs

2018-05-23T01:36:40+00:00

[ Upstream commit 184add2ca23ce5edcac0ab9c3b9be13f91e7b567 ]

Richard Jones has reported that using med_power_with_dipm on a T450s
with a Sandisk SD7UB3Q256G1001 SSD (firmware version X2180501) is
causing the machine to hang.

Switching the LPM to max_performance fixes this, so it seems that
this Sandisk SSD does not handle LPM well.

Note in the past there have been bug-reports about the following
Sandisk models not working with min_power, so we may need to extend
the quirk list in the future: name - firmware
Sandisk SD6SB2M512G1022I   - X210400
Sandisk SD6PP4M-256G-1006  - A200906

Cc: stable@vger.kernel.org
Cc: Richard W.M. Jones 
Reported-and-tested-by: Richard W.M. Jones 
Signed-off-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version

2018-05-23T01:33:53+00:00

[ Upstream commit d418ff56b8f2d2b296daafa8da151fe27689b757 ]

When commit 9c7be59fc519af ("libata: Apply NOLPM quirk to Crucial MX100
512GB SSDs") was added it inherited the ATA_HORKAGE_NO_NCQ_TRIM quirk
from the existing "Crucial_CT*MX100*" entry, but that entry sets model_rev
to "MU01", where as the entry adding the NOLPM quirk sets it to NULL.

This means that after this commit we no apply the NO_NCQ_TRIM quirk to
all "Crucial_CT512MX100*" SSDs even if they have the fixed "MU02"
firmware. This commit splits the "Crucial_CT512MX100*" quirk into 2
quirks, one for the "MU01" firmware and one for all other firmware
versions, so that we once again only apply the NO_NCQ_TRIM quirk to the
"MU01" firmware version.

Fixes: 9c7be59fc519af ("libata: Apply NOLPM quirk to ... MX100 512GB SSDs")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions

2018-05-23T01:33:53+00:00

[ Upstream commit 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f ]

Commit b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB
drive"), introduced a ATA_HORKAGE_NOLPM quirk for Crucial BX100 500GB SSDs
but limited this to the MU02 firmware version, according to:
http://www.crucial.com/usa/en/support-ssd-firmware

MU02 is the last version, so there are no newer possibly fixed versions
and if the MU02 version has broken LPM then the MU01 almost certainly
also has broken LPM, so this commit changes the quirk to apply to all
firmware versions.

Fixes: b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB...")
Cc: stable@vger.kernel.org
Cc: Kai-Heng Feng 
Signed-off-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs

2018-05-23T01:33:53+00:00

[ Upstream commit 62ac3f7305470e3f52f159de448bc1a771717e88 ]

There have been reports of the Crucial M500 480GB model not working
with LPM set to min_power / med_power_with_dipm level.

It has not been tested with medium_power, but that typically has no
measurable power-savings.

Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03
and there is a MU05 update available, but that update does not mention any
LPM fixes in its changelog, so the quirk matches all firmware versions.

In my experience the LPM problems with (older) Crucial SSDs seem to be
limited to higher capacity versions of the SSDs (different firmware?),
so this commit adds a NOLPM quirk for the 480 and 960GB versions of the
M500, to avoid LPM causing issues with these SSDs.

Cc: stable@vger.kernel.org
Reported-and-tested-by: Martin Steigerwald 
Signed-off-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

libata: Enable queued TRIM for Samsung SSD 860

2018-05-23T01:33:53+00:00

[ Upstream commit ca6bfcb2f6d9deab3924bf901e73622a94900473 ]

Samsung explicitly states that queued TRIM is supported for Linux with
860 PRO and 860 EVO.

Make the previous blacklist to cover only 840 and 850 series.

Signed-off-by: Park Ju Hyung 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

libata: disable LPM for Crucial BX100 SSD 500GB drive

2018-05-23T01:33:53+00:00

[ Upstream commit b17e5729a630d8326a48ec34ef02e6b4464a6aef ]

After Laptop Mode Tools starts to use min_power for LPM, a user found
out Crucial BX100 SSD can't get mounted.

Crucial BX100 SSD 500GB drive don't work well with min_power. This also
happens to med_power_with_dipm.

So let's disable LPM for Crucial BX100 SSD 500GB drive.

BugLink: https://bugs.launchpad.net/bugs/1726930
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs

2018-05-23T01:33:53+00:00

[ Upstream commit 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 ]

Various people have reported the Crucial MX100 512GB model not working
with LPM set to min_power. I've now received a report that it also does
not work with the new med_power_with_dipm level.

It does work with medium_power, but that has no measurable power-savings
and given the amount of people being bitten by the other levels not
working, this commit just disables LPM altogether.

Note all reporters of this have either the 512GB model (max capacity), or
are not specifying their SSD's size. So for now this quirk assumes this is
a problem with the 512GB model only.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=89261
Buglink: https://github.com/linrunner/TLP/issues/84
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

libata: remove WARN() for DMA or PIO command without data

2018-05-23T01:33:53+00:00

[ Upstream commit 9173e5e80729c8434b8d27531527c5245f4a5594 ]

syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0.  This
happened because it issued a READ_6 command with no data buffer.

Just remove the WARN(), as it doesn't appear indicate a kernel bug.  The
expected behavior is to fail the command, which the code does.

Here's a reproducer that works in QEMU when /dev/sg0 refers to a disk of
the default type ("82371SB PIIX3 IDE"):

    #include 
    #include 

    int main()
    {
            char buf[42] = { [36] = 0x8 /* READ_6 */ };

            write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
    }

Fixes: f92a26365a72 ("libata: change ATA_QCFLAG_DMAMAP semantics")
Reported-by: syzbot+f7b556d1766502a69d85071d2ff08bd87be53d0f@syzkaller.appspotmail.com
Cc:  # v2.6.25+
Signed-off-by: Eric Biggers 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

libata: apply MAX_SEC_1024 to all LITEON EP1 series devices

2018-03-01T03:09:39+00:00

[ Upstream commit db5ff909798ef0099004ad50a0ff5fde92426fd1 ]

LITEON EP1 has the same timeout issues as CX1 series devices.

Revert max_sectors to the value of 1024.

'e0edc8c54646 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")'

Signed-off-by: Xinyu Lin 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

libata: Fix ATA request sense

2017-03-06T22:29:13+00:00

[ Upstream commit 2dae99558e86894e9e5dbf097477baaa5eb70134 ]

For an ATA device supporting the sense data reporting feature set, a
failed command will trigger the execution of ata_eh_request_sense if
the result task file of the failed command has the ATA_SENSE bit set
(sense data available bit). ata_eh_request_sense executes the REQUEST
SENSE DATA EXT command to retrieve the sense data of the failed
command. On success of REQUEST SENSE DATA EXT, the ATA_SENSE bit will
NOT be set (the command succeeded) but ata_eh_request_sense
nevertheless tests the availability of sense data by testing that bit
presence in the result tf of the REQUEST SENSE DATA EXT command.  This
leads us to falsely assume that request sense data failed and to the
warning message:

atax.xx: request sense failed stat 50 emask 0

Upon success of REQUEST SENSE DATA EXT, set the ATA_SENSE bit in the
result task file command so that sense data can be returned by
ata_eh_request_sense.

Signed-off-by: Damien Le Moal 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin