From: Christer Weinigel <christer-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
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: 69+ 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 16:39 ` 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 [this message]
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:19 ` Mark Rutland
2016-05-25 12:50 ` Mark Brown
2016-05-25 12:33 ` Mark Brown
2016-05-25 12:33 ` Mark Brown
2016-05-24 23:34 ` Frank Rowand
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 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: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: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
2016-05-26 18:47 ` Mark Brown
[not found] ` <20160526184746.GF16172-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-05-26 21:04 ` Christer Weinigel
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 9:20 ` Mark Rutland
2016-05-25 10:38 ` Mark Brown
2016-05-25 10:38 ` Mark Brown
2016-05-25 11:20 ` Christer Weinigel
[not found] ` <57458A64.2090901-rKHMIqA5R6gwFerOooGFRg@public.gmane.org>
2016-05-25 12:34 ` Mark Rutland
2016-05-25 12:34 ` Mark Rutland
2016-05-25 13:08 ` Mark Brown
2016-05-25 13:08 ` Mark Brown
2016-05-25 15:32 ` Frank Rowand
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 15:59 ` Mark Rutland
2016-05-25 16:21 ` Frank Rowand
2016-05-25 16:21 ` Frank Rowand
2016-05-25 18:02 ` Mark Brown
2016-05-25 17:48 ` 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-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-30 16:13 ` Mark Brown
2016-05-25 15:25 ` Frank Rowand
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:06 ` Mark Rutland
2016-05-25 16:31 ` Frank Rowand
2016-05-25 18:44 ` Rob Herring
2016-05-25 18:44 ` Rob Herring
2016-05-25 18:48 ` Mark Brown
2016-05-25 18:48 ` Mark Brown
2016-05-26 8:21 ` Geert Uytterhoeven
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-rkhmiqa5r6gwferooogfrg@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.