linux-kernel - Re: [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds

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] [day] [month] [year] [list]

Message-ID: <20140609225707.GB5099@sirena.org.uk>
Date:	Mon, 9 Jun 2014 23:57:07 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Marcel Ziswiler <marcel@...wiler.com>
Cc:	Stephen Warren <swarren@...dotorg.org>, thierry.reding@...il.com,
	linux@....linux.org.uk, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-tegra@...r.kernel.org, stefan@...er.ch
Subject: Re: [PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev,
 lm95245, pwm leds

On Tue, Jun 10, 2014 at 12:16:13AM +0200, Marcel Ziswiler wrote:
> On 06/04/2014 01:17 PM, Mark Brown wrote:

> >You're saying you're controlling it from userspace.  This is a
> >particular detail of what you are doing in your system.  You happen to
> >want to control the devices you are hanging off the system with
> >userspace drivers but that's just what you're doing right now.

> Sorry, I don't get it. Yes, spidev is to control stuff from user space just
> like i2c-dev however bad that might sound.

There is absolutely nothing wrong with that.  What there is a problem
with is putting that implementation detail into a device tree, if
someone comes along and writes an in kernel driver for the same device
the device tree needs to continue to work without modification as it is
an ABI.

> >No, that's in the controller node - the chip selects are described
> >there.  The child node references a chip select number that the master
> >has and describes what's connected to that chip select.

> Well, unfortunately SPI without any chip select is just plain simply
> useless. It won't work.

I'm sorry but I'm not seeing how that follows on from what I said?

> >It's a perfectly fine way of controlling things from userspace if that's
> >a sensible way of controlling devices but that does not mean you should
> >describe it in the device tree in that fashion.

> Only that without describing such a chip select in the device tree spidev
> won't ever work.

Again I'm not sure how that follows.  To repeat, the chip selects are
described on the SPI controller and referenced by the child devices when
they are instantiated by chip select number.  Please refer to the SPI
bindings if this is unclear, or be specific in what is unclear.

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