linux-kernel - Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv

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] [day] [month] [year] [list]

Date:	Fri, 19 Dec 2008 22:41:01 +0900
From:	"Magnus Damm" <magnus.damm@...il.com>
To:	"Wolfram Sang" <w.sang@...gutronix.de>
Cc:	"Paul Mundt" <lethal@...ux-sh.org>, hjk@...utronix.de,
	gregkh@...e.de, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org
Subject: Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq

On Tue, Dec 16, 2008 at 9:41 PM, Wolfram Sang <w.sang@...gutronix.de> wrote:
>
>> It is pretty poor form to not even bother to Cc the only author of the
>> code you are modifying, and have no Signed-off-by or Acked-by to even
>> suggest that it was ever even looked at. This isn't something that ought
>> to have to be pointed out, either.
>
> Oops, yes, forgot this in the resend, I am sorry. I did CC Magnus in the
> first round, though, and he replied to me that he liked adding OF and
> just waited for Hans' reply first.

Right, that's exactly what happened. Last time when the platform
drivers got merged was very very very intense so I expected a similar
situation. Please excuse the hands-off handling.

The result of our discussions last time was basically that we should
have two reusable uio platform drivers; the regular uio_pdrv and
uio_pdrv_genirq. The good thing with this is that we clearly show the
difference between the two drivers, most people should just use the
regular uio_pdrv driver and crazy people with unique interrupt sources
should use the genirq version.

The downside with the two drivers is the duplicated code, but I guess
that's ok for now.

>> In addition to the stuff pointed out by Greg, I don't see what you
>> actually gain by hacking the OF crap in to this driver. You would be
>> better off layering the OF driver on top of this, rather than trying to
>> make them live together in the same file.

I totally agree.

> See my reply just posted. I found two ways to go, and from reading
> discussions on the lists, finally decided for this way. May have been
> the wrong path, but nothing that could not be changed.

In my mind, the best way forward is to write a new uio driver that
interfaces to open firmware. After that we can break out things like
resource handling and maybe generic interrupt code. Please CC me and
I'll help out.

Cheers,

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