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
next prev parent 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