linux-kernel - Re: [PATCH 1/2] dt-bindings: regulator: Add bindings for Richtek RT5739

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: <38824a96-804d-84a2-2750-be1325b2e1d2@linaro.org>
Date:   Thu, 16 Feb 2023 11:03:39 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     ChiYuan Huang <cy_huang@...htek.com>
Cc:     broonie@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, lgirdwood@...il.com,
        u0084500@...il.com, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: regulator: Add bindings for Richtek
 RT5739

On 16/02/2023 10:57, ChiYuan Huang wrote:
> On Thu, Feb 16, 2023 at 10:12:15AM +0100, Krzysztof Kozlowski wrote:
>> On 15/02/2023 03:00, cy_huang@...htek.com wrote:
>>> From: ChiYuan Huang <cy_huang@...htek.com>
>>>
>>> Add the binding document for Richtek RT5739.
>>
>> Subject: drop second/last, redundant "bindings for". The "dt-bindings"
>> prefix is already stating that these are bindings.
>>
> Then, refine it to "dt-bindings: regulator: Add Richtek RT5739 document" 

I propose also to drop "document" - it is also redundant. Can bindings
be something else than document?


>>>
>>> Signed-off-by: ChiYuan Huang <cy_huang@...htek.com>
>>> ---
>>>  .../bindings/regulator/richtek,rt5739.yaml         | 80 ++++++++++++++++++++++
>>>  1 file changed, 80 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
>>> new file mode 100644
>>> index 00000000..7dc4f78
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml
>>> @@ -0,0 +1,80 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Richtek RT5739 2.4MHz 3.5A Step-Down Converter
>>> +
>>> +maintainers:
>>> +  - ChiYuan Huang <cy_huang@...htek.com>
>>> +
>>> +description: |
>>> +  The RT5739 is a step-down switching voltage regulator that delivers a
>>> +  digitally programmable output from an input voltage supply of 2.5V to 5.5V.
>>> +  The output voltage is programmed through an I2C interface capable of
>>> +  operating up to 3.4MHz.
>>> +
>>> +  Using a proprietary architecture with synchronous rectification, the RT5739
>>> +  is capable of delivering 3.5A continuously at over 80% efficiency,
>>> +  maintaining that efficiency at load current as low as 10mA. The regulator
>>> +  operates at a normal fixed frequency of 2.4MHz, which reduces the value of
>>> +  the external components. 
>>
>> Can we drop the marketing from kernel? Last part of sentence is not
>> related to this submission at all. The internal frequency also looks
>> unrelated to the topic...
>>
> Okay, too much marketing text. I'll shorten it and simply describe the function or
> voltage range only. 
>>> Additional output capacitance can be added to
>>> +  improve regulation during load transients without affecting stability.
>>> +
>>> +allOf:
>>> +  - $ref: regulator.yaml#
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - richtek,rt5739
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  enable-gpios:
>>> +    maxItems: 1
>>> +
>>> +  richtek,vsel-active-high:
>>> +    description: |
>>> +      If property is present, use the 'VSEL1' register group for buck control.
>>> +      Else, use the 'VSEL0' register group. This depends on external hardware
>>> +      'VSEL' pin connecton.
>>> +    type: boolean
>>> +
>>> +  regulator-allowed-modes:
>>> +    description: |
>>> +      buck allowed operating mode
>>> +        0: Auto PFM/PWM mode
>>> +        1: Forced PWM mode
>>> +    maxItems: 2
>>> +    items:
>>> +      enum: [0, 1]
>>
>> So you always require two items? Thus I wonder what's the point of
>> having it in DT? To skip the property entirely if none of the modes are
>> allowed?
>>
> Not always need two. So does it mean no need to describe the 'maxItems' and 'Items'.

Your minItems is 2, so you always need two. If you accept one, the add
minItems: 1.



Best regards,
Krzysztof