Re: [PATCH v9 05/15] dt-bindings: connector: Add property to set initial current cap for FRS

[Badhri Jagan Sridharan]

On Tue, Oct 13, 2020 at 7:16 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Wed, Oct 7, 2020 at 8:07 PM Badhri Jagan Sridharan <badhri@xxxxxxxxxx> wrote:
> >
> > On Tue, Oct 6, 2020 at 11:29 AM Rob Herring <robh@xxxxxxxxxx> wrote:
> > >
> > > On Mon, Sep 28, 2020 at 07:39:54PM -0700, Badhri Jagan Sridharan wrote:
> > > > This change adds frs-typec-current which allows setting the initial current
> > > > capability of the new source when vSafe5V is applied during PD3.0
> > > > sink Fast Role Swap.
> > >
> > > Shouldn't you Cc the person you copied this from?
> > Not sure whether I get this comment. The patch wasn't copied. Maybe you were
> > expecting me to CC amelie.delaunay@xxxxxx ? if so, just now CC'ed.
> >
> > >
> > >
> > > > Signed-off-by: Badhri Jagan Sridharan <badhri@xxxxxxxxxx>
> > > > ---
> > > > Changes since v1:
> > > > - Changing patch version to v6 to fix version number confusion.
> > > >
> > > > Changes since v6:
> > > > - Removed the redundant usb-connector.txt that I created by mistake.
> > > > - Moved to yaml.
> > > >
> > > > Changes since v7:
> > > > - Rebase
> > > >
> > > > Changes since v8:
> > > > - Redefine new-source-frs-typec-current as string enums to address
> > > >   Rob Herring's comment.
> > > > ---
> > > >  .../bindings/connector/usb-connector.yaml     | 26 +++++++++++++++++++
> > > >  include/dt-bindings/usb/pd.h                  | 10 +++++++
> > > >  2 files changed, 36 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > index 9bd52e63c935..0b8cd08a8678 100644
> > > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > @@ -142,6 +142,32 @@ properties:
> > > >      required:
> > > >        - port@0
> > > >
> > > > +  new-source-frs-typec-current:
> > > > +    description: Initial current capability of the new source when vSafe5V
> > > > +      is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply PDO - Sink"
> > > > +      of "USB Power Delivery Specification Revision 3.0, Version 1.2" provides the
> > > > +      different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C Current"
> > > > +      provides a detailed description of the field. The sink PDO from current source
> > > > +      reflects the current source's(i.e. transmitter of the FRS signal) power
> > > > +      requirement during fr swap. The current sink (i.e. receiver of the FRS signal),
> > > > +      a.k.a new source, should check if it will be able to satisfy the current source's,
> > > > +      new sink's, requirement during frswap before enabling the frs signal reception.
> > > > +      This property refers to maximum current capability that the current sink can
> > > > +      satisfy. During FRS, VBUS voltage is at 5V, as the partners are in implicit
> > > > +      contract, hence, the power level is only a function of the current capability.
> > > > +      "not-supported" implies sink to source fast role swap not supported.
> > > > +      "default" refers to default USB power level as described by
> > > > +      "Table 6-14 Fixed Supply PDO - Sink".
> > > > +      "1.5A" refers to 1.5A@5V.
> > > > +      "3.0A" refers to 3.0A@5V.
> > >
> > >
> > > > +
> > > > +    $ref: /schemas/types.yaml#/definitions/string
> > > > +    enum:
> > > > +      - not-supported
> > > > +      - default
> > > > +      - 1.5A
> > > > +      - 3.0A
> > >
> > > What happens if the property is not present?
> >
> > The behavior would be the same as "not-supported".
>
> Then you don't need 'not-supported'.
>
> >
> > >
> > > I'm not crazy about mixing strings and what could be a number.
> >
> > v8 version[1] of the patch was using uint32. I moved to using strings
> > as you were asking to unify with the approach in [2]. Since [3] was using
> > string enums, I moved to that. I don't have a strong preference here, so
> > I can move back to using u32 if you feel so.
>
> Since the u32 values are based on the USB spec, I think I prefer that.
> Should be easier to deal with in the driver than doing strcmp's.
Done. Sent out as v11 of the patch.

Thanks,
Badhri

>
> Rob