devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Amit Sunil Dhamne <amitsd@google.com>,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, kyletso@google.com,
	rdbabiera@google.com, Badhri Jagan Sridharan <badhri@google.com>,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [RFC 1/2] dt-bindings: connector: Add property to set pd timer values
Date: Mon, 16 Sep 2024 11:33:28 -0500	[thread overview]
Message-ID: <20240916163328.GA394032-robh@kernel.org> (raw)
In-Reply-To: <ascu5yztalk62fernydttkywnqemnmjlcflzdyfmt7dzuzngho@vvxrnvwhfdmk>

On Fri, Sep 13, 2024 at 07:34:27AM +0300, Dmitry Baryshkov wrote:
> On Thu, Sep 12, 2024 at 04:26:25PM GMT, Amit Sunil Dhamne wrote:
> > Hi Dmitry,
> > 
> > On 9/12/24 3:05 AM, Dmitry Baryshkov wrote:
> > > On Tue, Sep 10, 2024 at 05:07:05PM GMT, Amit Sunil Dhamne wrote:
> > > > This commit adds a new property "pd-timers" to enable setting of
> > > > platform/board specific pd timer values for timers that have a range of
> > > > acceptable values.
> > > > 
> > > > Cc: Badhri Jagan Sridharan <badhri@google.com>
> > > > Cc: linux-usb@vger.kernel.org
> > > > Cc: devicetree@vger.kernel.org
> > > > Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
> > > > ---
> > > >   .../bindings/connector/usb-connector.yaml     | 23 +++++++++++++++++++
> > > >   include/dt-bindings/usb/pd.h                  |  8 +++++++
> > > >   2 files changed, 31 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > index fb216ce68bb3..9be4ed12f13c 100644
> > > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > > @@ -253,6 +253,16 @@ properties:
> > > >       additionalProperties: false
> > > > +  pd-timers:
> > > > +    description: An array of u32 integers, where an even index (i) is the timer (referenced in
> > > > +      dt-bindings/usb/pd.h) and the odd index (i+1) is the timer value in ms (refer
> > > > +      "Table 6-68 Time Values" of "USB Power Delivery Specification Revision 3.0, Version 1.2 " for
> > > > +      the appropriate value). For certain timers the PD spec defines a range rather than a fixed
> > > > +      value. The timers may need to be tuned based on the platform. This dt property allows the user
> > > > +      to assign specific values based on the platform. If these values are not explicitly defined,
> > > > +      TCPM will use a valid default value for such timers.
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > Is it really necessary to use the array property? I think it's easier
> > > and more logical to define corresponding individual properties, one per
> > > the timer.
> > 
> > Thanks for the review. The reason I did it this way was for
> > convenience. If in the future someone else wants add a new timer,
> > it'd be convenient to just add it as a new macro definition in pd.h
> > rather than having to define a new property each time, especially
> > if folks want to add more timers (scales better).
> > There are 3 timers already and I am working to add a fourth in a
> > follow up patch if the current RFC gets accepted.
> > 
> > Please let me know what do you think?
> 
> I'd leave the decision to DT maintainers, but in my opinion multiple
> properties scale better. Having a single value per property is easier to
> handle rather than changing the tagged array.

I agree. And it avoids what looks like a made up number space with the 
defines.

And note that an array of tuples is a matrix in DT defined types, not 
an array.

Rob

  reply	other threads:[~2024-09-16 16:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240911000715.554184-1-amitsd@google.com>
2024-09-11  0:07 ` [RFC 1/2] dt-bindings: connector: Add property to set pd timer values Amit Sunil Dhamne
2024-09-12 10:05   ` Dmitry Baryshkov
2024-09-12 23:26     ` Amit Sunil Dhamne
2024-09-13  4:34       ` Dmitry Baryshkov
2024-09-16 16:33         ` Rob Herring [this message]
2024-09-16 23:52           ` Amit Sunil Dhamne
2024-09-16 16:05       ` Krzysztof Kozlowski
2024-09-16 16:05   ` Krzysztof Kozlowski
2024-09-17  1:59     ` Amit Sunil Dhamne
2024-09-27  7:48       ` Krzysztof Kozlowski
2024-10-07 19:45         ` Amit Sunil Dhamne
2024-09-11  0:07 ` [RFC 2/2] usb: typec: tcpm: Add support for pd-timers DT property Amit Sunil Dhamne

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=20240916163328.GA394032-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=amitsd@google.com \
    --cc=badhri@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kyletso@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rdbabiera@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).