linux-kernel - Re: [PATCH 1/3] dt-bindings: usb: fsa4480: Add data-lanes property to endpoint

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:   Tue, 17 Oct 2023 14:12:37 -0500
From:   Rob Herring <robh@...nel.org>
To:     Neil Armstrong <neil.armstrong@...aro.org>
Cc:     Luca Weiss <luca.weiss@...rphone.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: usb: fsa4480: Add data-lanes property
 to endpoint

On Mon, Oct 16, 2023 at 04:32:55PM +0200, Neil Armstrong wrote:
> On 16/10/2023 16:22, Rob Herring wrote:
> > On Fri, Oct 13, 2023 at 01:38:05PM +0200, Luca Weiss wrote:
> > > Allow specifying data-lanes to reverse the SBU muxing orientation where
> > > necessary by the hardware design.
> > 
> > What situation in the hardware design makes this necessary. Please
> > describe the problem.
> > 
> > > 
> > > Signed-off-by: Luca Weiss <luca.weiss@...rphone.com>
> > > ---
> > >   .../devicetree/bindings/usb/fcs,fsa4480.yaml       | 29 +++++++++++++++++++++-
> > >   1 file changed, 28 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> > > index f6e7a5c1ff0b..86f6d633c2fb 100644
> > > --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> > > @@ -32,10 +32,37 @@ properties:
> > >       type: boolean
> > >     port:
> > > -    $ref: /schemas/graph.yaml#/properties/port
> > > +    $ref: /schemas/graph.yaml#/$defs/port-base
> > >       description:
> > >         A port node to link the FSA4480 to a TypeC controller for the purpose of
> > >         handling altmode muxing and orientation switching.
> > > +    unevaluatedProperties: false
> > > +
> > > +    properties:
> > > +      endpoint:
> > > +        $ref: /schemas/graph.yaml#/$defs/endpoint-base
> > > +        unevaluatedProperties: false
> > > +
> > > +        properties:
> > > +          data-lanes:
> > > +            $ref: /schemas/types.yaml#/definitions/uint32-array
> > > +            description:
> > > +              Specifies how the AUX+/- lines are connected to SBU1/2.
> > 
> > Doesn't this depend on the connector orientation? Or it is both that and
> > the lines can be swapped on the PCB?
> > 
> > Seems like an abuse of data-lanes which already has a definition which
> > is not about swapping + and - differential lanes.
> 
> The FSA acts as a mux between DP AUX, Audio lanes on one side and
> the USB-C SBU lanes on the other side.
> _______          ______
>       |          |     |
>       |-- HP   --|     |
>       |-- MIC  --|     |or
> SoC   |          | MUX |-- SBU1 --->  To the USB-C
> Codec |-- AUX+ --|     |-- SBU2 --->  connected
>       |-- AUX- --|     |
> ______|          |____ |
> 
> The SBU1 & SBU2 are connected to the USB-C connector, and the actual orientation
> to the connected devices/cable/whatever is determined by the TPCM and the MUX in
> the FSA4480 with be dynamically changed according to the CC1/CC2 detection and PD alt mode.
> 
> But on the other side the orientation of the AUX+/AUX- connected to the SoC
> is not tied to the USB-C orientation but how it's routed on the PCB.
> 
> This describes how the AUX+/AUX- are physically routed to the FSA4480 chip.

I'd hate for this ASCII art to go to waste. Please add this detail to 
the commit message.

Rob