| 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
| ||
|
Message-ID: <C6253E8254C80B0F+839b71d0-1bd8-40b7-9515-7ce4a1eb8673@airkyi.com>
Date: Thu, 30 Oct 2025 10:16:45 +0800
From: Chaoyi Chen <kernel@...kyi.com>
To: Peter Chen <hzpeterchen@...il.com>,
Chaoyi Chen <chaoyi.chen@...k-chips.com>
Cc: Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>, Heiko Stuebner
<heiko@...ech.de>, Sandy Huang <hjc@...k-chips.com>,
Andy Yan <andy.yan@...k-chips.com>,
Yubing Zhang <yubing.zhang@...k-chips.com>,
Frank Wang <frank.wang@...k-chips.com>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Amit Sunil Dhamne <amitsd@...gle.com>, Dragan Simic <dsimic@...jaro.org>,
Johan Jonker <jbx6244@...il.com>, Diederik de Haas <didi.debian@...ow.org>,
Peter Robinson <pbrobinson@...il.com>, linux-usb@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-phy@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v8 10/10] arm64: dts: rockchip: rk3399-evb-ind: Add
support for DisplayPort
Hi Peter,
On 10/30/2025 9:34 AM, Peter Chen wrote:
> On Wed, Oct 29, 2025 at 6:32 PM Chaoyi Chen <chaoyi.chen@...k-chips.com> wrote:
>> On 10/29/2025 6:21 PM, Chaoyi Chen wrote:
>>
>>> Hi Peter,
>>>
>>> On 10/29/2025 5:45 PM, Peter Chen wrote:
>>>>> +&i2c4 {
>>>>> + i2c-scl-rising-time-ns = <475>;
>>>>> + i2c-scl-falling-time-ns = <26>;
>>>>> + status = "okay";
>>>>> +
>>>>> + usbc0: typec-portc@22 {
>>>>> + compatible = "fcs,fusb302";
>>>>> + reg = <0x22>;
>>>>> + interrupt-parent = <&gpio1>;
>>>>> + interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&usbc0_int>;
>>>>> + vbus-supply = <&vbus_typec>;
>>>>> +
>>>>> + usb_con: connector {
>>>>> + compatible = "usb-c-connector";
>>>>> + label = "USB-C";
>>>>> + data-role = "dual";
>>>>> + power-role = "dual";
>>>>> + try-power-role = "sink";
>>>>> + op-sink-microwatt = <1000000>;
>>>>> + sink-pdos =
>>>>> + <PDO_FIXED(5000, 2500, PDO_FIXED_USB_COMM)>;
>>>>> + source-pdos =
>>>>> + <PDO_FIXED(5000, 1500, PDO_FIXED_USB_COMM)>;
>>>>> +
>>>>> + altmodes {
>>>>> + displayport {
>>>>> + svid = /bits/ 16 <0xff01>;
>>>>> + vdo = <0x00001c46>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + ports {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> +
>>>>> + port@0 {
>>>>> + reg = <0>;
>>>>> +
>>>>> + usbc_hs: endpoint {
>>>>> + remote-endpoint = <&u2phy0_typec_hs>;
>>>>> + };
>>>>> + };
>>>>> +
>>>> Why USB2 PHY needs to be notified for Type-C connection?
>>> I think the USB-connector binding require a port@0 for High Speed. So I filled in USB2 PHY here. And I have looked up boards with the same usage, and some of the results are as follows:
>>>
>>> - rk3399-firefly.dts
>>>
>>> - rk3399-pinebook-pro.dts
>>>
>>> - rk3399-eaidk-610.dts
>>>
> Okay. My question is basic: USB2 PHY supplies DP/DM, and the DP/DM is
> short for Type-C connector,
> and no control is needed for Type-C application.
> Why is there a remote-endpoint connection between USB2 PHY and Type-C connector?
From the perspective of Type-C, this should not be added. Is the approach in v2 correct [0] ?
[0]: https://lore.kernel.org/all/20250715112456.101-6-kernel@airkyi.com/
Or is the following approach correct?
port@0 {
reg = <0>;
usbc_hs: endpoint {
remote-endpoint = <&tcphy0>;
};
};
port@1 {
reg = <1>;
usbc_ss: endpoint {
remote-endpoint = <&tcphy0>;
};
};
port@2 {
reg = <2>;
usbc_dp: endpoint {
remote-endpoint = <&tcphy0_typec_dp>;
};
};
>
>>>>> + port@1 {
>>>>> + reg = <1>;
>>>>> +
>>>>> + usbc_ss: endpoint {
>>>>> + remote-endpoint = <&tcphy0_typec_ss>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + port@2 {
>>>>> + reg = <2>;
>>>>> +
>>>>> + usbc_dp: endpoint {
>>>>> + remote-endpoint = <&tcphy0_typec_dp>;
>>>>> + };
>>>>> + };
>>>>> + };
>>>>> + };
>>>>> + };
>>>>> +};
>>>>> +
>>>> .....
>>>>> &u2phy0 {
>>>>> status = "okay";
>>>>> +
>>>>> + port {
>>>>> + u2phy0_typec_hs: endpoint {
>>>>> + remote-endpoint = <&usbc_hs>;
>>>>> + };
>>>>> + };
>>>>> };
>>>>>
>>>> There is no switch and mux, how to co-work with Type-C?
>>> I checked the phy-rockchip-inno-usb2.c but did not find any switch or mux. Does this mean that we need to implement them? Thank you.
>> Wait a minute, actually we have multiple hardware interfaces, one of which is Type-C, eventually connected to USBDPPHY, and the other is micro-usb connected to U2PHY.
> I assume the Micro-USB connector does not use Type-C/PD IC, is it
> right? Does it relate to this patch?
>
> Best regards,
> Peter
>
Powered by blists - more mailing lists