On Tue, 23 Feb 2021 at 14:42, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > > On 23/02/21 1:54 pm, Ulf Hansson wrote: > > On Tue, 23 Feb 2021 at 12:19, Paul Fertser <fercerpav@xxxxxxxxx> wrote: > >> > >> Hello Adrian, > >> > >> On Tue, Feb 23, 2021 at 01:01:09PM +0200, Adrian Hunter wrote: > >>> On 23/02/21 11:32 am, Paul Fertser wrote: > >>>> Hello Ulf, > >>>> > >>>> On Tue, Feb 23, 2021 at 10:23:28AM +0100, Ulf Hansson wrote: > >>>>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > >>>>>> index f5dedb7f9b27..9adf735391fa 100644 > >>>>>> --- a/drivers/mmc/core/mmc.c > >>>>>> +++ b/drivers/mmc/core/mmc.c > >>>>>> @@ -426,8 +426,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 *ext_csd) > >>>>>> /* EXT_CSD value is in units of 10ms, but we store in ms */ > >>>>>> card->ext_csd.part_time = 10 * ext_csd[EXT_CSD_PART_SWITCH_TIME]; > >>>>>> /* Some eMMC set the value too low so set a minimum */ > >>>>>> - if (card->ext_csd.part_time && > >>>>>> - card->ext_csd.part_time < MMC_MIN_PART_SWITCH_TIME) > >>>>>> + if (card->ext_csd.part_time < MMC_MIN_PART_SWITCH_TIME) > >>>>>> card->ext_csd.part_time = MMC_MIN_PART_SWITCH_TIME; > >>>>>> > >>>>>> /* Sleep / awake timeout in 100ns units */ > >>>>>> > >>>>>> I do not see any more warnings on my system. > >>>>> > >>>>> That looks like the correct fix to the problem. Do you want to send a > >>>>> proper patch that I can pick up or do you prefer if help to do it? > >>>> > >>>> I've sent this as a diff precisely because 1c447116d017 was so > >>>> explicit about special-casing zero ext_csd timeout value, so I thought > >>>> probably Adrian can provide the rationale for that. I'd prefer to wait > >>>> for his feedback before sending a formal patch. Does this make sense? > >>> > >>> Zero means indefinite. Might be safer to use a higher value than > >>> MMC_MIN_PART_SWITCH_TIME for that case. The maximum GENERIC_CMD6_TIME is > >>> 2550 ms. > >> > >> Thanks for the clarification! I would guess that most likely than not > >> when whoever defines that value to be zero it means "I do not > >> care/know" rather than "the timeout must be set to more than 2550 ms, > >> too bad 8 bits are not enough to represent that". I'd say setting it > >> to DEFAULT_CMD6_TIMEOUT_MS should be safe enough since it worked > >> before. > > > > Hmm. > > > > The DEFAULT_CMD6_TIMEOUT_MS is intended to override the > > ext_csd->generic_cmd6_time, in case it's not defined in the register. > > > > Perhaps it's reasonable to think that eMMC vendors specify the > > GENERIC_CMD6_TIME, but may skip to specify other timeouts, like the > > PARTITION_SWITCH_TIME. In that case, should we use the specified > > GENERIC_CMD6_TIME, rather than always default to > > DEFAULT_CMD6_TIMEOUT_MS? > > Sounds reasonable, but perhaps still enforce a minimum, for some of the same > reasons as commit 1c447116d017 ? > e.g. > > if (!card->ext_csd.part_time) > card->ext_csd.part_time = card->ext_csd.generic_cmd6_time; > if (card->ext_csd.part_time < MMC_MIN_PART_SWITCH_TIME) > card->ext_csd.part_time = MMC_MIN_PART_SWITCH_TIME; > Makes perfect sense to me! Kind regards Uffe
