On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote: > On Wed, 2014-02-05 at 11:50 +0000, Russell King - ARM Linux wrote: > > 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, > > Apparently, people just convert stupidly large udelay()s > to mdelay and not be bothered. And that's the correct answer. Having udelay(10000) rather than mdelay(10) is a sign that they weren't paying that much attention when writing the code. > Perhaps there should be some runtime udelay > maximum supported check. Having both a runtime check _and_ a compile time check would actually be a good thing, but any runtime check needs to be suitably rate- limited. The compile time check is very important because it catches a lot of cases which wouldn't otherwise be found (eg, in drivers which hardly anyone uses on ARM.) Maybe the compile time check should be something which is implemented in a cross-architecture way in linux/delay.h with the maximum set to the lowest that any architecture can do? -- 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
