On Tue, 3 Jul 2007, Steven Rostedt wrote:
> The problem that we are facing in this thread is that the RT patch
> doesn't touch local_irq_save and restore. These still turn off
> interrupts, and can be a problem with the RT patch. We need a tight
> coupling between spin_lock and irq disable. This is done by
> spin_lock_irqsave, so in the RT patch we don't need to disable
> interrupts here. But calling local_irq_save() followed by spin_lock()
> it will cause bugs in RT.
>
> I'm liking the idea of having a local_irq_restore_from_spinlock(flags)
> which documents that the irqs were disabled by a spin_lock_irqsave.
You would want to add also a symmetric
local_irq_save_for_spinlock(flags) call.
However in the end I prefer to follow Alan's suggestion and convert all
the USB drivers. But that won't happen for a while because we're all
busy with other matters.
You never answered my second question. Is this sort of thing
acceptable?
DECLARE_SPINLOCK(lock);
static void irq_handler()
{
spin_lock_irqsave(&lock, flags);
...
internal_func();
...
spin_lock_irqrestore(&lock, flags);
}
static void internal_func()
{
...
spin_unlock(&lock);
invoke_callback();
spin_lock(&lock);
...
}
For that matter, would it be okay to use spin_lock_irq() rather than
spin_lock_irqsave() in the IRQ handler? Assume the handler was
registered without IRQF_DISABLED.
Alan Stern
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
