On Tue, Mar 10, 2009 at 05:58:58PM -0500, Scott Wood wrote: > Josh Boyer wrote: >> On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote: >>> Timur Tabi wrote: >>>> The macro spin_event_timeout() takes a condition and timeout value >>>> (in microseconds) as parameters. It spins until either the condition is >>>> true >>>> or the timeout expires. It returns zero if the timeout expires first, >>>> non-zero >>>> otherwise. >>>> >>>> This primary purpose of this macro is to poll on a hardware register until >>>> a >>>> status bit changes. The timeout ensures that the loop still terminates if >>>> the >>>> bit doesn't change as expected. This macro makes it easier for driver >>>> developers to perform this kind of operation properly. >>>> >>>> Signed-off-by: Timur Tabi <ti...@freescale.com> >>>> --- >>>> >>>> v5: ported to arch/powerpc, made it powerpc-specific, eliminated udelay >>> Why make it powerpc-specific? This would be nice to have in >>> arch-independent code. >> >> That's just mean. He already posted it to lkml and was told to make it >> powerpc specific by Alan. > > Well, that's what happens when a discussion hops mailing lists with no > backreference. :-P > > I don't see anywhere where he says it should be architecture dependent, > but rather a general "I don't like this, get off my lawn!" response. > > I cannot agree with the "we shouldn't be encouraging this" sentiment; > people don't generally do spin loops because they're lazy[1], but rather > because the hardware demands it -- and it's hardly only on powerpc (much > less just "some Freescale drivers") that I've encountered hardware that > demands it, typiclally during reset/initialization or similarly non-hot > paths. Why not provide something less likely to have bugs (the timeout > case is unlikely to be well tested), more easily seen when reviewing a > patch, and more likely to result in spin loops *with* a timeout rather > than without?
Excellent questions. Did you send them to lkml and Alan? josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
