user/sven/linux.git/drivers/ata, branch v4.14.99

sata_rcar: fix deferred probing

2019-02-12T18:46:03Z

[ 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:13:15Z

[ 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

ata: ftide010: Add a quirk for SQ201

2018-10-04T00:00:59Z

[ Upstream commit 46cb52ad414ac829680d0bb8cc7090ac2b577ca7 ] The DMA is broken on this specific device for some unknown reason (probably badly designed or plain broken interface electronics) and will only work with PIO. Other users of the same hardware does not have this problem. Add a specific quirk so that this Gemini device gets DMA turned off. Also fix up some code around passing the port information around in probe while we're at it. Signed-off-by: Linus Walleij Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ata: libahci: Correct setting of DEVSLP register

2018-09-19T20:43:41Z

[ 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

ata: libahci: Allow reconfigure of DEVSLP register

2018-09-19T20:43:41Z

[ Upstream commit 11c291461b6ea8d1195a96d6bba6673a94aacebc ] There are two modes in which DEVSLP can be entered. The OS initiated or hardware autonomous. In hardware autonomous mode, BIOS configures the AHCI controller and the device to enable DEVSLP. But they may not be ideal for all cases. So in this case, OS should be able to reconfigure DEVSLP register. Currently if the DEVSLP is already enabled, we can't set again as it will simply return. There are some systems where the firmware is setting high DITO by default, in this case we can't modify here to correct settings. With the default in several seconds, we are not able to transition to DEVSLP. This change will allow reconfiguration of devslp register if DITO is different. Signed-off-by: Srinivas Pandruvada Reviewed-by: Hans de Goede Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

libahci: Fix possible Spectre-v1 pmp indexing in ahci_led_store()

2018-08-24T11:09:00Z

[ Upstream commit fae2a63737e5973f1426bc139935a0f42e232844 ] Currently smatch warns of possible Spectre-V1 issue in ahci_led_store(): drivers/ata/libahci.c:1150 ahci_led_store() warn: potential spectre issue 'pp->em_priv' (local cap) Userspace controls @pmp from following callchain: em_message->store() ->ata_scsi_em_message_store() -->ap->ops->em_store() --->ahci_led_store() After the mask+shift @pmp is effectively an 8b value, which is used to index into an array of length 8, so sanitize the array index. Signed-off-by: John Garry Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

libata: Fix command retry decision

2018-08-03T05:50:35Z

[ 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:39:25Z

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

ata: Fix ZBC_OUT all bit handling

2018-07-17T09:39:24Z

commit 6edf1d4cb0acde3a0a5dac849f33031bd7abb7b1 upstream. If the ALL bit is set in the ZBC_OUT command, the command zone ID field (block) should be ignored. Reported-by: David Butterfield Signed-off-by: Damien Le Moal Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

ata: Fix ZBC_OUT command block check

2018-07-17T09:39:24Z

commit b320a0a9f23c98f21631eb27bcbbca91c79b1c6e upstream. The block (LBA) specified must not exceed the last addressable LBA, which is dev->nr_sectors - 1. So fix the correct check is "if (block >= dev->n_sectors)" and not "if (block > dev->n_sectords)". Additionally, the asc/ascq to return for an LBA that is not a zone start LBA should be ILLEGAL REQUEST, regardless if the bad LBA is out of range. Reported-by: David Butterfield Signed-off-by: Damien Le Moal Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman