| 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
| ||
|
Message-Id: <20200917165301.23100-2-krzk@kernel.org>
Date: Thu, 17 Sep 2020 18:52:49 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Rob Herring <robh+dt@...nel.org>, Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
bcm-kernel-feedback-list@...adcom.com,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Hoan Tran <hoan@...amperecomputing.com>,
Serge Semin <fancer.lancer@...il.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Jacopo Mondi <jacopo+renesas@...ndi.org>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
Niklas Söderlund
<niklas.soderlund+renesas@...natech.se>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Charles Keepax <ckeepax@...nsource.cirrus.com>,
Richard Fitzgerald <rf@...nsource.cirrus.com>,
Lee Jones <lee.jones@...aro.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...com>,
Andreas Färber <afaerber@...e.de>,
Maxime Ripard <mripard@...nel.org>,
Chen-Yu Tsai <wens@...e.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Chris Packham <chris.packham@...iedtelesis.co.nz>,
Anson Huang <Anson.Huang@....com>,
Sungbo Eo <mans0n@...ani.run>, Stefan Agner <stefan@...er.ch>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Magnus Damm <magnus.damm@...il.com>,
Yash Shah <yash.shah@...ive.com>,
Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
- <patches@...nsource.cirrus.com>,
Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
Amelie Delaunay <amelie.delaunay@...com>,
Cristian Ciocaltea <cristian.ciocaltea@...il.com>,
Paul Cercueil <paul@...pouillou.net>,
Andy Teng <andy.teng@...iatek.com>,
Sean Wang <sean.wang@...iatek.com>,
Sricharan R <sricharan@...eaurora.org>,
Chris Brandt <chris.brandt@...esas.com>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, linux-gpio@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-unisoc@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-media@...r.kernel.org, alsa-devel@...a-project.org,
linux-stm32@...md-mailman.stormreply.com,
linux-mediatek@...ts.infradead.org,
linux-renesas-soc@...r.kernel.org
Cc: Krzysztof Kozlowski <krzk@...nel.org>
Subject: [PATCH v2 01/13] dt-bindings: gpio: add common schema for GPIO controllers
Convert parts of gpio.txt bindings into common dtschema file for GPIO
controllers. The schema enforces proper naming of GPIO controller nodes
and GPIO hogs.
The schema should be included by specific GPIO controllers bindings.
Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>
---
Changes since v1:
1. Do not require compatible (some child nodes are gpio-controllers
without the compatible).
---
.../devicetree/bindings/gpio/gpio-common.yaml | 125 ++++++++++++++++++
1 file changed, 125 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-common.yaml
diff --git a/Documentation/devicetree/bindings/gpio/gpio-common.yaml b/Documentation/devicetree/bindings/gpio/gpio-common.yaml
new file mode 100644
index 000000000000..af9f6c7feeec
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-common.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common GPIO controller properties
+
+maintainers:
+ - Krzysztof Kozlowski <krzk@...nel.org>
+ - Linus Walleij <linus.walleij@...aro.org>
+
+properties:
+ nodename:
+ pattern: "^(gpio-controller|gpio)(@[0-9a-f]+|-[0-9a-f]+)?$"
+
+ '#gpio-cells': true
+ gpio-controller: true
+ gpio-ranges: true
+
+ gpio-line-names:
+ description: |
+ Optionally, a GPIO controller may have a "gpio-line-names" property. This
+ is an array of strings defining the names of the GPIO lines going out of
+ the GPIO controller. This name should be the most meaningful producer
+ name for the system, such as a rail name indicating the usage. Package
+ names such as pin name are discouraged: such lines have opaque names
+ (since they are by definition generic purpose) and such names are usually
+ not very helpful.
+
+ For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are reasonable
+ line names as they describe what the line is used for. "GPIO0" is not a
+ good name to give to a GPIO line.
+
+ Placeholders are discouraged: rather use the "" (blank string) if the use
+ of the GPIO line is undefined in your design. The names are assigned
+ starting from line offset 0 from left to right from the passed array. An
+ incomplete array (where the number of passed named are less than ngpios)
+ will still be used up until the last provided valid line index.
+
+ gpio-reserved-ranges:
+ description:
+ Indicates the start and size of the GPIOs that can't be used.
+
+ ngpios:
+ description: |
+ Optionally, a GPIO controller may have a "ngpios" property. This property
+ indicates the number of in-use slots of available slots for GPIOs. The
+ typical example is something like this: the hardware register is 32 bits
+ wide, but only 18 of the bits have a physical counterpart. The driver is
+ generally written so that all 32 bits can be used, but the IP block is
+ reused in a lot of designs, some using all 32 bits, some using 18 and
+ some using 12. In this case, setting "ngpios = <18>;" informs the driver
+ that only the first 18 GPIOs, at local offset 0 .. 17, are in use.
+
+ If these GPIOs do not happen to be the first N GPIOs at offset 0...N-1,
+ an additional set of tuples is needed to specify which GPIOs are
+ unusable, with the gpio-reserved-ranges binding.
+
+patternProperties:
+ "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
+ type: object
+ description:
+ The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
+ providing automatic GPIO request and configuration as part of the
+ gpio-controller's driver probe function.
+ Each GPIO hog definition is represented as a child node of the GPIO controller.
+
+ properties:
+ gpio-hog: true
+ gpios: true
+ input: true
+ output-high: true
+ output-low: true
+ line-name:
+ description:
+ The GPIO label name. If not present the node name is used.
+
+ required:
+ - gpio-hog
+ - gpios
+
+ oneOf:
+ - required:
+ - input
+ - required:
+ - output-high
+ - required:
+ - output-low
+
+ additionalProperties: false
+
+required:
+ - "#gpio-cells"
+ - gpio-controller
+
+examples:
+ - |
+ gpio-controller@...00000 {
+ compatible = "foo";
+ reg = <0x15000000 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <18>;
+ gpio-reserved-ranges = <0 4>, <12 2>;
+ gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R",
+ "LED G", "LED B", "Col A", "Col B", "Col C", "Col D",
+ "Row A", "Row B", "Row C", "Row D", "NMI button",
+ "poweroff", "reset";
+ };
+
+ - |
+ gpio-controller@...0 {
+ compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
+ reg = <0x1400 0x18>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ line-b-hog {
+ gpio-hog;
+ gpios = <6 0>;
+ input;
+ line-name = "foo-bar-gpio";
+ };
+ };
--
2.17.1
Powered by blists - more mailing lists