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]
Message-ID: <7ad81408-ee33-4b4a-b70e-0cebd8b46880@google.com>
Date: Mon, 16 Sep 2024 16:52:23 -0700
From: Amit Sunil Dhamne <amitsd@...gle.com>
To: Rob Herring <robh@...nel.org>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 heikki.krogerus@...ux.intel.com, gregkh@...uxfoundation.org,
 linux-kernel@...r.kernel.org, kyletso@...gle.com, rdbabiera@...gle.com,
 Badhri Jagan Sridharan <badhri@...gle.com>, linux-usb@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [RFC 1/2] dt-bindings: connector: Add property to set pd timer
 values

Hi Rob,

On 9/16/24 9:33 AM, Rob Herring wrote:
> 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@...gle.com>
>>>>> Cc: linux-usb@...r.kernel.org
>>>>> Cc: devicetree@...r.kernel.org
>>>>> Signed-off-by: Amit Sunil Dhamne <amitsd@...gle.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.
Thanks for the review! I will incorporate the suggested comments in the
next revision by creating a "single value per timer" property.

Regards,

Amit

>
> Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ