From: <gregkh@linuxfoundation.org>
To: <adrian.hunter@intel.com>, <gregkh@linuxfoundation.org>,
<ulf.hansson@linaro.org>
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "mmc: sdhci: Fix DMA descriptor with zero data length" has been added to the 4.4-stable tree
Date: Tue, 01 Mar 2016 19:10:28 +0000 [thread overview]
Message-ID: <14568594279960@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
mmc: sdhci: Fix DMA descriptor with zero data length
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mmc-sdhci-fix-dma-descriptor-with-zero-data-length.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 347ea32dc118326c4f2636928239a29d192cc9b8 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu, 26 Nov 2015 14:00:48 +0200
Subject: mmc: sdhci: Fix DMA descriptor with zero data length
From: Adrian Hunter <adrian.hunter@intel.com>
commit 347ea32dc118326c4f2636928239a29d192cc9b8 upstream.
SDHCI has built-in DMA called ADMA2. ADMA2 uses a descriptor
table to define DMA scatter-gather. Each desciptor can specify
a data length up to 65536 bytes, however the length field is
only 16-bits so zero means 65536. Consequently, putting zero
when the size is zero must not be allowed. This patch fixes
one case where zero data length could be set inadvertently.
The problem happens because unaligned data gets split and the
code did not consider that the remaining aligned portion might
be zero length. That case really only happens for SDIO because
SD and eMMC cards transfer blocks that are invariably sector-
aligned. For SDIO, access to function registers is done by
data transfer (CMD53) when the register is bigger than 1 byte.
Generally registers are 4 bytes but 2-byte registers are possible.
So DMA of 4 bytes or less can happen. When 32-bit DMA is used,
the data alignment must be 4, so 4-byte transfers won't casue a
problem, but a 2-byte transfer could. However with the introduction
of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes,
so all 4-byte transfers not on 8-byte boundaries get "split" into
a 4-byte chunk and a 0-byte chunk, thereby hitting the bug.
In fact, a closer look at the SDHCI specs indicates that only the
descriptor table requires 8-byte alignment for 64-bit DMA. That
will be dealt with in a separate patch, but the potential for a
2-byte access remains, so this fix is needed anyway.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -540,9 +540,12 @@ static int sdhci_adma_table_pre(struct s
BUG_ON(len > 65536);
- /* tran, valid */
- sdhci_adma_write_desc(host, desc, addr, len, ADMA2_TRAN_VALID);
- desc += host->desc_sz;
+ if (len) {
+ /* tran, valid */
+ sdhci_adma_write_desc(host, desc, addr, len,
+ ADMA2_TRAN_VALID);
+ desc += host->desc_sz;
+ }
/*
* If this triggers then we have a calculation bug
Patches currently in stable-queue which might be from adrian.hunter@intel.com are
queue-4.4/mmc-sdhci-acpi-fix-card-detect-race-for-intel-bxt-apl.patch
queue-4.4/mmc-mmc-fix-incorrect-use-of-driver-strength-switching-hs200-and-hs400.patch
queue-4.4/mmc-sdhci-allow-override-of-get_cd-called-from-sdhci_request.patch
queue-4.4/mmc-sdhci-pci-do-not-default-to-33-ohm-driver-strength-for-intel-spt.patch
queue-4.4/mmc-sdio-fix-invalid-vdd-in-voltage-switch-power-cycle.patch
queue-4.4/mmc-sdhci-fix-sdhci_runtime_pm_bus_on-off.patch
queue-4.4/mmc-sdhci-allow-override-of-mmc-host-operations.patch
queue-4.4/mmc-sdhci-fix-dma-descriptor-with-zero-data-length.patch
queue-4.4/mmc-sdhci-pci-fix-card-detect-race-for-intel-bxt-apl.patch
reply other threads:[~2016-03-01 19:10 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14568594279960@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=adrian.hunter@intel.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.