Messages in this thread | | | Date | Wed, 14 Sep 2011 17:15:14 +0800 | Subject | Re: [RFC] [PATCH 02/62] mpu401:snd_mpu401_uart_new(): split semantic of irq_flags | From | Yong Zhang <> |
| |
On Wed, Sep 14, 2011 at 5:06 PM, Takashi Iwai <tiwai@suse.de> wrote: > At Wed, 14 Sep 2011 16:49:57 +0800, > Yong Zhang wrote: >> >> On Tue, Sep 13, 2011 at 11:24:41AM +0200, Clemens Ladisch wrote: >> [snip] >> > >> > completely untested: >> > >> > --8<---------------------------------------------------------------->8-- >> > ALSA: mpu401: clean up interrupt specification >> > >> > The semantics of snd_mpu401_uart_new()'s interrupt parameters are >> > somewhat counterintuitive: To prevent the function from allocating its >> > own interrupt, either the irq number must be invalid, or the irq_flags >> > parameter must be zero. At the same time, the irq parameter being >> > invalid specifies that the mpu401 code has to work without an interrupt >> > allocated by the caller. This implies that, if there is an interrupt >> > and it is allocated by the caller, the irq parameter must be set to >> > a valid-looking number which then isn't actually used. >> > >> > With the removal of IRQF_DISABLED, zero becomes a valid irq_flags value, >> > which forces us to handle the parameters differently. >> > >> > This patch introduces a new flag MPU401_INFO_IRQ_HOOK for when the >> > device interrupt is handled by the caller, and makes the allocation of >> > the interrupt to depend only on the irq parameter. As suggested by >> > Takashi, the irq_flags parameter was dropped because, when used, it had >> > the constant value IRQF_DISABLED. >> >> Thanks Clemens. Your patch will eventually save much lines from mine , >> actually I only need to touch request_irq() in snd_mpu401_uart_new(). >> >> But do you have any idea by which tree this patch will go to mainline? >> Thus I could make a new patch based on it :) > > I applied Clemens' patch now to sound git tree. > The temporary location is: > git://github.com/tiwai/sound.git > > In general, such cross-tree patches should be based on linux-next, > which should contain the latest subsystem tree. But as kernel.org is > down now, you can check each subsystem tree.
Thanks for your guide, Takashi !
Will refresh my patch based on that.
Thanks, Yong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |