Message-ID: <E2F727E460ACE497+3eb0af61-5175-47f1-a2f2-4bae7471b916@radxa.com>
Date: Fri, 19 Sep 2025 19:21:10 +0900
From: FUKAUMI Naoki <naoki@...xa.com>
To: Heiko Stübner <heiko@...ech.de>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Ed W <lists@...dgooses.com>
Subject: Re: [PATCH 1/2] arm64: dts: rockchip: correct uart mux for Radxa
 ZERO3

On 9/19/25 19:17, Heiko Stübner wrote:
> Am Freitag, 19. September 2025, 01:57:57 Mitteleuropäische Sommerzeit schrieb FUKAUMI Naoki:
>> 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:
>>>> 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,
>>>>>
>>>>
>>>>
>>>> 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.
> 
> yes, exactly
> So patches for the other header peripherals welcome :-) .
> 
> But still it's nice to do it in steps like this one, as it makes reviewing easier.

I agree.

Best regards,

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

> 
> 
> Heiko
> 
> 
> 

Powered by blists - more mailing lists