From: Rob Herring <robh@kernel.org>
To: Amelie DELAUNAY <amelie.delaunay@st.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Russell King <linux@armlinux.org.uk>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Badhri Jagan Sridharan <badhri@google.com>,
Jun Li <lijun.kernel@gmail.com>,
devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux USB List <linux-usb@vger.kernel.org>,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-stm32@st-md-mailman.stormreply.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Fabrice Gasnier <fabrice.gasnier@st.com>
Subject: Re: [PATCH v5 1/5] dt-bindings: connector: add typec-power-opmode property to usb-connector
Date: Wed, 11 Nov 2020 14:25:04 -0600 [thread overview]
Message-ID: <20201111202504.GA1964362@bogus> (raw)
In-Reply-To: <5df74edf-b6f9-3397-4c85-683987dd5743@st.com>
On Mon, Nov 09, 2020 at 05:10:23PM +0100, Amelie DELAUNAY wrote:
>
>
> On 11/9/20 5:02 PM, Rob Herring wrote:
> > On Mon, Nov 9, 2020 at 9:54 AM Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> > >
> > > On 11/9/20 4:03 PM, Rob Herring wrote:
> > > > On Fri, Nov 6, 2020 at 10:58 AM Amelie Delaunay <amelie.delaunay@st.com> wrote:
> > > > >
> > > > > Power operation mode may depends on hardware design, so, add the optional
> > > > > property typec-power-opmode for usb-c connector to select the power
> > > > > operation mode capability.
> > > > >
> > > > > Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> > > > > ---
> > > > > Hi Bahdri, Rob,
> > > > >
> > > > > I've added the exlusion with FRS property, but new FRS property name
> > > > > should be use here so, be careful.
> > > > >
> > > > > ---
> > > > > .../bindings/connector/usb-connector.yaml | 24 +++++++++++++++++++
> > > > > 1 file changed, 24 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > > index 62781518aefc..a84464b3e1f2 100644
> > > > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > > @@ -93,6 +93,24 @@ properties:
> > > > > - device
> > > > > - dual
> > > > >
> > > > > + typec-power-opmode:
> > > > > + description: Determines the power operation mode that the Type C connector
> > > > > + will support and will advertise through CC pins when it has no power
> > > > > + delivery support.
> > > > > + - "default" corresponds to default USB voltage and current defined by the
> > > > > + USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and
> > > > > + 5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane
> > > > > + operation respectively.
> > > > > + - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in USB
> > > > > + Type-C Cable and Connector specification, when Power Delivery is not
> > > > > + supported.
> > > > > + allOf:
> > > > > + - $ref: /schemas/types.yaml#definitions/string
> > > > > + enum:
> > > > > + - default
> > > > > + - 1.5A
> > > > > + - 3.0A
> > > >
> > > > Use the enums here. Unless you want to define it as actual current as
> > > > a numerical value.
> > >
> > > If I understand your point correctly, I think I should remove allOf here
> > > and stick with what is done to describe power-role and data-role
> > > property. Right ?
> >
> > No, use the numerical values like FRS:
> >
> > + "1" refers to default USB power level as described by "Table
> > 6-14 Fixed Supply PDO - Sink".
> > + "2" refers to 1.5A@5V.
> > + "3" refers to 3.0A@5V.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum: [1, 2, 3]
>
> But it changes the type-c class philosophy. There is already an API to
> convert string into enum, the same kind is used for data-role and power-role
> properties.
> Moveover, FRS values doesn't fit with typec_pwr_opmode enum:
> enum typec_pwr_opmode {
> TYPEC_PWR_MODE_USB,
> TYPEC_PWR_MODE_1_5A,
> TYPEC_PWR_MODE_3_0A,
> TYPEC_PWR_MODE_PD,
> };
Okay, then strings it is I guess.
Reviewed-by: Rob Herring <robh@kernel.org>
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Amelie DELAUNAY <amelie.delaunay@st.com>
Cc: devicetree@vger.kernel.org,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux USB List <linux-usb@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Badhri Jagan Sridharan <badhri@google.com>,
Jun Li <lijun.kernel@gmail.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-stm32@st-md-mailman.stormreply.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 1/5] dt-bindings: connector: add typec-power-opmode property to usb-connector
Date: Wed, 11 Nov 2020 14:25:04 -0600 [thread overview]
Message-ID: <20201111202504.GA1964362@bogus> (raw)
In-Reply-To: <5df74edf-b6f9-3397-4c85-683987dd5743@st.com>
On Mon, Nov 09, 2020 at 05:10:23PM +0100, Amelie DELAUNAY wrote:
>
>
> On 11/9/20 5:02 PM, Rob Herring wrote:
> > On Mon, Nov 9, 2020 at 9:54 AM Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> > >
> > > On 11/9/20 4:03 PM, Rob Herring wrote:
> > > > On Fri, Nov 6, 2020 at 10:58 AM Amelie Delaunay <amelie.delaunay@st.com> wrote:
> > > > >
> > > > > Power operation mode may depends on hardware design, so, add the optional
> > > > > property typec-power-opmode for usb-c connector to select the power
> > > > > operation mode capability.
> > > > >
> > > > > Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> > > > > ---
> > > > > Hi Bahdri, Rob,
> > > > >
> > > > > I've added the exlusion with FRS property, but new FRS property name
> > > > > should be use here so, be careful.
> > > > >
> > > > > ---
> > > > > .../bindings/connector/usb-connector.yaml | 24 +++++++++++++++++++
> > > > > 1 file changed, 24 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > > index 62781518aefc..a84464b3e1f2 100644
> > > > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > > @@ -93,6 +93,24 @@ properties:
> > > > > - device
> > > > > - dual
> > > > >
> > > > > + typec-power-opmode:
> > > > > + description: Determines the power operation mode that the Type C connector
> > > > > + will support and will advertise through CC pins when it has no power
> > > > > + delivery support.
> > > > > + - "default" corresponds to default USB voltage and current defined by the
> > > > > + USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and
> > > > > + 5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane
> > > > > + operation respectively.
> > > > > + - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in USB
> > > > > + Type-C Cable and Connector specification, when Power Delivery is not
> > > > > + supported.
> > > > > + allOf:
> > > > > + - $ref: /schemas/types.yaml#definitions/string
> > > > > + enum:
> > > > > + - default
> > > > > + - 1.5A
> > > > > + - 3.0A
> > > >
> > > > Use the enums here. Unless you want to define it as actual current as
> > > > a numerical value.
> > >
> > > If I understand your point correctly, I think I should remove allOf here
> > > and stick with what is done to describe power-role and data-role
> > > property. Right ?
> >
> > No, use the numerical values like FRS:
> >
> > + "1" refers to default USB power level as described by "Table
> > 6-14 Fixed Supply PDO - Sink".
> > + "2" refers to 1.5A@5V.
> > + "3" refers to 3.0A@5V.
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + enum: [1, 2, 3]
>
> But it changes the type-c class philosophy. There is already an API to
> convert string into enum, the same kind is used for data-role and power-role
> properties.
> Moveover, FRS values doesn't fit with typec_pwr_opmode enum:
> enum typec_pwr_opmode {
> TYPEC_PWR_MODE_USB,
> TYPEC_PWR_MODE_1_5A,
> TYPEC_PWR_MODE_3_0A,
> TYPEC_PWR_MODE_PD,
> };
Okay, then strings it is I guess.
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-11 20:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 16:58 [PATCH v5 0/5] STUSB1600 support on STM32MP15xx-DKx Amelie Delaunay
2020-11-06 16:58 ` Amelie Delaunay
2020-11-06 16:58 ` [PATCH v5 1/5] dt-bindings: connector: add typec-power-opmode property to usb-connector Amelie Delaunay
2020-11-06 16:58 ` Amelie Delaunay
2020-11-09 15:03 ` Rob Herring
2020-11-09 15:03 ` Rob Herring
2020-11-09 15:54 ` Amelie DELAUNAY
2020-11-09 15:54 ` Amelie DELAUNAY
2020-11-09 16:02 ` Rob Herring
2020-11-09 16:02 ` Rob Herring
2020-11-09 16:10 ` Amelie DELAUNAY
2020-11-09 16:10 ` Amelie DELAUNAY
2020-11-11 20:25 ` Rob Herring [this message]
2020-11-11 20:25 ` Rob Herring
2020-11-06 16:58 ` [PATCH v5 2/5] dt-bindings: usb: Add DT bindings for STUSB160x Type-C controller Amelie Delaunay
2020-11-06 16:58 ` Amelie Delaunay
2020-11-11 20:26 ` Rob Herring
2020-11-11 20:26 ` Rob Herring
2020-11-06 16:58 ` [PATCH v5 3/5] usb: typec: stusb160x: fix power-opmode property with typec-power-opmode Amelie Delaunay
2020-11-06 16:58 ` Amelie Delaunay
2020-11-27 13:01 ` Amelie DELAUNAY
2020-11-27 13:01 ` Amelie DELAUNAY
2020-11-27 13:07 ` Greg Kroah-Hartman
2020-11-27 13:07 ` Greg Kroah-Hartman
2020-11-27 13:12 ` Amelie DELAUNAY
2020-11-27 13:12 ` Amelie DELAUNAY
2020-11-06 16:58 ` [PATCH v5 4/5] ARM: dts: stm32: add STUSB1600 Type-C using I2C4 on stm32mp15xx-dkx Amelie Delaunay
2020-11-06 16:58 ` Amelie Delaunay
2020-11-06 16:58 ` [PATCH v5 5/5] ARM: multi_v7_defconfig: enable STUSB160X Type-C port controller support Amelie Delaunay
2020-11-06 16:58 ` Amelie Delaunay
2020-11-17 9:30 ` [PATCH v5 0/5] STUSB1600 support on STM32MP15xx-DKx Alexandre Torgue
2020-11-17 9:30 ` Alexandre Torgue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201111202504.GA1964362@bogus \
--to=robh@kernel.org \
--cc=alexandre.torgue@st.com \
--cc=amelie.delaunay@st.com \
--cc=badhri@google.com \
--cc=devicetree@vger.kernel.org \
--cc=fabrice.gasnier@st.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=lijun.kernel@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-usb@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.