From: Greg Kroah-Hartman Date: Mon, 13 Jun 2022 07:30:27 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v4.9.318~54 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0ea9de80cc685338a43b2dc0b3ed4f7b42dc3ad3;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: ata-libata-transport-fix-dma-pio-xfer-_mode-sysfs-files.patch mmc-block-fix-cqe-recovery-reset-success.patch --- diff --git a/queue-4.19/ata-libata-transport-fix-dma-pio-xfer-_mode-sysfs-files.patch b/queue-4.19/ata-libata-transport-fix-dma-pio-xfer-_mode-sysfs-files.patch new file mode 100644 index 00000000000..57b7f0c7165 --- /dev/null +++ b/queue-4.19/ata-libata-transport-fix-dma-pio-xfer-_mode-sysfs-files.patch @@ -0,0 +1,74 @@ +From 72aad489f992871e908ff6d9055b26c6366fb864 Mon Sep 17 00:00:00 2001 +From: Sergey Shtylyov +Date: Wed, 8 Jun 2022 22:51:07 +0300 +Subject: ata: libata-transport: fix {dma|pio|xfer}_mode sysfs files + +From: Sergey Shtylyov + +commit 72aad489f992871e908ff6d9055b26c6366fb864 upstream. + +The {dma|pio}_mode sysfs files are incorrectly documented as having a +list of the supported DMA/PIO transfer modes, while the corresponding +fields of the *struct* ata_device hold the transfer mode IDs, not masks. + +To match these docs, the {dma|pio}_mode (and even xfer_mode!) sysfs +files are handled by the ata_bitfield_name_match() macro which leads to +reading such kind of nonsense from them: + +$ cat /sys/class/ata_device/dev3.0/pio_mode +XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_MW_DMA_4, +XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2, XFER_PIO_1, +XFER_PIO_0 + +Using the correct ata_bitfield_name_search() macro fixes that: + +$ cat /sys/class/ata_device/dev3.0/pio_mode +XFER_PIO_4 + +While fixing the file documentation, somewhat reword the {dma|pio}_mode +file doc and add a note about being mostly useful for PATA devices to +the xfer_mode file doc... + +Fixes: d9027470b886 ("[libata] Add ATA transport class") +Signed-off-by: Sergey Shtylyov +Cc: stable@vger.kernel.org +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/ABI/testing/sysfs-ata | 11 ++++++----- + drivers/ata/libata-transport.c | 2 +- + 2 files changed, 7 insertions(+), 6 deletions(-) + +--- a/Documentation/ABI/testing/sysfs-ata ++++ b/Documentation/ABI/testing/sysfs-ata +@@ -107,13 +107,14 @@ Description: + described in ATA8 7.16 and 7.17. Only valid if + the device is not a PM. + +- pio_mode: (RO) Transfer modes supported by the device when +- in PIO mode. Mostly used by PATA device. ++ pio_mode: (RO) PIO transfer mode used by the device. ++ Mostly used by PATA devices. + +- xfer_mode: (RO) Current transfer mode ++ xfer_mode: (RO) Current transfer mode. Mostly used by ++ PATA devices. + +- dma_mode: (RO) Transfer modes supported by the device when +- in DMA mode. Mostly used by PATA device. ++ dma_mode: (RO) DMA transfer mode used by the device. ++ Mostly used by PATA devices. + + class: (RO) Device class. Can be "ata" for disk, + "atapi" for packet device, "pmp" for PM, or +--- a/drivers/ata/libata-transport.c ++++ b/drivers/ata/libata-transport.c +@@ -196,7 +196,7 @@ static struct { + { XFER_PIO_0, "XFER_PIO_0" }, + { XFER_PIO_SLOW, "XFER_PIO_SLOW" } + }; +-ata_bitfield_name_match(xfer,ata_xfer_names) ++ata_bitfield_name_search(xfer, ata_xfer_names) + + /* + * ATA Port attributes diff --git a/queue-4.19/mmc-block-fix-cqe-recovery-reset-success.patch b/queue-4.19/mmc-block-fix-cqe-recovery-reset-success.patch new file mode 100644 index 00000000000..636d1ae75c9 --- /dev/null +++ b/queue-4.19/mmc-block-fix-cqe-recovery-reset-success.patch @@ -0,0 +1,41 @@ +From a051246b786af7e4a9d9219cc7038a6e8a411531 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Tue, 31 May 2022 20:19:22 +0300 +Subject: mmc: block: Fix CQE recovery reset success + +From: Adrian Hunter + +commit a051246b786af7e4a9d9219cc7038a6e8a411531 upstream. + +The intention of the use of mmc_blk_reset_success() in +mmc_blk_cqe_recovery() was to prevent repeated resets when retrying and +getting the same error. However, that may not be the case - any amount +of time and I/O may pass before another recovery is needed, in which +case there would be no reason to deny it the opportunity to recover via +a reset if necessary. CQE recovery is expected seldom and failure to +recover (if the clear tasks command fails), even more seldom, so it is +better to allow the reset always, which can be done by calling +mmc_blk_reset_success() always. + +Fixes: 1e8e55b67030c6 ("mmc: block: Add CQE support") +Cc: stable@vger.kernel.org +Signed-off-by: Adrian Hunter +Link: https://lore.kernel.org/r/20220531171922.76080-1-adrian.hunter@intel.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/block.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/mmc/core/block.c ++++ b/drivers/mmc/core/block.c +@@ -1499,8 +1499,7 @@ void mmc_blk_cqe_recovery(struct mmc_que + err = mmc_cqe_recovery(host); + if (err) + mmc_blk_reset(mq->blkdata, host, MMC_BLK_CQE_RECOVERY); +- else +- mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY); ++ mmc_blk_reset_success(mq->blkdata, MMC_BLK_CQE_RECOVERY); + + pr_debug("%s: CQE recovery done\n", mmc_hostname(host)); + } diff --git a/queue-4.19/series b/queue-4.19/series index f81e20acfa1..7dce3859526 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -275,3 +275,5 @@ nodemask-fix-return-values-to-be-unsigned.patch vringh-fix-loop-descriptors-check-in-the-indirect-ca.patch alsa-hda-conexant-fix-loopback-issue-with-cx20632.patch cifs-return-errors-during-session-setup-during-reconnects.patch +ata-libata-transport-fix-dma-pio-xfer-_mode-sysfs-files.patch +mmc-block-fix-cqe-recovery-reset-success.patch