public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christer Weinigel <christer@weinigel.se>
To: Mark Brown <broonie@kernel.org>
Cc: 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: Tue, 24 May 2016 20:57:06 +0200	[thread overview]
Message-ID: <5744A402.8050409@weinigel.se> (raw)
In-Reply-To: <20160524183256.GP8206@sirena.org.uk>

On 05/24/2016 08:32 PM, Mark Brown wrote:
> On Tue, May 24, 2016 at 08:03:48PM +0200, Christer Weinigel wrote:
>> On 05/24/2016 07:20 PM, Mark Brown wrote:
> 
>>> I'm not sure this is something we want to support at all, I
>>> can't immediately see anything that does this deliberately in
>>> the SPI code and obviously the "bus number" is something of a
>>> Linux specific concept which would need some explanation if we
>>> were going to document it.  It's something I'm struggling a bit
>>> to see a robust use case for that isn't better served by
>>> parsing sysfs, what's the goal here?
> 
>> If this isn't something that should be in the
>> Documentation/devicetree because it's not generig enough, where
>> should Linux-specific interpretations such as this be
>> documented?
> 
> I'm not clear that we want to document this at all since I am not
> clear that there is a sensible use case for doing it.  I did ask
> for one but you've not articulated one in this reply.  I am much
> less gung ho than Grant on this one, even as a Linux specific
> interface it seems very legacy.

It's bloody convenient.  I'm working with a Zync board right now where
we have multiple SPI ports.  Being able to label the ports on the
board spi1, spi2 and spi3 and having spidev devices show up as
/dev/spidev1.0 instead of dynamic assignment makes things much easier.
 Especially when doing driver development where unloading and
reloading the spi driver module will give it a new dynamic number
every time.

Yes, it's possible to iterate through all files /sys/class/spi_master
and then have a table to map those names to device names and create
symlinks to them, it's just painful.  It's much easier to do be able
to do "cat data >/dev/spidev1.0" from busybox and not have to set up
all that infrastructure.  And yes, this is on an embedded system using
busybox without udev.

In addition, right now I have a couple of different variants of the
boards that I work on, and with different SPI ports at different
addresses.   It's rather nice to be able to reuse the same kernel +
ramdisk on multiple variants and only have to update the devicetree to
get sensible devices names on all variants.

  /Christer

  reply	other threads:[~2016-05-24 18:57 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
2016-05-24 18:57       ` Christer Weinigel [this message]
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
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
2016-05-26  1:44                 ` Rob Herring
2016-05-26  1:56                   ` Christer Weinigel
2016-05-26 10:07                     ` Mark Brown
2016-05-26 10:58                       ` Christer Weinigel
2016-05-26 18:47                         ` Mark Brown
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
2016-05-25  9:20     ` Mark Rutland
2016-05-25 10:38       ` Mark Brown
2016-05-25 11:20         ` Christer Weinigel
2016-05-25 12:34           ` Mark Rutland
2016-05-25 13:08             ` Mark Brown
2016-05-25 15:32       ` Frank Rowand
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
2016-05-27 18:36             ` Mark Brown
2016-05-28 20:57               ` Christer Weinigel
2016-05-30 16:13                 ` Mark Brown
2016-05-25 15:25   ` Frank Rowand
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=5744A402.8050409@weinigel.se \
    --to=christer@weinigel.se \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    /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