linux-kernel - Re: [PATCH] spi: Force the registration of the spidev devices

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: <20140501223629.GJ3000@lukather>
Date:	Thu, 1 May 2014 15:36:29 -0700
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Subject: Re: [PATCH] spi: Force the registration of the spidev devices

On Wed, Apr 30, 2014 at 06:18:11PM -0700, Mark Brown wrote:
> On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
> > On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
> 
> > > Why can we not handle this by using sysfs to bind spidev to the
> > > device?
> 
> > I just tried it, and apparently, you can't really use this, since spi
> > devices are created from the device tree (or ACPI) whenever the master
> > registers.
> 
> Can you be more specific as to what the issue is here?  If we actually
> have a specific kernel driver for a device I would strongly expect that
> we would want to use it and not spidev, if we don't have one I don't see
> the issue.
>
> > It doesn't really work either for a device that would be bound to a
> > driver, that you unbind, and then try to bind to spidev instead. It
> > looks like the device is released whenever you unbind it, so you can't
> > really use it afterwards.
> 
> I guess this is the issue...  what exactly is the use case here?  I
> would only expect spidev to be used if there is no in kernel driver for
> a device.

The issue and use case is this: we don't have an upstreamable way to
use spidev.

You suggested a while back to add the compatibles of devices we would
want to drive with spidev in the spidev compatible list. It's fine for
devices where we should have a driver, but don't, or devices that will
never ever be handled by the kernel.

But it actually doesn't work in a case where you can't really predict
what is on the other side of the bus. Either because, on the board
you're using the pins are exposed and it's pretty much up to the user
to know what to put on it. That could be handled by DT overlays
though.

What never works is where the device on the other side is so generic
that you really can't tell what it does. Think of a microcontroller
that would behave as a SPI slave. It's behaviour and what it does is
pretty much dependant of what we flashed on it, and suddenly the
compatible string is not the proper reprensentation anymore.

i2c-dev works great in these cases, because you always have access to
all the bus, and all the devices, except if the device is already used
by someone. The patch I suggested is an attempt to mimic this.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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