linux-kernel - Re: UIO device tree bindings.

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: <20130402125149.GA7216@roeck-us.net>
Date:	Tue, 2 Apr 2013 05:51:49 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Pavel Machek <pavel@...x.de>
Cc:	sr@...x.de, w.sang@...gutronix.de, magnus.damm@...il.com,
	hjk@...utronix.de, Greg KH <greg@...ah.com>,
	linux-kernel@...r.kernel.org, dzu@...x.de
Subject: Re: UIO device tree bindings.

On Tue, Apr 02, 2013 at 01:51:51PM +0200, Pavel Machek wrote:
> On Mon 2013-04-01 19:42:12, Guenter Roeck wrote:
> > On Mon, Apr 01, 2013 at 05:40:08PM +0200, Pavel Machek wrote:
> > > On Mon 2013-04-01 16:23:36, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > I'd like to get uio device tree bindings to work -- with recent FPGA
> > > > parts it will be important. Latest version I see is 
> > > > 
> > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073087.html
> > > > 
> > > > ... Is there anything newer?
> > > > 
> > > > I red the discussion, and main problem seems to be the "tell kernel to
> > > > drive this device tree device", right?
> > > 
> > Problem seems to be the notion that the proposed devicetree entry would not
> > describe the hardware, but its use. Not really sure I understand the problem,
> > as I would see the hardware description to be "A hardware device which is
> > compatible to and managed by the generic-uio driver". I would argue that
> > this _is_ a hardware description (if not, what is ?), but I am not the one
> > to make the call.
> 
> Well... one could argue that having "generic-uio" in board's device
> tree _is_ wrong, but having driver that binds to "generic-uio" is
> not. Hmm?
> 
You mean like "ata-generic" ?

> Or maybe we can do some magic with module parameter. That should be
> enough for expected use.
> 
I don't think that would make a difference. I mean, just take ns16550 as another
example. No one has problems declaring some block of hardware addresses to be
compatible with "ns16550", even though it can be anything including a memory
block on one of the FPGAs or ASICs we are talking about here, it can be anything
but a NS16550, and many of the actual "compatible" strings are not defined
anythere either.

So there is no problem with "ata-generic" and "ns16550", and no one cares if
"fsl,mpc8349emitx-pata" or "xlnx,xps-uart16550-2.00.b" is defined or not, but
"generic-uio" together with "ptx,c64fpga001" is unacceptable.

I think it has more to do with the uio driver not being an actual driver, but
the kernel part of a user-space driver, though that is just a wild guess.

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