linux-stable.git/drivers/ata, branch v4.4.185

libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk

2019-06-22T06:18:22+00:00

commit 31f6264e225fb92cf6f4b63031424f20797c297d upstream.

We've received a bugreport that using LPM with ST1000LM024 drives leads
to system lockups. So it seems that these models are buggy in more then
1 way. Add NOLPM quirk to the existing quirks entry for BROKEN_FPDMA_AA.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330
Cc: stable@vger.kernel.org
Reviewed-by: Martin K. Petersen 
Signed-off-by: Hans de Goede 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

libata: fix using DMA buffers on stack

2019-05-16T17:44:59+00:00

[ Upstream commit dd08a8d9a66de4b54575c294a92630299f7e0fe7 ]

When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for
a stack virtual address. Stack DMA buffers must be avoided.

Signed-off-by: raymond pang 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin (Microsoft)

sata_rcar: fix deferred probing

2019-02-20T09:13:08+00:00

[ Upstream commit 9f83cfdb1ace3ef268ecc6fda50058d2ec37d603 ]

The driver overrides the error codes returned by platform_get_irq() to
-EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe
permanently instead of the deferred probing. Switch to propagating the
error code upstream, still checking/overriding IRQ0 as libata regards it
as "no IRQ" (thus polling) anyway...

Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
Reviewed-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

libata: whitelist all SAMSUNG MZ7KM* solid-state disks

2018-12-21T13:09:53+00:00

[ Upstream commit fd6f32f78645db32b6b95a42e45da2ddd6de0e67 ]

These devices support read zero after trim (RZAT), as they advertise to
the OS. However, the OS doesn't believe the SSDs unless they are
explicitly whitelisted.

Acked-by: Martin K. Petersen 
Signed-off-by: Juha-Matti Tilli 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

ahci: don't ignore result code of ahci_reset_controller()

2018-11-10T15:41:42+00:00

[ Upstream commit d312fefea8387503375f728855c9a62de20c9665 ]

ahci_pci_reset_controller() calls ahci_reset_controller(), which may
fail, but ignores the result code and always returns success. This
may result in failures like below

  ahci 0000:02:00.0: version 3.0
  ahci 0000:02:00.0: enabling device (0000 -> 0003)
  ahci 0000:02:00.0: SSS flag set, parallel bus scan disabled
  ahci 0000:02:00.0: controller reset failed (0xffffffff)
  ahci 0000:02:00.0: failed to stop engine (-5)
    ... repeated many times ...
  ahci 0000:02:00.0: failed to stop engine (-5)
  Unable to handle kernel paging request at virtual address ffff0000093f9018
    ...
  PC is at ahci_stop_engine+0x5c/0xd8 [libahci]
  LR is at ahci_deinit_port.constprop.12+0x1c/0xc0 [libahci]
    ...
  [] ahci_stop_engine+0x5c/0xd8 [libahci]
  [] ahci_deinit_port.constprop.12+0x1c/0xc0 [libahci]
  [] ahci_init_controller+0x80/0x168 [libahci]
  [] ahci_pci_init_controller+0x60/0x68 [ahci]
  [] ahci_init_one+0x75c/0xd88 [ahci]
  [] local_pci_probe+0x3c/0xb8
  [] pci_device_probe+0x138/0x170
  [] driver_probe_device+0x2dc/0x458
  [] __driver_attach+0x114/0x118
  [] bus_for_each_dev+0x60/0xa0
  [] driver_attach+0x20/0x28
  [] bus_add_driver+0x1f0/0x2a8
  [] driver_register+0x60/0xf8
  [] __pci_register_driver+0x3c/0x48
  [] ahci_pci_driver_init+0x1c/0x1000 [ahci]
  [] do_one_initcall+0x38/0x120

where an obvious hardware level failure results in an unnecessary 15 second
delay and a subsequent crash.

So record the result code of ahci_reset_controller() and relay it, rather
than ignoring it.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

ata: libahci: Correct setting of DEVSLP register

2018-09-19T20:48:58+00:00

[ Upstream commit 2dbb3ec29a6c069035857a2fc4c24e80e5dfe3cc ]

We have seen that on some platforms, SATA device never show any DEVSLP
residency. This prevent power gating of SATA IP, which prevent system
to transition to low power mode in systems with SLP_S0 aka modern
standby systems. The PHY logic is off only in DEVSLP not in slumber.
Reference:
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets
/332995-skylake-i-o-platform-datasheet-volume-1.pdf
Section 28.7.6.1

Here driver is trying to do read-modify-write the devslp register. But
not resetting the bits for which this driver will modify values (DITO,
MDAT and DETO). So simply reset those bits before updating to new values.

Signed-off-by: Srinivas Pandruvada 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

libata: Fix command retry decision

2018-08-06T14:24:36+00:00

[ Upstream commit 804689ad2d9b66d0d3920b48cf05881049d44589 ]

For failed commands with valid sense data (e.g. NCQ commands),
scsi_check_sense() is used in ata_analyze_tf() to determine if the
command can be retried. In such case, rely on this decision and ignore
the command error mask based decision done in ata_worth_retry().

This fixes useless retries of commands such as unaligned writes on zoned
disks (TYPE_ZAC).

Signed-off-by: Damien Le Moal 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ahci: Disable LPM on Lenovo 50 series laptops with a too old BIOS

2018-07-17T09:31:43+00:00

commit 240630e61870e62e39a97225048f9945848fa5f5 upstream.

There have been several reports of LPM related hard freezes about once
a day on multiple Lenovo 50 series models. Strange enough these reports
where not disk model specific as LPM issues usually are and some users
with the exact same disk + laptop where seeing them while other users
where not seeing these issues.

It turns out that enabling LPM triggers a firmware bug somewhere, which
has been fixed in later BIOS versions.

This commit adds a new ahci_broken_lpm() function and a new ATA_FLAG_NO_LPM
for dealing with this.

The ahci_broken_lpm() function contains DMI match info for the 4 models
which are known to be affected by this and the DMI BIOS date field for
known good BIOS versions. If the BIOS date is older then the one in the
table LPM will be disabled and a warning will be printed.

Note the BIOS dates are for known good versions, some older versions may
work too, but we don't know for sure, the table is using dates from BIOS
versions for which users have confirmed that upgrading to that version
makes the problem go away.

Unfortunately I've been unable to get hold of the reporter who reported
that BIOS version 2.35 fixed the problems on the W541 for him. I've been
able to verify the DMI_SYS_VENDOR and DMI_PRODUCT_VERSION from an older
dmidecode, but I don't know the exact BIOS date as reported in the DMI.
Lenovo keeps a changelog with dates in their release notes, but the
dates there are the release dates not the build dates which are in DMI.
So I've chosen to set the date to which we compare to one day past the
release date of the 2.34 BIOS. I plan to fix this with a follow up
commit once I've the necessary info.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk

2018-07-03T09:21:26+00:00

commit 2cfce3a86b64b53f0a70e92a6a659c720c319b45 upstream.

Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk
SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs.

This has lead to several reports of users of that SSD where LPM
was working fine and who know have a significantly increased idle
power consumption on their laptops.

Likely there is another problem on the T450s from the original
reporter which gets exposed by the uncore reaching deeper sleep
states (higher PC-states) due to LPM being enabled. The problem as
reported, a hardfreeze about once a day, already did not sound like
it would be caused by LPM and the reports of the SSD working fine
confirm this. The original reporter is ok with dropping the quirk.

A X250 user has reported the same hard freeze problem and for him
the problem went away after unrelated updates, I suspect some GPU
driver stack changes fixed things.

TL;DR: The original reporters problem were triggered by LPM but not
an LPM issue, so drop the quirk for the SSD in question.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207
Cc: stable@vger.kernel.org
Cc: Richard W.M. Jones 
Cc: Lorenzo Dalrio 
Reported-by: Lorenzo Dalrio 
Signed-off-by: Hans de Goede 
Signed-off-by: Tejun Heo 
Acked-by: "Richard W.M. Jones" 
Signed-off-by: Greg Kroah-Hartman

libata: zpodd: small read overflow in eject_tray()

2018-07-03T09:21:26+00:00

commit 18c9a99bce2a57dfd7e881658703b5d7469cc7b9 upstream.

We read from the cdb[] buffer in ata_exec_internal_sg().  It has to be
ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.

Fixes: 213342053db5 ("libata: handle power transition of ODD")
Signed-off-by: Dan Carpenter 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman