From: Ed W <lists@wildgooses.com>
To: "FUKAUMI Naoki" <naoki@radxa.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO3
Date: Fri, 19 Sep 2025 10:28:54 +0100 [thread overview]
Message-ID: <da24e503-cb43-45e7-99ff-38eab11a203b@wildgooses.com> (raw)
In-Reply-To: <0DB47BC84E90B0E6+694b1274-4826-4ec1-9aa2-ca8aa790f61a@radxa.com>
On 19/09/2025 00:57, FUKAUMI Naoki wrote:
> Hi Heiko, Ed,
>
> On 9/19/25 01:18, Heiko Stübner wrote:
>> Am Donnerstag, 18. September 2025, 17:23:04 Mitteleuropäische Sommerzeit schrieb Ed W:
>>> Personally, and I'm saying this as a user who is technical enough to fix the definitions, it
>>> took me
>>> quite a few days to figure out what was wrong with the definitions and understand the intricate
>>> tree
>>> of dtsi includes, to finally figure out why I couldn't just do a "status = "okay";" to enable the
>>> UARTs... (which is roughly what is shown in several radxa supplied overlays to enable uarts on
>>> various boards)
>>>
>>> So my vote would be to correctly define all the hardware for a given board. Then users can
>>> simply do
>>> a status="okay" to enable and off they go.
>>
>> And I'd agree with that argument. Setting up the needed pinctrl settings
>> for the peripherals described in the device documentation
>> ( https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface#gpio-interface )
>>
>> is the sensible thing to do. While keeping the peripherals itself disabled
>> and for the user to decide which peripheral to enable.
>
> I'm not strongly opposed to this policy, but I thought if you're going to do this, you should do
> it for everything, not just UARTs.
>
> Best regards,
>
> --
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
I would most definitely be in favour of doing this for all peripherals! Yes please!
I have a selection of Zero 3W and E devices here. We are going to potentially use them in an OEM
capacity, and I might have some I2C devices to plug into them in the future, and for example would
like to get the I2C working on the pins (is it 2 and 4?). It will be at least some weeks before I
can work on that, but if you want to offer some support to fixup at least that device I won't decline!
Thanks for making these boards
Ed W
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-09-19 9:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 11:49 [PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs Ed Wildgoose
2025-09-17 11:49 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3 Ed Wildgoose
2025-09-18 4:53 ` FUKAUMI Naoki
2025-09-18 15:23 ` Ed W
2025-09-18 16:18 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO3 Heiko Stübner
2025-09-18 23:57 ` FUKAUMI Naoki
2025-09-19 9:28 ` Ed W [this message]
2025-09-19 10:17 ` Heiko Stübner
2025-09-19 10:21 ` FUKAUMI Naoki
2025-09-19 0:13 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3 FUKAUMI Naoki
2025-09-20 8:14 ` Jonas Karlman
2025-09-17 11:49 ` [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property Ed Wildgoose
2025-09-17 12:22 ` Dragan Simic
2025-09-17 14:25 ` Heiko Stübner
2025-09-18 9:32 ` [PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs v2 Ed Wildgoose
2025-09-18 9:32 ` [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3 Ed Wildgoose
2025-09-18 9:32 ` [PATCH 2/2] rockchip: dts: Enable UART DMA by adding default dma-names property Ed Wildgoose
2025-09-18 16:22 ` Heiko Stübner
2025-09-18 16:20 ` [PATCH 0/2] arm64: dts: rockchip: fix dma and pinctrl defs v2 Heiko Stübner
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=da24e503-cb43-45e7-99ff-38eab11a203b@wildgooses.com \
--to=lists@wildgooses.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=naoki@radxa.com \
--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