Pull devicetree updates from Rob Herring:
"DT bindings:
- Convert lattice,ice40-fpga-mgr, apm,xgene-storm-dma,
brcm,sr-thermal, amazon,al-thermal, brcm,ocotp, mt8173-mdp, Actions
Owl SPS, Marvell AP80x System Controller, Marvell CP110 System
Controller, cznic,moxtet, and apm,xgene-slimpro-mbox to DT schema
format
- Add i.MX95 fsl,irqsteer, MT8365 Mali Bifrost GPU, Anvo ANV32C81W
EEPROM, and Microchip pic64gx PLIC
- Add missing LGE, AMD Seattle, and APM X-Gene SoC platform
compatibles
- Updates to brcm,bcm2836-l1-intc, brcm,bcm2835-hvs, and bcm2711-hdmi
bindings to fix warnings on BCM2712 platforms
- Drop obsolete db8500-thermal.txt
- Treewide clean-up of extra blank lines and inconsistent quoting
- Ensure all .dtbo targets are applied to a base .dtb
- Speed up dt_binding_check by skipping running validation on empty
examples
DT core:
- Add of_machine_device_match() and of_machine_get_match_data()
helpers and convert users treewide
- Fix bounds checking of address properties in FDT code. Rework the
code to have a single implementation of the bounds checks.
- Rework of_irq_init() to ignore any implicit interrupt-parent (i.e.
in a parent node) on nodes without an interrupt. This matches the
spec description and fixes some RISC-V platforms.
- Avoid a spurious message on overlay removal
- Skip DT kunit tests on RISCV+ACPI"
* tag 'devicetree-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (55 commits)
dt-bindings: kbuild: Skip validating empty examples
dt-bindings: interrupt-controller: brcm,bcm2836-l1-intc: Drop interrupt-controller requirement
dt-bindings: display: Fix brcm,bcm2835-hvs bindings for BCM2712
dt-bindings: display: bcm2711-hdmi: Add interrupt details for BCM2712
of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root node
soc: tegra: Simplify with of_machine_device_match()
soc: qcom: ubwc: Simplify with of_machine_get_match_data()
powercap: dtpm: Simplify with of_machine_get_match_data()
platform: surface: Simplify with of_machine_get_match_data()
irqchip/atmel-aic: Simplify with of_machine_get_match_data()
firmware: qcom: scm: Simplify with of_machine_device_match()
cpuidle: big_little: Simplify with of_machine_device_match()
cpufreq: sun50i: Simplify with of_machine_device_match()
cpufreq: mediatek: Simplify with of_machine_get_match_data()
cpufreq: dt-platdev: Simplify with of_machine_get_match_data()
of: Add wrappers to match root node with OF device ID tables
dt-bindings: eeprom: at25: Add Anvo ANV32C81W
of/reserved_mem: Simplify the logic of __reserved_mem_alloc_size()
of/reserved_mem: Simplify the logic of fdt_scan_reserved_mem_reg_nodes()
of/reserved_mem: Simplify the logic of __reserved_mem_reserve_reg()
...
Currently, CMD-DB names for RPMH regulators follow this format:
`^(smps|ldo|bob|vs)[a-n][1-9][0-9]?$`
Here, the `[a-n]` value is read from the `pmic-id` DT property,
which is unique to each PMIC present on the board.
Note that in this older CMD-DB name format the SPMI bus on which
a particular PMIC regulator exists was not apparent from its
CMD-DB name.
New targets like Glymur, where we have multiple SPMI buses,
overcome this limitation by following a new CMD-DB name format:
`^(L|S|B)[1-9][0-9]?[A-N]_E[0-3]$`
Here `[A-N]_E[0-3]` part will now be read from the `pmic-id` DT
prop and it includes the SPMI bus id `[0-3]` as well.
However, the PMIC ID part `[A-N]` of the CMD-DB name is now
unique only to the SPMI bus that the PMIC regulator is present
on. which means `L1B_E0` and `L1B_E1` are both possible CMD-DB
names for two different regulator LDOs present on two different
SPMI buses (bus id 0 and 1) on the same board.
Note that since the new `pmic-id` DT property is a combo of
PMIC ID and SPMI bus ID, so its still unique to each PMIC
present on the board.
Update the `pmic-id` property pattern information to reflect this
change in the driver handling to support this new CMD-DB naming
format while maintaining backward compatiblilty with old CMD-DB
naming format which is still supported for older/existing
targets.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-2-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For RPMH regulators it doesn't make sense to indicate
regulator-allow-set-load without saying what modes you can switch to,
so be sure to indicate a dependency on regulator-allowed-modes.
In general this is true for any regulators that are setting modes
instead of setting a load directly, for example RPMH regulators. A
counter example would be RPM based regulators, which set a load
change directly instead of a mode change. In the RPM case
regulator-allow-set-load alone is sufficient to describe the regulator
(the regulator can change its output current, here's the new load),
but in the RPMH case what valid operating modes exist must also be
stated to properly describe the regulator (the new load is this, what
is the optimum mode for this regulator with that load, let's change to
that mode now).
With this in place devicetree validation can catch issues like this:
/mnt/extrassd/git/linux-next/arch/arm64/boot/dts/qcom/sm8350-hdk.dtb: pm8350-rpmh-regulators: ldo5: 'regulator-allowed-modes' is a dependency of 'regulator-allow-set-load'
From schema: /mnt/extrassd/git/linux-next/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
Where the RPMH regulator hardware is described as being settable, but
there are no modes described to set it to!
Suggested-by: Johan Hovold <johan+kernel@kernel.org>
Reviewed-by: Johan Hovold <johan+kernel@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220907204924.173030-1-ahalaney@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The RPMH regulator binding covers several devices with different
regulator supplies, so it uses patterns matching broad range of these
supplies. This works fine but is not specific and might miss actual
mistakes when a wrong supply property is used for given variant.
Describe the supplies depending on the compatible, using a defs-allOf
method.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220426105501.73200-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
