* [PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response
@ 2014-08-15 6:05 rogerable
2014-08-15 6:06 ` [PATCH 1/2] mmc: rtsx_pci_sdmmc: " rogerable
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: rogerable @ 2014-08-15 6:05 UTC (permalink / raw)
To: Chris Ball, Ulf Hansson, Greg Kroah-Hartman
Cc: rogerable, Dan Carpenter, linux-kernel, linux-mmc,
driverdev-devel, wei_wang, micky_ching
From: Roger Tseng <rogerable@realtek.com>
(The original patch for PCI and USB was splitted here to make it easier for
stable tree.)
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Roger Tseng (2):
mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response
drivers/mmc/host/rtsx_pci_sdmmc.c | 7 +++++++
drivers/mmc/host/rtsx_usb_sdmmc.c | 7 +++++++
2 files changed, 14 insertions(+)
--
1.7.10.4
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH 1/2] mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
2014-08-15 6:05 [PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response rogerable
@ 2014-08-15 6:06 ` rogerable
2014-08-18 9:33 ` Ulf Hansson
2014-08-15 6:06 ` [PATCH 2/2] mmc: rtsx_usb_sdmmc: " rogerable
2014-08-27 2:00 ` [PATCH 0/2] mmc: rtsx: " rh_
2 siblings, 1 reply; 6+ messages in thread
From: rogerable @ 2014-08-15 6:06 UTC (permalink / raw)
To: Chris Ball, Ulf Hansson, Greg Kroah-Hartman
Cc: rogerable, Dan Carpenter, linux-kernel, linux-mmc,
driverdev-devel, wei_wang, micky_ching
From: Roger Tseng <rogerable@realtek.com>
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Cc: <stable@vger.kernel.org> # v3.8+
Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
Signed-off-by: Roger Tseng <rogerable@realtek.com>
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a210238..b2537e2f26b1 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,6 +412,13 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc *host,
}
if (rsp_type == SD_RSP_TYPE_R2) {
+ /*
+ * The controller offloads the last byte {CRC-7, end bit 1'b1}
+ * of response type R2. Assign dummy CRC, 0, and end bit to the
+ * byte(ptr[16], goes into the LSB of resp[3] later).
+ */
+ ptr[16] = 1;
+
for (i = 0; i < 4; i++) {
cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
--
1.7.10.4
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 1/2] mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
2014-08-15 6:06 ` [PATCH 1/2] mmc: rtsx_pci_sdmmc: " rogerable
@ 2014-08-18 9:33 ` Ulf Hansson
0 siblings, 0 replies; 6+ messages in thread
From: Ulf Hansson @ 2014-08-18 9:33 UTC (permalink / raw)
To: Roger
Cc: Chris Ball, Greg Kroah-Hartman, Dan Carpenter, linux-kernel,
linux-mmc, driverdev-devel, Wei WANG, micky
On 15 August 2014 08:06, <rogerable@realtek.com> wrote:
> From: Roger Tseng <rogerable@realtek.com>
>
> Current code erroneously fill the last byte of R2 response with an undefined
> value. In addition, the controller actually 'offloads' the last byte
> (CRC7, end bit) while receiving R2 response and thus it's impossible to get the
> actual value. This could cause mmc stack to obtain inconsistent CID from the
> same card after resume and misidentify it as a different card.
>
> Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Thanks! Applied for next.
Kind regards
Uffe
>
> Cc: <stable@vger.kernel.org> # v3.8+
> Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
> Signed-off-by: Roger Tseng <rogerable@realtek.com>
> ---
> drivers/mmc/host/rtsx_pci_sdmmc.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c
> index dfde4a210238..b2537e2f26b1 100644
> --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
> +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
> @@ -412,6 +412,13 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc *host,
> }
>
> if (rsp_type == SD_RSP_TYPE_R2) {
> + /*
> + * The controller offloads the last byte {CRC-7, end bit 1'b1}
> + * of response type R2. Assign dummy CRC, 0, and end bit to the
> + * byte(ptr[16], goes into the LSB of resp[3] later).
> + */
> + ptr[16] = 1;
> +
> for (i = 0; i < 4; i++) {
> cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
> dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 2/2] mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response
2014-08-15 6:05 [PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response rogerable
2014-08-15 6:06 ` [PATCH 1/2] mmc: rtsx_pci_sdmmc: " rogerable
@ 2014-08-15 6:06 ` rogerable
2014-08-18 9:33 ` Ulf Hansson
2014-08-27 2:00 ` [PATCH 0/2] mmc: rtsx: " rh_
2 siblings, 1 reply; 6+ messages in thread
From: rogerable @ 2014-08-15 6:06 UTC (permalink / raw)
To: Chris Ball, Ulf Hansson, Greg Kroah-Hartman
Cc: rogerable, Dan Carpenter, linux-kernel, linux-mmc,
driverdev-devel, wei_wang, micky_ching
From: Roger Tseng <rogerable@realtek.com>
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Cc: <stable@vger.kernel.org> # v3.16+
Fixes: c7f6558d84af ("mmc: Add realtek USB sdmmc host driver")
Signed-off-by: Roger Tseng <rogerable@realtek.com>
---
drivers/mmc/host/rtsx_usb_sdmmc.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 5d3766e792f0..d9153a7d160d 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -435,6 +435,13 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc *host,
}
if (rsp_type == SD_RSP_TYPE_R2) {
+ /*
+ * The controller offloads the last byte {CRC-7, end bit 1'b1}
+ * of response type R2. Assign dummy CRC, 0, and end bit to the
+ * byte(ptr[16], goes into the LSB of resp[3] later).
+ */
+ ptr[16] = 1;
+
for (i = 0; i < 4; i++) {
cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
--
1.7.10.4
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response
2014-08-15 6:06 ` [PATCH 2/2] mmc: rtsx_usb_sdmmc: " rogerable
@ 2014-08-18 9:33 ` Ulf Hansson
0 siblings, 0 replies; 6+ messages in thread
From: Ulf Hansson @ 2014-08-18 9:33 UTC (permalink / raw)
To: Roger
Cc: Chris Ball, Greg Kroah-Hartman, Dan Carpenter, linux-kernel,
linux-mmc, driverdev-devel, Wei WANG, micky
On 15 August 2014 08:06, <rogerable@realtek.com> wrote:
> From: Roger Tseng <rogerable@realtek.com>
>
> Current code erroneously fill the last byte of R2 response with an undefined
> value. In addition, the controller actually 'offloads' the last byte
> (CRC7, end bit) while receiving R2 response and thus it's impossible to get the
> actual value. This could cause mmc stack to obtain inconsistent CID from the
> same card after resume and misidentify it as a different card.
>
> Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
>
> Cc: <stable@vger.kernel.org> # v3.16+
> Fixes: c7f6558d84af ("mmc: Add realtek USB sdmmc host driver")
> Signed-off-by: Roger Tseng <rogerable@realtek.com>
Thanks! Applied for next.
Kind regards
Uffe
> ---
> drivers/mmc/host/rtsx_usb_sdmmc.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c
> index 5d3766e792f0..d9153a7d160d 100644
> --- a/drivers/mmc/host/rtsx_usb_sdmmc.c
> +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
> @@ -435,6 +435,13 @@ static void sd_send_cmd_get_rsp(struct rtsx_usb_sdmmc *host,
> }
>
> if (rsp_type == SD_RSP_TYPE_R2) {
> + /*
> + * The controller offloads the last byte {CRC-7, end bit 1'b1}
> + * of response type R2. Assign dummy CRC, 0, and end bit to the
> + * byte(ptr[16], goes into the LSB of resp[3] later).
> + */
> + ptr[16] = 1;
> +
> for (i = 0; i < 4; i++) {
> cmd->resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
> dev_dbg(sdmmc_dev(host), "cmd->resp[%d] = 0x%08x\n",
> --
> 1.7.10.4
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response
2014-08-15 6:05 [PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response rogerable
2014-08-15 6:06 ` [PATCH 1/2] mmc: rtsx_pci_sdmmc: " rogerable
2014-08-15 6:06 ` [PATCH 2/2] mmc: rtsx_usb_sdmmc: " rogerable
@ 2014-08-27 2:00 ` rh_
2 siblings, 0 replies; 6+ messages in thread
From: rh_ @ 2014-08-27 2:00 UTC (permalink / raw)
To: linux-kernel
On Fri, 15 Aug 2014 14:05:59 +0800
<rogerable@realtek.com> wrote:
> From: Roger Tseng <rogerable@realtek.com>
>
> (The original patch for PCI and USB was splitted here to make it
> easier for stable tree.)
>
> Current code erroneously fill the last byte of R2 response with an
> undefined value. In addition, the controller actually 'offloads' the
> last byte (CRC7, end bit) while receiving R2 response and thus it's
> impossible to get the actual value. This could cause mmc stack to
> obtain inconsistent CID from the same card after resume and
> misidentify it as a different card.
What does "resume" mean in this context? Good to see this was
finally fixed. This problem has caused copious log messages regarding
hotplug events and I don't have any debug or extra logging enabled.
I don't know what triggered the message to get logged as my system
doesn't suspend/resume so I wonder what in your investigation makes
you believe this is a symptom of "resume".
>
> Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last
> byte of R2.
>
> Roger Tseng (2):
> mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
> mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response
>
> drivers/mmc/host/rtsx_pci_sdmmc.c | 7 +++++++
> drivers/mmc/host/rtsx_usb_sdmmc.c | 7 +++++++
> 2 files changed, 14 insertions(+)
>
> --
> 1.7.10.4
--
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-08-27 2:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-15 6:05 [PATCH 0/2] mmc: rtsx: fix incorrect last byte in R2 response rogerable
2014-08-15 6:06 ` [PATCH 1/2] mmc: rtsx_pci_sdmmc: " rogerable
2014-08-18 9:33 ` Ulf Hansson
2014-08-15 6:06 ` [PATCH 2/2] mmc: rtsx_usb_sdmmc: " rogerable
2014-08-18 9:33 ` Ulf Hansson
2014-08-27 2:00 ` [PATCH 0/2] mmc: rtsx: " rh_
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®