linux-kernel - Re: [PATCH] arm64: dts: rockchip: rk3588-nanopc-t6: fix usb-c port functionality

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] [day] [month] [year] [list]

Message-Id: <20250422000748.59664-1-inindev@gmail.com>
Date: Mon, 21 Apr 2025 20:07:48 -0400
From: John Clark <inindev@...il.com>
To: sigmaris@...il.com
Cc: devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	robh@...nel.org,
	krzk+dt@...nel.org,
	conor+dt@...nel.org,
	heiko@...ech.de,
	mjuszkiewicz@...hat.com,
	sebastian.reichel@...labora.com,
	jonas@...boo.se,
	John Clark <inindev@...il.com>
Subject: Re: [PATCH] arm64: dts: rockchip: rk3588-nanopc-t6: fix usb-c port functionality

On Tue, Apr 22, 2025 at 00:12:02 +0100, Hugh Cole-Baker <sigmaris@...il.com> wrote:
> Hi John,
>
> On 19/04/2025 03:37, John Clark wrote:
>> The USB-C port on the NanoPC-T6 was not providing VBUS (vbus5v0_typec
>> regulator disabled, gpio-58 out lo) due to misconfiguration. The
>> original setup with regulator-always-on and regulator-boot-on forced
>> the port on, masking the issue, but removing these properties revealed
>> that the fusb302 driver was not enabling the regulator dynamically.
>>
>> Signed-off-by: John Clark <inindev@...il.com>
>> ---
>>  .../boot/dts/rockchip/rk3588-nanopc-t6.dtsi   | 21 ++++++++++---------
>>  1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> index cecfb788bf9e..8f2bd30786d9 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi
>> @@ -174,8 +174,6 @@ vbus5v0_typec: regulator-vbus5v0-typec {
>>  		gpio = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
>>  		pinctrl-names = "default";
>>  		pinctrl-0 = <&typec5v_pwren>;
>> -		regulator-always-on;
>> -		regulator-boot-on;
>>  		regulator-name = "vbus5v0_typec";
>> @@ -465,24 +461,30 @@ regulator-state-mem {
>>  &i2c6 {
>> -	clock-frequency = <200000>;
>>  	status = "okay";
>>
>> -	fusb302: typec-portc@22 {
>> +	usbc0: usb-typec@22 {
>>  		compatible = "fcs,fusb302";
>>  		connector {
>>  			compatible = "usb-c-connector";
>>  			data-role = "dual";
>>  			label = "USB-C";
>> -			power-role = "source";
>> +			/* fusb302 supports PD Rev 2.0 Ver 1.2 */
>> +			pd-revision = /bits/ 8 <0x2 0x0 0x1 0x2>;
>> +			power-role = "dual";
>> +			op-sink-microwatt = <1000000>;
>> +			sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
>>  			source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>;
>> +			try-power-role = "source";
>> +			typec-power-opmode = "3.0A";
>
> According to the manufacturer wiki [1] "Power Output Capacity" table, the USB-C
> port maximum output is 5V/2A. So I think "1.5A" would be a better value here.
>
> [1]: https://wiki.friendlyelec.com/wiki/index.php/NanoPC-T6

Hi Hugh,

Thank you for your feedback and for referencing the manufacturer’s wiki. To clarify, the line in question:

source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>;

was not modified in my patch. This value, which sets the USB-C port’s source capability to 5V/2A, is unchanged from the existing device tree.

Furthermore, the schematic for the NanoPC-T6 and the vendor’s upstream Linux device tree (e.g., FriendlyARM’s kernel at https://github.com/friendlyarm/kernel-rockchip/blob/nanopi6-v6.1.y/arch/arm64/boot/dts/rockchip/rk3588-nanopi6-rev01.dts#L346) also specify the source capability as 5V/2A. Given this consistency across the schematic and vendor sources, I believe 2A is an appropriate value for this configuration.

Please let me know if you have further concerns or suggestions!

Best regards,
John Clark