On Wed, 2014-02-05 at 14:21 +0000, Russell King - ARM Linux wrote: > On Wed, Feb 05, 2014 at 06:03:13AM -0800, Joe Perches wrote: > > On Wed, 2014-02-05 at 13:39 +0000, Russell King - ARM Linux wrote: > > > On Wed, Feb 05, 2014 at 05:04:54AM -0800, Joe Perches wrote: > > > > On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote: > > > > > On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote: > > > > > > 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. > > > > > > > > Not really. > > [] > > > > It's not so much not paying attention as not > > > > knowing ARM is broken for large udelay(). > > > > > > And now read my suggestion about how to avoid the "not knowing" problem. :) > > > > I'd read it already. I didn't and don't disagree. > > Please explain /why/ you don't agree. Please reread what I wrote. We agree a lot more than you seem to think. > > I still think adding a #warning on large static udelay()s > > would be sensible. Maybe adding another option like > > #define UDELAY_TOO_BIG_I_KNOW_ALREADY_DONT_BOTHER_ME > > guard to avoid seeing the #warning when there's no other > > option. > > How does that help? It's /not/ a warning situation - if you ask for > udelay(10000) on ARM, you will /not/ get a 10ms delay. You'll instead > get something much shorter because the arithmetic will overflow. > Now, you could argue that maybe ARM's udelay() implementation should > know about this and implement a loop around the underlying udelay() > implementation to achieve it, I suggested something like that was possible. > and I might agree with you - but I > don't for one very simple reason: we /already/ have such an > implementation. It's called mdelay(): I think mdelay should be for the case where the range is too big for a udelay. I think arm's 11 bit range is unfortunately small. I think we agree be nice to get a generic compiler #warning when a __builtin_constant_p value is too large and a ratelimited dmesg/warning for the runtime case. -- 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
