Re: RT-friendly IRQ management in USB

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel