linux-kernel - Re: [PATCH 1/2] dt-bindings: usb: Introduce GPIO-based SBU mux

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]

Date:   Fri, 19 Aug 2022 17:00:57 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Prashant Malani <pmalani@...omium.org>
Cc:     Stephen Boyd <swboyd@...omium.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        Pin-yen Lin <treapking@...omium.org>
Subject: Re: [PATCH 1/2] dt-bindings: usb: Introduce GPIO-based SBU mux

On Fri 19 Aug 15:14 CDT 2022, Prashant Malani wrote:

> > This would do that for us, but when all four lanes are connected from
> > the qmp phy directly to the connector we could just as easily have done
> > it with one endpoint.
> >
> >         qmp_phy {
> >                 ports {
> >                         port@0 {
> >                                 reg = <0>;
> >                                 endpoint@0 {
> >                                         reg = <0>;
> >                                         remote-endpoint = <&usb_c_ss>;
> >                                         data-lanes = <1 2 3 0>
> >                                 };
> >                         };
> >                 };
> >         };
> >
> > So should we explicitly have two endpoints in the usb-c-connector for
> > the two pairs all the time, or should we represent that via data-lanes
> > and only split up the connector's endpoint if we need to connect the
> > usb-c-connector to two different endpoints?
> 
> I like 2 endpoints to represent the usb-c-connector, but that doesn't seem
> to be compatible (without introducing `data-lanes`, at least) with all
> the various
> combinations on the remote side, if that remote side is a DRM bridge with DP
> output capability (like it6505 or anx7625).
> That type of DRM bridge supports 1, 2 or 4 lane DP connections.
> 

You can't physically connect 1, 2 or 4 lanes of DP from a DP chip to
your usb-c-connector at the same time as you physically connect 0, 2 or
4 lanes of USB from a USB PHY.

You must either have another component inbetween, or you will connect
some predefined subset of those signals to each output.

In the case where you have a mux of some sort inbetween, that would be
the thing that the usb-c-connector's port@...ndpoint references.

In the case that you hardwire 2 SS lanes to USB and 2 to the DP
hardware, you could specify port@1 with two endpoints and the Type-C
controller would be able to signal both when to turn on/off their
signals. But you wouldn't be able to do orientation switching.

> So, how about 4 endpoints (1 for each SS lane) in the usb-c-connector port@1?
> That should support every conceivable configuration and bridge/PHY hardware.
> and also allows a way to specify any lane remapping (similar to what
> "data lanes" does)
> if that is required.

Wouldn't that prevent you from handling orientation switching, given
that the graph is static?

> Then we are consistent with what an endpoint represents, regardless of whether
> the DRM bridge has a DP panel (1,2 or 4 lane) or Type-C connector  (2
> or 4 lane) on its output side.

We can represent that perfectly fine with the proposed bindings.
In the USB Type-C case I have:

dp-controller {
    phys = <&qmp>;

    ports {
       dp_hpd: port@1 {
            endpoint = <&port_1_endpoint_1>;
        };
    };
};

qmp: qmp {
    port {
        qmp_out: endpoint {
            remote-endpoint = <&port_1_endpoint_0>;
        };
    };
};

connector {
    compatible = "usb-c-connector";
    ports {
        port@1 {
            port_1_endpoint_0: endpoint@0 {
                remote-endpoint = <&qmp_out>;
            };
            port_1_endpoint_1: endpoint@1 {
                remote-endpoint = <&dp_hpd>;
            };
        };
    };
};

The dp-controller binding is defined to have the output on port@1 and by
implementing a drm_bridge in the controller backing the connector it
will find that. The controller can use the links to inform the QMP about
muxing and orientation switching.

In the case of DP we have:

dp-controller {
    phys = <&dp_phy>;

    ports {
       dp_hpd: port@1 {
            endpoint = <&dp_connector>;
        };
    };
};

dp_phy: dp-phy {
    compatible = "qcom,dp-phy";
};

connector {
    compatible = "dp-connector";
    port {
        dp_connector: endpoint@0 {
            remote-endpoint = <&dp_hpd>;
        };
    };
};


The link between the dp_phy and the dp connector could be expressed
further, but this is a binding that already exists...

Regards,
Bjorn