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]

Date:	Fri, 2 May 2014 10:40:48 -0700
From:	Mark Brown <broonie@...nel.org>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
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 Thu, May 01, 2014 at 03:36:29PM -0700, Maxime Ripard wrote:

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

Right, that's a completely unrelated issue.

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

That sounds like another situation for overlays, really the thing that's
compatible here is going to be the whole assembly rather than just the
device in isolation (or you're in a similar situation to the one you're
in with FPGAs where you have a driver implementing an application like a
loadeer

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

It seems better to implement something like this at the device model
level, provide a way to have a default UIO driver for anything on a
given bus.  I don't see anything bus specific apart from saying what the
default driver to use is and it avoids the icky code fiddling about with
what devices are bound and the races that might be involved duplicated
in individual buses.

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