* [PATCH v3] mmc: block: prevent propagating R1_OUT_OF_RANGE for open-ending mode
@ 2017-08-16 1:11 Shawn Lin
2017-08-17 10:40 ` Wolfram Sang
0 siblings, 1 reply; 5+ messages in thread
From: Shawn Lin @ 2017-08-16 1:11 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Shawn Guo, Wolfram Sang, Yoshihiro Shimoda, Shawn Lin
We to some extent should tolerate R1_OUT_OF_RANGE for open-ending
mode as it is expected behaviour and most of the backup partition
tables should be located near some of the last blocks which will
always make open-ending read exceed the capacity of cards.
Fixes: 9820a5b11101 ("mmc: core: for data errors, take response of stop cmd into account")
Fixes: a04e6bae9e6f ("mmc: core: check also R1 response for stop commands")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Shawn Guo <shawnguo@kernel.org>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
Changes in v3:
- add explanation for why don't check predefined method
- check brq->mrq.sbc for easier to read suggested by Wolfram
Changes in v2:
- fix a typo and introduce STOP_ERROR
- reword the comment and always include a description from the spec if possible
drivers/mmc/core/block.c | 47 +++++++++++++++++++++++++++++++++++++++++------
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index a11bead..a5a375b 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1369,12 +1369,44 @@ static inline void mmc_apply_rel_rw(struct mmc_blk_request *brq,
R1_CC_ERROR | /* Card controller error */ \
R1_ERROR) /* General/unknown error */
-static bool mmc_blk_has_cmd_err(struct mmc_command *cmd)
+static void mmc_blk_eval_resp_error(struct mmc_blk_request *brq)
{
- if (!cmd->error && cmd->resp[0] & CMD_ERRORS)
- cmd->error = -EIO;
+ u32 val;
- return cmd->error;
+ /*
+ * Per the SD specification(physical layer version 4.10)[1],
+ * section 4.3.3, it explicitly states that "When the last
+ * block of user area is read using CMD18, the host should
+ * ignore OUT_OF_RANGE error that may occur even the sequence
+ * is correct". And JESD84-B51 for eMMC also has a similar
+ * statement on section 6.8.3.
+ *
+ * Multiple block read/write could be done by either predefined
+ * method, namely CMD23, or open-ending mode.
+ *
+ * For open-ending mode, we should ignore the OUT_OF_RANGE
+ * error as it's normal behaviour.
+ *
+ * However the spec[1] doesn't tell us whether we should also
+ * ignore that for predefined method. But per the spec[1], section
+ * 4.15 Set Block Count Command, it says"If illegal block count
+ * is set, out of range error will be indicated during read/write
+ * operation (For example, data transfer is stopped at user area
+ * boundary)." In another word, we could expect a out of range error
+ * in the response for the following CMD18/25. And if argument of
+ * CMD23 + the argument of CMD18/25 exceed the max number of blocks,
+ * we could also expect to get a -ETIMEDOUT or any error number from
+ * the host drivers due to missing data response(for write)/data(for
+ * read), as the cards will stop the data transfer by itself per the
+ * spec. So we only need to check R1_OUT_OF_RANGE for open-ending mode.
+ */
+
+ if (!brq->stop.error) {
+ /* If there is no error yet, check R1 response */
+ val = brq->stop.resp[0] & CMD_ERRORS;
+ if (val && !(val & R1_OUT_OF_RANGE && !brq->mrq.sbc))
+ brq->stop.error = -EIO;
+ }
}
static enum mmc_blk_status mmc_blk_err_check(struct mmc_card *card,
@@ -1398,8 +1430,11 @@ static enum mmc_blk_status mmc_blk_err_check(struct mmc_card *card,
* stop.error indicates a problem with the stop command. Data
* may have been transferred, or may still be transferring.
*/
- if (brq->sbc.error || brq->cmd.error || mmc_blk_has_cmd_err(&brq->stop) ||
- brq->data.error) {
+
+ mmc_blk_eval_resp_error(brq);
+
+ if (brq->sbc.error || brq->cmd.error ||
+ brq->stop.error || brq->data.error) {
switch (mmc_blk_cmd_recovery(card, req, brq, &ecc_err, &gen_err)) {
case ERR_RETRY:
return MMC_BLK_RETRY;
--
1.9.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v3] mmc: block: prevent propagating R1_OUT_OF_RANGE for open-ending mode
2017-08-16 1:11 [PATCH v3] mmc: block: prevent propagating R1_OUT_OF_RANGE for open-ending mode Shawn Lin
@ 2017-08-17 10:40 ` Wolfram Sang
2017-08-17 13:34 ` Shawn Guo
2017-08-18 1:02 ` Shawn Lin
0 siblings, 2 replies; 5+ messages in thread
From: Wolfram Sang @ 2017-08-17 10:40 UTC (permalink / raw)
To: Shawn Lin; +Cc: Ulf Hansson, linux-mmc, Shawn Guo, Yoshihiro Shimoda
[-- Attachment #1: Type: text/plain, Size: 3262 bytes --]
Hi Shawn,
On Wed, Aug 16, 2017 at 09:11:41AM +0800, Shawn Lin wrote:
> We to some extent should tolerate R1_OUT_OF_RANGE for open-ending
> mode as it is expected behaviour and most of the backup partition
> tables should be located near some of the last blocks which will
> always make open-ending read exceed the capacity of cards.
>
> Fixes: 9820a5b11101 ("mmc: core: for data errors, take response of stop cmd into account")
> Fixes: a04e6bae9e6f ("mmc: core: check also R1 response for stop commands")
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> Tested-by: Shawn Guo <shawnguo@kernel.org>
> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
I'd think these Tested-by should be dropped. We changed the patch quite
a bit meanwhile and I am quite sure Shimoda-san didn't test this new
version of the patch. Dunno about Shawn. Hopefully they have time to
re-test?
> + /*
> + * Per the SD specification(physical layer version 4.10)[1],
> + * section 4.3.3, it explicitly states that "When the last
> + * block of user area is read using CMD18, the host should
> + * ignore OUT_OF_RANGE error that may occur even the sequence
> + * is correct". And JESD84-B51 for eMMC also has a similar
> + * statement on section 6.8.3.
> + *
> + * Multiple block read/write could be done by either predefined
> + * method, namely CMD23, or open-ending mode.
> + *
Very minor nit: I'd remove this empty line and merge the two paragraphs.
> + * For open-ending mode, we should ignore the OUT_OF_RANGE
> + * error as it's normal behaviour.
> + *
> + * However the spec[1] doesn't tell us whether we should also
> + * ignore that for predefined method. But per the spec[1], section
> + * 4.15 Set Block Count Command, it says"If illegal block count
> + * is set, out of range error will be indicated during read/write
> + * operation (For example, data transfer is stopped at user area
> + * boundary)." In another word, we could expect a out of range error
> + * in the response for the following CMD18/25. And if argument of
> + * CMD23 + the argument of CMD18/25 exceed the max number of blocks,
> + * we could also expect to get a -ETIMEDOUT or any error number from
> + * the host drivers due to missing data response(for write)/data(for
> + * read), as the cards will stop the data transfer by itself per the
> + * spec. So we only need to check R1_OUT_OF_RANGE for open-ending mode.
> + */
Very good! I like this a lot.
Also minor nit, but likely better readable:
> +
> + if (!brq->stop.error) {
bool OOR_with_open_end;
> + /* If there is no error yet, check R1 response */
> + val = brq->stop.resp[0] & CMD_ERRORS;
OOR_with_open_end = val & R1_OUT_OF_RANGE && !brq->mrq.sbc;
if (val && !OOR_with_open_end)
> + brq->stop.error = -EIO;
...
> + if (brq->sbc.error || brq->cmd.error ||
> + brq->stop.error || brq->data.error) {
I am not super strict with the 80 char limit and think one line is
better readable, but I leave that to you and/or Ulf.
Other than that minor stuff:
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Thanks for this collaboration! I liked it :)
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3] mmc: block: prevent propagating R1_OUT_OF_RANGE for open-ending mode
2017-08-17 10:40 ` Wolfram Sang
@ 2017-08-17 13:34 ` Shawn Guo
2017-08-18 1:03 ` Shawn Lin
2017-08-18 1:02 ` Shawn Lin
1 sibling, 1 reply; 5+ messages in thread
From: Shawn Guo @ 2017-08-17 13:34 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Shawn Lin, Ulf Hansson, linux-mmc, Yoshihiro Shimoda
On Thu, Aug 17, 2017 at 12:40:47PM +0200, Wolfram Sang wrote:
> Hi Shawn,
>
> On Wed, Aug 16, 2017 at 09:11:41AM +0800, Shawn Lin wrote:
> > We to some extent should tolerate R1_OUT_OF_RANGE for open-ending
> > mode as it is expected behaviour and most of the backup partition
> > tables should be located near some of the last blocks which will
> > always make open-ending read exceed the capacity of cards.
> >
> > Fixes: 9820a5b11101 ("mmc: core: for data errors, take response of stop cmd into account")
> > Fixes: a04e6bae9e6f ("mmc: core: check also R1 response for stop commands")
> > Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> >
> > Tested-by: Shawn Guo <shawnguo@kernel.org>
> > Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> I'd think these Tested-by should be dropped. We changed the patch quite
> a bit meanwhile and I am quite sure Shimoda-san didn't test this new
> version of the patch. Dunno about Shawn. Hopefully they have time to
> re-test?
I just re-tested it on Hikey, so my Tested-by tag can be kept.
Shawn
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3] mmc: block: prevent propagating R1_OUT_OF_RANGE for open-ending mode
2017-08-17 10:40 ` Wolfram Sang
2017-08-17 13:34 ` Shawn Guo
@ 2017-08-18 1:02 ` Shawn Lin
1 sibling, 0 replies; 5+ messages in thread
From: Shawn Lin @ 2017-08-18 1:02 UTC (permalink / raw)
To: Wolfram Sang
Cc: shawn.lin, Ulf Hansson, linux-mmc, Shawn Guo, Yoshihiro Shimoda
Hi Wolfram,
On 2017/8/17 18:40, Wolfram Sang wrote:
> Hi Shawn,
>
> On Wed, Aug 16, 2017 at 09:11:41AM +0800, Shawn Lin wrote:
>> We to some extent should tolerate R1_OUT_OF_RANGE for open-ending
>> mode as it is expected behaviour and most of the backup partition
>> tables should be located near some of the last blocks which will
>> always make open-ending read exceed the capacity of cards.
>>
>> Fixes: 9820a5b11101 ("mmc: core: for data errors, take response of stop cmd into account")
>> Fixes: a04e6bae9e6f ("mmc: core: check also R1 response for stop commands")
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>>
>> Tested-by: Shawn Guo <shawnguo@kernel.org>
>> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> I'd think these Tested-by should be dropped. We changed the patch quite
> a bit meanwhile and I am quite sure Shimoda-san didn't test this new
> version of the patch. Dunno about Shawn. Hopefully they have time to
> re-test?
>
>> + /*
>> + * Per the SD specification(physical layer version 4.10)[1],
>> + * section 4.3.3, it explicitly states that "When the last
>> + * block of user area is read using CMD18, the host should
>> + * ignore OUT_OF_RANGE error that may occur even the sequence
>> + * is correct". And JESD84-B51 for eMMC also has a similar
>> + * statement on section 6.8.3.
>> + *
>> + * Multiple block read/write could be done by either predefined
>> + * method, namely CMD23, or open-ending mode.
>> + *
>
> Very minor nit: I'd remove this empty line and merge the two paragraphs.
well do in v4
>
>> + * For open-ending mode, we should ignore the OUT_OF_RANGE
>> + * error as it's normal behaviour.
>> + *
>> + * However the spec[1] doesn't tell us whether we should also
>> + * ignore that for predefined method. But per the spec[1], section
>> + * 4.15 Set Block Count Command, it says"If illegal block count
>> + * is set, out of range error will be indicated during read/write
>> + * operation (For example, data transfer is stopped at user area
>> + * boundary)." In another word, we could expect a out of range error
>> + * in the response for the following CMD18/25. And if argument of
>> + * CMD23 + the argument of CMD18/25 exceed the max number of blocks,
>> + * we could also expect to get a -ETIMEDOUT or any error number from
>> + * the host drivers due to missing data response(for write)/data(for
>> + * read), as the cards will stop the data transfer by itself per the
>> + * spec. So we only need to check R1_OUT_OF_RANGE for open-ending mode.
>> + */
>
> Very good! I like this a lot.
>
> Also minor nit, but likely better readable:
>
>> +
>> + if (!brq->stop.error) {
> bool OOR_with_open_end;
>
>> + /* If there is no error yet, check R1 response */
>> + val = brq->stop.resp[0] & CMD_ERRORS;
>
> OOR_with_open_end = val & R1_OUT_OF_RANGE && !brq->mrq.sbc;
>
> if (val && !OOR_with_open_end)
>> + brq->stop.error = -EIO;
>
> ...
>
>> + if (brq->sbc.error || brq->cmd.error ||
>> + brq->stop.error || brq->data.error) {
>
will do in v4 but slightly rename it to oor_with_open_end as
it doesn't seem general to name a variable with upper letter.
> I am not super strict with the 80 char limit and think one line is
> better readable, but I leave that to you and/or Ulf.
Make sense but I will keep it and leave that to Ulf too. :)
>
> Other than that minor stuff:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Thanks for this collaboration! I liked it :)
>
> Regards,
>
> Wolfram
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v3] mmc: block: prevent propagating R1_OUT_OF_RANGE for open-ending mode
2017-08-17 13:34 ` Shawn Guo
@ 2017-08-18 1:03 ` Shawn Lin
0 siblings, 0 replies; 5+ messages in thread
From: Shawn Lin @ 2017-08-18 1:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Wolfram Sang, shawn.lin, Ulf Hansson, linux-mmc, Yoshihiro Shimoda
On 2017/8/17 21:34, Shawn Guo wrote:
> On Thu, Aug 17, 2017 at 12:40:47PM +0200, Wolfram Sang wrote:
>> Hi Shawn,
>>
>> On Wed, Aug 16, 2017 at 09:11:41AM +0800, Shawn Lin wrote:
>>> We to some extent should tolerate R1_OUT_OF_RANGE for open-ending
>>> mode as it is expected behaviour and most of the backup partition
>>> tables should be located near some of the last blocks which will
>>> always make open-ending read exceed the capacity of cards.
>>>
>>> Fixes: 9820a5b11101 ("mmc: core: for data errors, take response of stop cmd into account")
>>> Fixes: a04e6bae9e6f ("mmc: core: check also R1 response for stop commands")
>>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>>>
>>> Tested-by: Shawn Guo <shawnguo@kernel.org>
>>> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>
>> I'd think these Tested-by should be dropped. We changed the patch quite
>> a bit meanwhile and I am quite sure Shimoda-san didn't test this new
>> version of the patch. Dunno about Shawn. Hopefully they have time to
>> re-test?
>
> I just re-tested it on Hikey, so my Tested-by tag can be kept.
Great! Thanks for testing it again!
>
> Shawn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-08-18 1:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-16 1:11 [PATCH v3] mmc: block: prevent propagating R1_OUT_OF_RANGE for open-ending mode Shawn Lin
2017-08-17 10:40 ` Wolfram Sang
2017-08-17 13:34 ` Shawn Guo
2017-08-18 1:03 ` Shawn Lin
2017-08-18 1:02 ` Shawn Lin
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.