From: Christian Lamparter <chunkeey@gmail.com>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Brian Norris <briannorris@chromium.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
swboyd@chromium.org, Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH] dt-bindings: Add bindings for aliases node
Date: Fri, 12 Oct 2018 18:31:11 +0200 [thread overview]
Message-ID: <1626442.UsWqDEgn3j@debian64> (raw)
In-Reply-To: <20181012000837.GP22824@google.com>
On Friday, October 12, 2018 2:08:37 AM CEST Matthias Kaehlcke wrote:
> Maybe the doc should include a recommendation to use aliases
> sparingly? I'm open to input on that from folks who have a better
> understanding of the potential pitfalls
I had a similar discussion with the OpenWrt devs over the
use of "led-$function" aliases in a DTS. I did a bit of digging and
found this wonderful emails from Mark Rutland regarding the general
use and abuse of aliases in a reply to a patch by Christer Weinigel
"devicetree - document using aliases to set spi bus number."
<https://patchwork.kernel.org/patch/9133903/#19207021>
|"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."
And he followed it up with a summary:
<https://patchwork.kernel.org/comment/19207071/>
|Typically, serial ports are much more user-accessible (physically), and
|much more directly useful to a user in a generic fashion. They're often
|labelled (physically or in a manual) with a number, and we use aliases
|to describe those labels to the kernel. The fact that the kernel may use
|that to drive its own internal numbering is immaterial to the binding.
So the gist of this is that aliases are meant for user-accessible /
physically devices/ports/etc... that are labeled as such. And this of
course works perfectly for power/status LEDs and such because they
usually have little "power" symbols/pictograms/lables near them.
next prev parent reply other threads:[~2018-10-12 16:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180925210255.172734-1-mka@chromium.org>
2018-10-09 1:07 ` [PATCH] dt-bindings: Add bindings for aliases node Brian Norris
2018-10-09 7:22 ` Geert Uytterhoeven
2018-10-09 18:31 ` Brian Norris
2018-10-12 0:08 ` Matthias Kaehlcke
2018-10-12 16:31 ` Christian Lamparter [this message]
2018-10-15 18:00 ` Rob Herring
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=1626442.UsWqDEgn3j@debian64 \
--to=chunkeey@gmail.com \
--cc=briannorris@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.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;
as well as URLs for NNTP newsgroup(s).