[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPDyKFpfDg9yejcaojv=9yvjFndJ00PmYNWuXOAZCw4cOevUFA@mail.gmail.com>
Date: Tue, 31 Jan 2017 11:50:34 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Ravikumar <rk@...com>
Cc: Peter Ujfalusi <peter.ujfalusi@...com>,
Sekhar Nori <nsekhar@...com>, Tony Lindgren <tony@...mide.com>,
Andreas Fenkart <afenkart@...il.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
linux-omap <linux-omap@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kishon <kishon@...com>
Subject: Re: [PATCH 2/3] mmc: host: omap_hsmmc: use generic_cmd6_time to
program timeout value for CMD6
[...]
>>> + /*
>>> + * Set an arbitrary 100ms data timeout for
>>> commands with
>>> + * busy signal and no indication of busy_timeout.
>>> + */
>>> + if (!timeout)
>>
>> This is a bug in the mmc core if this ever happen.
>>
>> Therefore I am particularly interested to find out if this is really
>> needed or it's just playing safe?
>
> You could call it playing safe.
> We haven't hit any case where it was set to zero but per mmc_switch()
> description you are allowed to set it to zero to let the host decide what it
> wants to use.
I check the code in the core. Apparently there are some cases when
INAND_CMD38_ARG* is used, but also some cases where I think the
timeout value becomes picked from the EXT_CSD without validating its
value.
Let's keep $subject patch as is, then allow me to submit a few changes
for core to deal with this properly.
>
>>> + timeout = 100000000U;
>>> +
>>> + set_data_timeout(host, timeout, 0);
>>> + }
>>> return 0;
>>> }
Kind regards
Uffe
Powered by blists - more mailing lists