linux-kernel - Re: [PATCH v1 1/3] arm64: dts: marvell: Fix anyOf conditional failed

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] [day] [month] [year] [list]

Message-ID: <ZzNOD_dpK0e4WFLL@ryzen>
Date: Tue, 12 Nov 2024 13:46:07 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: frank-w@...lic-files.de, Andrew Lunn <andrew@...n.ch>,
	Frank Wunderlich <linux@...web.de>,
	Damien Le Moal <dlemoal@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Gregory Clement <gregory.clement@...tlin.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Hans de Goede <hdegoede@...hat.com>, Jens Axboe <axboe@...nel.dk>,
	linux-ide@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v1 1/3] arm64: dts: marvell: Fix anyOf conditional failed

On Tue, Nov 12, 2024 at 01:36:51PM +0100, Niklas Cassel wrote:
> On Mon, Nov 11, 2024 at 10:25:12AM -0600, Rob Herring wrote:
> > > >
> > > >I don't know the yaml too well, but it is not obvious how adding a few
> > > >status = "disabled"; status = "okay"; fixes a "'anyOf' conditional failed".
> > > >
> > > >Maybe you can expand the explanation a bit?
> > > >
> > > >       Andrew
> > >
> > > Hi angelo,
> > >
> > > I guess the dtbs_check only checks required properties from yaml if the node is enabled.
> > 
> > Yes, that is exactly how it works.
> > 
> > Rob
> 
> Hello Rob,
> 
> If we look at e.g. this binding:
> Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
> 
> We can see that it does not define iommu-map in the binding,
> likewise the binding does have:
> unevaluatedProperties: false
> 
> 
> If I apply my patch that adds iommu-map for e.g. the pcie2x1l0 node:
> (the patch does not add anything to the binding above):
> https://lore.kernel.org/linux-rockchip/20241107123732.1160063-2-cassel@kernel.org/
> 
> 
> If look at the pcie2x1l0 node, it is marked as status = "disabled"
> in arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
> 
> but is marked as status = "enabled"
> in arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> 
> If I run CHECK_DTBS for this dts/dtb:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CHECK_DTBS=y rockchip/rk3588-rock-5b.dtb
>   DTC [C] arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dtb
> $ 
> 
> No warnings.
> 
> What am I missing?
> 
> Considering the warning in this series where the binding also
> had unevaluatedProperties: false
> I would have expected the same error for the pcie2x1l0 node.
> 
> (And if I look at most PCI controler bindings, they actually do define
> iommu-map, so it seems a requirement for it to be defined if used.)
> 

Or perhaps the question should have been, if iommu-map is an exception,
why isn't iommus also an exception?


Kind regards,
Niklas