linux-kernel - Re: [PATCH v8 10/10] arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort

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: <e2fcc437-0650-4fdf-bb75-3463a80299fe@rock-chips.com>
Date: Thu, 30 Oct 2025 14:50:33 +0800
From: Chaoyi Chen <chaoyi.chen@...k-chips.com>
To: Peter Chen <hzpeterchen@...il.com>
Cc: Chaoyi Chen <kernel@...kyi.com>,
 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

On 10/30/2025 2:13 PM, Peter Chen wrote:

> On Thu, Oct 30, 2025 at 11:14 AM Chaoyi Chen <chaoyi.chen@...k-chips.com> wrote:
>> On 10/30/2025 10:50 AM, Peter Chen wrote:
>>
>>>>> 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] ?
>>>>
>>> Have you tried debugging based on upstream code?
>> Yes, I have tried both the v2 and v8 approaches, and both can work.
>>
>>
>>> v2 is correct, but the dts needs to improve.
>>> - There is a remote-endpoint connection for USB role switch between
>>> Type-C connector
>>> device and USB controller device
>>> - There is a remote-endpoint connection for orientation and lane configuration
>>> between Type-C connector device and USB/DP PHY device.
>> In v8 patch5, we implemented typec_mux and typec_switch in the USB/DP PHY.
>>
>> I think the current remote-endpoint connections are all child node of the USB/DP PHY. That is:
>>
>>
>> &tcphy0_dp {
>>       mode-switch;
>>       ...
>> };
>>
>>
>> &tcphy0_usb3 {
>>       orientation-switch;
>>       ...
>> };
>>
>>
>> Does this still need to be improved? Thank you.
>>
> Hi Chaoyi,
>
> There are two questions I have still not seen the answer to:
> - Why USB2 PHY is related to your Type-C patch?

I was just following other people's approach. Sorry, this should be removed from the dts.


> - How does the USB role switch event notify the USB controller driver, eg dwc3?

Sorry, I misunderstood what you said before. There is indeed a missing usb-role-switch now. I referred to the approach in rk3588-evb1-v10.dts. Is the following way of writing correct?

&usbc_connector {
     ports {
         #address-cells = <1>;
         #size-cells = <0>;

         port@0 {
             reg = <0>;

             usbc_orien_sw: endpoint {
                 remote-endpoint = <&tcphy0_typec_orien_sw>;
             };
         };

         port@1 {
             reg = <1>;

             usbc_role_sw: endpoint {
                 remote-endpoint = <&dwc3_0_role_switch>;
             };
         };


         port@2 {
             reg = <2>;

             usbc_dp: endpoint {
                 remote-endpoint = <&tcphy0_typec_dp>;
             };
         };
     };
};

&usbdrd_dwc3_0 {
     status = "okay";
     usb-role-switch;

     port {
         #address-cells = <1>;
         #size-cells = <0>;
         dwc3_0_role_switch: endpoint@0 {
             reg = <0>;
             remote-endpoint = <&usbc_role_sw>;
         };
     };
};

&tcphy0_usb3 {
     orientation-switch;

     port {
         tcphy0_typec_orien_sw: endpoint {
             remote-endpoint = <&usbc_orien_sw>;
         };
     };
};

&tcphy0_dp {
     mode-switch;

     port {
         #address-cells = <1>;
         #size-cells = <0>;

         tcphy0_typec_dp: endpoint@0 {
             reg = <0>;
             remote-endpoint = <&usbc_dp>;
         };
     };
};


> Peter
>>> Peter
>>>
>>>> [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
>>>>>
>> --
>> Best,
>> Chaoyi
>>
>
-- 
Best,
Chaoyi