Re: [PATCH v2] dt-bindings: usb: add common Type-C USB Switch schema

[Luca Weiss]

On Thu Apr 11, 2024 at 9:25 AM CEST, Krzysztof Kozlowski wrote:
> On 11/04/2024 09:13, Luca Weiss wrote:
> > On Mon Jan 22, 2024 at 10:44 AM CET, Krzysztof Kozlowski wrote:
> >> Several bindings implement parts of Type-C USB orientation and mode
> >> switching, and retiming.  Keep definition of such properties in one
> >> place, new usb-switch schema, to avoid duplicate defines.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> >>
> >> ---
> >>
> >> Changes in v2:
> >> 1. Fix language typos handle->handler (Luca)
> >> 2. Drop debugging left-over (Luca)
> >> ---
> >>  .../devicetree/bindings/usb/fcs,fsa4480.yaml  | 12 ++--
> >>  .../devicetree/bindings/usb/gpio-sbu-mux.yaml | 12 ++--
> >>  .../devicetree/bindings/usb/nxp,ptn36502.yaml | 12 ++--
> >>  .../bindings/usb/onnn,nb7vpq904m.yaml         | 13 ++--
> >>  .../bindings/usb/qcom,wcd939x-usbss.yaml      | 12 ++--
> >>  .../devicetree/bindings/usb/usb-switch.yaml   | 67 +++++++++++++++++++
> >>  6 files changed, 92 insertions(+), 36 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/usb/usb-switch.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> >> index f9410eb76a62..8b25b9a01ced 100644
> >> --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> >> +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> >> @@ -27,13 +27,8 @@ properties:
> >>    vcc-supply:
> >>      description: power supply (2.7V-5.5V)
> >>  
> >> -  mode-switch:
> >> -    description: Flag the port as possible handle of altmode switching
> >> -    type: boolean
> >> -
> >> -  orientation-switch:
> >> -    description: Flag the port as possible handler of orientation switching
> >> -    type: boolean
> >> +  mode-switch: true
> >> +  orientation-switch: true
> >>  
> >>    port:
> >>      $ref: /schemas/graph.yaml#/$defs/port-base
> >> @@ -79,6 +74,9 @@ required:
> >>    - reg
> >>    - port
> >>  
> >> +allOf:
> >> +  - $ref: usb-switch.yaml#
> >> +
> >>  additionalProperties: false
> >>  
> >>  examples:
> > 
> > Hi Krzysztof,
> > 
> > This patch seems to break validation for fsa4480 if data-lanes is set in
> > the endpoint like the following
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> > index f9410eb76a62..3aa03fd65556 100644
> > --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> > +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> > @@ -102,6 +102,7 @@ examples:
> >            port {
> >              fsa4480_ept: endpoint {
> >                remote-endpoint = <&typec_controller>;
> > +              data-lanes = <0 1>;
> >              };
> >            };
> >          };
> > 
> > Similar to how it's already used on qcom/qcm6490-fairphone-fp5.dts
> > 
> > I'm guessing the 'port' definition in the common schema somehow
> > disallows the fsa4480 schema from describing it further?
>
> There is no such code in qcm6490-fairphone-fp5.dts. There was no such
> code in the example of fsa4480 when I was testing my changes (and
> examples should be complete), so this did not pop up.

Right, I'm sorry this is just out-of-tree for now, I've forgotten this.
There's some dependency chain with some unsupported DSC configuration in
DPU for now that blocks upstreaming this.

My tree with these patches is here if you want to take a look:
https://github.com/sc7280-mainline/linux/blob/sc7280-6.8.y/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts#L628

>
> You right, new schema does not allow extending the port. However the
> true question is, why muxing happens on the port to the SoC controller?
> The graph in commit msg fad89aa14 shows it happens on the side of the
> connector.
>
> Looks like fsa4480 mixes connector with the controller.

Could be honestly.. I trust you with knowing better how the ports are
supposed to work.

The property is for telling the fsa4480 driver that essentially the
hardware is wired up the reverse way. So with this info the driver can
handle the orientation switching correctly.

There's another layer to this as explained in the patches there that the
OCP96011 essentially works reversed compared to FSA4480, that's why it's
all a bit of a mess.

Regards
Luca

>
> Best regards,
> Krzysztof