On 2017-08-17 15:01, Russell King - ARM Linux wrote:
On Thu, Aug 17, 2017 at 12:51:33PM +0200, Danilo Krummrich wrote:
That having the correct execution order is not enough on some buses
because
of buffering is really something to be aware of, thanks again for
pointing
this out.
PCI guarantees the order of writes to a device, but there are
situations
on SoCs where you can't rely on that - for instance, if the writes go
over different buses to different devices (eg, write to a peripheral
vs write to an interrupt controller.)
Even then, with interrupts delivered by message (eg, MSI) there's
issues.
So for the scenario I was concerned about I would expect the irqchip
driver
guarantees the write actually hits the the hardware (if necessary read
it
back) before the function (disable_irq_nosync()) returns, is that
correct?
Though, having the need should be very unlikely.
Well, disable_irq_nosync() doesn't guarantee that the interrupt handler
isn't running - a CPU may have just received the interrupt and is just
entering the interrupt handler when disable_irq_nosync() returns. The
hint is the "nosync" - there's no synchronisation. If you need to
guarantee that the interrupt handler is not running, disable_irq() does
that. By implication, however, disable_irq() can not be called from
within the same interrupt handler for the interrupt that is being
disabled.
Thanks again, I'm aware of that. As in my case the code could be called
from
atomic context disable_irq() is not an option.
My main point is if it can be assumed that after disable_irq_nosync()
returns
it is guaranteed, by convention, that the hardware was hit. But I really
would
think so.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
