devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml
Date: Fri, 19 Jun 2020 09:46:54 +0200	[thread overview]
Message-ID: <20200619074654.GD3704347@ulmo> (raw)
In-Reply-To: <20200618025140.GB3378010@bogus>

[-- Attachment #1: Type: text/plain, Size: 5747 bytes --]

On Wed, Jun 17, 2020 at 08:51:40PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:19:02PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > For PWM controller device tree bindings, make sure that they include the
> > pwm.yaml controller core bindings explicitly. This prevents the tooling
> > from matching on the $nodename pattern, which can falsely match things
> > like pinmux nodes, etc.
> 
> My preference here is to clean-up the mess that is pinmux nodes.

Any suggestions on how to do that? Do you just want to rename the
problematic nodes? Or do you want to introduce a standard naming scheme?
As an example, I was running into the issue with this node:

	pinmux@70000014 {
		pinctrl-names = "default";
		pinctrl-0 = <&state_default>;

		state_default: pinmux {
			...

			pwm-a-b {
				nvidia,pins = "sdc";
				nvidia,function = "pwm";
				nvidia,tristate = <TEGRA_PIN_ENABLE>;
			};

			...
		};
	};

My first instinct was to just add some sort of prefix to this, but then
I realized that might not be the best option because there could be
countless other nodes whose names might start with "pwm-" but that had
nothing to do with PWM controllers whatsoever.

You could for example have some node named "pwm-fan" and then these
standard bindings will require that to be have a #pwm-cells property.

So I think the solution of only explicitly "activating" PWM controller
bindings would work well in this particular case because it would only
apply the bindings where explicitly requested. That way it doesn't
matter what nodes are named.

> This has the side effect of no longer checking pwm nodes that didn't 
> have explicit schema. Perhaps that's of somewhat limited value.

There are two easy solutions to this: 1) convert all PWM bindings to
YAML so that they have an explicit schema or 2) consider the presence of
the #pwm-cells property as a marker that the node represents a PWM
controller/provider, irrespective of the name. The latter would be much
like gpio-controller or interrupt-controller, though less redundant.

We could even go as far as using #pwm-cells as the definitive marker and
then require that it has a certain name, like we do for other types of
nodes. I did a quick audit and came up with the following results. These
are all the PWM controller nodes that I could find that don't follow the
"^pwm(@.*)?$" pattern. The files are only one example of where I found
them and there were often others that used the same pattern.

 - arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
     - ec-pwm

       It should be trivial to rename these to just "pwm" since I don't
       see the cros-ec driver relying on the exact name.

 - arch/arm/boot/dts/am5729-beagleboneai.dts
     - stmpe_pwm

       The stmpe MFD driver actually relies on this name, so not sure if
       there's a lot we can do about that.

 - arch/arm/boot/dts/armada-38x.dtsi
     - gpio@...

       This is both a GPIO and PWM controller, so can't really do much
       about the name.

 - arch/arm/boot/dts/at91-kizbox.dts
     - pwm

       Actually also matches the pattern because the '@.*' part is
       optional.

 - arch/arm/boot/dts/at91sam9n12.dtsi
     - hlcdc-pwm

       The MFD driver matches on the compatible string, so we should be
       able to just rename this to "pwm".

 - arch/arm/boot/dts/da850.dtsi
    - ecap@...

      No matching on the name as far as I can tell, so we should be able
      to rename this 'pwm@...'.

 - arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi
    - dmtimer-pwm

      Could probably be renamed 'pwm'.

 - arch/arm/boot/dts/lpc32xx.dtsi
    - mpwm@...

      Could probably be renamed 'pwm'.

 - arch/arm/boot/dts/motorola-mapphone-common.dtsi
    - dmtimer-pwm-*

      Maybe these should be renamed 'pwm@*' instead?

 - arch/arm/boot/dts/s3c24xx.dtsi
    - timer@...

      This is a variant similar to dmtimer-pwm above and is driven by a
      timer that can run in PWM mode. I think this is the same category
      as the GPIO/PWM controller hybrid above.

      Not much we can do about the name.

 - arch/arm/boot/dts/stm32f429.dtsi
    - pwm

      Matches the pattern.

 - arch/arm/boot/dts/twl4030.dtsi
    - pwm

      Matches the pattern.

    - pwmled

      Perhaps both of the above should be named 'pwm@*'? There doesn't
      seem to be any matching on the name.

For many of the above it should be possible to rename them. But then we
will always have exceptions where we can't do that because then it might
conflict with other bindings.

Two interesting things I gathered from the above are that:

  1) nothing in the above actually matches the pwm-* variant that's part
     of the current pattern defined in pwm.yaml and which is causing the
     problem for the pinmux nodes, so an easy solution would be to
     simply drop that part of the pattern since it is useless anyway.

  2) There are actually quite a few PWM controllers that currently are
     not checked because of the name matching. Now I haven't actually
     checked the reverse, i.e. to see if all nodes matching the pattern
     actually have a #pwm-cells property, but given that we miss a
     number of controller because they don't match the pattern makes me
     think that that aspect isn't actually very helpful.

All of the above makes me think even more that we should just abandon
the idea of matching on the names for PWM controller because in some
instances we can't change the name for backwards-compatibility or
because the names would then conflict with other bindings.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-19  7:47 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
2020-06-12 14:18 ` [PATCH 01/38] dt-bindings: interrupt-controller: arm,gic: Add compatible for Tegra186 AGIC Thierry Reding
2020-06-12 14:18 ` [PATCH 02/38] dt-bindings: memory: nvidia: Mark memory controller as interconnect provider Thierry Reding
2020-06-12 14:18 ` [PATCH 03/38] dt-bindings: memory: Increase number of reg entries on Tegra194 Thierry Reding
2020-06-12 14:18 ` [PATCH 04/38] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema Thierry Reding
2020-06-17 22:49   ` Rob Herring
2020-06-12 14:18 ` [PATCH 05/38] dt-bindings: firmware: tegra186-bpmp: Document interconnect paths Thierry Reding
2020-06-17 22:50   ` Rob Herring
2020-06-12 14:18 ` [PATCH 06/38] dt-bindings: display: tegra: Document display-hub Thierry Reding
2020-06-17 22:55   ` Rob Herring
2020-06-18 10:27     ` Thierry Reding
2020-06-18 18:17       ` Rob Herring
2020-06-19  6:45         ` Thierry Reding
2020-06-12 14:18 ` [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema Thierry Reding
2020-06-12 15:54   ` Dmitry Osipenko
2020-06-16 14:51     ` Thierry Reding
2020-06-17 23:13   ` Rob Herring
2020-06-18 14:16     ` Thierry Reding
2020-06-18 15:23       ` Rob Herring
2020-06-19  8:08         ` Thierry Reding
2020-06-12 14:18 ` [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths Thierry Reding
2020-06-12 15:52   ` Dmitry Osipenko
2020-06-16 14:47     ` Thierry Reding
2020-06-12 14:18 ` [PATCH 09/38] dt-bindings: gpu: tegra: Convert to json-schema Thierry Reding
2020-06-18  2:29   ` Rob Herring
2020-06-12 14:18 ` [PATCH 10/38] dt-bindings: gpu: tegra: Document interconnect paths Thierry Reding
2020-06-12 14:18 ` [PATCH 11/38] dt-bindings: mmc: tegra: Convert to json-schema Thierry Reding
2020-06-12 14:18 ` [PATCH 12/38] dt-bindings: mmc: tegra: Document interconnect paths Thierry Reding
2020-06-12 14:18 ` [PATCH 13/38] dt-bindings: pci: tegra: Convert to json-schema Thierry Reding
2020-06-12 14:18 ` [PATCH 14/38] dt-bindings: pci: tegra: Document interconnect paths Thierry Reding
2020-06-12 14:18 ` [PATCH 15/38] dt-bindings: sound: tegra: hda: Convert to json-schema Thierry Reding
2020-06-12 14:18 ` [PATCH 16/38] dt-bindings: sound: tegra: hda: Document interconnect paths Thierry Reding
2020-06-12 14:18 ` [PATCH 17/38] dt-bindings: usb: tegra-xusb: Convert to json-schema Thierry Reding
2020-06-12 14:18 ` [PATCH 18/38] dt-bindings: usb: tegra-xusb: Document interconnect paths Thierry Reding
2020-06-12 14:18 ` [PATCH 19/38] dt-bindings: net: dwc-qos-ethernet: Convert to json-schema Thierry Reding
2020-06-12 14:18 ` [PATCH 20/38] dt-bindings: net: dwc-qos-ethernet: Document interconnect paths Thierry Reding
2020-06-12 14:18 ` [PATCH 21/38] dt-bindings: sound: sgtl5000: Convert to json-schema Thierry Reding
2020-06-18  2:41   ` Rob Herring
2020-06-12 14:18 ` [PATCH 22/38] dt-bindings: gpio: tegra186: Use unique include guard Thierry Reding
2020-06-12 14:18 ` [PATCH 23/38] dt-bindings: gpio: tegra186: Convert to json-schema Thierry Reding
2020-06-18  2:44   ` Rob Herring
2020-06-12 14:18 ` [PATCH 24/38] dt-bindings: mfd: max77620: " Thierry Reding
2020-06-12 14:18 ` [PATCH 25/38] dt-bindings: gpio: tegra: " Thierry Reding
2020-06-17  4:24   ` Dmitry Osipenko
2020-06-17 14:17     ` Thierry Reding
2020-06-17 14:24       ` Dmitry Osipenko
2020-06-17 14:33         ` Dmitry Osipenko
2020-06-17 16:50           ` Thierry Reding
2020-06-18 15:07             ` Dmitry Osipenko
2020-06-12 14:18 ` [PATCH 26/38] dt-bindings: pci: iommu: " Thierry Reding
2020-06-18  2:34   ` Rob Herring
2020-06-18 14:18     ` Thierry Reding
2020-06-19  6:45     ` Thierry Reding
2020-06-12 14:18 ` [PATCH 27/38] dt-bindings: tegra: Add missing compatible strings Thierry Reding
2020-06-12 14:18 ` [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema Thierry Reding
2020-06-18  2:38   ` Rob Herring
2020-06-19  6:47     ` Thierry Reding
2020-06-12 14:18 ` [PATCH 29/38] dt-bindings: tegra: pmc: Increase clock limit for power domains Thierry Reding
2020-06-12 14:18 ` [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels Thierry Reding
2020-06-12 14:29   ` Rob Herring
2020-06-16 14:35     ` Thierry Reding
2020-06-12 14:18 ` [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties Thierry Reding
2020-06-12 14:28   ` Rob Herring
2020-06-16 14:33     ` Thierry Reding
2020-06-12 14:18 ` [PATCH 32/38] dt-bindings: leds: Document rfkill* trigger Thierry Reding
2020-06-12 14:18 ` [PATCH 33/38] dt-bindings: memory-controller: Document Tegra132 EMC Thierry Reding
2020-06-12 14:18 ` [PATCH 34/38] dt-bindings: memory-controller: Fix "reg" entries on Tegra194 Thierry Reding
2020-06-12 14:19 ` [PATCH 35/38] dt-bindings: memory: Update Tegra210 EMC bindings Thierry Reding
2020-06-18 15:36   ` Rob Herring
2020-06-12 14:19 ` [PATCH 36/38] dt-bindings: power: supply: sbs-battery: Document TI BQ20Z45 compatible Thierry Reding
2020-06-12 14:19 ` [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml Thierry Reding
2020-06-18  2:51   ` Rob Herring
2020-06-19  7:46     ` Thierry Reding [this message]
2020-06-19 18:05       ` Rob Herring
2020-06-12 14:19 ` [PATCH 38/38] dt-bindings: serial: Document Tegra-specific properties Thierry Reding
2020-06-18  2:47   ` 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=20200619074654.GD3704347@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-tegra@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 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).