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: <20250205095547.536083-2-herve.codina@bootlin.com>
Date: Wed,  5 Feb 2025 10:55:42 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Uwe Kleine-König <ukleinek@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Herve Codina <herve.codina@...tlin.com>
Cc: linux-pwm@...r.kernel.org,
	devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: [PATCH v3 1/2] dt-bindings: pwm: Add support for PWM nexus node

Platforms can have a standardized connector/expansion slot that exposes
PWMs signals to expansion boards.

A nexus node [1] allows to remap a phandle list in a consumer node
through a connector node in a generic way. With this remapping, the
consumer node needs to know only about the nexus node. Resources behind
the nexus node are decoupled by the nexus node itself.

This is particularly useful when this consumer is described in a
device-tree overlay. Indeed, to have the exact same overlay reused with
several base systems the overlay needs to known only about the connector
is going to be applied to without any knowledge of the SoC (or the
component providing the resource) available in the system.

As an example, suppose 3 PWMs connected to a connector. The connector
PWM 0 and 2 comes from the PWM 1 and 3 of the pwm-controller1. The
connector PWM 1 comes from the PWM 4 of the pwm-controller2. An
expansion device is connected to the connector and uses the connector
PMW 1.

Nexus node support in PWM allows the following description:
        soc {
                soc_pwm1: pwm-controller1 {
                        #pwm-cells = <3>;
                };

                soc_pwm2: pwm-controller2 {
                        #pwm-cells = <3>;
                };
        };

        connector: connector {
                #pwm-cells = <3>;
                pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
                          <1 0 0 &soc_pwm2 4 0 0>,
                          <2 0 0 &soc_pwm1 3 0 0>;
                pwm-map-mask = <0xffffffff 0x0 0x0>;
                pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
        };

        expansion_device {
                pwms = <&connector 1 57000 0>;
        };

>From the expansion device point of view, the PWM requested is the PWM 1
available at the connector regardless of the exact PWM wired to this
connector PWM 1. Thanks to nexus node remapping described at connector
node, this PWM is the PWM 4 of the pwm-controller2.

[1] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping

Signed-off-by: Herve Codina <herve.codina@...tlin.com>
---
 .../bindings/pwm/pwm-nexus-node.yaml          | 65 +++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml

diff --git a/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
new file mode 100644
index 000000000000..55412fe50d01
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-nexus-node.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM Nexus node properties
+
+description:
+  Platforms can have a standardized connector/expansion slot that exposes PWMs
+  signals to expansion boards.
+
+  A nexus node allows to remap a phandle list in a consumer node through a
+  connector node in a generic way. With this remapping, the consumer node needs
+  to know only about the nexus node. Resources behind the nexus node are
+  decoupled by the nexus node itself.
+
+maintainers:
+  - Herve Codina <herve.codina@...tlin.com>
+
+select: true
+
+properties:
+  '#pwm-cells': true
+
+  pwm-map:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+  pwm-map-mask:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  pwm-map-pass-thru:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+dependentRequired:
+  pwm-map: ['#pwm-cells']
+  pwm-map-mask: [ pwm-map ]
+  pwm-map-pass-thru: [ pwm-map ]
+
+additionalProperties: true
+
+examples:
+  - |
+        pwm1: pwm@100 {
+            reg = <0x100 0x10>;
+            #pwm-cells = <3>;
+        };
+
+        pwm2: pwm@200 {
+            reg = <0x200 0x10>;
+            #pwm-cells = <3>;
+        };
+
+        connector: connector {
+            #pwm-cells = <3>;
+            pwm-map = <0 0 0 &pwm1 1 0 0>,
+                      <1 0 0 &pwm2 4 0 0>,
+                      <2 0 0 &pwm1 3 0 0>;
+            pwm-map-mask = <0xffffffff 0x0 0x0>;
+            pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
+        };
+
+        device {
+            pwms = <&connector 1 57000 0>;
+        };
-- 
2.47.1


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ