linux-kernel - Re: [PATCH V0 1/7] dt-bindings: connector: Add property for eud type c connector

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:   Thu, 07 Oct 2021 14:55:09 +0530
From:   schowdhu@...eaurora.org
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Rob Herring <robh@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
        Bryan O'Donoghue <pure.logic@...us-software.ie>,
        Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
        ckadabi@...eaurora.org, tsoni@...eaurora.org,
        bryanh@...eaurora.org, psodagud@...eaurora.org,
        satyap@...eaurora.org, pheragu@...eaurora.org,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Sibi Sankar <sibis@...eaurora.org>,
        Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
Subject: Re: [PATCH V0 1/7] dt-bindings: connector: Add property for eud type
 c connector

On 2021-10-05 22:07, Bjorn Andersson wrote:
> On Tue 05 Oct 06:11 PDT 2021, schowdhu@...eaurora.org wrote:
> 
>> On 2021-10-04 22:07, Rob Herring wrote:
>> > On Mon, Oct 04, 2021 at 04:46:19PM +0530, Souradeep Chowdhury wrote:
>> > > Added the property for EUD(Embedded USB Debug) connector.Added
>> > > the "reg" and "interrupts" property which is needed for EUD.
>> >
>> > You are going to need a better explanation of this h/w.
>> 
>> Ack. Will update this with the detailed hardware description
>> in the next version.
>> 
>> >
>> > >
>> > > Signed-off-by: Souradeep Chowdhury <schowdhu@...eaurora.org>
>> > > ---
>> > >  .../devicetree/bindings/connector/usb-connector.yaml      | 15
>> > > +++++++++++++++
>> > >  1 file changed, 15 insertions(+)
>> > >
>> > > diff --git
>> > > a/Documentation/devicetree/bindings/connector/usb-connector.yaml
>> > > b/Documentation/devicetree/bindings/connector/usb-connector.yaml
>> > > index 7eb8659..908129f 100644
>> > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
>> > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
>> > > @@ -30,6 +30,21 @@ properties:
>> > >            - const: samsung,usb-connector-11pin
>> > >            - const: usb-b-connector
>> > >
>> > > +      - items:
>> > > +          - enum:
>> > > +              - qcom,sc7280-usb-connector-eud
>> > > +          - const: qcom,usb-connector-eud
>> > > +          - const: usb-c-connector
>> > > +
>> > > +  reg:
>> > > +    items:
>> > > +      - description: EUD Base Register Region
>> > > +      - description: EUD Mode Manager Region
>> >
>> > A connector node represents the physical connector on a board. That
>> > can't really be an MMIO peripheral. Maybe you need a node for EUD and
>> > then it should have a connector child node? Don't really know without
>> > understanding this h/w.
>> 
>> As per the previous discussion on the EUD, it was agreed upon to map 
>> EUD
>> as a type C connector and use Role-Switch to change the USB role 
>> instead
>> of extcon interface that was being used previously. The link for the 
>> same
>> is as follows:-
>> 
>> https://lore.kernel.org/lkml/5db1a666-62ec-c850-6626-ad33d337b452@codeaurora.org/
>> 
> 
> Not using extcon is the right thing, but perhaps we should make the EUD
> a role_switch provider and client, so that we can describe how it sits
> inbetween the connector and the controller.
> 
> That way it has the power to pass through or override requests from the
> upstream role-switcher, based on the status of EUD.
> 
> 
> That said, I'm still curious to what happens if I renegotiate the roles
> dynamically in a Type-C environment, while enabling EUD. How would the
> device on the other end of the cable know that it's supposed to be a
> host? Or there's simply a reset of the link when this happens?
> 
> Thanks,
> Bjorn

Hi Bjorn,

By making EUD Role-Switch provider and client do you mean that
we should have a EUD node which will have a connector node as
child and this connector node will have a port that points towards
the drd role-switch?

So that my device tree node will look like the following in that case

eud@...0000 {
         compatible = "qcom,usb-connector-eud";
         reg = <0 0x88e0000 0 0x2000>,
               <0 0x88e2000 0 0x1000>;
         interrupt-parent = <&pdc>;
         interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
         usb_con: connector {
                 compatible = "usb-c-connector";
                 label = "USB-C";
                 port {
                       eud_usb_output: endpoint {
                       remote-endpoint = <&eud_usb3_input>;
                  };
         };

};


@usb2 {
     dwc3 {
        usb-role-switch;
        port {
              eud_usb3_input: endpoint {
                    remote-endpoint = <&eud_usb_output>;
              };
      };
};

Also EUD functions only in device mode, so when the role-switch is done 
by the controller
to set the device mode, the PC on the other end becomes the host.

Thanks,
Souradeep

> 
>> >
>> > > +
>> > > +  interrupts:
>> > > +    description:
>> > > +      EUD interrupt
>> > > +
>> > >    label:
>> > >      description: Symbolic name for the connector.
>> > >
>> > > --
>> > > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>> > > member
>> > > of Code Aurora Forum, hosted by The Linux Foundation
>> > >
>> > >