[PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds
Mark Brown
broonie at kernel.org
Mon Jun 9 15:57:07 PDT 2014
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140609/3e25535e/attachment.sig>
More information about the linux-arm-kernel
mailing list