Hi,
checking some patches thru www.kernel.org
I noticed "off by one" timing logic error in
/arch/arm/mach-omap2/prcm.c
in function
int omap2_cm_wait_idlest(void __iomem *reg, u32 mask, const char *name)
...
/* Wait for lock */
while (((__raw_readl(reg) & mask) != ena) &&
(i++ < MAX_MODULE_ENABLE_WAIT))
udelay(1);
if (i < MAX_MODULE_ENABLE_WAIT)
pr_debug("cm: Module associated with clock %s ready after %d "
"loops\n", name, i);
else
pr_err("cm: Module associated with clock %s didn't enable in "
"%d tries\n", name, MAX_MODULE_ENABLE_WAIT);
return (i < MAX_MODULE_ENABLE_WAIT) ? 1 : 0;
...
If the while loop "timeouts", i==MAX_MODULE_ENABLE_WAIT+1.
Simple correction could be something like
....
- if (i < MAX_MODULE_ENABLE_WAIT)
+ if (i <= MAX_MODULE_ENABLE_WAIT)
pr_debug("cm: Module associated with clock %s ready after %d "
<SNIP>
- return (i < MAX_MODULE_ENABLE_WAIT) ? 1 : 0;
+ return (i <= MAX_MODULE_ENABLE_WAIT) ? 1 : 0;
....
Signed-off-by: "Juha Leppanen" <[email protected]>
No reply needed to me,
my spam filter will probably eat your reply.
Reported-by: "Juha Leppanen" <[email protected]>
tag would be nice in kernel.org :)
Not so many kernel hackers give credit these days :(
Happy hacking,
Mr. Juha Leppanen
Kuopio, Finland
....................................................................
Luukku Plus -paketilla pääset eroon tila- ja turvallisuusongelmista.
Hanki Luukku Plus ja helpotat elämääsi. http://www.mtv3.fi/luukku
