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  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" <>
To:	Uwe Kleine-K?nig <>
Cc:	Magnus Damm <>,
	"Hans J. Koch" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
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 <> 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 <>
> > >> > >
> > >> > > 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists