| 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: <oel3t35pxegxaowcfjbrzrxvuw47p7pzcinz7kf2uj2ivcderv@efbttlqpwcc7>
Date: Tue, 2 Sep 2025 15:22:17 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Neil Armstrong <neil.armstrong@...aro.org>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>, 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>,
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>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-phy@...ts.infradead.org
Subject: Re: [PATCH v2 3/5] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy:
Document static lanes mapping
On Tue, Sep 02, 2025 at 12:05:45PM +0200, Neil Armstrong wrote:
> On 02/09/2025 11:46, Dmitry Baryshkov wrote:
> > On Tue, Sep 02, 2025 at 11:35:25AM +0200, Neil Armstrong wrote:
> > > On 02/09/2025 11:30, Dmitry Baryshkov wrote:
> > > > On Tue, Sep 02, 2025 at 11:00:30AM +0200, Neil Armstrong wrote:
> > > > > The QMP USB3/DP Combo PHY hosts an USB3 phy and a DP PHY on top
> > > > > of a combo glue to route either lanes to the 4 shared physical lanes.
> > > > >
> > > > > The routing of the lanes can be:
> > > > > - 2 DP + 2 USB3
> > > > > - 4 DP
> > > > > - 2 USB3
> > > > >
> > > > > The layout of the lanes was designed to be mapped and swapped
> > > > > related to the USB-C Power Delivery negociation, so it supports
> > > > > a finite set of mappings inherited by the USB-C Altmode layouts.
> > > > >
> > > > > Nevertheless those QMP Comby PHY can be statically used to
> > > > > drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector,
> > > > > etc... without an USB-C connector and no PD events.
> > > > >
> > > > > Add a property that documents the static lanes mapping to
> > > > > each underlying PHY to allow supporting boards directly
> > > > > connecting USB3 and DisplayPort lanes to the QMP Combo
> > > > > lanes.
> > > > >
> > > > > Signed-off-by: Neil Armstrong <neil.armstrong@...aro.org>
> > > > > ---
> > > > > .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++
> > > > > 1 file changed, 29 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > > index c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644
> > > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > > @@ -76,6 +76,35 @@ properties:
> > > > > mode-switch: true
> > > > > orientation-switch: true
> > > > > + qcom,static-lanes-mapping:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > > + minItems: 4
> > > > > + items:
> > > > > + enum:
> > > > > + - 0 # Unconnected (PHY_NONE)
> > > > > + - 4 # USB3 (PHY_TYPE_USB3)
> > > > > + - 6 # DisplayPort (PHY_TYPE_DP)
> > > > > + description:
> > > > > + Describes the static mapping of the Combo PHY lanes, when not used
> > > > > + a in a Type-C dynamic setup using USB-C PD Events to change the mapping.
> > > > > + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY.
> > > > > + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can
> > > > > + be connected to the DP PHY.
> > > >
> > > > It feels like this significantly duplicates existing data-lanes
> > > > definitions. Can we use that property to express the same semantics?
> > >
> > > Well yes it has the same semantics, but not really the same meaning. data-lanes is designed
> > > to describes the lanes layout/ordering, not the type/mapping.
> > >
> > > Here, we do not describe the ordering, i.e which source lane is connected to which endpoint splot,
> > > but which lane is supposed to connect to which internal PHY.
> > >
> > > Anyway, I'm open to suggestions.
> >
> > phy@...def {
> > ports {
> > port@1 {
> > endpoint {
> > remote-endpoint = <&&usb_1_dwc3_ss>;
> > data-lanes = <2 3>;
> > };
> > };
> >
> > port@2 {
> > endpoint {
> > remote-endpoint = <&mdss_dp0_out>;
> > data-lanes = <1>;
> > };
> > };
> > };
> > };
> >
> > phy@...ecafe {
> > ports {
> > port@1 {
> > endpoint {
> > remote-endpoint = <&&usb_1_dwc3_ss>;
> > status = "disabled";
> > };
> > };
> >
> > port@2 {
> > endpoint {
> > remote-endpoint = <&mdss_dp0_out>;
> > data-lanes = <2 3 0 1>;
> > };
> > };
> > };
> > };
>
> This is wrong, those are the internal connections to the controllers,
> those are fixed. I'm speaking about the external lanes, but there's only
> a single port.
>
> So, following your suggestion, we should use the Output port 0, but as it's
> only a single port it would need to have 2 endpoints, one for USB3 and one for
> DP.
>
> For example:
>
> \{
> dp-connector {
> compatible = "dp-connector";
> type = "a";
>
> port {
> dp_con: endpoint {
> remote-endpoint = <&usb_1_ss2_qmpphy_dp_out>;
> };
> };
> };
>
> usb-a-connector {
> compatible = "usb-a-connector";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> usb_con_hs: endpoint {
> remote-endpoint = <&usb_1_ss2_dwc3_hs>;
> };
> };
>
> port@1 {
> reg = <1>;
> usb_con_ss: endpoint {
> remote-endpoint = <&usb_1_ss2_qmpphy_usb3_out>;
> };
> };
> };
> };
>
> };
>
> &usb_1_ss2_dwc3_hs {
> remote-endpoint = <&usb_1_ss2_dwc3_hs>;
> };
>
> &usb_1_ss2_qmpphy {
> /delete-property/ mode-switch;
> /delete-property/ orientation-switch;
>
> ports {
>
> port@0{
> #address-cells = <1>;
> #size-cells = <0>;
>
> /delete-node/ endpoint;
>
> usb_1_ss2_qmpphy_usb3_out: endpoint@0 {
> reg = <0>;
>
> remote-endpoint = <&usb_con_ss>;
>
> data-lanes = <1 2 0 0>;
> };
>
> usb_1_ss2_qmpphy_dp_out: endpoint@1 {
> reg = <1>;
>
> remote-endpoint = <&dp_con>;
>
> data-lanes = <0 0 1 2>;
> };
> };
> };
> };
>
> So the driver logic would need to look at the port0/endpoint0 and port0/endpoint1
> data-lanes to figure out the mode.
>
> Is this what you were thinking ?
No, I was really thinking about the data-lanes in the PHY parts, so I
was incorrect there (which is incrrect as you've pointed out).
The endpoints approach looks interesting though.
--
With best wishes
Dmitry
Powered by blists - more mailing lists