linux-kernel - Re: [PATCH] uio: User IRQ Mode

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]

Date:	Fri, 4 Jul 2008 08:01:08 +0200
From:	Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com>
To:	Magnus Damm <magnus.damm@...il.com>
CC:	"Hans J. Koch" <hjk@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [PATCH] uio: User IRQ Mode

Magnus Damm wrote:
> On Thu, Jul 3, 2008 at 9:45 PM, Hans J. Koch <hjk@...utronix.de> wrote:
> > On Thu, Jul 03, 2008 at 09:10:19AM +0200, Uwe Kleine-König wrote:
> >> Hans J. Koch wrote:
> >> > On Wed, Jul 02, 2008 at 07:59:51PM +0900, Magnus Damm wrote:
> >> > > From: Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com>
> >> > >
> >> > > This patch adds a "User IRQ Mode" to UIO. In this mode the user space driver
> >> > > is responsible for acknowledging and re-enabling the interrupt.
> >> >
> >> > This can easily be done without your patch.
> >
> > BTW, the above wording "the user space driver is responsible for
> > acknowledging and re-enabling the interrupt" is misleading. The kernel
> > always has to acknowledge/disable/mask the interrupt. Userspace can only
> > reenable it, ideally by writing to a chip register. In some cornercases
> > for broken hardware we need the newly introduced write function.
> 
> You seem to be mixing up masking/acknowledging the interrupt
> controller and masking/acknowledging the actual hardware device. In
> User IRQ Mode, the only thing the user space driver is accessing is
> the hardware device, with the exception of write() to re-enable
> interrupts which results in a enable_irq() that touches the interrupt
> controller.
But to be honest Hans is right here, the commit log wording is not
optimal.  I suggest:

	This patch adds a "User IRQ Mode" to UIO. In this mode the
	kernel space simply disables the serviced interrupt in the
	interrupt controller and the user space driver is responsible
	for acknowledging it in the device and reenabling it.

	Note that this implies that the interrupt might be disabled for
	long periods, so this isn't usable for shared interrupt lines.

Maybe it's sensible to add the User IRQ Mode functions at least for now
into platform code.  Then at a later time if and when there are several
copies the discussion to move it to the generic part might be easier.

BTW, I currently have a situation where it IMHO really makes sense to
use the User IRQ Mode:  We sell a cpu module to a customer with
Linux.  I provide a uio device for some memory mapped periphal on the
customers board that I don't know in detail.  With the User IRQ Mode I
only need to know the chip select and the irq line, no further
information is needed for the device.

Best regards,
Uwe

-- 
Uwe Kleine-König, Software Engineer
Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany
Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962
--
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/