From: Patrick Williams <patrick@stwcx.xyz>
To: Andrew Jeffery <andrew@codeconstruct.com.au>
Cc: openbmc <openbmc@lists.ozlabs.org>,
Andrew Geissler <geissonator@gmail.com>
Subject: Re: Proposed deprecation of device-tree-gpio-naming.md
Date: Tue, 12 Aug 2025 17:14:17 -0400 [thread overview]
Message-ID: <aJuuqQxqOeuBYhmg@heinlein> (raw)
In-Reply-To: <eff663ee55f2614dde750f5f0669ec876f107c0d.camel@codeconstruct.com.au>
[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]
On Wed, Aug 06, 2025 at 09:24:37AM +0930, Andrew Jeffery wrote:
> Devicetrees represent the hardware, and from experience
> over time I think it's best that they reflect the information from the
> schematics without influence from software implementation choices.
Can you elaborate on what this experience is? I'm not sure what this is
referring to or what issues you've observed with it.
Devicetrees do often represent the hardware but they don't just represent the
hardware. For example, we have the flash layout in there. That's
strictly a software function that has no connection to the hardware
(except for the flash size itself). I'm not convinced we have enough
words as to why it is okay to specify the flash layout but not okay to
represent the intended purpose of a GPIO.
If GPIO names were to reflect the "information from the schematics", I
assume this is to mean the net-name? Which net-name are we going to
use? The one on the DC-SCM, the one on the connector the DC-SCM is
plugged into, etc. There are probably, on average, 4 different names
from a source of a signal to the BMC.
You could of course say "whatever the person implementing the devicetree
wants" for the pin name, but usually that's the least useful name to
anyone else. On top of that, schematics are often times closed and
unavailable to more than a handful of people. Having a devicetree named
"power-sequence-start" is way better than "DC_SCM_GPIO_P7", right?
Sure, we can have this translation in entity-manager or wherever, if
someone contributes the entity-manager config for their board. But,
that means it's only available to BMC code. When I'm actively debugging
something, I have yet another hoop to jump through to go from
"DC_SCM_GPIO_P7" to "this is the power sequence start". If it is in the
device tree it shows up right in "gpioinfo".
> However, perhaps it's still a reasonable set of suggestions for
> consumption of pins with the translation from net names done by the
> applications themselves?
I think it is.
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-08-12 21:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 23:54 Proposed deprecation of device-tree-gpio-naming.md Andrew Jeffery
2025-08-06 19:21 ` Andrew Geissler
2025-08-07 0:01 ` Andrew Jeffery
2025-08-12 21:14 ` Patrick Williams [this message]
2025-08-13 1:03 ` Andrew Jeffery
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=aJuuqQxqOeuBYhmg@heinlein \
--to=patrick@stwcx.xyz \
--cc=andrew@codeconstruct.com.au \
--cc=geissonator@gmail.com \
--cc=openbmc@lists.ozlabs.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.