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]

Date:	Fri, 22 Apr 2011 08:07:28 +0200
From:	Wolfram Sang <w.sang@...gutronix.de>
To:	John Williams <john.williams@...alogix.com>
Cc:	Michal Simek <monstr@...str.eu>,
	devicetree-discuss@...ts.ozlabs.org, grant.likely@...retlab.ca,
	linux-kernel@...r.kernel.org, hjk@...sjkoch.de, arnd@...db.de
Subject: Re: [PATCH v3] uio/pdrv_genirq: Add OF support

> The difference between what you are doing for these multifunction
> devices, versus the generic-uio approach, is surely only a matter of
> degree rather than fundamentals?

I don't think so.

If you write "uio-generic", then you explicitly specify uio which is linux
specific and not hardware related. There is no uio-hardware :)

If you write "fsl,mpc5200b-psc-uart" then you describe that in your hardware
the psc is used as an UART (and not SPI) and every OS can make its assumption
about it.

So, you could have "company, super-fpga64-uart" which would bind to the
corresponding UART driver. And "company, super-fpga64-encryptor" would be
handled in Linux by the uio-driver if you setup this way, for example. If you
later have a seperate driver for it, then it will match against this
compatible-entry instead of uio. No change of the devicetree, the hardware did
not change.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)