| 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: <air5bftw42xfc3ikm3zmcd2u7jwjya3wkqgw6ojjpf3v6q2d4y@djmxtnhzosed>
Date: Thu, 24 Apr 2025 14:10:31 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Stephen Boyd <swboyd@...omium.org>
Cc: Tzung-Bi Shih <tzungbi@...nel.org>, linux-kernel@...r.kernel.org,
patches@...ts.linux.dev, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, devicetree@...r.kernel.org,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Rob Herring <robh@...nel.org>, linux-arm-msm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Conor Dooley <conor+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Lee Jones <lee@...nel.org>, Benson Leung <bleung@...omium.org>,
Guenter Roeck <groeck@...omium.org>, chrome-platform@...ts.linux.dev,
Pin-yen Lin <treapking@...omium.org>,
Abhishek Pandit-Subedi <abhishekpandit@...omium.org>,
Łukasz Bartosik <ukaszb@...omium.org>,
Jameson Thies <jthies@...gle.com>,
Andrei Kuchynski <akuchynski@...omium.org>
Subject: Re: [PATCH 5/7] dt-bindings: usb: google,cros-ec-typec: Add ports
for DP altmode
On Tue, Apr 15, 2025 at 05:02:05PM -0700, Stephen Boyd wrote:
> Add a DT graph binding to google,cros-ec-typec so that it can combine
> DisplayPort (DP) and USB SuperSpeed (SS) data into a USB type-c endpoint
> that is connected to the usb-c-connector node's SS endpoint. Allow there
> to be multiple 'typec' nodes underneath the EC node so that one DT graph
> exists per DP bridge. The EC is actually controlling TCPCs and redrivers
> that combine the DP and USB signals together so this more accurately
> reflects the hardware design without introducing yet another DT node
> underneath the EC for USB type-c "stuff".
>
> If the type-c ports are being shared between a single DP controller then
> the ports need to know about each other and determine a policy to drive
> DP to one type-c port or the other. If the type-c ports each have their
> own dedicated DP controller then they're able to operate independently
> and enter/exit DP altmode independently as well. We can't connect the DP
> controller's endpoint to one usb-c-connector port@1 endpoint and the USB
> controller's endpoint to another usb-c-connector port@1 endpoint either
> because the DP muxing case would have DP connected to two
> usb-c-connector endpoints which the graph binding doesn't support.
>
> Therefore, one typec node is required per the capabilities of the type-c
> port(s) being managed. Add a port to the DisplayPort altmode as well, so
> that we can show the connection between the DP controller and the DP
> altmode. This lets us indicate which type-c ports the DP controller is
> wired to. For example, if DP was connected to ports 0 and 2, while port
> 1 was connected to another DP controller we wouldn't be able to
> implement that without having some other DT property to indicate which
> output ports are connected to the DP endpoint.
>
> Furthermore, this supports ChromeOS designs like Corsola where a DP
> controller/PHY is split with two lanes going to one connector and the
> other two lanes going to another connector. In this case, we wouldn't
> have the graph binding under the cros-ec-typec node, but we would have
> the graph binding in the DP altmode directly connected to the DP
> controller's two output endpoints.
>
> Cc: Rob Herring (Arm) <robh@...nel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
> Cc: Conor Dooley <conor+dt@...nel.org>
> Acked-by: Lee Jones <lee@...nel.org>
> Cc: Benson Leung <bleung@...omium.org>
> Cc: Guenter Roeck <groeck@...omium.org>
> Cc: Tzung-Bi Shih <tzungbi@...nel.org>
> Cc: <devicetree@...r.kernel.org>
> Cc: <chrome-platform@...ts.linux.dev>
> Cc: Pin-yen Lin <treapking@...omium.org>
> Cc: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> Cc: Łukasz Bartosik <ukaszb@...omium.org>
> Cc: Jameson Thies <jthies@...gle.com>
> Cc: Andrei Kuchynski <akuchynski@...omium.org>
> Signed-off-by: Stephen Boyd <swboyd@...omium.org>
> ---
> .../bindings/connector/usb-connector.yaml | 6 +
> .../bindings/mfd/google,cros-ec.yaml | 7 +-
> .../bindings/usb/google,cros-ec-typec.yaml | 165 ++++++++++++++++++
> 3 files changed, 175 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 11e40d225b9f..e3d60997c03e 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -179,6 +179,12 @@ properties:
> $ref: /schemas/types.yaml#/definitions/uint32
> description: VDO returned by Discover Modes USB PD command.
>
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: OF graph bindings modeling a data bus to the
> + DisplayPort altmode from the DisplayPort controller. Used when
> + the altmode switch is part of the port manager.
Well......
> +
> port:
> $ref: /schemas/graph.yaml#/properties/port
> description: OF graph bindings modeling a data bus to the connector, e.g.
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index ac89696fa649..63d506e88abb 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -98,9 +98,6 @@ properties:
>
> gpio-controller: true
>
> - typec:
> - $ref: /schemas/usb/google,cros-ec-typec.yaml#
> -
> ec-pwm:
> $ref: /schemas/pwm/google,cros-ec-pwm.yaml#
> deprecated: true
> @@ -163,6 +160,10 @@ patternProperties:
> type: object
> $ref: /schemas/extcon/extcon-usbc-cros-ec.yaml#
>
> + "^typec(-[0-9])*$":
> + type: object
> + $ref: /schemas/usb/google,cros-ec-typec.yaml#
> +
> required:
> - compatible
>
> diff --git a/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml
> index 3272d0e01f7e..611345bbe884 100644
> --- a/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml
> @@ -26,6 +26,55 @@ properties:
> '#size-cells':
> const: 0
>
> + mux-gpios:
> + description: GPIOs indicating which way the DisplayPort mux is steered
> + minItems: 1
> + maxItems: 3
> +
> + no-hpd:
> + description: Indicates this device doesn't signal HPD for DisplayPort
> + type: boolean
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Port for DisplayPort (DP) data
> +
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: Input DP port
> +
> + patternProperties:
> + '^endpoint@[1-8]$':
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: Output to the usb-c connector's DP altmode
> +
> + required:
> + - endpoint@0
> +
> + anyOf:
> + - required:
> + - endpoint@1
> + - required:
> + - endpoint@2
> + - required:
> + - endpoint@3
> + - required:
> + - endpoint@4
> + - required:
> + - endpoint@5
> + - required:
> + - endpoint@6
> + - required:
> + - endpoint@7
> + - required:
> + - endpoint@8
> +
> patternProperties:
> '^connector@[0-9a-f]+$':
> $ref: /schemas/connector/usb-connector.yaml#
> @@ -35,10 +84,30 @@ patternProperties:
> required:
> - compatible
>
> +allOf:
> + - if:
> + required:
> + - no-hpd
> + then:
> + properties:
> + ports:
> + required:
> + - port@0
> + - if:
> + required:
> + - mux-gpios
> + then:
> + properties:
> + ports:
> + required:
> + - port@0
> +
> additionalProperties: false
>
> examples:
> - |+
> + #include <dt-bindings/gpio/gpio.h>
> +
> spi {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -47,6 +116,8 @@ examples:
> compatible = "google,cros-ec-spi";
> reg = <0>;
> interrupts = <35 0>;
> + #gpio-cells = <2>;
> + gpio-controller;
>
> typec {
> compatible = "google,cros-ec-typec";
> @@ -54,12 +125,106 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> + mux-gpios = <&cros_ec 42 GPIO_ACTIVE_HIGH>, <&cros_ec 3 GPIO_ACTIVE_HIGH>;
> +
> connector@0 {
> compatible = "usb-c-connector";
> reg = <0>;
> power-role = "dual";
> data-role = "dual";
> try-power-role = "source";
> +
> + altmodes {
> + displayport {
Should there be an svid / vdo definition?
> + port {
> + usbc0_dp: endpoint {
> + remote-endpoint = <&dp_out0>;
> + };
I think this is slightly incorrect. The lanes from the DP mux inside the
EC are routed to the SS part of the USB-C connector. As such...
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usb_c0_hs: endpoint {
> + remote-endpoint = <&usb_hub_dfp3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + usb_c0_ss: endpoint {
> + remote-endpoint = <&usb_hub_dfp3_ss>;
> + };
This should be more like
port@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
usb_c0_ss: endpoint@0 {
reg = <0>;
remote-endpoint = <&usb_hub_dfp3_ss>;
};
usbc0_dp: endpoint@1 {
reg = <1>;
remote-endpoint = <&dp_out0>;
};
};
Would it make the driver significantly more complicated?
--
With best wishes
Dmitry
Powered by blists - more mailing lists