On Tue, Feb 04, 2014 at 08:36:36AM -0800, Joe Perches wrote: > On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote: > > Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay > > cannot handle large values because of lost-of-precision. > > > > IMHO udelay on ARM is broken, because it also cannot work with fast > > ARM processors (where bogomips >= 3355, which is in sight now). It's > > just not broken enought that someone did something against it ... so > > the current kludge is good enought. > > Maybe something like this would be better? No, the point of __bad_udelay() is that people doing stupidly large udelay()s result in build errors, rather than having to run the kernel and trip over a non-existent debugging message beacuse they haven't built the kernel with DEBUG defined. NAK. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit". -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
