devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christer Weinigel <christer@weinigel.se>
To: Mark Brown <broonie@kernel.org>, Mark Rutland <mark.rutland@arm.com>
Cc: Frank Rowand <frowand.list@gmail.com>,
	linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH] devicetree - document using aliases to set spi bus number.
Date: Wed, 25 May 2016 13:20:04 +0200	[thread overview]
Message-ID: <57458A64.2090901@weinigel.se> (raw)
In-Reply-To: <20160525103810.GU8206@sirena.org.uk>

On 05/25/2016 12:38 PM, Mark Brown wrote:
> On Wed, May 25, 2016 at 10:20:34AM +0100, Mark Rutland wrote:
>> On Tue, May 24, 2016 at 01:41:26PM -0700, Frank Rowand wrote:
> 
>>> The code and behavior is in the Linux kernel. It should be
>>> visible in the documentation instead of being a big mystery of
>>> how it works.
> 
>> As above, I don't entirely agree. Mindlessly documenting existing
>> Linux behaviour can have the unfortuante effect of moving people
>> towards the wrong tool for the job.
> 
> Yes, this is exactly my concern - the articulated use case (which
> didn't suprise me at all) is for using spidev which is itself not
> just Linux specific but this particular version of Linux right now
> specific.  There are lots of things that happen to work but are in
> fact terrible ideas that leave messes for our future selves.  We
> need to distinguish between things that are real, meaningful system
> descriptions and things that are implementation details resulting
> from the rush to force everyone on to DT.

Oh, for *beep* *beep* sake.

It used to be very easy to use SPI devices on Linux with stable device
names.  Add a platform device entry and set bus_num.  Add spidev
entries specifying the chip select, mode, speed and other specifics
for the devices on the bus.  Then just use
/dev/spi$bus_num.$chip_select to talk to them.  Very simple to use and
understand.

Doing the same with devicetree ought to be just as simple, and since
Grant added that patch it actually is.  The behaviour is already in
the Linux kernel.  Nobody is going to rip out the of_alias_get_id
usage from the spi driver sice that will break existing userspace.
Nobody is going to rip out the spidev framework from the Linux kernel.
 The aliases mechanism which is specifically intended to provide
easy-to use names for userspace.  From "A Symphony of Flavours: Using
the device tree to describe embedded hardware" by Grant Likely and
Josh Boyer:

    In order to ease device lookup in client operating systems, it is
    often desirable to define an aliases node.  This allows one to
    provide a shorthand method for identifying a device without having
    to specify the full path on lookup.

What is so horrible about documenting the actual behaviour of the
Linux kernel?  How is documenting that serial0 = /amba@0/blah@blah"
which is ok, so markedly different from documenting spi0 =
"/amba@0/blah/blah"?
Does everything have to be so damn difficult?

Ignore the patch if you want to, I give up.  I just hope that someone
else that needs to do the same thing will find my patch with this
(ought to be) trivial documentation.

    /Christer (tired of bikeshedding)

  reply	other threads:[~2016-05-25 11:20 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-24 16:39 [PATCH] devicetree - document using aliases to set spi bus number Christer Weinigel
2016-05-24 17:20 ` Mark Brown
2016-05-24 18:03   ` Christer Weinigel
2016-05-24 18:32     ` Mark Brown
     [not found]       ` <20160524183256.GP8206-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-05-24 18:57         ` Christer Weinigel
     [not found]           ` <5744A402.8050409-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
2016-05-25 12:19             ` Mark Rutland
2016-05-25 12:50               ` Mark Brown
2016-05-25 12:33             ` Mark Brown
2016-05-24 23:34         ` Frank Rowand
     [not found]           ` <5744E51A.1040506-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-25  0:18             ` Frank Rowand
2016-05-25 17:49           ` Rob Herring
2016-05-25 18:03             ` Mark Brown
2016-05-25 18:06             ` Frank Rowand
2016-05-25 18:44               ` Mark Brown
2016-05-26  1:10                 ` Christer Weinigel
     [not found]                   ` <57464D0A.1030706-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
2016-05-26  1:44                     ` Rob Herring
2016-05-26  1:56                       ` Christer Weinigel
     [not found]                         ` <574657BB.6070300-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
2016-05-26 10:07                           ` Mark Brown
2016-05-26 10:58                             ` Christer Weinigel
     [not found]                               ` <5746D6CE.5020605-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
2016-05-26 18:47                                 ` Mark Brown
     [not found]                                   ` <20160526184746.GF16172-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-05-26 21:04                                     ` Christer Weinigel
2016-05-27 16:43                                       ` Mark Brown
2016-05-24 17:41 ` Mark Rutland
2016-05-24 20:41   ` Frank Rowand
     [not found]     ` <5744BC76.9090403-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-25  9:20       ` Mark Rutland
2016-05-25 10:38         ` Mark Brown
2016-05-25 11:20           ` Christer Weinigel [this message]
     [not found]             ` <57458A64.2090901-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
2016-05-25 12:34               ` Mark Rutland
2016-05-25 13:08                 ` Mark Brown
2016-05-25 15:32         ` Frank Rowand
     [not found]           ` <5745C5A3.6060202-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-25 15:59             ` Mark Rutland
2016-05-25 16:21               ` Frank Rowand
2016-05-25 18:02               ` Mark Brown
2016-05-25 17:48             ` Mark Brown
2016-05-25 18:46               ` Frank Rowand
     [not found]                 ` <5745F30B.2040605-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-27 18:36                   ` Mark Brown
2016-05-28 20:57                     ` Christer Weinigel
     [not found]                       ` <574A063D.5030700-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
2016-05-30 16:13                         ` Mark Brown
2016-05-25 15:25   ` Frank Rowand
     [not found]     ` <5745C3F8.4020909-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-25 16:06       ` Mark Rutland
2016-05-25 16:31         ` Frank Rowand
2016-05-25 18:44   ` Rob Herring
2016-05-25 18:48     ` Mark Brown
2016-05-26  8:21     ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57458A64.2090901@weinigel.se \
    --to=christer@weinigel.se \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).