linux-kernel - Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.

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: <20150427112539.GR22845@sirena.org.uk>
Date:	Mon, 27 Apr 2015 12:25:39 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Hans de Goede <hdegoede@...hat.com>
Cc:	Michal Suchanek <hramrach@...il.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Martin Sperl <kernel@...tin.sperl.org>,
	linux-sunxi <linux-sunxi@...glegroups.com>,
	Jonathan Corbet <corbet@....net>,
	linux-spi <linux-spi@...r.kernel.org>,
	linux-doc <linux-doc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.

On Mon, Apr 27, 2015 at 12:04:12PM +0200, Hans de Goede wrote:

> Have you seen my mail about the raspberry pi use-case? Using dt-overlays
> simply is not an acceptable answer there. There are legitimate use-cases
> for a "generic spi bus" concept with the bus only being accessible via
> spidev.

> Blocking this use-case because you do not believe it is a valid use-case
> is not going to help, this will just lead to the custom distros these
> boards are shipping doing some ugly hack, which is not what we want
> IMHO.

I don't think you've fully considered your use case here.  As I said in
my reply to your earlier e-mail I think what you're looking for here is
something like better UI around overlays.  Registering a SPI bus without
knowing what's connected to it doesn't allow generic maker style usage
of the board, it's just as likely to hinder a user as help them.  For
example, if someone wants to use the SPI pins for another function such
as GPIO they'll have to handle that (and may have problems with pin
conflicts causing electrical issues if they do load up the DT with
spidev in it).  If someone has a SPI device they want to bind an in
kernel driver to they'll have to handle that, if they want to use a GPIO
to provide an additional chip select they'll have to handle that too.

Note that the discussion here isn't about userspace drivers, it's about
how the hardware is described.

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