All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Rob Herring <robh@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	devicetree@vger.kernel.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>
Subject: Re: [PATCH v3] dt-bindings: gpio: add common consumer GPIO lines
Date: Fri, 1 Apr 2022 17:11:57 +0200	[thread overview]
Message-ID: <b035194e-c27f-ca23-cdb9-8d0dc38f6e5e@linaro.org> (raw)
In-Reply-To: <CAL_JsqJxZZVpregyGK93oKd6KMfhGXVjNYWYhoUZiPJXjELTxQ@mail.gmail.com>

On 01/04/2022 17:01, Rob Herring wrote:
> On Fri, Apr 1, 2022 at 8:27 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 01/04/2022 15:13, Rob Herring wrote:
>>> On Fri, 01 Apr 2022 09:27:14 +0200, Krzysztof Kozlowski wrote:
>>>> Typical GPIO lines like enable, powerdown, reset or wakeup are not
>>>> documented as common, which leads to new variations of these (e.g.
>>>> pwdn-gpios).  Add a common schema which serves also as a documentation
>>>> for preferred naming.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>
>>>> ---
>>>>
>>>> Changes since v2:
>>>> 1. Correct email.
>>>>
>>>> Changes since v1:
>>>> 1. Select-true, add maxItems and description for each entry (Rob).
>>>> 2. Mention ACTIVE_LOW in bindings description (Linus).
>>>> 3. Add allOf for pwrseq reset-gpios case.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>> ---
>>>>  .../bindings/gpio/gpio-consumer-common.yaml   | 64 +++++++++++++++++++
>>>>  1 file changed, 64 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml
>>>>
>>>
>>> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
>>> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>>>
>>> yamllint warnings/errors:
>>>
>>> dtschema/dtc warnings/errors:
>>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.example.dt.yaml: rt4801@73: enable-gpios: [[4294967295, 2, 0], [4294967295, 3, 0]] is too long
>>>       From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml
>>>
>>
>> Hi Rob,
>>
>> With v1, you proposed to use maxItems for all these standard gpios, but
>> as we see here there are two exceptions:
>> 1. pwrseq might have up to 32 reset-gpios,
>> 2. richtek,rt4801 uses up to 2 enable-gpios.
> 
> There's always an outlier...
> 
>> One way is to add exceptions in gpio-consumer-common.yaml, like I did
>> for reset-gpios and pwrseq. However this scales poor if more of such
>> usages appear.
> 
> I'd reject any new cases, but even just 2 I don't really like.

The richtek,rt4801 enable-gpios are for controlling two separate
regulators, so it should have been under regulator subnodes/children.
Some other regulators follow this pattern, so only this one is done that
way.

That driver could be converted to enable-gpios per regulator, so if you
are sure about rejection of new cases, how about keeping current
exceptions in allOf:if?

> 
>> Maybe let's drop the maxItems for all of them?
> 
> Let's just drop it at least for now (though it seems we can keep it
> for powerdown-gpios).
> 
> A possible solution here may be adding 'maxItems: 1' automatically to
> schemas if not specified. I've been thinking of doing this on standard
> unit properties. That's another case of
> 99% of cases are a single entry with a few outliers.
> 


Best regards,
Krzysztof

  reply	other threads:[~2022-04-01 15:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-01  7:27 [PATCH v3] dt-bindings: gpio: add common consumer GPIO lines Krzysztof Kozlowski
2022-04-01 13:13 ` Rob Herring
2022-04-01 13:26   ` Krzysztof Kozlowski
2022-04-01 15:01     ` Rob Herring
2022-04-01 15:11       ` Krzysztof Kozlowski [this message]
2022-04-01 19:44         ` Rob Herring

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=b035194e-c27f-ca23-cdb9-8d0dc38f6e5e@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /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.