Josh Boyer jwboyer at linux.vnet.ibm.com
Fri May 2 00:26:52 EST 2008

On Thu, 2008-05-01 at 08:22 -0500, Kumar Gala wrote:
> >> So we have 4 actual exceptions:
> >> * CriticalInput (some external device signaled this.  There are two
> >> concepts of critical.  One is error the other is high priority)
> >> However this would have the same caveats as any ExternalInput  
> >> handler.
> >
> > No, it's worse. It can interrupt code that normally has
> > local_irq_disabled() and thus doesn't expect to be interrupted. That
> > means that everything becomes unsafe including locks etc....
> Fair.  Should local_irq_disable() clear MSR_SE & MSR_BE on classic  
> parts?
> > Note that driver that want to make active use of that probably want  
> > some
> > explicit local_crit_irq_disable/enable functions to be able to  
> > implement
> > some sort of synchronization.
> Or we could just have local_irq_disable -- clear MSR_EE and MSR_CE

That sort of defeats the purpose of using critical interrupts in the
"higher priority" sense, doesn't it?  Seems it would effectively
eliminate that level altogether.  And it would also mask off the
watchdog interrupt, which I don't think you want to do.

Ben suggested local_crit_irq_disable.  That would suffice for drivers
that know they are configured as CE and need to do locking primitives,
but that isn't very common.  On 4xx there isn't even an interface for a
driver to request it's interrupts be set to CE and we init all UICs to
have UIC_CR be 0.

So for 4xx at least, most of this discussion is theoretical for now.
However, I can see value in having CEs being used for certain devices,
etc so it would be nice to figure it out in the long run.


More information about the Linuxppc-dev mailing list