| 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: <46ac6ab8-b0a5-497d-91b6-1d2ced33184b@linaro.org>
Date: Sun, 11 Feb 2024 14:34:25 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Stephen Boyd <swboyd@...omium.org>, chrome-platform@...ts.linux.dev
Cc: linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-arm-msm@...r.kernel.org, Douglas Anderson <dianders@...omium.org>,
Pin-yen Lin <treapking@...omium.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Lee Jones <lee@...nel.org>,
Benson Leung <bleung@...omium.org>, Guenter Roeck <groeck@...omium.org>,
Prashant Malani <pmalani@...omium.org>, Tzung-Bi Shih <tzungbi@...nel.org>
Subject: Re: [PATCH 13/22] dt-bindings: chrome: Add
google,cros-ec-typec-switch binding
On 10/02/2024 08:09, Stephen Boyd wrote:
> Add a binding for the USB type-c switch controls found on some ChromeOS
> Embedded Controllers (ECs). When this device is a mode switch, it takes
> one DisplayPort (DP) port as input and some number (possibly zero) of
> USB SuperSpeed ports (bundles of USB SS lanes) as input, and muxes those
> lanes into USB type-c SuperSpeed lanes suitable for the SSTRX1/2 pins on
> a usb-c-connector. When this device is an orientation switch, it
> redirects the DP lanes to the proper USB type-c SSTRX lanes.
>
> Cc: Rob Herring <robh+dt@...nel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
> Cc: Conor Dooley <conor+dt@...nel.org>
> Cc: Lee Jones <lee@...nel.org>
> Cc: Benson Leung <bleung@...omium.org>
> Cc: Guenter Roeck <groeck@...omium.org>
> Cc: Prashant Malani <pmalani@...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>
> Signed-off-by: Stephen Boyd <swboyd@...omium.org>
> ---
> .../chrome/google,cros-ec-typec-switch.yaml | 365 ++++++++++++++++++
> .../bindings/mfd/google,cros-ec.yaml | 5 +
> 2 files changed, 370 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml
>
> diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml
> new file mode 100644
> index 000000000000..17a0ba928f5d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml
> @@ -0,0 +1,365 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/chrome/google,cros-ec-typec-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google Chrome OS EC(Embedded Controller) USB Type C Switch
> +
> +maintainers:
> + - Benson Leung <bleung@...omium.org>
> + - Prashant Malani <pmalani@...omium.org>
> + - Stephen Boyd <swboyd@...omium.org>
> +
> +description:
> + Chrome OS devices have an Embedded Controller(EC) which has access to USB
> + Type C switching. This node is intended to allow the OS to control Type C
> + signal muxing for USB-C orientation and alternate modes. The node for this
> + device should be under a cros-ec node like google,cros-ec-spi.
> +
If this is USB Type C switch, then you miss reference to
usb-switch.yaml, but then ports look a bit different.
> +properties:
> + compatible:
> + const: google,cros-ec-typec-switch
> +
> + mode-switch:
> + description: Indicates this device controls altmode switching
> + type: boolean
> +
> + orientation-switch:
> + description: Indicates this device controls orientation switching
> + type: boolean
> +
> + mux-gpios:
> + description: GPIOs indicating which way the DP mux is steered
missing maxItems
> +
> + 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#/$defs/port-base
> + description: Input port to receive DisplayPort (DP) data
> + unevaluatedProperties: false
> +
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: DisplayPort data
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical DP data lane indexes
> + - 0 is DP ML0 lane
> + - 1 is DP ML1 lane
> + - 2 is DP ML2 lane
> + - 3 is DP ML3 lane
> + oneOf:
> + - items:
> + - const: 0
> + - const: 1
> + - items:
> + - const: 0
> + - const: 1
> + - const: 2
> + - const: 3
> +
> + required:
> + - endpoint@0
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port to receive USB SuperSpeed (SS) data
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: USB SS data
> +
> + endpoint@1:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: USB SS data
> +
> + anyOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> +
> + port@2:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Output port for USB-C data
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + endpoint@1:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data for EC's 1st type-c port
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + endpoint@2:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data for EC's 2nd type-c port
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + endpoint@3:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data for EC's 3rd type-c port
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + endpoint@4:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data for EC's 4th type-c port
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + endpoint@5:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data for EC's 5th type-c port
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + endpoint@6:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data for EC's 6th type-c port
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + endpoint@7:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: USB-C data for EC's 7th type-c port
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + anyOf:
> + - required:
> + - endpoint@0
I don't get what you want to say here. This anyOf should have no effect.
> + - required:
> + - endpoint@1
> + - required:
> + - endpoint@2
> + - required:
> + - endpoint@3
> + - required:
> + - endpoint@4
> + - required:
> + - endpoint@5
> + - required:
> + - endpoint@6
> + - required:
> + - endpoint@7
> +
> + required:
> + - port@2
> + anyOf:
> + - required:
> + - port@0
> + - required:
> + - port@1
Same problem here
> +
> +required:
> + - compatible
> + - ports
> +
> +allOf:
> + - if:
> + properties:
> + no-hpd: true
I don't understand this either. What is it for? Where did you see such
syntax?
> + required:
> + - no-hpd> + then:
> + properties:
> + ports:
> + required:
> + - port@0
> + - if:
> + properties:
> + mode-switch: true
> + required:
> + - mode-switch
> + then:
> + properties:
> + ports:
> + required:
> + - port@0
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cros_ec: ec@0 {
> + compatible = "google,cros-ec-spi";
> + reg = <0>;
> + interrupts = <35 0>;
Same concerns about interrupts.
> +
> + typec-switch {
> + compatible = "google,cros-ec-typec-switch";
> + mode-switch;
> + orientation-switch;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dp_in: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&dp_phy>;
> + data-lanes = <0 1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb_in_0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&usb_ss_0_out>;
> + };
> +
> + usb_in_1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&usb_ss_1_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cros_typec_c0_ss: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&usb_c0_ss>;
> + };
> +
> + cros_typec_c1_ss: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&usb_c1_ss>;
> + };
> + };
> + };
> + };
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index ded396b28fba..563c51a4a39c 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -164,6 +164,10 @@ patternProperties:
> type: object
> $ref: /schemas/extcon/extcon-usbc-cros-ec.yaml#
>
> + "^typec-switch[0-9]*$":
Missing - after typec-switch (e.g. typec-switch-1)
> + type: object
> + $ref: /schemas/chrome/google,cros-ec-typec-switch.yaml#
Best regards,
Krzysztof
Powered by blists - more mailing lists