From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Peng Fan <peng.fan@oss.nxp.com>,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
shawnguo@kernel.org, Fabio Estevam <festevam@denx.de>,
Lucas Stach <l.stach@pengutronix.de>,
Sascha Hauer <s.hauer@pengutronix.de>,
kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-imx@nxp.com,
abelvesa@kernel.org, Marek Vasut <marex@denx.de>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Subject: Re: Re: Align fsl,pins with dtschema
Date: Thu, 28 Jul 2022 10:34:08 +0200 [thread overview]
Message-ID: <1920944.usQuhbGJ8B@steina-w> (raw)
In-Reply-To: <26aa352e-d39c-1784-e5c3-9e90d25d8ab5@linaro.org>
Am Dienstag, 26. Juli 2022, 11:35:52 CEST schrieb Krzysztof Kozlowski:
> On 23/07/2022 14:15, Peng Fan wrote:
> > All,
> >
> > I am thinking whether we need to modify the fsl,pins as below. Because
> > fsl,pins use uint32-matrix, so just wanna know we should do this update.
> >
> > Anyway there is NO dtbs check warning. If we update fsl,pins, there are
> > bunches of dts files need update. Do you think we need to update or not?
> >
> > pinctrl_ov5640: ov5640grp {
> >
> > - fsl,pins = <
> > - MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7
> > 0x19 - MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6
> > 0x19 -
> > MX8MM_IOMUXC_GPIO1_IO14_CCMSRCGPCMIX_CLKO1 0x59 - >;
> > + fsl,pins =
> > + <MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7
> > 0x19>,
> > + <MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6
> > 0x19>,
> > + <MX8MM_IOMUXC_GPIO1_IO14_CCMSRCGPCMIX_CLKO1
> > 0x59>;
> >
> > };
>
> I believe yes, but as Rob replied, the dtschema has trouble matching the
> different fsl,pins, if I understood correctly.
I remember getting a lot of warnings, most probably using old dt-schema before
[1] and [2].
[1] only mentions problems detecting matrix "where neither dimension is
fixed".
Having that said, adding a small uint32-matrix example to dt-schema tests
raises errors when used incorrectly. Take the following diff:
---8<---
diff --git a/test/device.dts b/test/device.dts
index 47aa31c..a0988c6 100644
--- a/test/device.dts
+++ b/test/device.dts
@@ -51,5 +51,6 @@
vendor,int-array-prop = <5>, <6>, <7>, <8>;
vendor,int-array-size-only-prop = <2>, <3>, <4>;
vendor,int64-array-prop = /bits/ 64 <0x10000000 0x1>;
+ vendor,uint32-matrix-prop = <1 2 3>, <4 5 6>, <7>;
};
};
\ No newline at end of file
diff --git a/test/schemas/good-example.yaml b/test/schemas/good-example.yaml
index b8493a9..dc72046 100644
--- a/test/schemas/good-example.yaml
+++ b/test/schemas/good-example.yaml
@@ -177,6 +177,17 @@ properties:
- description: the 2nd cell data
description: Vendor specific array of phandles property
+ vendor,uint32-matrix-prop:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: Vendor specific 32-bit integer matrix property
+ items:
+ items:
+ - description: |
+ 1st item
+ - description: |
+ 2nd item
+ - description: |
+ 3rd item
required:
- compatible
---8<---
test-dt-validate.py does detect this misuse:
> Failed validating 'minItems' in schema['properties']['vendor,uint32-matrix-
prop']['items']:
> {'maxItems': 3, 'minItems': 3, 'type': 'array'}
>
> On instance['vendor,uint32-matrix-prop'][2]:
> [7]
This seems pretty good to me.
But apparently this is not true for fsl,pins in board .dts. Given the
following diff, converting to an actual matrix and adding a excessive number
(Note the 5 at the end), this raises no error. So I suspect this is treated as
an array rather than a matrix.
---8<---
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -505,10 +505,9 @@ MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x40
};
pinctrl_uart2: uart2grp {
- fsl,pins = <
- MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x140
- MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x140
- >;
+ fsl,pins =
+ <MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x140 5>;
};
pinctrl_usb1_vbus: usb1grp {
---8<---
This is how I tested:
$ git describe
v5.19-rc8
$ dt-validate --version
2022.8.dev24+g59f2e31
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/pinctrl/
fsl,imx8mp-pinctrl.yaml
make[1]: Entering directory '/mnt/ssd/repo/linux/build_arm64'
DTC arch/arm64/boot/dts/freescale/imx8mp-evk.dtb
CHECK arch/arm64/boot/dts/freescale/imx8mp-evk.dtb
make[1]: Leaving directory '/mnt/ssd/repo/linux/build_arm64'
Best regards,
Alexander
[1] https://lore.kernel.org/all/20220310160513.1708182-3-robh@kernel.org/
[2] https://github.com/devicetree-org/dt-schema/commit/
5646cd473017d702844fda382c7b88994e080ee8
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2022-07-28 8:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-23 12:15 Align fsl,pins with dtschema Peng Fan
2022-07-26 9:35 ` Krzysztof Kozlowski
2022-07-28 8:34 ` Alexander Stein [this message]
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=1920944.usQuhbGJ8B@steina-w \
--to=alexander.stein@ew.tq-group.com \
--cc=abelvesa@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@denx.de \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=marex@denx.de \
--cc=peng.fan@oss.nxp.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@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