Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1406282 > unrolled thread

[PATCH] devicetree - document using aliases to set spi bus number.

Back to article view | Back to linux.kernel

Contents

  [PATCH] devicetree - document using aliases to set spi bus number. Christer Weinigel <christer@weinigel.se> - 2016-05-24 18:50 +0200
    Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-24 19:30 +0200
      Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-24 20:20 +0200
        Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-24 20:40 +0200
          Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-24 21:00 +0200
            Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Rutland <mark.rutland@arm.com> - 2016-05-25 14:20 +0200
              Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 15:00 +0200
            Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 14:40 +0200
          Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 01:40 +0200
            Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 02:20 +0200
            Re: [PATCH] devicetree - document using aliases to set spi bus  number. Rob Herring <robh@kernel.org> - 2016-05-25 19:50 +0200
              Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 20:10 +0200
              Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 20:10 +0200
                Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 20:50 +0200
                  Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-26 03:20 +0200
                    Re: [PATCH] devicetree - document using aliases to set spi bus number. Rob Herring <robh@kernel.org> - 2016-05-26 03:50 +0200
                      Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-26 04:00 +0200
                        Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-26 12:20 +0200
                          Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-26 13:00 +0200
                            Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-26 20:50 +0200
                              Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-26 23:10 +0200
                                Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-27 18:50 +0200
    Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Rutland <mark.rutland@arm.com> - 2016-05-24 19:50 +0200
      Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-24 22:50 +0200
        Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Rutland <mark.rutland@arm.com> - 2016-05-25 11:30 +0200
          Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 12:40 +0200
            Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-25 13:30 +0200
              Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Rutland <mark.rutland@arm.com> - 2016-05-25 14:40 +0200
                Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 15:10 +0200
          Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 17:40 +0200
            Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Rutland <mark.rutland@arm.com> - 2016-05-25 18:10 +0200
              Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 18:30 +0200
              Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 20:10 +0200
            Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 20:00 +0200
              Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 20:50 +0200
                Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-27 20:40 +0200
                  Re: [PATCH] devicetree - document using aliases to set spi bus  number. Christer Weinigel <christer@weinigel.se> - 2016-05-28 23:00 +0200
                    Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-30 18:20 +0200
      Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 17:30 +0200
        Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Rutland <mark.rutland@arm.com> - 2016-05-25 18:10 +0200
          Re: [PATCH] devicetree - document using aliases to set spi bus number. Frank Rowand <frowand.list@gmail.com> - 2016-05-25 18:40 +0200
      Re: [PATCH] devicetree - document using aliases to set spi bus  number. Mark Brown <broonie@kernel.org> - 2016-05-25 20:50 +0200
      Re: [PATCH] devicetree - document using aliases to set spi bus  number. Rob Herring <robh@kernel.org> - 2016-05-25 20:50 +0200
        Re: [PATCH] devicetree - document using aliases to set spi bus number. Geert Uytterhoeven <geert@linux-m68k.org> - 2016-05-26 10:30 +0200

Page 1 of 3  [1] 2 3  Next page →

#1406282 — [PATCH] devicetree - document using aliases to set spi bus number.

Document how to use devicetree aliases to assign a stable
bus number to a spi bus.

Signed-off-by: Christer Weinigel <christer@weinigel.se>

---

Trivial documentation change.

Not having used devicetree that much it was surprisingly hard to
figure out how to assign a stable bus number to a spi bus.  Add a
simple example that shows how to do that.

Mark Cced as the SPI maintainer.  Or should trivial documentation
fixes like this be addressed to someone else?

  /Christer

 Documentation/devicetree/bindings/spi/spi-bus.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt
index 42d5954..c35c4c2 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -94,3 +94,13 @@ SPI example for an MPC5200 SPI bus:
 			reg = <1>;
 		};
 	};
+
+Normally SPI buses are assigned dynamic bus numbers starting at 32766
+and counting downwards.  It is possible to assign the bus number
+statically using devicetee aliases.  For example, on the MPC5200 the
+"spi@f00" device above is connected to the "soc" bus.  To set its
+bus_num to 1 add an aliases entry like this:
+
+	aliases {
+		spi1 = "/soc/spi@f00";
+	};
-- 
1.9.1

[toc] | [next] | [standalone]

#1406301 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 24, 2016 at 06:39:20PM +0200, Christer Weinigel wrote:
> Document how to use devicetree aliases to assign a stable
> bus number to a spi bus.

Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.

> Not having used devicetree that much it was surprisingly hard to
> figure out how to assign a stable bus number to a spi bus.  Add a
> simple example that shows how to do that.

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?

> Mark Cced as the SPI maintainer.  Or should trivial documentation
> fixes like this be addressed to someone else?

This is definitely *not* trivial but yes, in general you should CC
maintainers on things.

[toc] | [prev] | [next] | [standalone]

#1406371 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

On 05/24/2016 07:20 PM, Mark Brown wrote:
>> Not having used devicetree that much it was surprisingly hard to 
>> figure out how to assign a stable bus number to a spi bus.  Add
>> a simple example that shows how to do that.
> 
> 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?

Well, that's how it works right now:

commit bb29785e0d6d150181704be2efcc3141044625e2
Author: Grant Likely <grant.likely@secretlab.ca>
Date:   Fri Dec 21 19:32:09 2012 +0000

    spi/of: Use DT aliases for assigning bus number

> + if ((master->bus_num < 0) && master->dev.of_node) +
> master->bus_num = of_alias_get_id(master->dev.of_node, "spi");

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?

  /Christer

[toc] | [prev] | [next] | [standalone]

#1406385 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1406392 — 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

[toc] | [prev] | [next] | [standalone]

#1406859 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

On Tue, May 24, 2016 at 08:57:06PM +0200, Christer Weinigel wrote:
> 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.

Do these numbers match anything, or have you assigned them artificially?

i.e. are the labels for those well defined for the board? Are they in a
manul, or printed on the board itself?

If these are well-defined and the ports are accessible to, and under the
control of, the end-user, then this would be largely similar to what we
do for serial ports and other user-accessible physical connectors.

>  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.

If those ports are physically organised and labelled the same, then
using aliases could make sense, to describe the well-defined physical
labels. If you've assigned the numbers artificially, or if the physical
organisation differs across boards, then aliases are not the right tool
for the job.

In the latter cases we're altering the hardware description to suit an
application, rather than providing the necessary abstraction, which is
the kind of (ab)use of aliases which we want to avoid.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1406883 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 25, 2016 at 01:19:24PM +0100, Mark Rutland wrote:
> On Tue, May 24, 2016 at 08:57:06PM +0200, Christer Weinigel wrote:

> > 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.

> Do these numbers match anything, or have you assigned them artificially?

> i.e. are the labels for those well defined for the board? Are they in a
> manul, or printed on the board itself?

> If these are well-defined and the ports are accessible to, and under the
> control of, the end-user, then this would be largely similar to what we
> do for serial ports and other user-accessible physical connectors.

It's not a physical connector on the board that this is covering, it's
for the SPI bus which isn't a meaningful thing since there's no overall
connection standard and to do anything useful you'd need to handle the
chip selects which numbering the buses does nothing to help with.
Anything that's actually exposed at the SPI level would be a particular
device or set of devices on one or more buses, if the goal is to label
bare pins on boards then we're looking at the individual device level
rather than the bus level.

Really such a connector is the equivalent of a BeagleBone cape connector
or whatever.

[toc] | [prev] | [next] | [standalone]

#1406872 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 24, 2016 at 08:57:06PM +0200, Christer Weinigel wrote:
> On 05/24/2016 08:32 PM, Mark Brown wrote:

> > 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.

So you're using it with spidev, probably directly at a guess rather than
with an explicitly enumerated device in there?  This is also something
we don't support in DT unless you've added an explicit compatible string
for the device you've got attached for it to bind to - it will print an
enormous warning if you try to instantiate it directly from DT since
unfortunately implementation details of how we match compatible strings
mean that any Linux device will match.

The DT should describe the hardware in the system, not the
implementation details of how a particular software release should
control that hardware.  If your software release is intending to expose
a SPI interface connected to nothing it's not clear that this is useful
hardware to describe and that we can't just optimise this by not doing
anything with the hardware at all but whatever happens we should be
explicitly exposing that, not doing global level hacks for it.  We're
talking about very limited test usage in a new system here as far as I
can tell.

> 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.

You're way off in the implementation detail weeds here.  What you're
looking for here is something very much specific to how spidev device
files happen to be named with the particular userspace you're using,
with the choice to use spidev to control the devices (if there are any)
itself being something that's not at all general.  It doesn't follow
from this that assigning numbers to SPI buses is a good idea, it's
something that only has meaning in this very specific context, and there
is no guarantee that the chip select numbers will end up being stable
for that matter.

If this is something it makes sense to have in device trees at all it's
something that should be being done as part of describing the specific
thing you are trying to describe.

[toc] | [prev] | [next] | [standalone]

#1406515

On 5/24/2016 11:32 AM, 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.
> 

The time for the use case was when the patch was accepted.

It is in the kernel, it is appropriate to document it.

-Frank

[toc] | [prev] | [next] | [standalone]

#1406537

On 5/24/2016 4:34 PM, Frank Rowand wrote:
> On 5/24/2016 11:32 AM, 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.
>>
> 
> The time for the use case was when the patch was accepted.

I phrased that sentence poorly.  A more clear wording is:
The time for the use case was when the source code patch
was accepted (commit bb29785e0d6d150181704be2efcc3141044625e2).

> 
> It is in the kernel, it is appropriate to document it.
> 
> -Frank
> 

[toc] | [prev] | [next] | [standalone]

#1407135 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

On Tue, May 24, 2016 at 04:34:50PM -0700, Frank Rowand wrote:
> On 5/24/2016 11:32 AM, 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.

No, we don't.

> > 
> 
> The time for the use case was when the patch was accepted.

Ideally, yes, but things getting missed in review or later deciding 
things were a bad idea can always be debated again.

> It is in the kernel, it is appropriate to document it.

Things get undocumented all the time when we deprecate them.

Rob

[toc] | [prev] | [next] | [standalone]

#1407148 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 25, 2016 at 12:49:32PM -0500, Rob Herring wrote:
> On Tue, May 24, 2016 at 04:34:50PM -0700, Frank Rowand wrote:

> > It is in the kernel, it is appropriate to document it.

> Things get undocumented all the time when we deprecate them.

There's also the X.org approach of breaking documented behaviour and
seeing if anyone complains before you deprecate :)

[toc] | [prev] | [next] | [standalone]

#1407149

On 5/25/2016 10:49 AM, Rob Herring wrote:
> On Tue, May 24, 2016 at 04:34:50PM -0700, Frank Rowand wrote:
>> On 5/24/2016 11:32 AM, 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.
> 
> No, we don't.
> 
>>>
>>
>> The time for the use case was when the patch was accepted.
> 
> Ideally, yes, but things getting missed in review or later deciding 
> things were a bad idea can always be debated again.
> 
>> It is in the kernel, it is appropriate to document it.
> 
> Things get undocumented all the time when we deprecate them.

If it is deprecated then it should be documented as deprecated so
people do not attempt to use it.

> 
> Rob
> 

[toc] | [prev] | [next] | [standalone]

#1407162 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

On Wed, May 25, 2016 at 11:06:46AM -0700, Frank Rowand wrote:
> On 5/25/2016 10:49 AM, Rob Herring wrote:

> > Things get undocumented all the time when we deprecate them.

> If it is deprecated then it should be documented as deprecated so
> people do not attempt to use it.

Or we could just remove the code, we don't appear to have any in tree
users anyway (the few in tree aliases for SPI buses I can see are string
based).

[toc] | [prev] | [next] | [standalone]

#1407325 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

On 05/25/2016 08:44 PM, Mark Brown wrote:
> On Wed, May 25, 2016 at 11:06:46AM -0700, Frank Rowand wrote:
>> On 5/25/2016 10:49 AM, Rob Herring wrote:
> 
>>> Things get undocumented all the time when we deprecate them.
> 
>> If it is deprecated then it should be documented as deprecated
>> so people do not attempt to use it.
> 
> Or we could just remove the code, we don't appear to have any in
> tree users anyway (the few in tree aliases for SPI buses I can see
> are string based).

Lovely.  "Here's something that's simple and useful for users.  Let's
break it".  What part of "we do not break userspace" do you not
understand?  Because that would be a user visible change.

  /Christer

[toc] | [prev] | [next] | [standalone]

#1407329

On Wed, May 25, 2016 at 8:10 PM, Christer Weinigel <christer@weinigel.se> wrote:
> On 05/25/2016 08:44 PM, Mark Brown wrote:
>> On Wed, May 25, 2016 at 11:06:46AM -0700, Frank Rowand wrote:
>>> On 5/25/2016 10:49 AM, Rob Herring wrote:
>>
>>>> Things get undocumented all the time when we deprecate them.
>>
>>> If it is deprecated then it should be documented as deprecated
>>> so people do not attempt to use it.
>>
>> Or we could just remove the code, we don't appear to have any in
>> tree users anyway (the few in tree aliases for SPI buses I can see
>> are string based).
>
> Lovely.  "Here's something that's simple and useful for users.  Let's
> break it".  What part of "we do not break userspace" do you not
> understand?  Because that would be a user visible change.

The other saying is "if it is not upstream, it doesn't exist." That
said, I don't think we should remove it. Maybe some time later, but
first we need a suitable alternative.

Rob

[toc] | [prev] | [next] | [standalone]

#1407335 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

On 05/26/2016 03:44 AM, Rob Herring wrote:
> Lovely. "Here's something that's simple and useful for users. Let's 
> break it". What part of "we do not break userspace" do you not 
> understand? Because that would be a user visible change.
> The other saying is "if it is not upstream, it doesn't exist." That
> said, I don't think we should remove it. Maybe some time later, but
> first we need a suitable alternative.
Huh?  Commit bb29785e0d6d, which added support for assigning spi bus 
numbers via devicetree aliases, has been in the upstream Linux kernel 
since v3.9 which was released over three years ago.

   /Christer

-- 
Have laptop, will travel.  I'm a consultant looking for interesting
jobs anywhere in the world.  I'm an experienced software engineer with
a solid understanding of hardware.  Specialities: Linux, device
drivers and embedded systems in general.  Find me at www.weinigel.se.

[toc] | [prev] | [next] | [standalone]

#1407499 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

On Thu, May 26, 2016 at 03:56:11AM +0200, Christer Weinigel wrote:
> On 05/26/2016 03:44 AM, Rob Herring wrote:
> > Lovely. "Here's something that's simple and useful for users. Let's
> > break it". What part of "we do not break userspace" do you not
> > understand? Because that would be a user visible change.

You'll notice I've not actually posted this patch...

> > The other saying is "if it is not upstream, it doesn't exist." That
> > said, I don't think we should remove it. Maybe some time later, but
> > first we need a suitable alternative.

My inclination is to leave it unless we think of and implement something
better to do (like using labels), except possibly for paying attention
to string based aliases too.  Or perhaps we want to just treat all
aliases as strings.

> Huh?  Commit bb29785e0d6d, which added support for assigning spi bus numbers
> via devicetree aliases, has been in the upstream Linux kernel since v3.9
> which was released over three years ago.

I think Rob's referring to the fact that there are no in tree DTs that
use this feature - all the aliases for SPI controllers in mainline are
string based.

[toc] | [prev] | [next] | [standalone]

#1407518 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

On 05/26/2016 12:07 PM, Mark Brown wrote:
> I think Rob's referring to the fact that there are no in tree DTs
> that use this feature - all the aliases for SPI controllers in
> mainline are string based.

One of the main drivers behind devicetree was that Linus got fed up
with the churn for all platform device changes in arch/arm.  I faintly
recall him writing that he would be rather unhappy if that just got
replaced with churn for devicetree dts files.

It makes sense to include dts files for reference boards in the
mainline kernel.  To include dts files for every vendors variant of a
design would add just as much churn and be rather pointless.  My guess
is that the dts file for most platforms are kept private.

For platforms based on a FPGA such as the Xilinx Zync it's even more
pointless to submit dts files to mainline.  When you have "hardware"
that can be reconfigured the device tree files can't be set in stone.
 If I use Xilinx tools [1] to add one more UART I have just added new
hardware this needs to be reflected in the devicetree for the devices
to be usable in Linux.  And something like aliases which provides a
stable device name can be very useful here.

  /Christer

[1] http://www.wiki.xilinx.com/Build+Device+Tree+Blob

[toc] | [prev] | [next] | [standalone]

#1407670 — Re: [PATCH] devicetree - document using aliases to set spi bus number.

[Multipart message — attachments visible in raw view] — view raw

On Thu, May 26, 2016 at 12:58:22PM +0200, Christer Weinigel wrote:

> One of the main drivers behind devicetree was that Linus got fed up
> with the churn for all platform device changes in arch/arm.  I faintly
> recall him writing that he would be rather unhappy if that just got
> replaced with churn for devicetree dts files.

Since device trees are hardware descriptions they really shouldn't be
churning at all - if they are that's an indication that we're failing at
device tree.

> It makes sense to include dts files for reference boards in the
> mainline kernel.  To include dts files for every vendors variant of a
> design would add just as much churn and be rather pointless.  My guess
> is that the dts file for most platforms are kept private.

Well, a huge proportion of platforms don't work with upstream or upgrade
kernel versions at all but rather use vendor BSPs with all sorts of fun
stuff that the broader community would question strongly.  It's really
quite muddy.

> For platforms based on a FPGA such as the Xilinx Zync it's even more
> pointless to submit dts files to mainline.  When you have "hardware"
> that can be reconfigured the device tree files can't be set in stone.
>  If I use Xilinx tools [1] to add one more UART I have just added new
> hardware this needs to be reflected in the devicetree for the devices
> to be usable in Linux.  And something like aliases which provides a
> stable device name can be very useful here.

Right, but it doesn't follow that aliases are what we should be doing
here - both Rob and myself have mentioned providing a way to label the
actual SPI devices themselves, this seems like a more robust way of
doing things.  For example in a FPGA environment it would allow you to 
keep names stable even if you decide to reorganize the distribution of
devices between controllers or mappings of chip selects and would have
similar benefits for handling board variants.  Just numbering the buses
provides a partial solution for some systems with usability drawbacks
(you need to know the number to name mapping somehow), naming devices
is both more direct and more general.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web