linux-kernel - Re: [PATCH v3 1/3] spi: spidev: create spidev device for all spi slaves.

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: <20160719171959.GD30372@sirena.org.uk>
Date:	Tue, 19 Jul 2016 18:19:59 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Michal Suchanek <hramrach@...il.com>
Cc:	linux-spi <linux-spi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] spi: spidev: create spidev device for all spi
 slaves.

On Tue, Jul 19, 2016 at 05:32:24PM +0200, Michal Suchanek wrote:
> On 19 July 2016 at 14:44, Mark Brown <broonie@...nel.org> wrote:

> >> -       status = register_chrdev(SPIDEV_MAJOR, "spi", &spidev_fops);
> >> +       status = register_chrdev(SPIDEV_MAJOR, "spidev", &spidev_fops);

> > also looks like a needless ABI change

> ABI change to what?

> The spidev ABI should be the IOCTLs on /dev/spidev*. These are preserved.

> What parts of the kernel or userspace should depend on spidev
> devices belonging to class spi?

It's a string that's exposed to userspace (via /proc/devices if nothing
else).

> > If userspace is managing to figure out how to control the device then
> > providing a description of the hardware is clearly within the bounds of
> > possibility and there is no need to fake anything.

> However. maintaining the hardware description in multiple places is
> redundant and error-prone. Since the userspace somehow managed to
> figure it out on legacy kernels without devicetree it does not need
> the information in devicetree. Users of such software will not want the
> hardware description in devicetree and if forced to provide it will stub it out.

Userspace is just as capable of looking at the DT as anything else, I'd
expect that where this is a viable way of deploying things people would
be writing udev/systemd magic to fire up userspace drivers automatically
when they see suitable hardware.  The only way this has ever worked in
the past has been with system specific hacks which lead to fragile,
non-portable userpaces that are hard to upgrade.  If we're trying to say
this is an interface that's there for all devices then we shouldn't be
defining it in a way that makes it difficult to automatically configure.

> Also world is not all devicetree so userspace applications should be free
> to consult devicetree information if present or use whatever other means
> at their disposal to determine what hardware they are dealing with.
> When portability is a concern consulting devicetree may be a secondary
> source at best.

ACPI has similar facilities (it's got a direct translation of DT in it
these days so most things with a DT binding also have an ACPI one for
free).

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