Kumar Gala <[EMAIL PROTECTED]> wrote:
> I was wondering what the state of the usb-gadget.bkbits.net:8080/gadget-2.4
> tree was. It appears that some changes got accepted into this tree (ARC EHCI
> TT host support).
As pointed out, it's nothing to do with me.
David
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> It is called in interrupt and uses no locking. What happens if the next
> irq is processed on another cpu? Is that cpu guaranteed to see the updates
> to the incremented variables?
I thought that possibility was prevented by IRQ_INPROGRESS.
David
-
Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> I think he is concerned about CPU A executing an interrupt handler, its
> stores getting stuck in its store buffer or its write-back cache, the IRQ
> finished, IRQ get migrated to CPU B, CPU B taking next interrupt and seeing
> old RAM state. I don't see
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> + (*) entering and returning from interrupt handlers implies a full barrier
That shouldn't really be under the "MISCELLANEOUS FUNCTIONS" subheading as
it's not precisely describing a callable function that has barrier effects.
Hmmm... also it isn't quit
Greg KH <[EMAIL PROTECTED]> wrote:
> David, does this look correct?
Andrew's patch is better as it uses the proper incantation.
David
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay pane
