[PATCH] mtd: cfi_cmdset_0001: Fix max timeout for locking operations

[Anders Grafström]

On 2010-05-14 01:06, David Woodhouse wrote:
> On Fri, 2010-02-26 at 21:54 +0100, Anders Grafström wrote:
>> The max timeout is currently too short for some flash chips.
>> This patch increases it to 10 seconds. The typical timeout
>> remains unchanged (the tick period, 1000000/HZ).
>>
>> Specification change #11 in '5 Volt Intel StrataFlash Memory Specification Update'
>> (297848-15) specifies an increase of Clear Block Lock-Bit Time Max to 7 sec.
>> This is contradicted by the table in Specification Change #8 which says .70 sec
>> but a 10 sec timeout doesn't hurt so play it safe.
>>
>> Signed-off-by: Anders Grafström <anders.grafstrom at netinsight.net>
>> ---
>>  drivers/mtd/chips/cfi_cmdset_0001.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
>> index 9253043..83e4ae2 100644
>> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
>> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
>> @@ -2077,7 +2077,7 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
>>          */
>>         udelay = (!extp || !(extp->FeatureSupport & (1 << 5))) ? 1000000/HZ : 0;
>>  
>> -       ret = WAIT_TIMEOUT(map, chip, adr, udelay, udelay * 100);
>> +       ret = WAIT_TIMEOUT(map, chip, adr, udelay, udelay * HZ * 10); 
> 
> I don't see how this makes any sense. What is the _unit_ of the argument
> you're changing? Is it µs, is it ticks? You aren't just changing the
> value here; you're actually changing the units. The dimensional analysis
> doesn't make sense.
> 
> AFAICT this really is supposed to be µs, so multiplying by HZ has to be
> wrong.

Hm, I make it:

udelay: 1000000 / HZ = (µs/s) / (ticks/s) = µs/ticks
udelay_max (before): udelay * 100 = (µs/ticks) * ticks = µs
udelay_max (after): udelay * HZ * 10 = (µs/ticks) * (ticks/s) * s = µs

Here's a re-spin, with less HZ involvement: