On Thu, Jul 30, 2026 at 09:35:02AM +0200, Krzysztof Kozlowski wrote: > On Thu, Jul 30, 2026 at 12:39:08AM +0800, Yu-Chien Peter Lin wrote: > > Add YAML binding schema for the SiFive wgChecker, a programmable > > There is no "YAML" binding schema. > > > access controller integrated in the interconnect fabric of RISC-V > > Worlds-capable SoCs. > > > > wgChecker enforces World ID (WID) based access control on downstream > > bus transactions. Each checker slot encodes a 2-bit permission field > > per WID (read/write), enabling fine-grained memory partitioning and > > device isolation between execution contexts. Violations are reported > > via bus errors, interrupts, or both, selectable and lockable per slot. > > > > The binding registers wgChecker as an access-controllers provider. > > Consumers (i.e. its protected device) reference it via the standard > > access-controllers phandle to declare their access requirements. > > > > Also document the sifive,trustedwid property for the /cpus node, > > identifying the privileged WID authorized to configure all checkers > > on the platform. > > > > Link: https://github.com/riscvarchive/security/blob/main/papers/worldguard%20proposal.pdf > > Signed-off-by: Yu-Chien Peter Lin > > Reviewed-by: Zong Li > > Reviewed-by: Jim Shu > > What exactly these reviews pointed out? > > > --- > > .../devicetree/bindings/riscv/worlds.yaml | 9 + > > .../bindings/sifive/sifive,wgchecker2.yaml | 356 ++++++++++++++++++ > > 2 files changed, 365 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml > > > > diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml > > index cc8b3747591e..c39a06c2dd8d 100644 > > --- a/Documentation/devicetree/bindings/riscv/worlds.yaml > > +++ b/Documentation/devicetree/bindings/riscv/worlds.yaml > > @@ -34,6 +34,14 @@ properties: > > minimum: 2 > > maximum: 64 > > > > + sifive,trustedwid: > > No, for the same reasons. I am not entirely sure that this is defined by the platform compatible, if you've got something like a FPGA with lots of configurability then it may be needed. Then again, yeah maybe it can just come from the platform compatible unlike a device shows up that actually needs it. This is especially true if the consumer of the property is the SBI firmware. (that's assuming "same reason" follows on from your comment on the prior binding) > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + maximum: 31 > > + description: | > > + The World ID (WID) designated as the trusted WID for this platform. > > + Transactions tagged with this WID are authorized to access and configure > > + WorldGuard blocks, including wgCheckers and wgMarkers. > > + > > additionalProperties: true > > > > examples: > > @@ -44,6 +52,7 @@ examples: > > #size-cells = <0>; > > timebase-frequency = <1000000>; > > riscv,nworlds = <4>; > > + sifive,trustedwid = <3>; > > > > cpu@0 { > > device_type = "cpu"; > > diff --git a/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml > > new file mode 100644 > > index 000000000000..c025a4765cb3 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml > > No, you do not get per vendor directory. NAK. > > Do you see Qcom? Or TI? Or NXP? > > Place it in appropriate directory matching the hardware. Which would be access-controllers. > > > > @@ -0,0 +1,356 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +# Copyright (C) 2026 SiFive, Inc. > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/sifive/sifive,wgchecker2.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: SiFive WorldGuard Checker > > + > > +maintainers: > > + - Yu-Chien Peter Lin > > + > > +description: | > > + The RISC-V Worlds ISA extension defines World IDs (WIDs) as architectural > > + identifiers that tag each system transaction with its originating context. > > + System integrators assign WIDs to execution contexts such as privilege modes, > > + trusted execution environments, or other isolation boundaries. > > + > > + The SiFive WorldGuard Checker is a hardware firewall positioned in the > > + system interconnect fabric. It inspects every transaction, evaluating the > > + WID against access control policies encoded in checker slots for each > > + protected resource. Transactions from unauthorized WIDs are blocked and > > + reported as bus errors, interrupts, or both. > > + > > + This enables spatial partitioning of memory regions and memory-mapped devices > > + across execution contexts. Different address ranges can enforce distinct > > + policies, allowing isolated workloads to coexist with hardware-enforced > > + protection. > > + > > + The wgChecker acts as an access-controller provider as defined in the > > + access-controllers framework. Protected devices are consumers that declare > > + their access policy via the access-controllers property. The hardware > > + supports up to 32 World IDs. > > + > > + The World ID authorized to configure WorldGuard blocks is specified by the > > + sifive,trustedwid property in the /cpus node. > > + > > +allOf: > > + - $ref: /schemas/access-controllers/access-controllers.yaml# > > + > > +properties: > > + compatible: > > + oneOf: > > + - items: > > + - const: qemu,wgchecker2 > > + - const: sifive,wgchecker2 > > + - const: sifive,wgchecker2 > > You need soc specific compatibles. > > I do not believe the two review tags did any actual real review. They > would tell you to read writing bindings document, wouldn't they? I did okay the qemu compatible FWIW, the standalone sifive one though I did not.