lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E6F1194.80106@ladisch.de>
Date:	Tue, 13 Sep 2011 10:17:24 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	Takashi Iwai <tiwai@...e.de>
CC:	Yong Zhang <yong.zhang0@...il.com>, linux-kernel@...r.kernel.org,
	Jaroslav Kysela <perex@...ex.cz>, alsa-devel@...a-project.org
Subject: Re: [RFC] [PATCH 02/62] mpu401:snd_mpu401_uart_new(): split semantic
 of irq_flags

Takashi Iwai wrote:
> Clemens Ladisch wrote:
> > 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.
> > 
> > Signed-off-by: Clemens Ladisch <clemens@...isch.de>
> 
> This patch looks better indeed.
> 
> However, if we are going to remove IRQF_DISABLED in near future, and
> all the callers use IRQF_DISABLED when requesting an irq, why not
> remove this argument now?  Then the IRQF_DISABLED-removal patch will
> touch less code.

I wanted to change only the minimum amount of code needed to make the
IRQF_DISABLED-removal patch possible, and wait with further cleanups of
snd_mpu401_uart_new() until after that patch to avoid conflicts.

However, moving the IRQF_DISABLED into snd_mpu401_uart_new() avoids
those conflicts, so it's clearly better.


Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ