From: E Shattow <e@freeshell.de>
To: Owen O'Hehir <oo.hehir@gmail.com>,
Conor Dooley <conor@kernel.org>,
Emil Renner Berthing <kernel@esmil.dk>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: dts: starfive: jh7110-common: keep the status power LED on
Date: Fri, 6 Nov 2026 12:30:44 -0800 [thread overview]
Message-ID: <d051c5f2-3df2-4eeb-b324-6e9ce39a6b27@freeshell.de> (raw)
In-Reply-To: <20261106195945.4157095-1-oo.hehir@gmail.com>
Hi Owen,
On 11/6/26 11:59, Owen O'Hehir wrote:
> Hi E,
>
> Thanks for checking. You're right about the commit message: I saw the
> LED lit before Linux probes and assumed the firmware set it, without
> checking where it comes from.
>
> On the Lite, the schematic (sheet 21) shows RGPIO3 driving the system
> LED and also used for fastboot detection, through jumper J20 that pulls
> it to 1.8 V via R257 (1k). Detection happens at reset, before Linux,
No, the software is not any concern for a hardware description.
> and R257 limits the current whichever level the pin is driven to
> afterwards, so I don't think driving it high conflicts there.
>
> Owen
It may or may not conflict in software operation but that has nothing to
do with if it should be applied to device tree that describes hardware.
Conor since applied, which is trusting you researched this correctly
before sending to the list. I'm saying that all things being good in
intention this is obviously not well researched, and not allowing for
discussion to verify the fix before applying.
Anyways it is a user light not a power LED. Pine64 Star64 has a power
LED and this user LED. If a board does not have power LED then co-opting
the user LED is something that should be done in inittab not treating
upstream device tree as a preferences config file for userland.
-E
next prev parent reply other threads:[~2026-11-06 20:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 18:40 Owen O'Hehir
2026-11-06 18:51 ` E Shattow
2026-11-06 19:59 ` Owen O'Hehir
2026-11-06 20:30 ` E Shattow [this message]
2026-11-06 21:12 ` Owen O'Hehir
2026-11-06 21:13 ` Owen O'Hehir
2026-11-06 18:54 ` Conor Dooley
2026-11-06 19:06 ` E Shattow
2026-11-06 21:15 ` Conor Dooley
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=d051c5f2-3df2-4eeb-b324-6e9ce39a6b27@freeshell.de \
--to=e@freeshell.de \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@esmil.dk \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=oo.hehir@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=robh@kernel.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
all inboxes | Powered by JetHome®