linux-kernel - Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <F1C5CEF8D2933380+98b20449-12bb-4697-84e0-40fd8c2ed81f@radxa.com>
Date: Fri, 19 Sep 2025 09:13:51 +0900
From: FUKAUMI Naoki <naoki@...xa.com>
To: Ed W <lists@...dgooses.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa ZERO
 3

Hi Ed,

On 9/19/25 00:23, Ed W wrote:
> On 18/09/2025 05:53, FUKAUMI Naoki wrote:
>> Hi Ed,
>>
>> Thank you very much for your work.
>>
>> On 9/17/25 20:49, Ed Wildgoose wrote:
>>> The rk3566 has multiplexed pins and the uarts can be moved to a choice
>>> of 2 pin groups. The default rk356x-base.dtsi appears to default to mux0
>>> for all uarts, however, specific hardware might choose to implement
>>> alternatives
>>>
>>> The Radxa zero 3 shows that is uses M1 for uarts:
>>> - uart4
>>> - uart5
>>> - uart9
>>>
>>> These aren't normally enabled, but we should at least correct the
>>> default pinctrl definitions. Without these changes there will be
>>> conflicts with mmc0/mmc1, leading to the SD or eMMC going missing.
>>
>> Sorry, but why do we need these definitions for disabled nodes?
>>
>> Or why don't we do similar definitions for nodes other than uart?
>> For example, PWM12, I2S3, and SPI3 also use M1. Are they not related to SD/eMMC and therefore
>> don't need to be defined?
>>
>> If users want to use UARTs on pin headers, they will refer to the correct documentation[1] to
>> determine which pins are UARTs and will of course write the correct pinctrl definition.
>>
>> [1] https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface#gpio-interface
>>
>> Best regards,
>>
>> -- 
>> FUKAUMI Naoki
>> Radxa Computer (Shenzhen) Co., Ltd.
> 
> 
> 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. Phrased another way, I can't see a disadvantage in doing
> this, rather than leaving broken definitions in place which don't work correctly. Ideally I think
> you should add at least the I2C defs as well, as that is something I would like to use for another
> reason and haven't even got to the point of discovering that was broken?
> 
> I might also (gently) add that it was not easy to find all the documentation to fix this. I located
> the datasheet for the Zero 3 via google (it's not obviously available on the wiki?), then there is
> the reading through and I must admit I missed the multiplex difference the first few reads through.
> Eventually I fed the docs into a LLM and it pointed out what I missed and we got there

In addition to docs.radxa.com, we also distribute some PDFs on the 
following pages:

  https://radxa.com/products/zeros/zero3e#downloads
  https://radxa.com/products/zeros/zero3w#downloads

All information should be linked from the product pages (e.g. 
https://radxa.com/products/zeros/zero3e), but if something is missing, 
please report the issue by clicking "Report issue" at the bottom of each 
page on docs.radxa.com.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> So in summary, I'm hoping you will adjust the (really very well structured! thanks!) dtsi include
> tree to correctly define all hardware on each board so that we don't have a situation that every
> user in the world needs to be a really decent level kernel tech just to use the board! Pretty please!
> 
> Thanks for listening
> 
> Ed W
> 
> 
>