On Fri, 2010-02-19 at 01:56 +0000, Ben Hutchings wrote: > udelay() is supposed to be limited to 1 ms, and will generate a > __bad_udelay() on ARM for constant arguments > 2000. Split > udelay(0x800) into mdelay(2); udelay(48). (I suspect that msleep(3) > would work but I do not know how critical the timing is here.) So no to this one. Either ARM is right and udelay > 2000 is wrong (which actually sounds correct given how long this will eat CPU for) so the driver needs fixing, or ARM is wrong and the warning needs fixing. Splitting the delay to defeat the warning while retaining the behaviour it was trying to warn about is the wrong thing to do. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
