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:   Mon, 16 Oct 2023 16:32:55 +0200
From:   Neil Armstrong <neil.armstrong@...aro.org>
To:     Rob Herring <robh@...nel.org>,
        Luca Weiss <luca.weiss@...rphone.com>
Cc:     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 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.

Neil

> 
> Rob