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

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, 13 Oct 2020 09:15:58 -0500
From:   Rob Herring <robh@...nel.org>
To:     Badhri Jagan Sridharan <badhri@...gle.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Maxime Ripard <mripard@...nel.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Thierry Reding <treding@...dia.com>,
        Prashant Malani <pmalani@...omium.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        USB <linux-usb@...r.kernel.org>,
        Amelie Delaunay <amelie.delaunay@...com>
Subject: Re: [PATCH v9 05/15] dt-bindings: connector: Add property to set
 initial current cap for FRS

On Wed, Oct 7, 2020 at 8:07 PM Badhri Jagan Sridharan <badhri@...gle.com> wrote:
>
> On Tue, Oct 6, 2020 at 11:29 AM Rob Herring <robh@...nel.org> 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@...com ? if so, just now CC'ed.
>
> >
> >
> > > Signed-off-by: Badhri Jagan Sridharan <badhri@...gle.com>
> > > ---
> > > 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.

Rob