linux.git/drivers/ata, branch v5.3-rc1

Merge tag 'for-5.3/libata-20190708' of git://git.kernel.dk/linux-block

2019-07-09T17:59:26+00:00

Pull libata updates from Jens Axboe:
 "These are the changes that are reviewed, tested, and queued up for
  this merge window. This contains:

   - Removal of redundant memset after dmam_alloc_coherent (Fuqian)

   - Expand blacklist check for ST1000LM024, making it independent of
     firmware version (Hans)

   - Request sense fix (Tejun)

   - ahci_sunxi FIFO fix (Uenal)"

* tag 'for-5.3/libata-20190708' of git://git.kernel.dk/linux-block:
  drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs
  libata: Drop firmware version check from the ST1000LM024 quirk
  ata: sata_sil24: Remove call to memset after dmam_alloc_coherent
  ata:sata_qstor: Remove call to memset after dmam_alloc_coherent
  ata: sata_nv: Remove call to memset after dmam_alloc_coherent
  ata: pdc_adma: Remove call to memset after dmam_alloc_coherent
  ata: libahci: Remove call to memset after dmam_alloc_coherent
  ata: acard-ahci: Remove call to memset after dmam_alloc_coherent
  libata: don't request sense data on !ZAC ATA devices

drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs

2019-07-05T16:17:18+00:00

Increasing the SATA/AHCI DMA TX/RX FIFOs (P0DMACR.TXTS and .RXTS, ie.
TX_TRANSACTION_SIZE and RX_TRANSACTION_SIZE) from default 0x0 each
to 0x3 each, gives a write performance boost of 120 MiB/s to 132 MiB/s
from lame 36 MiB/s to 45 MiB/s previously.
Read performance is above 200 MiB/s.
[tested on SSD using dd bs=4K/8K/12K/16K/20K/24K/32K: peak-perf at 12K]

Tested on the SBCs Banana Pi R1 (aka Lamobo R1) and Banana Pi M1 which
are based on the Allwinner A20 32bit-SoC (ARMv7-a / arm-linux-gnueabihf).
These devices are RaspberryPi-like small devices.

This problem of slow SATA write-speed with these small devices lasts
for about 7 years now (beginning with the A10 SoC). Many commentators
throughout the years wrongly assumed the slow write speed was a
hardware limitation. This patch finally solves the problem, which
in fact was just a hard-to-find software problem due to lack of
SATA/AHCI documentation by the SoC-maker Allwinner Technology.

Lists of the affected sunxi and other boards and SoCs with SATA using
the ahci_sunxi driver:
  $ grep -i -e "^&ahci" arch/arm/boot/dts/sun*dts
  and http://linux-sunxi.org/SATA#Devices_with_SATA_ports
  See also http://linux-sunxi.org/Category:Devices_with_SATA_port

Tested-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
Reviewed-by: Hans de Goede 
Signed-off-by: Uenal Mutlu 
Signed-off-by: Jens Axboe

libata: Drop firmware version check from the ST1000LM024 quirk

2019-07-02T21:53:09+00:00

There are several firmware versions between version 2AR10001 and
2BA30001, presumably these also have broken FPDMA_AA activation, so
lets play it safe and apply the quirk to all firmware versions.

Suggested-by: Martin K. Petersen 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Hans de Goede 
Signed-off-by: Jens Axboe

ata: sata_sil24: Remove call to memset after dmam_alloc_coherent

2019-06-29T15:42:23+00:00

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),,
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang 
Signed-off-by: Jens Axboe

ata:sata_qstor: Remove call to memset after dmam_alloc_coherent

2019-06-29T15:42:23+00:00

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang 
Signed-off-by: Jens Axboe

ata: sata_nv: Remove call to memset after dmam_alloc_coherent

2019-06-29T15:42:23+00:00

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang 
Signed-off-by: Jens Axboe

ata: pdc_adma: Remove call to memset after dmam_alloc_coherent

2019-06-29T15:42:23+00:00

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang 
Signed-off-by: Jens Axboe

ata: libahci: Remove call to memset after dmam_alloc_coherent

2019-06-29T15:42:23+00:00

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang 
Signed-off-by: Jens Axboe

ata: acard-ahci: Remove call to memset after dmam_alloc_coherent

2019-06-29T15:42:23+00:00

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang 
Signed-off-by: Jens Axboe

libata: don't request sense data on !ZAC ATA devices

2019-06-25T15:22:45+00:00

ZAC support added sense data requesting on error for both ZAC and ATA
devices. This seems to cause erratic error handling behaviors on some
SSDs where the device reports sense data availability and then
delivers the wrong content making EH take the wrong actions.  The
failure mode was sporadic on a LITE-ON ssd and couldn't be reliably
reproduced.

There is no value in requesting sense data from non-ZAC ATA devices
while there's a significant risk of introducing EH misbehaviors which
are difficult to reproduce and fix.  Let's do the sense data dancing
only for ZAC devices.

Reviewed-by: Hannes Reinecke 
Tested-by: Masato Suzuki 
Reviewed-by: Damien Le Moal 
Signed-off-by: Tejun Heo 
Signed-off-by: Jens Axboe