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 15:32:21 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Uwe Kleine-K?nig <Uwe.Kleine-Koenig@...i.com>
Cc:	Magnus Damm <magnus.damm@...il.com>,
	"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

On Fri, Jul 04, 2008 at 08:01:08AM +0200, Uwe Kleine-K?nig wrote:
> 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.

Thanks for this suggestion. I agree. Maybe we find a different solution
until then.

> 
> 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.

The only additional information you need now is which bit in which
register you have to set/clear to mask the irq. I also have customer
chips here where this one information is all I know about the chip.

Thanks,
Hans

--
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/