The #address-cells and #size-cells properties are not useful on the DSI
controller nodes; they are only useful/required on ports and panel(s).
So remove them from the controller node and add them where actually
needed on the various rk3399 based boards.
Next to that, there were several (exact) redefinitions of nodes which
are already present in rk3399-base.dtsi to add a mipi_out endpoint.
Simplify that by referencing the mipi_out phandle and add the endpoint
to that, which allows the removeal of the ports redefinition.
And fix 1 instance where the mipi_out referenced node was not sorted
correctly.
This fixes the following DTB validation warnings:
unnecessary #address-cells/#size-cells without "ranges",
"dma-ranges" or child "reg" property
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
---
arch/arm64/boot/dts/rockchip/rk3399-base.dtsi | 4 ---
.../boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 30 ++++++++-----------
.../dts/rockchip/rk3399-pinephone-pro.dts | 2 ++
.../rk3399-puma-haikou-video-demo.dtso | 12 ++++----
.../dts/rockchip/rk3399-rockpro64-screen.dtso | 21 ++++---------
5 files changed, 26 insertions(+), 43 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
index 9d5f5b083e3c..4dcceb9136b7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-base.dtsi
@@ -2071,8 +2071,6 @@ mipi_dsi: dsi@ff960000 {
resets = <&cru SRST_P_MIPI_DSI0>;
reset-names = "apb";
rockchip,grf = <&grf>;
- #address-cells = <1>;
- #size-cells = <0>;
status = "disabled";
ports {
@@ -2112,8 +2110,6 @@ mipi_dsi1: dsi@ff968000 {
resets = <&cru SRST_P_MIPI_DSI1>;
reset-names = "apb";
rockchip,grf = <&grf>;
- #address-cells = <1>;
- #size-cells = <0>;
#phy-cells = <0>;
status = "disabled";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi
index 5e068377a0a2..100c22af7265 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi
@@ -627,18 +627,10 @@ &mipi_dphy_rx0 {
};
&mipi_dsi {
- status = "okay";
clock-master;
-
- ports {
- mipi_out: port@1 {
- reg = <1>;
-
- mipi_out_panel: endpoint {
- remote-endpoint = <&mipi_in_panel>;
- };
- };
- };
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
mipi_panel: panel@0 {
/* 2 different panels are used, compatibles are in dts files */
@@ -673,15 +665,17 @@ mipi1_in_panel: endpoint {
&mipi_dsi1 {
status = "okay";
+};
- ports {
- mipi1_out: port@1 {
- reg = <1>;
+&mipi_out {
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+};
- mipi1_out_panel: endpoint {
- remote-endpoint = <&mipi1_in_panel>;
- };
- };
+&mipi1_out {
+ mipi1_out_panel: endpoint {
+ remote-endpoint = <&mipi1_in_panel>;
};
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index 909ed14035f7..fe32937a2d16 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -464,6 +464,8 @@ &io_domains {
&mipi_dsi {
clock-master;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
panel@0 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou-video-demo.dtso b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou-video-demo.dtso
index 0377ec860d35..d28880b8dd44 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou-video-demo.dtso
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou-video-demo.dtso
@@ -124,12 +124,6 @@ pca9670: gpio@27 {
};
};
-&mipi_out {
- mipi_out_panel: endpoint {
- remote-endpoint = <&mipi_in_panel>;
- };
-};
-
&mipi_dsi {
#address-cells = <1>;
#size-cells = <0>;
@@ -151,6 +145,12 @@ mipi_in_panel: endpoint {
};
};
+&mipi_out {
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+};
+
&pinctrl {
pca9670 {
pca9670_resetn: pca9670-resetn {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64-screen.dtso b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64-screen.dtso
index b1f4ab22b99c..3a68c5f7c5ff 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64-screen.dtso
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64-screen.dtso
@@ -47,25 +47,11 @@ touch: touchscreen@5d {
};
&mipi_dsi {
+ clock-master;
#address-cells = <1>;
#size-cells = <0>;
-
- clock-master;
status = "okay";
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- mipi_out: port@1 {
- reg = <1>;
-
- mipi_out_panel: endpoint {
- remote-endpoint = <&mipi_in_panel>;
- };
- };
- };
-
mipi_panel: panel@0 {
compatible = "feiyang,fy07024di26a30d";
reg = <0>;
@@ -81,6 +67,11 @@ mipi_in_panel: endpoint {
};
};
+&mipi_out {
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+}
&pwm0 {
status = "okay";
};
--
2.50.0Hi Diederik, kernel test robot noticed the following build errors: [auto build test ERROR on rockchip/for-next] [also build test ERROR on next-20250627] [cannot apply to robh/for-next krzk/for-next krzk-dt/for-next linus/master v6.16-rc3] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Diederik-de-Haas/arm64-dts-rockchip-Refactor-DSI-nodes-on-px30-boards/20250627-233300 base: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next patch link: https://lore.kernel.org/r/20250627152645.740981-3-didi.debian%40cknow.org patch subject: [PATCH 2/8] arm64: dts: rockchip: Refactor DSI nodes on rk3399 boards config: arm64-randconfig-002-20250629 (https://download.01.org/0day-ci/archive/20250629/202506290852.bWro2lBe-lkp@intel.com/config) compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250629/202506290852.bWro2lBe-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202506290852.bWro2lBe-lkp@intel.com/ All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/rockchip/rk3399-rockpro64-screen.dtso:75.1-6 syntax error FATAL ERROR: Unable to parse input tree -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Hi, On Sun Jun 29, 2025 at 2:32 AM CEST, kernel test robot wrote: > kernel test robot noticed the following build errors: > > [auto build test ERROR on rockchip/for-next] > [also build test ERROR on next-20250627] > [cannot apply to robh/for-next krzk/for-next krzk-dt/for-next linus/master v6.16-rc3] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Diederik-de-Haas/arm64-dts-rockchip-Refactor-DSI-nodes-on-px30-boards/20250627-233300 > base: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next > patch link: https://lore.kernel.org/r/20250627152645.740981-3-didi.debian%40cknow.org > patch subject: [PATCH 2/8] arm64: dts: rockchip: Refactor DSI nodes on rk3399 boards > config: arm64-randconfig-002-20250629 (https://download.01.org/0day-ci/archive/20250629/202506290852.bWro2lBe-lkp@intel.com/config) > compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90) > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250629/202506290852.bWro2lBe-lkp@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp@intel.com> > | Closes: https://lore.kernel.org/oe-kbuild-all/202506290852.bWro2lBe-lkp@intel.com/ > > All errors (new ones prefixed by >>): > >>> Error: arch/arm64/boot/dts/rockchip/rk3399-rockpro64-screen.dtso:75.1-6 syntax error > FATAL ERROR: Unable to parse input tree The kernel test robot is right as the ``&mipi_out`` node is missing a closing ``;``, so thanks for that :-) The problem is also present in v2, so I'll send a v3 shortly. Luckily I've now found why my build script didn't catch it. ```sh export PATH=~/dev/kernel.org/dt-schema-venv/bin/:$PATH CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make distclean make debarm64_defconfig make CHECK_DTBS=y W=1 rockchip/px30-cobra-ltk050h3146w-a2.dtb <quite-a-long-list-of-all-boards-at-least-I-thought-so> ``` (debarm64_defconfig is my own defconfig based on Debian's kernel config) That long list didn't have ``rockchip/rk3399-rockpro64-screen.dtbo``. Is there a better/simpler way to validate all rockchip boards without having to explicitly list each and every one of them? Cheers, Diederik
On 29/06/2025 12:09, Diederik de Haas wrote: > Hi, > > On Sun Jun 29, 2025 at 2:32 AM CEST, kernel test robot wrote: >> kernel test robot noticed the following build errors: >> >> [auto build test ERROR on rockchip/for-next] >> [also build test ERROR on next-20250627] >> [cannot apply to robh/for-next krzk/for-next krzk-dt/for-next linus/master v6.16-rc3] >> [If your patch is applied to the wrong git tree, kindly drop us a note. >> And when submitting patch, we suggest to use '--base' as documented in >> https://git-scm.com/docs/git-format-patch#_base_tree_information] >> >> url: https://github.com/intel-lab-lkp/linux/commits/Diederik-de-Haas/arm64-dts-rockchip-Refactor-DSI-nodes-on-px30-boards/20250627-233300 >> base: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next >> patch link: https://lore.kernel.org/r/20250627152645.740981-3-didi.debian%40cknow.org >> patch subject: [PATCH 2/8] arm64: dts: rockchip: Refactor DSI nodes on rk3399 boards >> config: arm64-randconfig-002-20250629 (https://download.01.org/0day-ci/archive/20250629/202506290852.bWro2lBe-lkp@intel.com/config) >> compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90) >> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250629/202506290852.bWro2lBe-lkp@intel.com/reproduce) >> >> If you fix the issue in a separate patch/commit (i.e. not just a new version of >> the same patch/commit), kindly add following tags >> | Reported-by: kernel test robot <lkp@intel.com> >> | Closes: https://lore.kernel.org/oe-kbuild-all/202506290852.bWro2lBe-lkp@intel.com/ >> >> All errors (new ones prefixed by >>): >> >>>> Error: arch/arm64/boot/dts/rockchip/rk3399-rockpro64-screen.dtso:75.1-6 syntax error >> FATAL ERROR: Unable to parse input tree > > The kernel test robot is right as the ``&mipi_out`` node is missing a > closing ``;``, so thanks for that :-) > The problem is also present in v2, so I'll send a v3 shortly. > > Luckily I've now found why my build script didn't catch it. > ```sh > export PATH=~/dev/kernel.org/dt-schema-venv/bin/:$PATH CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 > make distclean > make debarm64_defconfig > make CHECK_DTBS=y W=1 rockchip/px30-cobra-ltk050h3146w-a2.dtb > <quite-a-long-list-of-all-boards-at-least-I-thought-so> > ``` > > (debarm64_defconfig is my own defconfig based on Debian's kernel config) > > That long list didn't have ``rockchip/rk3399-rockpro64-screen.dtbo``. > Is there a better/simpler way to validate all rockchip boards without > having to explicitly list each and every one of them? make defconfig && make or make dtbs Best regards, Krzysztof
On Mon Jun 30, 2025 at 7:57 AM CEST, Krzysztof Kozlowski wrote: > On 29/06/2025 12:09, Diederik de Haas wrote: >> >> Luckily I've now found why my build script didn't catch it. >> ```sh >> export PATH=~/dev/kernel.org/dt-schema-venv/bin/:$PATH CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 >> make distclean >> make debarm64_defconfig >> make CHECK_DTBS=y W=1 rockchip/px30-cobra-ltk050h3146w-a2.dtb >> <quite-a-long-list-of-all-boards-at-least-I-thought-so> >> ``` >> >> (debarm64_defconfig is my own defconfig based on Debian's kernel config) >> >> That long list didn't have ``rockchip/rk3399-rockpro64-screen.dtbo``. >> Is there a better/simpler way to validate all rockchip boards without >> having to explicitly list each and every one of them? > make defconfig && make > > or make dtbs ``make dtbs`` is faster then I recalled, but I do like the detail with ``make CHECK_DTBS=y W=1 rockchip/<board1>.dtb rockchip/<board2>.dtb``. If I don't specify a list of boards, then it will build them all including freescale/qcom/renesas/etc, while I only want the rockchip ones. And as my script takes 20-30 minutes, that will probably be several hours. Per run. And I ran it after each patch. Giving ``rockchip/*.dtb[o]`` as parameter is basically what I want, but I'm not aware of that being possible. OTOH it's (already) a script, so I will probably just do a ``find`` to dynamically generate the board list. Cheers, Diederik
Hi Diederik, On 6/27/25 5:16 PM, Diederik de Haas wrote: > The #address-cells and #size-cells properties are not useful on the DSI > controller nodes; they are only useful/required on ports and panel(s). > So remove them from the controller node and add them where actually > needed on the various rk3399 based boards. > > Next to that, there were several (exact) redefinitions of nodes which > are already present in rk3399-base.dtsi to add a mipi_out endpoint. > Simplify that by referencing the mipi_out phandle and add the endpoint > to that, which allows the removeal of the ports redefinition. > > And fix 1 instance where the mipi_out referenced node was not sorted > correctly. > > This fixes the following DTB validation warnings: > > unnecessary #address-cells/#size-cells without "ranges", > "dma-ranges" or child "reg" property > Too many unrelated changes in this commit, please split into multiple commits. I could identify: - moving address-cells/size-cells from SoC.dtsi to board dts(i)s, - reordering properties to better match DT coding style https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node - use phandle to directly access ports, - reorder DT node to better match DT coding style https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes The change for RK3399 Puma Haikou Video Demo DTSO is fine for me. Cheers, Quentin
Hi Quentin, Thanks for taking a look. On Fri Jun 27, 2025 at 6:10 PM CEST, Quentin Schulz wrote: > On 6/27/25 5:16 PM, Diederik de Haas wrote: >> The #address-cells and #size-cells properties are not useful on the DSI >> controller nodes; they are only useful/required on ports and panel(s). >> So remove them from the controller node and add them where actually >> needed on the various rk3399 based boards. >> >> Next to that, there were several (exact) redefinitions of nodes which >> are already present in rk3399-base.dtsi to add a mipi_out endpoint. >> Simplify that by referencing the mipi_out phandle and add the endpoint >> to that, which allows the removeal of the ports redefinition. >> >> And fix 1 instance where the mipi_out referenced node was not sorted >> correctly. >> >> This fixes the following DTB validation warnings: >> >> unnecessary #address-cells/#size-cells without "ranges", >> "dma-ranges" or child "reg" property >> > > Too many unrelated changes in this commit, please split into multiple > commits. > > I could identify: > > - moving address-cells/size-cells from SoC.dtsi to board dts(i)s, > - reordering properties to better match DT coding style > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node > - use phandle to directly access ports, > - reorder DT node to better match DT coding style > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes I initially had it as several commits, but that resulted in (f.e.) 1 issue being fixed, but 1 (or more) others would pop up. Those were then fixed in follow-up commits, but I assumed I'd get Rob's bot screaming at me for introducing new warnings (first). And as they all relate(d) to fixing the dsi node, I then choose to combine them (but still separated by SoC). IMO there are several ways to organize the commits and each would have their pros and cons, so I 'settled' for this arrangement. So I prefer to wait for other people's opinion first before reorganizing the commits again (if there's a different consensus). > The change for RK3399 Puma Haikou Video Demo DTSO is fine for me. Thanks :) Cheers, Diederik
Am Freitag, 27. Juni 2025, 18:52:08 Mitteleuropäische Sommerzeit schrieb Diederik de Haas: > Hi Quentin, > > Thanks for taking a look. > > On Fri Jun 27, 2025 at 6:10 PM CEST, Quentin Schulz wrote: > > On 6/27/25 5:16 PM, Diederik de Haas wrote: > >> The #address-cells and #size-cells properties are not useful on the DSI > >> controller nodes; they are only useful/required on ports and panel(s). > >> So remove them from the controller node and add them where actually > >> needed on the various rk3399 based boards. > >> > >> Next to that, there were several (exact) redefinitions of nodes which > >> are already present in rk3399-base.dtsi to add a mipi_out endpoint. > >> Simplify that by referencing the mipi_out phandle and add the endpoint > >> to that, which allows the removeal of the ports redefinition. > >> > >> And fix 1 instance where the mipi_out referenced node was not sorted > >> correctly. > >> > >> This fixes the following DTB validation warnings: > >> > >> unnecessary #address-cells/#size-cells without "ranges", > >> "dma-ranges" or child "reg" property > >> > > > > Too many unrelated changes in this commit, please split into multiple > > commits. > > > > I could identify: > > > > - moving address-cells/size-cells from SoC.dtsi to board dts(i)s, > > - reordering properties to better match DT coding style > > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node > > - use phandle to directly access ports, > > - reorder DT node to better match DT coding style > > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes > > I initially had it as several commits, but that resulted in (f.e.) 1 > issue being fixed, but 1 (or more) others would pop up. > Those were then fixed in follow-up commits, but I assumed I'd get Rob's > bot screaming at me for introducing new warnings (first). > > And as they all relate(d) to fixing the dsi node, I then choose to > combine them (but still separated by SoC). > IMO there are several ways to organize the commits and each would have > their pros and cons, so I 'settled' for this arrangement. > > So I prefer to wait for other people's opinion first before reorganizing > the commits again (if there's a different consensus). personally, I can live with the current setup here, because as you said it's all DSI related, and also not a functional change ;-) . I guess you _could_ move the clock-master + status moves into a separate patch, as that should not trigger any warnings. > > The change for RK3399 Puma Haikou Video Demo DTSO is fine for me. > > Thanks :) > > Cheers, > Diederik >
Hi Heiko & Quentin, On Fri Jun 27, 2025 at 8:25 PM CEST, Heiko Stübner wrote: > Am Freitag, 27. Juni 2025, 18:52:08 Mitteleuropäische Sommerzeit schrieb Diederik de Haas: >> On Fri Jun 27, 2025 at 6:10 PM CEST, Quentin Schulz wrote: >> > On 6/27/25 5:16 PM, Diederik de Haas wrote: >> >> The #address-cells and #size-cells properties are not useful on the DSI >> >> controller nodes; they are only useful/required on ports and panel(s). >> >> So remove them from the controller node and add them where actually >> >> needed on the various rk3399 based boards. >> >> >> >> Next to that, there were several (exact) redefinitions of nodes which >> >> are already present in rk3399-base.dtsi to add a mipi_out endpoint. >> >> Simplify that by referencing the mipi_out phandle and add the endpoint >> >> to that, which allows the removeal of the ports redefinition. >> >> >> >> And fix 1 instance where the mipi_out referenced node was not sorted >> >> correctly. >> >> >> >> This fixes the following DTB validation warnings: >> >> >> >> unnecessary #address-cells/#size-cells without "ranges", >> >> "dma-ranges" or child "reg" property >> >> >> > >> > Too many unrelated changes in this commit, please split into multiple >> > commits. >> > >> > I could identify: >> > >> > - moving address-cells/size-cells from SoC.dtsi to board dts(i)s, >> > - reordering properties to better match DT coding style >> > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node >> > - use phandle to directly access ports, >> > - reorder DT node to better match DT coding style >> > https://www.kernel.org/doc/html/latest/devicetree/bindings/dts-coding-style.html#order-of-nodes >> >> I initially had it as several commits, but that resulted in (f.e.) 1 >> issue being fixed, but 1 (or more) others would pop up. >> Those were then fixed in follow-up commits, but I assumed I'd get Rob's >> bot screaming at me for introducing new warnings (first). >> >> And as they all relate(d) to fixing the dsi node, I then choose to >> combine them (but still separated by SoC). >> IMO there are several ways to organize the commits and each would have >> their pros and cons, so I 'settled' for this arrangement. >> >> So I prefer to wait for other people's opinion first before reorganizing >> the commits again (if there's a different consensus). > > personally, I can live with the current setup here, because as you said > it's all DSI related, and also not a functional change ;-) . > > I guess you _could_ move the clock-master + status moves into a separate > patch, as that should not trigger any warnings. After having thought a bit more about it, I actually agree that the moving of address/size-cells from SoC to board dts[i] should be separate from extracting the ports/endpoints into a node with a phandle reference. This patch set is actually from 2 branches: - dtb-fixes-dsi - dtb-fixes-ports-endpoints (although I now use 'dtb-fixes-fruit') ports-endpoints is on top of dsi and came forth as it made sense to do the ports/endpoints extraction in more places. I'll then also put the DT node movement in a separate patch. I'm not a fan of putting clock-master + status property move into a separate patch as then the address/size patch would look weird (to me) as you'd see how those properties were inconsistently sorted ... just so that can be fixed in a separate patch. Cheers, Diederik
© 2016 - 2025 Red Hat, Inc.