[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqKxW9BeFQGsLqa-ZRurR8gDDrTSaDYs=mj7TYtF9ZDiYQ@mail.gmail.com>
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
Powered by blists - more mailing lists