linux-kernel - Re: [PATCH] devicetree - document using aliases to set spi bus number.

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: <5744A402.8050409@weinigel.se>
Date:	Tue, 24 May 2016 20:57:06 +0200
From:	Christer Weinigel <christer@...nigel.se>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH] devicetree - document using aliases to set spi bus
 number.

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