linux-kernel - Re: [PATCH] uio_pdrv: Unique 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:	Thu, 5 Jun 2008 10:25:27 +0900
From:	"Magnus Damm" <magnus.damm@...il.com>
To:	"Hans J. Koch" <hjk@...utronix.de>
Cc:	linux-kernel@...r.kernel.org, Uwe.Kleine-Koenig@...i.com,
	gregkh@...e.de, akpm@...ux-foundation.org, lethal@...ux-sh.org,
	tglx@...utronix.de
Subject: Re: [PATCH] uio_pdrv: Unique IRQ Mode

On Wed, Jun 4, 2008 at 7:11 PM, Hans J. Koch <hjk@...utronix.de> wrote:
> On Wed, Jun 04, 2008 at 03:08:26PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm@...l.co.jp>
>>
>> This patch adds a "Unique IRQ Mode" to the uio_pdrv UIO platform driver.
>> In this mode the user space driver is responsible for acknowledging and
>> re-enabling the interrupt. Shared interrupts are not supported.
>
> I still don't see any gain in this. This only works for embedded
> devices, so a user has to setup hardware specific code in his board
> support anyway.

Exactly what in my patch makes this platform driver only suitable for
embedded devices?

> With your code, we would have to add something like this
> to the docs:
>
> IF you define an irq AND ommit the irq handler THEN we silently add a
> handler that blindly assumes the irq is not shared...

I'm not sure if silently and blindly are the first words that pop into
my mind, but sure. Documentation is a good idea. Just let me know
which uio_pdrv document you want me to modify.

> In my opinion, this is confusing, and all it does is saving the need for a
> three-lines irq handler in the board support.

You propose that I put the callbacks in my board support code instead
of modifying the driver. I don't think the board support level is the
proper place for this code. The patch contains no board specific code,
and it is independent of both architecture and cpu model.

> So, NAK to this until somebody convinces me that I completely missed the
> point.

We can reuse this driver for _many_ different SuperH processor models.
Most of these processor models even have more than one hardware block
that can be exported to user space using this uio_pdrv driver in
"Unique IRQ Mode". There is nothing board specific with this at all,
so yes, I think you are missing the point.

Maybe you prefer that I repost my "Reusable UIO Platform Driver"
instead of modifying uio_pdrv?

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