Schemas for array properties should only have 1 level of array
constraints (e.g. items, maxItems, minItems). Sometimes the old
encoding of all properties into a matrix leaked into the schema, and
didn't matter for validation. Now the inner constraints are just
silently ignored as json-schema array keywords are ignored on scalar
values.
Generally, keep the inner constraints and drop the outer "items". With
gicv3 "mbi-alias" property, it is more appropriately a uint32 or uint64
as it is an address and size depends on "#address-cells".
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240925232409.2208515-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The GIC v3 specifications allow redistributors and ITSes interconnect
ports used to access memory to be wired up in a way that makes the
respective initiators/memory observers non-coherent.
Add the standard dma-noncoherent property to the GICv3 bindings to
allow firmware to describe the redistributors/ITSes components and
interconnect ports behaviour in system designs where the redistributors
and ITSes are not coherent with the CPU.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231006125929.48591-2-lpieralisi@kernel.org
When trying to turn on the "pseudo NMI" kernel feature in Linux, it
was discovered that all Mediatek-based Chromebooks that ever shipped
(at least ones with GICv3) had a firmware bug where they wouldn't save
certain GIC "GICR" registers properly. If a processor ever entered a
suspend/idle mode where the GICR registers lost state then they'd be
reset to their default state.
As a result of the bug, if you try to enable "pseudo NMIs" on the
affected devices then certain interrupts will unexpectedly get
promoted to be "pseudo NMIs" and cause crashes / freezes / general
mayhem.
ChromeOS is looking to start turning on "pseudo NMIs" in production to
make crash reports more actionable. To do so, we will release firmware
updates for at least some of the affected Mediatek Chromebooks.
However, even when we update the firmware of a Chromebook it's always
possible that a user will end up booting with old firmware. We need to
be able to detect when we're running with firmware that will crash and
burn if pseudo NMIs are enabled.
The current plan is:
* Update the device trees of all affected Chromebooks to include the
'mediatek,broken-save-restore-fw' property. The kernel can use this
to know not to enable certain features like "pseudo NMI". NOTE:
device trees for Chromebooks are never baked into the firmware but
are bundled with the kernel. A kernel will never be configured to
use "pseudo NMIs" and be bundled with an old device tree.
* When we get a fixed firmware for one of these Chromebooks, it will
patch the device tree to remove this property.
For some details, you can also see the public bug
<https://issuetracker.google.com/281831288>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230515131353.v2.1.Iabe67a827e206496efec6beb5616d5a3b99c1e65@changeid
A GICv3 implementation without virtualization, such as the base QEMU
virt machine (without -M virtualization=on), does not issue maintenance
interrupts. Therefore its device-tree node does not need an 'interrupts'
property. Currently, validating the QEMU virt device-tree throws a
warning that 'interrupts' is missing. Make it optional.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220822152224.507497-3-jean-philippe@linaro.org
A common mistake when writing a device tree for a platform that is using
GICv3 with ancient CPUs is to overlook the MMIO frames that implement
the GICv2 compatibility feature, because this feature is implemented by
the CPUs and not by the GIC itself.
The compatibility feature itself is optional (all the modern
implementations have dropped it), but is present in all the ARM Ltd
implementations of the ARMv8.0 architecture (A3x, A53, A57, A72, A73),
and many others from various implementers.
Make it explicit that GICC, GICH and GICV are required for these CPUs.
Also take this opportunity to update my email address, as people keep
sending them to the wrong place...
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220409101617.268796-1-maz@kernel.org
The 'phandle-array' type is a bit ambiguous. It can be either just an
array of phandles or an array of phandles plus args. Many schemas for
phandle-array properties aren't clear in the schema which case applies
though the description usually describes it.
The array of phandles case boils down to needing:
items:
maxItems: 1
The phandle plus args cases should typically take this form:
items:
- items:
- description: A phandle
- description: 1st arg cell
- description: 2nd arg cell
With this change, some examples need updating so that the bracketing of
property values matches the schema.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Georgi Djakov <djakov@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20220119015038.2433585-1-robh@kernel.org
json-schema versions draft7 and earlier have a weird behavior in that
any keywords combined with a '$ref' are ignored (silently). The correct
form was to put a '$ref' under an 'allOf'. This behavior is now changed
in the 2019-09 json-schema spec and '$ref' can be mixed with other
keywords. The json-schema library doesn't yet support this, but the
tooling now does a fixup for this and either way works.
This has been a constant source of review comments, so let's change this
treewide so everyone copies the simpler syntax.
Scripted with ruamel.yaml with some manual fixups. Some minor whitespace
changes from the script.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-By: Vinod Koul <vkoul@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de> # for I2C
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for-iio
Reviewed-by: Stephen Boyd <sboyd@kernel.org> # clock
Signed-off-by: Rob Herring <robh@kernel.org>
Add missing 'type: object' schema to interrupt-partition-* nodes. Found
with fix to meta-schema checks.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
GICv3.1 introduces support for new interrupt ranges, one of them being
the Extended SPI range (ESPI). The DT binding is extended to deal with
it as a new interrupt class.
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
