Re: [PATCH 3/3] mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux