linux-kernel - Re: [PATCH v3] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110419061121.GB5252@ponder.secretlab.ca>
Date:	Tue, 19 Apr 2011 00:11:21 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	John Williams <john.williams@...alogix.com>
Cc:	Wolfram Sang <w.sang@...gutronix.de>,
	Michal Simek <monstr@...str.eu>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	hjk@...sjkoch.de, arnd@...db.de
Subject: Re: [PATCH v3] uio/pdrv_genirq: Add OF support

On Tue, Apr 19, 2011 at 11:58:25AM +1000, John Williams wrote:
> On Tue, Apr 19, 2011 at 2:06 AM, Wolfram Sang <w.sang@...gutronix.de> wrote:
> > Hi,
> >
> >> For example with "uio" compatible string:
> >> static const struct of_device_id __devinitconst uio_of_genirq_match[] = {
> >>       { .compatible = "uio", },
> >>       { /* empty for now */ },
> >> };
> >
> > Please use a proper example with "vendor,device".
> > (And after that it won't be empty anymore)
> 
> My vote is, and always has been 'generic-uio' :)
> 
> Putting some random vendor/device string in there is just nuts. Do you
> really want a kernel patch every time some one binds their device to
> it?
> 
> Or, is there no expectation that anybody would attempt to merge such a
> pointless patch to begin with?
> 
> As we discussed at ELC, putting a real vendor/device in there is also
> broken because all instances in the system wil bind to the generic
> uio, which is not necessarily what is desired.
> 
> I know the arguments against the 'generic-uio' tag, but come on, let's
> look at the lesser of two evils here!  I call BS on this DTS purity.

Call it what you like, but the reasons are well founded.  The alternative
that has been proposed which I am in agreement with is to investigate
giving userspace the hook to tell the kernel at runtime which devices
should be picked up by the uio driver.

In the mean time, explicitly modifying the match table is an okay
compromise.

g.

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