Old code:
- while (!(ret = readl_relaxed(sdma->regs + SDMA_H_INTR) & 1)) {
- if (timeout-- <= 0)
- break;
- udelay(1);
- }
So, while bit 0 is _clear_ the loop continues to poll.
New code:
+ ret = readl_relaxed_poll_timeout_atomic(sdma->regs + SDMA_H_STATSTOP,
+ reg, !(reg & 1), 1, 500);
Doesn't really tell us what the termination condition is (because of
the obfuscation taking away the details), but if we dig into the
macro maze:
#define readl_relaxed_poll_timeout_atomic(addr, val, cond, delay_us, timeout_us) \
readx_poll_timeout_atomic(readl_relaxed, addr, val, cond, delay_us, timeout_us)
#define readx_poll_timeout_atomic(op, addr, val, cond, delay_us, timeout_us) \
({ \
u64 __timeout_us = (timeout_us); \
unsigned long __delay_us = (delay_us); \
ktime_t __timeout = ktime_add_us(ktime_get(), __timeout_us); \
for (;;) { \
(val) = op(addr); \
if (cond) \
break; \
"cond" is passed in to here unmodified, so this becomes:
for (;;) {
reg = readl_relaxed(sdma->regs + SDMA_H_STATSTOP);
if (!(reg & 1))
break;
So, if bit 0 of this register is clear, we terminate the loop.
Seems to me like this is a great illustration why using a helper
_introduces_ bugs, because it hides the detail about what the exit
condition for the embedded loop actually is, and leads to this kind
of error.
In any case, the conversion is obviously incorrect.
I occasionally see the "Timeout waiting for CH0 ready" error during
boot on a cbi4, which, given the above, means that we did end up
seeing bit 1 set (so according to the old code, we waited
successfully.)
Looking at the date of the commit, this is almost a three year old
bug.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
