Re: [PATCH 0/2] Add basic APR sound support for SC7280 SoC
On Fri, 10 May 2024 14:27:07 +0200, Luca Weiss wrote: > Validated on Fairphone 5 (QCM6490) smartphone by using DisplayPort over > USB-C audio, connected to a TV, with a basic UCM to enable > 'DISPLAY_PORT_RX Audio Mixer MultiMedia1': > https://gitlab.com/postmarketOS/pmaports/-/tree/master/device/testing/device-fairphone-fp5/ucm > > Unfortunately all the device-specific things can't be enabled yet > upstream as detailed in the second patch, but the SoC parts should be > good to go. > > As an extra note, I'm not sure how this will behave on SC7280 devices > that seem to use GPR (q6apm + q6prm) / "audioreach" as added in this > series from mid 2023 which was never applied: > https://lore.kernel.org/linux-arm-msm/20230616103534.4031331-1-quic_m...@quicinc.com/ > > Signed-off-by: Luca Weiss > --- > Luca Weiss (2): > arm64: dts: qcom: sc7280: Add APR nodes for sound > [DNM] arm64: dts: qcom: qcm6490-fairphone-fp5: Add DisplayPort sound > support > > arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 36 +++ > arch/arm64/boot/dts/qcom/sc7280.dtsi | 73 > ++ > 2 files changed, 109 insertions(+) > --- > base-commit: 940d65ef852b4a58c9115eb82b07844c999b8356 > change-id: 20240510-sc7280-apr-c6d10ac2c331 > > Best regards, > -- > Luca Weiss > > > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade New warnings running 'make CHECK_DTBS=y qcom/qcm6490-fairphone-fp5.dtb' for 20240510-sc7280-apr-v1-0-e9eabda05...@fairphone.com: arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dtb: /sound: failed to match any schema with compatible: ['fairphone,fp5-sndcard']
Re: [PATCH 1/2] dt-bindings: remoteproc: qcom,smd-edge: Mark qcom,ipc as deprecated
On Thu, 25 Apr 2024 21:14:30 +0200, Luca Weiss wrote: > Deprecate the qcom,ipc way of accessing the mailbox in favor of the > 'mboxes' property. > > Update the example to use mboxes. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring (Arm)
Re: [PATCH 2/2] dt-bindings: soc: qcom,smp2p: Mark qcom,ipc as deprecated
On Thu, 25 Apr 2024 21:14:31 +0200, Luca Weiss wrote: > Deprecate the qcom,ipc way of accessing the mailbox in favor of the > 'mboxes' property. > > Update the example to use mboxes. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring (Arm)
Re: [PATCH RFC 1/2] dt-bindings: soc: qcom,smsm: Allow specifying mboxes instead of qcom,ipc
On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> The qcom,ipc-N properties are essentially providing a reference to a
> mailbox, so allow using the mboxes property to do the same in a more
> structured way.
Can we mark qcom,ipc-N as deprecated then?
> Since multiple SMSM hosts are supported, we need to be able to provide
> the correct mailbox for each host. The old qcom,ipc-N properties map to
> the mboxes property by index, starting at 0 since that's a valid SMSM
> host also.
>
> The new example shows how an smsm node with just qcom,ipc-3 should be
> specified with the mboxes property.
>
> Signed-off-by: Luca Weiss
> ---
> .../devicetree/bindings/soc/qcom/qcom,smsm.yaml| 48
> ++
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
> index db67cf043256..b12589171169 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.yaml
> @@ -33,6 +33,13 @@ properties:
>specifier of the column in the subscription matrix representing the
> local
>processor.
>
> + mboxes:
> +minItems: 1
> +maxItems: 5
Need to define what each entry is.
> +description:
> + Reference to the mailbox representing the outgoing doorbell in APCS for
> + this client.
> +
>'#size-cells':
> const: 0
>
> @@ -98,15 +105,18 @@ required:
>- '#address-cells'
>- '#size-cells'
>
> -anyOf:
> +oneOf:
>- required:
> - - qcom,ipc-1
> - - required:
> - - qcom,ipc-2
> - - required:
> - - qcom,ipc-3
> - - required:
> - - qcom,ipc-4
> + - mboxes
> + - anyOf:
> + - required:
> + - qcom,ipc-1
> + - required:
> + - qcom,ipc-2
> + - required:
> + - qcom,ipc-3
> + - required:
> + - qcom,ipc-4
>
> additionalProperties: false
>
> @@ -136,3 +146,25 @@ examples:
> #interrupt-cells = <2>;
> };
> };
> + # Example using mboxes property
> + - |
> +#include
> +
> +shared-memory {
> +compatible = "qcom,smsm";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +mboxes = <0>, <0>, <0>, < 19>;
> +
> +apps@0 {
> +reg = <0>;
> +#qcom,smem-state-cells = <1>;
> +};
> +
> +wcnss@7 {
> +reg = <7>;
> +interrupts = ;
> +interrupt-controller;
> +#interrupt-cells = <2>;
> +};
> +};
>
> --
> 2.44.0
>
Re: [PATCH v10 00/12] Initial Marvell PXA1908 support
On Wed, 24 Apr 2024 20:42:27 +0200, Duje Mihanović wrote: > Hello, > > This series adds initial support for the Marvell PXA1908 SoC and > "samsung,coreprimevelte", a smartphone using the SoC. > > USB works and the phone can boot a rootfs from an SD card, but there are > some warnings in the dmesg: > > During SMP initialization: > [0.006519] CPU features: SANITY CHECK: Unexpected variation in > SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU1: 0x00 > [0.006542] CPU features: Unsupported CPU feature variation detected. > [0.006589] CPU1: Booted secondary processor 0x01 [0x410fd032] > [0.010710] Detected VIPT I-cache on CPU2 > [0.010716] CPU features: SANITY CHECK: Unexpected variation in > SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU2: 0x00 > [0.010758] CPU2: Booted secondary processor 0x02 [0x410fd032] > [0.014849] Detected VIPT I-cache on CPU3 > [0.014855] CPU features: SANITY CHECK: Unexpected variation in > SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU3: 0x00 > [0.014895] CPU3: Booted secondary processor 0x03 [0x410fd032] > > SMMU probing fails: > [0.101798] arm-smmu c001.iommu: probing hardware configuration... > [0.101809] arm-smmu c001.iommu: SMMUv1 with: > [0.101816] arm-smmu c001.iommu: no translation support! > > A 3.14 based Marvell tree is available on GitHub > acorn-marvell/brillo_pxa_kernel, and a Samsung one on GitHub > CoderCharmander/g361f-kernel. > > Andreas Färber attempted to upstream support for this SoC in 2017: > https://lore.kernel.org/lkml/20170222022929.10540-1-afaer...@suse.de/ > > Signed-off-by: Duje Mihanović > > Changes in v10: > - Update trailers > - Rebase on v6.9-rc5 > - Clock driver changes: > - Add a couple of forgotten clocks in APBC > - The clocks are thermal_clk, ipc_clk, ssp0_clk, ssp2_clk and swjtag > - The IDs and register offsets were already present, but I forgot to > actually register them > - Split each controller block into own file > - Drop unneeded -of in clock driver filenames > - Simplify struct pxa1908_clk_unit > - Convert to platform driver > - Add module metadata > - DTS changes: > - Properly name pinctrl nodes > - Drop pinctrl #size-cells, #address-cells, ranges and #gpio-size-cells > - Fix pinctrl input-schmitt configuration > - Link to v9: > https://lore.kernel.org/20240402-pxa1908-lkml-v9-0-25a003e83...@skole.hr > > Changes in v9: > - Update trailers and rebase on v6.9-rc2, no changes > - Link to v8: > https://lore.kernel.org/20240110-pxa1908-lkml-v8-0-fea768a59...@skole.hr > > Changes in v8: > - Drop SSPA patch > - Drop broken-cd from eMMC node > - Specify S-Boot hardcoded initramfs location in device tree > - Add ARM PMU node > - Correct inverted modem memory base and size > - Update trailers > - Rebase on next-20240110 > - Link to v7: > https://lore.kernel.org/20231102-pxa1908-lkml-v7-0-cabb1a0cb...@skole.hr > and https://lore.kernel.org/20231102152033.5511-1-duje.mihano...@skole.hr > > Changes in v7: > - Suppress SND_MMP_SOC_SSPA on ARM64 > - Update trailers > - Rebase on v6.6-rc7 > - Link to v6: > https://lore.kernel.org/r/20231010-pxa1908-lkml-v6-0-b2fe09240...@skole.hr > > Changes in v6: > - Address maintainer comments: > - Add "marvell,pxa1908-padconf" binding to pinctrl-single driver > - Drop GPIO patch as it's been pulled > - Update trailers > - Rebase on v6.6-rc5 > - Link to v5: > https://lore.kernel.org/r/20230812-pxa1908-lkml-v5-0-a5d51937e...@skole.hr > > Changes in v5: > - Address maintainer comments: > - Move *_NR_CLKS to clock driver from dt binding file > - Allocate correct number of clocks for each block instead of blindly > allocating 50 for each > - Link to v4: > https://lore.kernel.org/r/20230807-pxa1908-lkml-v4-0-cb387d73b...@skole.hr > > Changes in v4: > - Address maintainer comments: > - Relicense clock binding file to BSD-2 > - Add pinctrl-names to SD card node > - Add vgic registers to GIC node > - Rebase on v6.5-rc5 > - Link to v3: > https://lore.kernel.org/r/20230804-pxa1908-lkml-v3-0-8e48fca37...@skole.hr > > Changes in v3: > - Address maintainer comments: > - Drop GPIO dynamic allocation patch > - Move clock register offsets into driver (instead of bindings file) > - Add missing Tested-by trailer to u32_fract patch > - Move SoC binding to arm/mrvl/mrvl.yaml > - Add serial0 alias and stdout-path to board dts to enable UART > debugging > - Rebase on v6.5-rc4 > - Link to v2: > https://lore.kernel.org/r/20230727162909.6031-1-duje.mihano...@skole.hr > > Changes in v2: > - Remove earlycon patch as it's been merged into tty-next > - Address maintainer comments: > - Clarify GPIO regressions on older PXA platforms > - Add Fixes tag to commit disabling GPIO pinctrl calls for this SoC > - Add missing includes to clock driver > - Clock driver uses HZ_PER_MHZ, u32_fract and GENMASK > - Dual license clock bindings
Re: [PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote: > From: Hari Nagalla > > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > The remote processor's life cycle management and IPC mechanisms are > similar across the R5F and M4F cores from remote processor driver > point of view. However, there are subtle differences in image loading > and starting the M4F subsystems. > > The YAML binding document provides the various node properties to be > configured by the consumers of the M4F subsystem. > > Signed-off-by: Martyn Welch > Signed-off-by: Hari Nagalla > Signed-off-by: Andrew Davis > --- > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 ++ > 1 file changed, 126 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): Warning: Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml references a file that doesn't exist: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240424190612.17349-2-...@ti.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 0/3] Fix up qcom,halt-regs definition in various schemas
On Sun, Apr 07, 2024 at 11:58:29AM +0200, Luca Weiss wrote: > The original motivation is that a bunch of other schemas fail to > validate qcom,halt-regs, for example like in the following examples: > > arch/arm64/boot/dts/qcom/apq8016-sbc.dtb: remoteproc@408: > qcom,halt-regs:0: [20] is too short > from schema $id: > http://devicetree.org/schemas/remoteproc/qcom,msm8916-mss-pil.yaml# > arch/arm64/boot/dts/qcom/apq8096-ifc6640.dtb: remoteproc@208: > qcom,halt-regs:0: [82] is too short > from schema $id: > http://devicetree.org/schemas/remoteproc/qcom,msm8996-mss-pil.yaml# > arch/arm64/boot/dts/qcom/apq8039-t2.dtb: remoteproc@408: > qcom,halt-regs:0: [32] is too short > from schema $id: > http://devicetree.org/schemas/remoteproc/qcom,msm8916-mss-pil.yaml# > > While I'm actually not quite sure why these patches fix this in > the other schemas - feels like a bug/limitation in dt-schema maybe? - Was this with v2024.02? It should be a bit better there. Though it may just have different errors. The limitation is that property types and in the case of matrix's (which phandle-array actually is) range for dimensions are global. So if there's not correct dimensions for a property, the tools aren't going to decode it properly. Rob
Re: [PATCH v3 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
On Sun, 07 Apr 2024 11:05:10 +0200, Stanislav Jakubek wrote: > Document the Motorola Moto G (2013), which is a smartphone based > on the Qualcomm MSM8226 SoC. > > Acked-by: Krzysztof Kozlowski > Signed-off-by: Stanislav Jakubek > --- > Changes in V3: > - no changes > > Changes in V2: > - collect Krzysztof's A-b > > Documentation/devicetree/bindings/arm/qcom.yaml | 1 + > 1 file changed, 1 insertion(+) > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade New warnings running 'make CHECK_DTBS=y qcom/msm8226-motorola-falcon.dtb' for 32c507337ab80c550fb1df08f7014d1e31eb4c32.1712480582.git.stano.jaku...@gmail.com: arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dtb: syscon@f9011000: compatible: 'anyOf' conditional failed, one must be fixed: ['syscon'] is too short 'syscon' is not one of ['allwinner,sun8i-a83t-system-controller', 'allwinner,sun8i-h3-system-controller', 'allwinner,sun8i-v3s-system-controller', 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon', 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller', 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg', 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl', 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg', 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg', 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon', 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm', 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos', 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos', 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', ' rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain', 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl', 'ti,j784s4-pcie-ctrl'] from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
Re: [PATCH v9 0/9] Initial Marvell PXA1908 support
On Tue, 02 Apr 2024 22:55:36 +0200, Duje Mihanović wrote: > Hello, > > This series adds initial support for the Marvell PXA1908 SoC and > "samsung,coreprimevelte", a smartphone using the SoC. > > USB works and the phone can boot a rootfs from an SD card, but there are > some warnings in the dmesg: > > During SMP initialization: > [0.006519] CPU features: SANITY CHECK: Unexpected variation in > SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU1: 0x00 > [0.006542] CPU features: Unsupported CPU feature variation detected. > [0.006589] CPU1: Booted secondary processor 0x01 [0x410fd032] > [0.010710] Detected VIPT I-cache on CPU2 > [0.010716] CPU features: SANITY CHECK: Unexpected variation in > SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU2: 0x00 > [0.010758] CPU2: Booted secondary processor 0x02 [0x410fd032] > [0.014849] Detected VIPT I-cache on CPU3 > [0.014855] CPU features: SANITY CHECK: Unexpected variation in > SYS_CNTFRQ_EL0. Boot CPU: 0x00018cba80, CPU3: 0x00 > [0.014895] CPU3: Booted secondary processor 0x03 [0x410fd032] > > SMMU probing fails: > [0.101798] arm-smmu c001.iommu: probing hardware configuration... > [0.101809] arm-smmu c001.iommu: SMMUv1 with: > [0.101816] arm-smmu c001.iommu: no translation support! > > A 3.14 based Marvell tree is available on GitHub > acorn-marvell/brillo_pxa_kernel, and a Samsung one on GitHub > CoderCharmander/g361f-kernel. > > Andreas Färber attempted to upstream support for this SoC in 2017: > https://lore.kernel.org/lkml/20170222022929.10540-1-afaer...@suse.de/ > > Signed-off-by: Duje Mihanović > > Changes in v9: > - Update trailers and rebase on v6.9-rc2, no changes > - Link to v8: > https://lore.kernel.org/20240110-pxa1908-lkml-v8-0-fea768a59...@skole.hr > > Changes in v8: > - Drop SSPA patch > - Drop broken-cd from eMMC node > - Specify S-Boot hardcoded initramfs location in device tree > - Add ARM PMU node > - Correct inverted modem memory base and size > - Update trailers > - Rebase on next-20240110 > - Link to v7: > https://lore.kernel.org/20231102-pxa1908-lkml-v7-0-cabb1a0cb...@skole.hr > and https://lore.kernel.org/20231102152033.5511-1-duje.mihano...@skole.hr > > Changes in v7: > - Suppress SND_MMP_SOC_SSPA on ARM64 > - Update trailers > - Rebase on v6.6-rc7 > - Link to v6: > https://lore.kernel.org/r/20231010-pxa1908-lkml-v6-0-b2fe09240...@skole.hr > > Changes in v6: > - Address maintainer comments: > - Add "marvell,pxa1908-padconf" binding to pinctrl-single driver > - Drop GPIO patch as it's been pulled > - Update trailers > - Rebase on v6.6-rc5 > - Link to v5: > https://lore.kernel.org/r/20230812-pxa1908-lkml-v5-0-a5d51937e...@skole.hr > > Changes in v5: > - Address maintainer comments: > - Move *_NR_CLKS to clock driver from dt binding file > - Allocate correct number of clocks for each block instead of blindly > allocating 50 for each > - Link to v4: > https://lore.kernel.org/r/20230807-pxa1908-lkml-v4-0-cb387d73b...@skole.hr > > Changes in v4: > - Address maintainer comments: > - Relicense clock binding file to BSD-2 > - Add pinctrl-names to SD card node > - Add vgic registers to GIC node > - Rebase on v6.5-rc5 > - Link to v3: > https://lore.kernel.org/r/20230804-pxa1908-lkml-v3-0-8e48fca37...@skole.hr > > Changes in v3: > - Address maintainer comments: > - Drop GPIO dynamic allocation patch > - Move clock register offsets into driver (instead of bindings file) > - Add missing Tested-by trailer to u32_fract patch > - Move SoC binding to arm/mrvl/mrvl.yaml > - Add serial0 alias and stdout-path to board dts to enable UART > debugging > - Rebase on v6.5-rc4 > - Link to v2: > https://lore.kernel.org/r/20230727162909.6031-1-duje.mihano...@skole.hr > > Changes in v2: > - Remove earlycon patch as it's been merged into tty-next > - Address maintainer comments: > - Clarify GPIO regressions on older PXA platforms > - Add Fixes tag to commit disabling GPIO pinctrl calls for this SoC > - Add missing includes to clock driver > - Clock driver uses HZ_PER_MHZ, u32_fract and GENMASK > - Dual license clock bindings > - Change clock IDs to decimal > - Fix underscores in dt node names > - Move chosen node to top of board dts > - Clean up documentation > - Reorder commits > - Drop pxa,rev-id > - Rename muic-i2c to i2c-muic > - Reword some commits > - Move framebuffer node to chosen > - Add aliases for mmc nodes > - Rebase on v6.5-rc3 > - Link to v1: > https://lore.kernel.org/r/20230721210042.21535-1-duje.mihano...@skole.hr > > --- > Andy Shevchenko (1): > clk: mmp: Switch to use struct u32_fract instead of custom one > > Duje Mihanović (8): > dt-bindings: pinctrl: pinctrl-single: add marvell,pxa1908-padconf > compatible > pinctrl: single: add marvell,pxa1908-padconf compatible > dt-bindings: clock: Add Marvell PXA1908 clock bindings >
Re: [PATCH 1/3] dt-bindings: remoteproc: qcom,msm8996-mss-pil: allow glink-edge on msm8996
On Mon, 01 Apr 2024 00:10:42 +0300, Dmitry Baryshkov wrote: > MSM8996 has limited glink support, allow glink-edge node on MSM8996 > platform. > > Signed-off-by: Dmitry Baryshkov > --- > Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Motorola Moto G (2013)
On Sun, 24 Mar 2024 15:03:59 +0100, Stanislav Jakubek wrote: > Document the Motorola Moto G (2013), which is a smartphone based > on the Qualcomm MSM8226 SoC. > > Signed-off-by: Stanislav Jakubek > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 1 + > 1 file changed, 1 insertion(+) > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade New warnings running 'make CHECK_DTBS=y qcom/msm8226-motorola-falcon.dtb' for f5d4d71cd59f25b80889ef88fa044aa3a4268d46.1711288736.git.stano.jaku...@gmail.com: arch/arm/boot/dts/qcom/msm8226-motorola-falcon.dtb: syscon@f9011000: compatible: 'anyOf' conditional failed, one must be fixed: ['syscon'] is too short 'syscon' is not one of ['allwinner,sun8i-a83t-system-controller', 'allwinner,sun8i-h3-system-controller', 'allwinner,sun8i-v3s-system-controller', 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon', 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller', 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg', 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl', 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg', 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg', 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon', 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm', 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos', 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos', 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', ' rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain', 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl', 'ti,j784s4-pcie-ctrl'] from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
Re: [PATCH v2 0/2] Add Samsung Galaxy Note 3 support
On Thu, 14 Mar 2024 20:00:13 +0100, Luca Weiss wrote:
> Add the dts for "hlte" which is a phablet from 2013.
>
> Signed-off-by: Luca Weiss
> ---
> Changes in v2:
> - Correct property order (Konrad)
> - Pick up tags
> - Link to v1:
> https://lore.kernel.org/r/20240310-samsung-hlte-v1-0-e9b55bf98...@z3ntu.xyz
>
> ---
> Adam Honse (1):
> ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3
>
> Luca Weiss (1):
> dt-bindings: arm: qcom: Add Samsung Galaxy Note 3
>
> Documentation/devicetree/bindings/arm/qcom.yaml| 1 +
> arch/arm/boot/dts/qcom/Makefile| 1 +
> .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts| 401
> +
> 3 files changed, 403 insertions(+)
> ---
> base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
> change-id: 20240310-samsung-hlte-78d1a287b0a8
>
> Best regards,
> --
> Luca Weiss
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/qcom-msm8974-samsung-hlte.dtb' for
20240314-samsung-hlte-v2-0-84094b41c...@z3ntu.xyz:
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: /: memory: False schema
does not allow {'device_type': ['memory'], 'reg': [[0, 0]]}
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: l2-cache: Unevaluated
properties are not allowed ('qcom,saw' was unexpected)
from schema $id: http://devicetree.org/schemas/cache.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: idle-states: 'spc' does
not match any of the regexes: '^(cpu|cluster)-', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/cpu/idle-states.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: syscon@f9011000:
compatible: 'anyOf' conditional failed, one must be fixed:
['syscon'] is too short
'syscon' is not one of ['allwinner,sun8i-a83t-system-controller',
'allwinner,sun8i-h3-system-controller',
'allwinner,sun8i-v3s-system-controller',
'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon',
'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller',
'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg',
'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl',
'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg',
'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon',
'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg',
'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg',
'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon',
'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm',
'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos',
'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos',
'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', '
rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain',
'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl',
'ti,j784s4-pcie-ctrl']
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
Re: [PATCH 3/3] sh: Call paging_init() earlier in the init sequence
On Fri, Feb 9, 2024 at 5:29 PM Oreoluwa Babatunde wrote: > > The unflatten_device_tree() function contains a call to > memblock_alloc(). This is a problem because this allocation is done > before any of the reserved memory is set aside in paging_init(). > This means that there is a possibility for memblock to allocate from > any of the memory regions that are supposed to be set aside as reserved. > > Hence, move the call to paging_init() to be earlier in the init > sequence so that the reserved memory regions are set aside before any > allocations are done using memblock. > > Signed-off-by: Oreoluwa Babatunde > --- > arch/sh/kernel/setup.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Rob Herring
Re: [PATCH 0/2] Add Samsung Galaxy Note 3 support
On Sun, 10 Mar 2024 15:13:35 +0100, Luca Weiss wrote:
> Add the dts for "hlte" which is a phablet from 2013.
>
> Signed-off-by: Luca Weiss
> ---
> Adam Honse (1):
> ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3
>
> Luca Weiss (1):
> dt-bindings: arm: qcom: Add Samsung Galaxy Note 3
>
> Documentation/devicetree/bindings/arm/qcom.yaml| 1 +
> arch/arm/boot/dts/qcom/Makefile| 1 +
> .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts| 403
> +
> 3 files changed, 405 insertions(+)
> ---
> base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
> change-id: 20240310-samsung-hlte-78d1a287b0a8
>
> Best regards,
> --
> Luca Weiss
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
New warnings running 'make CHECK_DTBS=y qcom/qcom-msm8974-samsung-hlte.dtb' for
20240310-samsung-hlte-v1-0-e9b55bf98...@z3ntu.xyz:
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: /: memory: False schema
does not allow {'device_type': ['memory'], 'reg': [[0, 0]]}
from schema $id: http://devicetree.org/schemas/root-node.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: l2-cache: Unevaluated
properties are not allowed ('qcom,saw' was unexpected)
from schema $id: http://devicetree.org/schemas/cache.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: idle-states: 'spc' does
not match any of the regexes: '^(cpu|cluster)-', 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/cpu/idle-states.yaml#
arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dtb: syscon@f9011000:
compatible: 'anyOf' conditional failed, one must be fixed:
['syscon'] is too short
'syscon' is not one of ['allwinner,sun8i-a83t-system-controller',
'allwinner,sun8i-h3-system-controller',
'allwinner,sun8i-v3s-system-controller',
'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon',
'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller',
'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg',
'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl',
'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg',
'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon',
'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg',
'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg',
'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon',
'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm',
'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos',
'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos',
'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk3568-qos', '
rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain',
'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl',
'ti,j784s4-pcie-ctrl']
from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
Re: [PATCH 1/3] remoteproc: Add Arm remoteproc driver
On Fri, Mar 01, 2024 at 04:42:25PM +, abdellatif.elkhl...@arm.com wrote: > From: Abdellatif El Khlifi > > introduce remoteproc support for Arm remote processors > > The supported remote processors are those that come with a reset > control register and a reset status register. The driver allows to > switch on or off the remote processor. > > The current use case is Corstone-1000 External System (Cortex-M3). > > The driver can be extended to support other remote processors > controlled with a reset control and a reset status registers. > > The driver also supports control of multiple remote processors at the > same time. > > Signed-off-by: Abdellatif El Khlifi > --- > MAINTAINERS| 6 + > drivers/remoteproc/Kconfig | 18 ++ > drivers/remoteproc/Makefile| 1 + > drivers/remoteproc/arm_rproc.c | 395 + > 4 files changed, 420 insertions(+) > create mode 100644 drivers/remoteproc/arm_rproc.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8d1052fa6a69..54d6a40feea5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1764,6 +1764,12 @@ S: Maintained > F: Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml > F: drivers/irqchip/irq-vic.c > > +ARM REMOTEPROC DRIVER > +M: Abdellatif El Khlifi > +L: linux-remotep...@vger.kernel.org > +S: Maintained > +F: drivers/remoteproc/arm_rproc.c > + > ARM SMC WATCHDOG DRIVER > M: Julius Werner > R: Evan Benn > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index 48845dc8fa85..57fbac454a5d 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig > @@ -365,6 +365,24 @@ config XLNX_R5_REMOTEPROC > > It's safe to say N if not interested in using RPU r5f cores. > > +config ARM_REMOTEPROC > + tristate "Arm remoteproc support" Too generic of a name. It should say Corstone or Corstone-1000. Here and everywhere you use just 'Arm'. > + depends on HAS_IOMEM && ARM64 depends on ARM64 || (HAS_IOMEM && COMPILE_TEST) That gets us wider build coverage. You should check at least x86 allmodconfig passes. > + default n The default is already n, so drop. > + help > + Say y here to support Arm remote processors via the remote > + processor framework. > + > + The supported processors are those that come with a reset control > register > + and a reset status register. The design can be extended to support > different > + processors meeting these requirements. > + The driver also supports control of multiple remote cores at the same > time. > + > + Supported remote cores: > + Corstone-1000 External System (Cortex-M3) > + > + It's safe to say N here. > + > endif # REMOTEPROC > > endmenu > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile > index 91314a9b43ce..73126310835b 100644 > --- a/drivers/remoteproc/Makefile > +++ b/drivers/remoteproc/Makefile > @@ -39,3 +39,4 @@ obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o > obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o > obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o > obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o > +obj-$(CONFIG_ARM_REMOTEPROC) += arm_rproc.o > diff --git a/drivers/remoteproc/arm_rproc.c b/drivers/remoteproc/arm_rproc.c > new file mode 100644 > index ..6afa78ae7ad3 > --- /dev/null > +++ b/drivers/remoteproc/arm_rproc.c > @@ -0,0 +1,395 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright 2024 Arm Limited and/or its affiliates > We don't normally put OSO email in here. > + * > + * Authors: > + * Abdellatif El Khlifi That's recorded in the commit message and by git, so no need to put it in the file. > + */
Re: [PATCH] dt-bindings: remoteproc: qcom,glink-rpm-edge: drop redundant type from label
On Mon, 26 Feb 2024 13:28:54 +0100, Krzysztof Kozlowski wrote: > dtschema defines label as string, so $ref in other bindings is > redundant. > > Signed-off-by: Krzysztof Kozlowski > --- > .../devicetree/bindings/remoteproc/qcom,glink-rpm-edge.yaml | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Rob Herring
Re: [PATCH 3/3] dt-bindings: remoteproc: ti,davinci: remove unstable remark
On Sat, 24 Feb 2024 10:12:36 +0100, Krzysztof Kozlowski wrote:
> TI Davinci remoteproc bindings were marked as work-in-progress /
> unstable in 2017 in commit ae67b8007816 ("dt-bindings: remoteproc: Add
> bindings for Davinci DSP processors"). Almost seven years is enough, so
> drop the "unstable" remark and expect usual ABI rules.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> .../devicetree/bindings/remoteproc/ti,davinci-rproc.txt| 3 ---
> 1 file changed, 3 deletions(-)
>
Acked-by: Rob Herring
Re: [PATCH 2/3] dt-bindings: clock: ti: remove unstable remark
On Sat, 24 Feb 2024 10:12:35 +0100, Krzysztof Kozlowski wrote:
> Several TI SoC clock bindings were marked as work-in-progress / unstable
> between 2013-2016, for example in commit f60b1ea5ea7a ("CLK: TI: add
> support for gate clock"). It was enough of time to consider them stable
> and expect usual ABI rules.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/devicetree/bindings/clock/ti/adpll.txt| 2 --
> Documentation/devicetree/bindings/clock/ti/apll.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/autoidle.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/clockdomain.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/composite.txt| 2 --
> Documentation/devicetree/bindings/clock/ti/divider.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/dpll.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/fapll.txt| 2 --
> .../devicetree/bindings/clock/ti/fixed-factor-clock.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/gate.txt | 2 --
> Documentation/devicetree/bindings/clock/ti/interface.txt| 2 --
> Documentation/devicetree/bindings/clock/ti/mux.txt | 2 --
> 12 files changed, 24 deletions(-)
>
Acked-by: Rob Herring
Re: [PATCH 1/3] dt-bindings: clock: keystone: remove unstable remark
On Sat, 24 Feb 2024 10:12:34 +0100, Krzysztof Kozlowski wrote:
> Keystone clock controller bindings were marked as work-in-progress /
> unstable in 2013 in commit b9e0d40c0d83 ("clk: keystone: add Keystone
> PLL clock driver") and commit 7affe5685c96 ("clk: keystone: Add gate
> control clock driver") Almost eleven years is enough, so drop the
> "unstable" remark and expect usual ABI rules.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/devicetree/bindings/clock/keystone-gate.txt | 2 --
> Documentation/devicetree/bindings/clock/keystone-pll.txt | 2 --
> 2 files changed, 4 deletions(-)
>
Acked-by: Rob Herring
Re: [PATCHv2 1/2] dt-bindings: usb: typec: anx7688: start a binding document
On Fri, 23 Feb 2024 22:28:42 +0100, Pavel Machek wrote: > Add binding for anx7688 usb type-c bridge. I don't have a datasheet, > but I did best I could. > > Signed-off-by: Pavel Machek > > --- > > v2: implement review feedback > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/usb/analogix,anx7688.example.dtb: typec@2c: 'hdmi_vt-supply' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/ZdkOCqPKqa/u9...@duo.ucw.cz The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v3 5/7] dt-bindings: remoteproc: Add compatibility for TEE support
On Wed, 14 Feb 2024 18:21:25 +0100, Arnaud Pouliquen wrote: > The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration > where the Cortex-M4 firmware is loaded by the Trusted execution Environment > (TEE). > For instance, this compatible is used in both the Linux and OP-TEE > device-tree: > - In OP-TEE, a node is defined in the device tree with the > st,stm32mp1-m4-tee to support signed remoteproc firmware. > Based on DT properties, OP-TEE authenticates, loads, starts, and stops > the firmware. > - On Linux, when the compatibility is set, the Cortex-M resets should not > be declared in the device tree. > > Signed-off-by: Arnaud Pouliquen > --- > V1 to V2 updates > - update "st,stm32mp1-m4" compatible description to generalize > - remove the 'reset-names' requirement in one conditional branch, as the > property is already part of the condition test. > --- > .../bindings/remoteproc/st,stm32-rproc.yaml | 51 ++++++++--- > 1 file changed, 43 insertions(+), 8 deletions(-) > Reviewed-by: Rob Herring
Re: [RFC PATCH v2 4/6] dt-bindings: input: add entry for Marvell 88PM88X PMICs onkey
On Sun, Feb 11, 2024 at 10:35:54AM +0100, Karel Balej wrote: > From: Karel Balej > > Marvell 88PM88X PMICs provide onkey functionality -- add the bindings. > > Signed-off-by: Karel Balej > --- > > Notes: > RFC v2: > - Add wakeup-source property and reference onkey schema from MFD. > - Reword commit message. > > .../bindings/input/marvell,88pm88x-onkey.yaml | 32 +++ > .../bindings/mfd/marvell,88pm88x.yaml | 8 + > 2 files changed, 40 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml > > diff --git > a/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml > b/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml > new file mode 100644 > index ..5d3d451d0e1f > --- /dev/null > +++ b/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml > @@ -0,0 +1,32 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/input/marvell,88pm88x-onkey.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Onkey driver for Marvell 88PM88X PMICs. > + > +maintainers: > + - Karel Balej > + > +description: | > + This module is part of the 88PM88X MFD device. For more details > + see Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml. > + > + The onkey controller is represented as a sub-node of the PMIC node in > + the device tree. Why do you need a child node? You don't. Just add 'wakeup-source' to the parent. > + > +allOf: > + - $ref: input.yaml# Doesn't look like you are using any properties from this? > + > +properties: > + compatible: > +const: marvell,88pm88x-onkey > + > + wakeup-source: true > + > +required: > + - compatible > + > +additionalProperties: false > +...
Re: [RFC PATCH v2 1/6] dt-bindings: mfd: add entry for Marvell 88PM886 PMIC
On Sun, Feb 11, 2024 at 10:35:51AM +0100, Karel Balej wrote:
> From: Karel Balej
>
> Marvell 88PM886 is a PMIC with several subdevices such as onkey,
> regulators or battery and charger. It comes in at least two revisions,
> A0 and A1 -- only A1 is described here at the moment.
>
> Signed-off-by: Karel Balej
> ---
>
> Notes:
> RFC v2:
> - Address Rob's feedback:
> - Drop mention of 88PM880.
> - Make sure the file passes bindings check (add the necessary header
> and fix `interrupt-cells`).
> - Other small changes.
> - Add regulators. Changes with respect to the regulator RFC series:
> - Address Krzysztof's comments:
> - Drop unused compatible.
> - Fix sub-node pattern.
>
> .../bindings/mfd/marvell,88pm88x.yaml | 74 +++
Filename should match the compatible.
In general, drop the 'x' wildcard.
> .../regulator/marvell,88pm88x-regulator.yaml | 28 +++
> 2 files changed, 102 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> create mode 100644
> Documentation/devicetree/bindings/regulator/marvell,88pm88x-regulator.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> new file mode 100644
> index ..29ab979862d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/marvell,88pm88x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell 88PM88X PMIC core
> +
> +maintainers:
> + - Karel Balej
> +
> +description:
> + Marvell 88PM886 is a PMIC providing several functions such as onkey,
> + regulators or battery and charger.
> +
> +properties:
> + compatible:
> +const: marvell,88pm886-a1
> +
> + reg:
> +maxItems: 1
> +
> + interrupt-controller: true
What is the device providing interrupts to (in DT)?
> +
> + interrupts:
> +maxItems: 1
> +
> + "#interrupt-cells":
> +const: 1
> +
> + regulators:
> +$ref: /schemas/regulator/marvell,88pm88x-regulator.yaml#
That's simple enough, I'd just move the regulator nodes into this doc.
> +
> +required:
> + - compatible
> + - reg
> + - interrupt-controller
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pmic@30 {
> +compatible = "marvell,88pm886-a1";
> +reg = <0x30>;
> +interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
> +interrupt-parent = <>;
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +
> +regulators {
> + ldo2: ldo2 {
> +regulator-min-microvolt = <310>;
> +regulator-max-microvolt = <330>;
> +};
> +
> + ldo15: ldo15 {
> +regulator-min-microvolt = <330>;
> +regulator-max-microvolt = <330>;
> +};
> +
> + buck2: buck2 {
> +regulator-min-microvolt = <180>;
> +regulator-max-microvolt = <180>;
> +};
> +};
> + };
> +};
> +...
> diff --git
> a/Documentation/devicetree/bindings/regulator/marvell,88pm88x-regulator.yaml
> b/Documentation/devicetree/bindings/regulator/marvell,88pm88x-regulator.yaml
> new file mode 100644
> index ..1b4b5f1b4932
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/regulator/marvell,88pm88x-regulator.yaml
> @@ -0,0 +1,28 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/marvell,88pm88x-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Regulators of Marvell 88PM88X PMICs.
> +
> +maintainers:
> + - Karel Balej
> +
> +description: |
> + This is a part of device tree bindings for Marvell 88PM88X MFD.
> +
> + The regulators node is represented as a sub-node of the PMIC node on the
> + device tree.
> +
> + See also Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml for
> + additional information and example.
> +
> +patternProperties:
> + "^(ldo(1[0-6]|[1-9])|buck[1-5])$":
> +type: object
> +$ref: /schemas/regulator/regulator.yaml#
> +description: LDO or buck regulator.
> +unevaluatedProperties: false
> +
> +additionalProperties: false
> --
> 2.43.0
>
Re: [PATCH v10 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
On Tue, Feb 13, 2024 at 02:37:49PM -0600, Tanmay Shah wrote: > Hello, > > Thanks for reviews please find my comments below. > > On 2/13/24 1:20 PM, Rob Herring wrote: > > On Tue, 13 Feb 2024 09:54:48 -0800, Tanmay Shah wrote: > > > From: Radhey Shyam Pandey > > > > > > Introduce bindings for TCM memory address space on AMD-xilinx Zynq > > > UltraScale+ platform. It will help in defining TCM in device-tree > > > and make it's access platform agnostic and data-driven. > > > > > > Tightly-coupled memories(TCMs) are low-latency memory that provides > > > predictable instruction execution and predictable data load/store > > > timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory > > > banks on the ATCM and BTCM ports, for a total of 128 KB of memory. > > > > > > The TCM resources(reg, reg-names and power-domain) are documented for > > > each TCM in the R5 node. The reg and reg-names are made as required > > > properties as we don't want to hardcode TCM addresses for future > > > platforms and for zu+ legacy implementation will ensure that the > > > old dts w/o reg/reg-names works and stable ABI is maintained. > > > > > > It also extends the examples for TCM split and lockstep modes. > > > > > > Signed-off-by: Radhey Shyam Pandey > > > Signed-off-by: Tanmay Shah > > > --- > > > > > > Changes in v10: > > > - modify number of "reg", "reg-names" and "power-domains" entries > > > based on cluster mode > > > - Add extra optional atcm and btcm in "reg" property for lockstep mode > > > - Add "reg-names" for extra optional atcm and btcm for lockstep mode > > > - Drop previous Ack as bindings has new change > > > > > > Changes in v9: > > > - None > > > Changes in v8: > > > - None > > > Changes in v7: > > > - None > > > Changes in v6: > > > - None > > > Changes in v5: > > > - None > > > > > > Changes in v4: > > > - Use address-cells and size-cells value 2 > > > - Modify ranges property as per new value of address-cells > > > and size-cells > > > - Modify child node "reg" property accordingly > > > - Remove previous ack for further review > > > > > > v4 link: > > > https://lore.kernel.org/all/20230829181900.2561194-2-tanmay.s...@amd.com/ > > > > > > .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 -- > > > 1 file changed, 170 insertions(+), 22 deletions(-) > > > > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > > > yamllint warnings/errors: > > ./Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml:118:13: > > [warning] wrong indentation: expected 10 but found 12 (indentation) > Ack. I will fix this. > > However, can I still get reviews on patch itself so if something else needs > to be fixed I can fix in next revision as well. > > Also, I tried to run yamllint with following command: > > make DT_CHECKER_FLAGS=-m dt_binding_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml > O=../build/zynqmp/linux-next/ > > > However, I see following logs without any error on bindings: > > LINT Documentation/devicetree/bindings > invalid config: unknown option "required" for rule "quoted-strings" > *xargs: /usr/bin/yamllint: exited with status 255; aborting* > CHKDT Documentation/devicetree/bindings/processed-schema.json > SCHEMA Documentation/devicetree/bindings/processed-schema.json > DTEX > Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.example.dts > DTC_CHK > Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.example.dtb > > I am not sure if my system is missing something but, yamllint tool is failing. "unknown option" means old version of yamllint. Rob
Re: [PATCH v10 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
On Tue, 13 Feb 2024 09:54:48 -0800, Tanmay Shah wrote: > From: Radhey Shyam Pandey > > Introduce bindings for TCM memory address space on AMD-xilinx Zynq > UltraScale+ platform. It will help in defining TCM in device-tree > and make it's access platform agnostic and data-driven. > > Tightly-coupled memories(TCMs) are low-latency memory that provides > predictable instruction execution and predictable data load/store > timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory > banks on the ATCM and BTCM ports, for a total of 128 KB of memory. > > The TCM resources(reg, reg-names and power-domain) are documented for > each TCM in the R5 node. The reg and reg-names are made as required > properties as we don't want to hardcode TCM addresses for future > platforms and for zu+ legacy implementation will ensure that the > old dts w/o reg/reg-names works and stable ABI is maintained. > > It also extends the examples for TCM split and lockstep modes. > > Signed-off-by: Radhey Shyam Pandey > Signed-off-by: Tanmay Shah > --- > > Changes in v10: > - modify number of "reg", "reg-names" and "power-domains" entries > based on cluster mode > - Add extra optional atcm and btcm in "reg" property for lockstep mode > - Add "reg-names" for extra optional atcm and btcm for lockstep mode > - Drop previous Ack as bindings has new change > > Changes in v9: > - None > Changes in v8: > - None > Changes in v7: > - None > Changes in v6: > - None > Changes in v5: > - None > > Changes in v4: > - Use address-cells and size-cells value 2 > - Modify ranges property as per new value of address-cells > and size-cells > - Modify child node "reg" property accordingly > - Remove previous ack for further review > > v4 link: > https://lore.kernel.org/all/20230829181900.2561194-2-tanmay.s...@amd.com/ > > .../remoteproc/xlnx,zynqmp-r5fss.yaml | 192 -- > 1 file changed, 170 insertions(+), 22 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml:118:13: [warning] wrong indentation: expected 10 but found 12 (indentation) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240213175450.3097308-3-tanmay.s...@amd.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH 1/3] dt-bindings: mfd: qcom,spmi-pmic: Add pbs to SPMI device types
On Mon, 05 Feb 2024 10:51:38 +0100, Luca Weiss wrote: > Add the PBS (Programmable Boot Sequencer) to the list of devices. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 > 1 file changed, 4 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml: Error in referenced schema matching $id: http://devicetree.org/schemas/soc/qcom/qcom,pbs.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240205-pmi632-ppg-v1-1-e236c95a2...@fairphone.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v7 1/5] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Fri, Feb 02, 2024 at 11:55:34AM -0600, Hari Nagalla wrote:
> K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
> The remote processor's life cycle management and IPC mechanisms are
> similar across the R5F and M4F cores from remote processor driver
> point of view. However, there are subtle differences in image loading
> and starting the M4F subsystems.
>
> The YAML binding document provides the various node properties to be
> configured by the consumers of the M4F subsystem.
>
> Signed-off-by: Martyn Welch
> Signed-off-by: Hari Nagalla
> ---
> Changes since v1:
> - Spelling corrections
> - Corrected to pass DT checks
>
> Changes since v2:
> - Missed spelling correction to commit message
>
> Changes since v3:
> - Removed unnecessary descriptions and used generic memory region names
> - Made mboxes and memory-region optional
> - Removed unrelated items from examples
>
> Changes since v4:
> - Rebased to the latest kernel-next tree
> - Added optional sram memory region for m4f device node
>
> Changes since v5:
> - None
>
> Changes since v6:
> - Removed blank line, fixed type for firm-ware property and binding check
>errors.
>
> link to v6:
> https://lore.kernel.org/all/20230913111644.29889-2-hnaga...@ti.com/
>
> .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 138 ++
> 1 file changed, 138 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
> b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
> new file mode 100644
> index ..645dbce3773b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
> @@ -0,0 +1,138 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI K3 M4F processor subsystems
> +
> +maintainers:
> + - Hari Nagalla
> + - Mathieu Poirier
> +
> +description: |
> + Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
> + family with a M4F core. Typically safety oriented applications may use
> + the M4F core in isolation without an IPC. Where as some industrial and
> + home automation applications, may use the M4F core as a remote processor
> + with IPC communications.
> +
> +$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - ti,am64-m4fss
> +
> + power-domains:
> +maxItems: 1
> +
> + "#address-cells":
> +const: 2
> +
> + "#size-cells":
> +const: 2
> +
> + reg:
> +items:
> + - description: IRAM internal memory region
> + - description: DRAM internal memory region
> +
> + reg-names:
> +items:
> + - const: iram
> + - const: dram
> +
> + resets:
> +maxItems: 1
> +
> + firmware-name:
> +maxItems: 1
> +description: Name of firmware to load for the M4F core
> +
> + mboxes:
> +description: |
Don't need '|' if no formatting.
> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
> + communication with the remote processor. This property should match
> + with the sub-mailbox node used in the firmware image.
> +maxItems: 1
> +
> + memory-region:
> +description: |
> + phandle to the reserved memory nodes to be associated with the
> + remoteproc device. The reserved memory nodes should be carveout nodes,
> + and should be defined with a "no-map" property as per the bindings in
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
This has moved to dtschema. I'd just drop the file name.
> + Optional memory regions available for firmware specific purposes.
> +maxItems: 8
> +items:
> + - description: regions used for DMA allocations like vrings, vring
> buffers
> + and memory dedicated to firmware's specific purposes.
> +additionalItems: true
I think you want just:
minItems: 1
maxItems: 8
> +
> + sram:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +maxItems: 4
> +items:
> + maxItems: 1
> +description: |
> + phandles to reserved on-chip SRAM regions. The regions should be
> + defined as child nodes of the respective SRAM node, and
> + should be defined as per the generic bindings in,
> + Documentation/devicetree/bindings/sram/sram.yaml
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - ti,sci
> + - ti,sci-dev-id
> + - ti,sci-proc-ids
> + - resets
> + - firmware-name
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +reserved-memory {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
> +compatible = "shared-dma-pool";
> +
Re: [PATCH v7 1/5] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Fri, 02 Feb 2024 11:55:34 -0600, Hari Nagalla wrote: > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > The remote processor's life cycle management and IPC mechanisms are > similar across the R5F and M4F cores from remote processor driver > point of view. However, there are subtle differences in image loading > and starting the M4F subsystems. > > The YAML binding document provides the various node properties to be > configured by the consumers of the M4F subsystem. > > Signed-off-by: Martyn Welch > Signed-off-by: Hari Nagalla > --- > Changes since v1: > - Spelling corrections > - Corrected to pass DT checks > > Changes since v2: > - Missed spelling correction to commit message > > Changes since v3: > - Removed unnecessary descriptions and used generic memory region names > - Made mboxes and memory-region optional > - Removed unrelated items from examples > > Changes since v4: > - Rebased to the latest kernel-next tree > - Added optional sram memory region for m4f device node > > Changes since v5: > - None > > Changes since v6: > - Removed blank line, fixed type for firm-ware property and binding check >errors. > > link to v6: > https://lore.kernel.org/all/20230913111644.29889-2-hnaga...@ti.com/ > > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 138 ++ > 1 file changed, 138 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): Warning: Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml references a file that doesn't exist: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240202175538.1705-2-hnaga...@ti.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v4 4/5] dt-bindings: input/touchscreen: imagis: add compatible for IST3032C
On Sat, 20 Jan 2024 20:11:15 +0100, Karel Balej wrote: > From: Karel Balej > > IST3032C is a touchscreen IC which seems mostly compatible with IST3038C > except that it reports a different chip ID value. > > Signed-off-by: Karel Balej > --- > > Notes: > v4: > * Reword commit description to mention how this IC differs from the > already supported. > > .../devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add compatibility for TEE support
On Thu, Jan 18, 2024 at 11:04:31AM +0100, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In OP-TEE, a node is defined in the device tree with the
> st,stm32mp1-m4-tee to support signed remoteproc firmware.
> Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> the firmware.
> - On Linux, when the compatibility is set, the Cortex-M resets should not
> be declared in the device tree.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> V1 to V2 updates
> - update "st,stm32mp1-m4" compatible description to generalize
> - remove the 'reset-names' requirement in one conditional branch, as the
> property is already part of the condition test.
> ---
> .../bindings/remoteproc/st,stm32-rproc.yaml | 52 +++
> 1 file changed, 43 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> index 370af61d8f28..6af821b15736 100644
> --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> @@ -16,7 +16,12 @@ maintainers:
>
> properties:
>compatible:
> -const: st,stm32mp1-m4
> +enum:
> + - st,stm32mp1-m4
> + - st,stm32mp1-m4-tee
> +description:
> + Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by
> non-secure context
> + Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by
> secure context
>
>reg:
> description:
> @@ -142,21 +147,40 @@ properties:
> required:
>- compatible
>- reg
> - - resets
>
> allOf:
>- if:
>properties:
> -reset-names:
> - not:
> -contains:
> - const: hold_boot
> +compatible:
> + contains:
> +const: st,stm32mp1-m4
> +then:
> + if:
> +properties:
> + reset-names:
> +not:
> + contains:
> +const: hold_boot
Note that this is true when 'reset-names' is not present. If that is not
desired, then you need 'required: [reset-names]'. Not really a new issue
though.
> + then:
> +required:
> + - st,syscfg-holdboot
> + - resets
> + else:
> +properties:
> + st,syscfg-holdboot: false
> +required:
> + - resets
'resets' is always required within the outer 'then' schema, so you can
move this up a level.
> +
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: st,stm32mp1-m4-tee
> then:
> - required:
> -- st,syscfg-holdboot
> -else:
>properties:
> st,syscfg-holdboot: false
> +reset-names: false
> +resets: false
>
> additionalProperties: false
>
> @@ -188,5 +212,15 @@ examples:
>st,syscfg-rsc-tbl = < 0x144 0x>;
>st,syscfg-m4-state = < 0x148 0x>;
> };
> + - |
> +#include
> +m4@1000 {
> + compatible = "st,stm32mp1-m4-tee";
> + reg = <0x1000 0x4>,
> +<0x3000 0x4>,
> +<0x3800 0x1>;
> + st,syscfg-rsc-tbl = < 0x144 0x>;
> + st,syscfg-m4-state = < 0x148 0x>;
> +};
>
> ...
> --
> 2.25.1
>
Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add compatibility for TEE support
On Fri, Jan 26, 2024 at 12:03:25PM +0100, Krzysztof Kozlowski wrote: > On 18/01/2024 11:04, Arnaud Pouliquen wrote: > > The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration > > where the Cortex-M4 firmware is loaded by the Trusted execution Environment > > (TEE). > > For instance, this compatible is used in both the Linux and OP-TEE > > device-tree: > > - In OP-TEE, a node is defined in the device tree with the > > st,stm32mp1-m4-tee to support signed remoteproc firmware. > > Based on DT properties, OP-TEE authenticates, loads, starts, and stops > > the firmware. > > - On Linux, when the compatibility is set, the Cortex-M resets should not > > be declared in the device tree. > > > > Signed-off-by: Arnaud Pouliquen > > --- > > V1 to V2 updates > > - update "st,stm32mp1-m4" compatible description to generalize > > - remove the 'reset-names' requirement in one conditional branch, as the > > property is already part of the condition test. > > --- > > .../bindings/remoteproc/st,stm32-rproc.yaml | 52 +++ > > 1 file changed, 43 insertions(+), 9 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > index 370af61d8f28..6af821b15736 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > @@ -16,7 +16,12 @@ maintainers: > > > > properties: > >compatible: > > -const: st,stm32mp1-m4 > > +enum: > > + - st,stm32mp1-m4 > > + - st,stm32mp1-m4-tee > > The patch looks good to me, but I wonder about this choice of two > compatibles. > > Basically this is the same hardware with the same interface, but two > compatibles to differentiate a bit different firmware setup. We have > already such cases for Qualcomm [1] [2] and new ones will be coming. [3] > > I wonder whether this should be rather the same compatible with > additional property, e.g. "st,tee-control" or "remote-control". > > [1] > https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml#L54 > > [2] > https://elixir.bootlin.com/linux/v6.7.1/source/Documentation/devicetree/bindings/net/qcom,ipa.yaml#L129 > (that's a bit different) > > [3] https://lore.kernel.org/linux-devicetree/20240124103623.GJ4906@thinkpad/ > > @Rob, > Any general guidance for this and Qualcomm? I think we have cases using compatible already as well. Either way is fine with me. Rob
Re: [PATCH 2/4] dt-bindings: remoteproc: add compatibility for TEE support
On Mon, Jan 15, 2024 at 02:52:47PM +0100, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> This compatible is used in both the Linux and OP-TEE device-tree.
> - In OP-TEE, a node is defined in the device tree with the
> st,stm32mp1-m4-tee to support signed remoteproc firmware.
> Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> the firmware.
> - On Linux, when the compatibility is set, the Cortex-M resets should not
> be declared in the device tree.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> .../bindings/remoteproc/st,stm32-rproc.yaml | 53 +++
> 1 file changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> index 370af61d8f28..9fdfa30eff20 100644
> --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> @@ -16,7 +16,12 @@ maintainers:
>
> properties:
>compatible:
> -const: st,stm32mp1-m4
> +enum:
> + - st,stm32mp1-m4
> + - st,stm32mp1-m4-tee
> +description:
> + Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by Linux
What if other OSs want to manage the M4?
> + Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by
> secure context
>
>reg:
> description:
> @@ -142,21 +147,41 @@ properties:
> required:
>- compatible
>- reg
> - - resets
>
> allOf:
>- if:
>properties:
> -reset-names:
> - not:
> -contains:
> - const: hold_boot
> +compatible:
> + contains:
> +const: st,stm32mp1-m4
> +then:
> + if:
> +properties:
> + reset-names:
> +not:
> + contains:
> +const: hold_boot
> + then:
> +required:
> + - st,syscfg-holdboot
> + - resets
> + else:
> +properties:
> + st,syscfg-holdboot: false
> +required:
> + - reset-names
Looks like a new required property.
> + - resets
> +
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: st,stm32mp1-m4-tee
> then:
> - required:
> -- st,syscfg-holdboot
> -else:
>properties:
> st,syscfg-holdboot: false
> +reset-names: false
> +resets: false
>
> additionalProperties: false
>
> @@ -188,5 +213,15 @@ examples:
>st,syscfg-rsc-tbl = < 0x144 0x>;
>st,syscfg-m4-state = < 0x148 0x>;
> };
> + - |
> +#include
> +m4@1000 {
> + compatible = "st,stm32mp1-m4-tee";
> + reg = <0x1000 0x4>,
> +<0x3000 0x4>,
> +<0x3800 0x1>;
> + st,syscfg-rsc-tbl = < 0x144 0x>;
> + st,syscfg-m4-state = < 0x148 0x>;
> +};
>
> ...
> --
> 2.25.1
>
Re: [RFC PATCH 3/5] dt-bindings: input: add entry for 88pm88x-onkey
On Sun, Dec 17, 2023 at 02:17:01PM +0100, Karel Balej wrote:
> From: Karel Balej
>
> Marvell 88PM88X PMICs provide onkey functionality. Document it.
>
> Signed-off-by: Karel Balej
> ---
> .../bindings/input/marvell,88pm88x-onkey.yaml | 30 +++
> .../bindings/mfd/marvell,88pm88x.yaml | 4 +++
> 2 files changed, 34 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
> b/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
> new file mode 100644
> index ..aeb7673189f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/marvell,88pm88x-onkey.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Onkey driver for Marvell 88PM88X PMICs.
> +
> +maintainers:
> + - Karel Balej
> +
> +description: |
> + This module is part of the 88PM88X MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml.
> +
> + The onkey controller is represented as a sub-node of the PMIC node in
> + the device tree.
> +
> +allOf:
> + - $ref: input.yaml#
> +
> +properties:
> + compatible:
> +const: marvell,88pm88x-onkey
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +...
> diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> index e075729c360f..115b41c9f22c 100644
> --- a/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> +++ b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> @@ -50,6 +50,10 @@ examples:
> interrupt-parent = <>;
> interrupt-controller;
> #interrupt-cells = <1>;
> +
> +onkey {
> + compatible = "marvell,88pm88x-onkey";
> +};
Why do you need this? You have no properties for it. The parent driver
can instantiate child drivers. You don't need a DT node for that.
Rob
Re: [RFC PATCH 1/5] dt-bindings: mfd: add entry for the Marvell 88PM88X PMICs
On Sun, Dec 17, 2023 at 02:16:59PM +0100, Karel Balej wrote:
> From: Karel Balej
>
> Marvell 88PM880 and 88PM886 are two similar PMICs with mostly matching
> register mapping and subdevices such as onkey, regulators or battery and
> charger. Both seem to come in two revisions which seem to be handled
> slightly differently in some subdevice drivers.
>
> Signed-off-by: Karel Balej
> ---
> .../bindings/mfd/marvell,88pm88x.yaml | 55 +++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> new file mode 100644
> index ..e075729c360f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/marvell,88pm88x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell 88PM88X PMIC core MFD
Drop 'MFD'.
> +
> +maintainers:
> + - Karel Balej
> +
> +description: |
Don't need '|' as there is no formatting to preserve.
> + Marvell 88PM880 and 88PM886 are two similar PMICs providing
> + several functions such as onkey, regulators or battery and
> + charger. Both seem to come in two revisions -- A0 and A1.
> +
> +properties:
> + compatible:
> +const: marvell,88pm886-a1
The description talks about 4 different devices, but only 1 here.
Do you expect to need A0 support? Devices with these PMICs should be
known and few, right?
> +
> + reg:
> +description: I2C device address
Drop.
> +maxItems: 1
> +
> + interrupt-controller: true
> +
> + interrupts:
> +maxItems: 1
> +
> + "#interrupt-cells":
> +const: 2
> +
> +required:
> + - compatible
> + - reg
> + - interrupt-controller
> + - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pmic0: 88pm886@30 {
pmic@30
Drop the unused label.
> +compatible = "marvell,88pm886-a1";
> +reg = <0x30>;
> +interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
You need the header for this.
You'll find the input binding fails too. Please test your bindings
before sending.
> +interrupt-parent = <>;
> +interrupt-controller;
> +#interrupt-cells = <1>;
> + };
> +};
> +...
> --
> 2.43.0
>
Re: [RFC PATCH 3/5] dt-bindings: input: add entry for 88pm88x-onkey
On Sun, 17 Dec 2023 14:17:01 +0100, Karel Balej wrote: > From: Karel Balej > > Marvell 88PM88X PMICs provide onkey functionality. Document it. > > Signed-off-by: Karel Balej > --- > .../bindings/input/marvell,88pm88x-onkey.yaml | 30 +++ > .../bindings/mfd/marvell,88pm88x.yaml | 4 +++ > 2 files changed, 34 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/marvell,88pm88x-onkey.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231217131838.7569-4-kar...@gimli.ms.mff.cuni.cz The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [RFC PATCH 1/5] dt-bindings: mfd: add entry for the Marvell 88PM88X PMICs
On Sun, 17 Dec 2023 14:16:59 +0100, Karel Balej wrote: > From: Karel Balej > > Marvell 88PM880 and 88PM886 are two similar PMICs with mostly matching > register mapping and subdevices such as onkey, regulators or battery and > charger. Both seem to come in two revisions which seem to be handled > slightly differently in some subdevice drivers. > > Signed-off-by: Karel Balej > --- > .../bindings/mfd/marvell,88pm88x.yaml | 55 +++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm88x.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Error: Documentation/devicetree/bindings/mfd/marvell,88pm88x.example.dts:30.31-32 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/mfd/marvell,88pm88x.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: dt_binding_check] Error 2 make: *** [Makefile:234: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231217131838.7569-2-kar...@gimli.ms.mff.cuni.cz The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
On Thu, Dec 14, 2023 at 9:45 AM Alexandru Elisei
wrote:
>
> Hi,
>
> On Wed, Dec 13, 2023 at 02:30:42PM -0600, Rob Herring wrote:
> > On Wed, Dec 13, 2023 at 11:44 AM Alexandru Elisei
> > wrote:
> > >
> > > On Wed, Dec 13, 2023 at 11:22:17AM -0600, Rob Herring wrote:
> > > > On Wed, Dec 13, 2023 at 8:51 AM Alexandru Elisei
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > > > > > On Wed, Dec 13, 2023 at 7:05 AM Alexandru Elisei
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > > > > > On Tue, Dec 12, 2023 at 10:38 AM Alexandru Elisei
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Rob,
> > > > > > > > >
> > > > > > > > > Thank you so much for the feedback, I'm not very familiar
> > > > > > > > > with device tree,
> > > > > > > > > and any comments are very useful.
> > > > > > > > >
> > > > > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > > > > > On Sun, Nov 19, 2023 at 10:59 AM Alexandru Elisei
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Allow the kernel to get the size and location of the MTE
> > > > > > > > > > > tag storage
> > > > > > > > > > > regions from the DTB. This memory is marked as reserved
> > > > > > > > > > > for now.
> > > > > > > > > > >
> > > > > > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > > > > > >
> > > > > > > > > > > tags0: tag-storage@8f800 {
> > > > > > > > > > > compatible = "arm,mte-tag-storage";
> > > > > > > > > > > reg = <0x08 0xf800 0x00 0x400>;
> > > > > > > > > > > block-size = <0x1000>;
> > > > > > > > > > > memory = <>;// Associated
> > > > > > > > > > > tagged memory node
> > > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > I skimmed thru the discussion some. If this memory range is
> > > > > > > > > > within
> > > > > > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > > > > > >
> > > > > > > > > Ok, will do that.
> > > > > > > > >
> > > > > > > > > If you don't mind, why do you say that it definitely belongs
> > > > > > > > > in
> > > > > > > > > reserved-memory? I'm not trying to argue otherwise, I'm
> > > > > > > > > curious about the
> > > > > > > > > motivation.
> > > > > > > >
> > > > > > > > Simply so that /memory nodes describe all possible memory and
> > > > > > > > /reserved-memory is just adding restrictions. It's also because
> > > > > > > > /reserved-memory is what gets handled early, and we don't need
> > > > > > > > multiple things to handle early.
> > > > > > > >
> > > > > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > > > > >
> > > > > > > > Then why put it in DT at all? The only reason CMA is there is
> > > > > > > > to set
> > > > > > > > the size. It's not even clear to me we need CMA in DT either.
> > > > > > > > The
> > > > > > > > reasoning long ago was the kernel didn't do a good job of
> > > > > > > > moving and
> > > > > > >
Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
On Wed, Dec 13, 2023 at 11:44 AM Alexandru Elisei
wrote:
>
> On Wed, Dec 13, 2023 at 11:22:17AM -0600, Rob Herring wrote:
> > On Wed, Dec 13, 2023 at 8:51 AM Alexandru Elisei
> > wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > > > On Wed, Dec 13, 2023 at 7:05 AM Alexandru Elisei
> > > > wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > > > On Tue, Dec 12, 2023 at 10:38 AM Alexandru Elisei
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > Thank you so much for the feedback, I'm not very familiar with
> > > > > > > device tree,
> > > > > > > and any comments are very useful.
> > > > > > >
> > > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > > > On Sun, Nov 19, 2023 at 10:59 AM Alexandru Elisei
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Allow the kernel to get the size and location of the MTE tag
> > > > > > > > > storage
> > > > > > > > > regions from the DTB. This memory is marked as reserved for
> > > > > > > > > now.
> > > > > > > > >
> > > > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > > > >
> > > > > > > > > tags0: tag-storage@8f800 {
> > > > > > > > > compatible = "arm,mte-tag-storage";
> > > > > > > > > reg = <0x08 0xf800 0x00 0x400>;
> > > > > > > > > block-size = <0x1000>;
> > > > > > > > > memory = <>;// Associated tagged
> > > > > > > > > memory node
> > > > > > > > > };
> > > > > > > >
> > > > > > > > I skimmed thru the discussion some. If this memory range is
> > > > > > > > within
> > > > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > > > >
> > > > > > > Ok, will do that.
> > > > > > >
> > > > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious
> > > > > > > about the
> > > > > > > motivation.
> > > > > >
> > > > > > Simply so that /memory nodes describe all possible memory and
> > > > > > /reserved-memory is just adding restrictions. It's also because
> > > > > > /reserved-memory is what gets handled early, and we don't need
> > > > > > multiple things to handle early.
> > > > > >
> > > > > > > Tag storage is not DMA and can live anywhere in memory.
> > > > > >
> > > > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > > > reclaiming contiguous space, but that's supposed to be better now
> > > > > > (and
> > > > > > most h/w figured out they need IOMMUs).
> > > > > >
> > > > > > But for tag storage you know the size as it is a function of the
> > > > > > memory size, right? After all, you are validating the size is
> > > > > > correct.
> > > > > > I guess there is still the aspect of whether you want enable MTE or
> > > > > > not which could be done in a variety of ways.
> > > > >
> > > > > Oh, sorry, my bad, I should have been clearer about this. I don't
> > > > > want to
> > > > > put it in the DT as a "linux,cma" node. But I want it to be managed
> > > > > by CMA.
> > > >
> > > > Yes, I understand, but my point remains. Why do y
Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
On Wed, Dec 13, 2023 at 8:51 AM Alexandru Elisei
wrote:
>
> Hi,
>
> On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote:
> > On Wed, Dec 13, 2023 at 7:05 AM Alexandru Elisei
> > wrote:
> > >
> > > Hi Rob,
> > >
> > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > > > On Tue, Dec 12, 2023 at 10:38 AM Alexandru Elisei
> > > > wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > Thank you so much for the feedback, I'm not very familiar with device
> > > > > tree,
> > > > > and any comments are very useful.
> > > > >
> > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > > > On Sun, Nov 19, 2023 at 10:59 AM Alexandru Elisei
> > > > > > wrote:
> > > > > > >
> > > > > > > Allow the kernel to get the size and location of the MTE tag
> > > > > > > storage
> > > > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > > > >
> > > > > > > The DTB node for the tag storage region is defined as:
> > > > > > >
> > > > > > > tags0: tag-storage@8f800 {
> > > > > > > compatible = "arm,mte-tag-storage";
> > > > > > > reg = <0x08 0xf800 0x00 0x400>;
> > > > > > > block-size = <0x1000>;
> > > > > > > memory = <>;// Associated tagged
> > > > > > > memory node
> > > > > > > };
> > > > > >
> > > > > > I skimmed thru the discussion some. If this memory range is within
> > > > > > main RAM, then it definitely belongs in /reserved-memory.
> > > > >
> > > > > Ok, will do that.
> > > > >
> > > > > If you don't mind, why do you say that it definitely belongs in
> > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious about
> > > > > the
> > > > > motivation.
> > > >
> > > > Simply so that /memory nodes describe all possible memory and
> > > > /reserved-memory is just adding restrictions. It's also because
> > > > /reserved-memory is what gets handled early, and we don't need
> > > > multiple things to handle early.
> > > >
> > > > > Tag storage is not DMA and can live anywhere in memory.
> > > >
> > > > Then why put it in DT at all? The only reason CMA is there is to set
> > > > the size. It's not even clear to me we need CMA in DT either. The
> > > > reasoning long ago was the kernel didn't do a good job of moving and
> > > > reclaiming contiguous space, but that's supposed to be better now (and
> > > > most h/w figured out they need IOMMUs).
> > > >
> > > > But for tag storage you know the size as it is a function of the
> > > > memory size, right? After all, you are validating the size is correct.
> > > > I guess there is still the aspect of whether you want enable MTE or
> > > > not which could be done in a variety of ways.
> > >
> > > Oh, sorry, my bad, I should have been clearer about this. I don't want to
> > > put it in the DT as a "linux,cma" node. But I want it to be managed by
> > > CMA.
> >
> > Yes, I understand, but my point remains. Why do you need this in DT?
> > If the location doesn't matter and you can calculate the size from the
> > memory size, what else is there to add to the DT?
>
> I am afraid there has been a misunderstanding. What do you mean by
> "location doesn't matter"?
You said:
> Tag storage is not DMA and can live anywhere in memory.
Which I took as the kernel can figure out where to put it. But maybe
you meant the h/w platform can hard code it to be anywhere in memory?
If so, then yes, DT is needed.
> At the very least, Linux needs to know the address and size of a memory
> region to use it. The series is about using the tag storage memory for
> data. Tag storage cannot be described as a regular memory node because it
> cannot be tagged (and normal memory can).
If the tag storage lives in the middle of memory, then it would be
described in the memory node, but removed by being in reserved-memory
node.
> Then there's the matter of the tag storage block size (explained in this
> commit message), and also knowing the memory range for which a tag storage
> region stores the tags. This is explained in the cover letter.
Honestly, I just forgot about that part.
Rob
Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
On Wed, Dec 13, 2023 at 7:05 AM Alexandru Elisei
wrote:
>
> Hi Rob,
>
> On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote:
> > On Tue, Dec 12, 2023 at 10:38 AM Alexandru Elisei
> > wrote:
> > >
> > > Hi Rob,
> > >
> > > Thank you so much for the feedback, I'm not very familiar with device
> > > tree,
> > > and any comments are very useful.
> > >
> > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > > > On Sun, Nov 19, 2023 at 10:59 AM Alexandru Elisei
> > > > wrote:
> > > > >
> > > > > Allow the kernel to get the size and location of the MTE tag storage
> > > > > regions from the DTB. This memory is marked as reserved for now.
> > > > >
> > > > > The DTB node for the tag storage region is defined as:
> > > > >
> > > > > tags0: tag-storage@8f800 {
> > > > > compatible = "arm,mte-tag-storage";
> > > > > reg = <0x08 0xf800 0x00 0x400>;
> > > > > block-size = <0x1000>;
> > > > > memory = <>;// Associated tagged memory
> > > > > node
> > > > > };
> > > >
> > > > I skimmed thru the discussion some. If this memory range is within
> > > > main RAM, then it definitely belongs in /reserved-memory.
> > >
> > > Ok, will do that.
> > >
> > > If you don't mind, why do you say that it definitely belongs in
> > > reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> > > motivation.
> >
> > Simply so that /memory nodes describe all possible memory and
> > /reserved-memory is just adding restrictions. It's also because
> > /reserved-memory is what gets handled early, and we don't need
> > multiple things to handle early.
> >
> > > Tag storage is not DMA and can live anywhere in memory.
> >
> > Then why put it in DT at all? The only reason CMA is there is to set
> > the size. It's not even clear to me we need CMA in DT either. The
> > reasoning long ago was the kernel didn't do a good job of moving and
> > reclaiming contiguous space, but that's supposed to be better now (and
> > most h/w figured out they need IOMMUs).
> >
> > But for tag storage you know the size as it is a function of the
> > memory size, right? After all, you are validating the size is correct.
> > I guess there is still the aspect of whether you want enable MTE or
> > not which could be done in a variety of ways.
>
> Oh, sorry, my bad, I should have been clearer about this. I don't want to
> put it in the DT as a "linux,cma" node. But I want it to be managed by CMA.
Yes, I understand, but my point remains. Why do you need this in DT?
If the location doesn't matter and you can calculate the size from the
memory size, what else is there to add to the DT?
Rob
Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
On Tue, Dec 12, 2023 at 10:38 AM Alexandru Elisei
wrote:
>
> Hi Rob,
>
> Thank you so much for the feedback, I'm not very familiar with device tree,
> and any comments are very useful.
>
> On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote:
> > On Sun, Nov 19, 2023 at 10:59 AM Alexandru Elisei
> > wrote:
> > >
> > > Allow the kernel to get the size and location of the MTE tag storage
> > > regions from the DTB. This memory is marked as reserved for now.
> > >
> > > The DTB node for the tag storage region is defined as:
> > >
> > > tags0: tag-storage@8f800 {
> > > compatible = "arm,mte-tag-storage";
> > > reg = <0x08 0xf800 0x00 0x400>;
> > > block-size = <0x1000>;
> > > memory = <>;// Associated tagged memory node
> > > };
> >
> > I skimmed thru the discussion some. If this memory range is within
> > main RAM, then it definitely belongs in /reserved-memory.
>
> Ok, will do that.
>
> If you don't mind, why do you say that it definitely belongs in
> reserved-memory? I'm not trying to argue otherwise, I'm curious about the
> motivation.
Simply so that /memory nodes describe all possible memory and
/reserved-memory is just adding restrictions. It's also because
/reserved-memory is what gets handled early, and we don't need
multiple things to handle early.
> Tag storage is not DMA and can live anywhere in memory.
Then why put it in DT at all? The only reason CMA is there is to set
the size. It's not even clear to me we need CMA in DT either. The
reasoning long ago was the kernel didn't do a good job of moving and
reclaiming contiguous space, but that's supposed to be better now (and
most h/w figured out they need IOMMUs).
But for tag storage you know the size as it is a function of the
memory size, right? After all, you are validating the size is correct.
I guess there is still the aspect of whether you want enable MTE or
not which could be done in a variety of ways.
> In
> arm64_memblock_init(), the kernel first removes the memory that it cannot
> address from memblock. For example, because it has been compiled with
> CONFIG_ARM64_VA_BITS_39=y. And then calls
> early_init_fdt_scan_reserved_mem().
>
> What happens if reserved memory is above what the kernel can address?
I would hope the kernel handles it. That's the kernel's problem unless
there's some h/w limitation to access some region. The DT can't have
things dependent on the kernel config.
> From my testing, when the kernel is compiled with 39 bit VA, if I use
> reserved memory to discover tag storage the lives above the virtua address
> limit and then I try to use CMA to manage the tag storage memory, I get a
> kernel panic:
Looks like we should handle that better...
>> [0.00] Reserved memory: created CMA memory pool at
>> 0x0100, size 64 MiB
> [0.00] OF: reserved mem: initialized node linux,cma, compatible id
> shared-dma-pool
> [0.00] OF: reserved mem: 0x0100..0x010003ff
> (65536 KiB) map reusable linux,cma
> [..]
> [0.806945] Unable to handle kernel paging request at virtual address
> 0001fe00
> [0.807277] Mem abort info:
> [0.807277] ESR = 0x9605
> [0.807693] EC = 0x25: DABT (current EL), IL = 32 bits
> [0.808110] SET = 0, FnV = 0
> [0.808443] EA = 0, S1PTW = 0
> [0.808526] FSC = 0x05: level 1 translation fault
> [0.808943] Data abort info:
> [0.808943] ISV = 0, ISS = 0x0005, ISS2 = 0x
> [0.809360] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [0.809776] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [0.810221] [0001fe00] user address but active_mm is swapper
> [..]
> [0.820887] Call trace:
> [0.821027] cma_init_reserved_areas+0xc4/0x378
>
> >
> > You need a binding for this too.
>
> By binding you mean having an yaml file in dt-schem [1] describing the tag
> storage node, right?
Yes, but in the kernel tree is fine.
[...]
> > > +static int __init tag_storage_of_flat_get_range(unsigned long node,
> > > const __be32 *reg,
> > > + int reg_len, struct range
> > > *range)
> > > +{
> > > + int addr_cells = dt_root_addr_cells;
> > > + int size_cells = dt_root_size_cells;
> > > + u64 size;
> > > +
> > > + if (reg_len / 4 > addr_cells + size_cells)
> > > + return -EINVAL;
> > > +
> > > + range->start = PHYS_PFN(of_read_number(reg,
Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory
On Sun, Nov 19, 2023 at 10:59 AM Alexandru Elisei
wrote:
>
> Allow the kernel to get the size and location of the MTE tag storage
> regions from the DTB. This memory is marked as reserved for now.
>
> The DTB node for the tag storage region is defined as:
>
> tags0: tag-storage@8f800 {
> compatible = "arm,mte-tag-storage";
> reg = <0x08 0xf800 0x00 0x400>;
> block-size = <0x1000>;
> memory = <>;// Associated tagged memory node
> };
I skimmed thru the discussion some. If this memory range is within
main RAM, then it definitely belongs in /reserved-memory.
You need a binding for this too.
> The tag storage region represents the largest contiguous memory region that
> holds all the tags for the associated contiguous memory region which can be
> tagged. For example, for a 32GB contiguous tagged memory the corresponding
> tag storage region is 1GB of contiguous memory, not two adjacent 512M of
> tag storage memory.
>
> "block-size" represents the minimum multiple of 4K of tag storage where all
> the tags stored in the block correspond to a contiguous memory region. This
> is needed for platforms where the memory controller interleaves tag writes
> to memory. For example, if the memory controller interleaves tag writes for
> 256KB of contiguous memory across 8K of tag storage (2-way interleave),
> then the correct value for "block-size" is 0x2000. This value is a hardware
> property, independent of the selected kernel page size.
>
> Signed-off-by: Alexandru Elisei
> ---
> arch/arm64/Kconfig | 12 ++
> arch/arm64/include/asm/mte_tag_storage.h | 15 ++
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/mte_tag_storage.c | 256 +++
> arch/arm64/kernel/setup.c| 7 +
> 5 files changed, 291 insertions(+)
> create mode 100644 arch/arm64/include/asm/mte_tag_storage.h
> create mode 100644 arch/arm64/kernel/mte_tag_storage.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7b071a00425d..fe8276fdc7a8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2062,6 +2062,18 @@ config ARM64_MTE
>
> Documentation/arch/arm64/memory-tagging-extension.rst.
>
> +if ARM64_MTE
> +config ARM64_MTE_TAG_STORAGE
> + bool "Dynamic MTE tag storage management"
> + help
> + Adds support for dynamic management of the memory used by the
> hardware
> + for storing MTE tags. This memory, unlike normal memory, cannot be
> + tagged. When it is used to store tags for another memory location it
> + cannot be used for any type of allocation.
> +
> + If unsure, say N
> +endif # ARM64_MTE
> +
> endmenu # "ARMv8.5 architectural features"
>
> menu "ARMv8.7 architectural features"
> diff --git a/arch/arm64/include/asm/mte_tag_storage.h
> b/arch/arm64/include/asm/mte_tag_storage.h
> new file mode 100644
> index ..8f86c4f9a7c3
> --- /dev/null
> +++ b/arch/arm64/include/asm/mte_tag_storage.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2023 ARM Ltd.
> + */
> +#ifndef __ASM_MTE_TAG_STORAGE_H
> +#define __ASM_MTE_TAG_STORAGE_H
> +
> +#ifdef CONFIG_ARM64_MTE_TAG_STORAGE
> +void mte_tag_storage_init(void);
> +#else
> +static inline void mte_tag_storage_init(void)
> +{
> +}
> +#endif /* CONFIG_ARM64_MTE_TAG_STORAGE */
> +#endif /* __ASM_MTE_TAG_STORAGE_H */
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index d95b3d6b471a..5f031bf9f8f1 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_CRASH_CORE) += crash_core.o
> obj-$(CONFIG_ARM_SDE_INTERFACE)+= sdei.o
> obj-$(CONFIG_ARM64_PTR_AUTH) += pointer_auth.o
> obj-$(CONFIG_ARM64_MTE)+= mte.o
> +obj-$(CONFIG_ARM64_MTE_TAG_STORAGE)+= mte_tag_storage.o
> obj-y += vdso-wrap.o
> obj-$(CONFIG_COMPAT_VDSO) += vdso32-wrap.o
> obj-$(CONFIG_UNWIND_PATCH_PAC_INTO_SCS)+= patch-scs.o
> diff --git a/arch/arm64/kernel/mte_tag_storage.c
> b/arch/arm64/kernel/mte_tag_storage.c
> new file mode 100644
> index ..fa6267ef8392
> --- /dev/null
> +++ b/arch/arm64/kernel/mte_tag_storage.c
> @@ -0,0 +1,256 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Support for dynamic tag storage.
> + *
> + * Copyright (C) 2023 ARM Ltd.
> + */
> +
> +#include
> +#include
> +#include
You probably don't need this header. If you depend on what it
implicitly includes, then that will now break in linux-next.
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct tag_region {
> + struct range mem_range; /* Memory associated with the tag storage, in
> PFNs. */
> + struct range tag_range; /* Tag storage memory, in PFNs. */
> + u32 block_size;
Re: [PATCH] dt-bindings: correct white-spaces in examples
On Fri, 24 Nov 2023 10:21:21 +0100, Krzysztof Kozlowski wrote: > Use only one and exactly one space around '=' in DTS example. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Merging idea: Rob's DT. > Should apply cleanly on Rob's for-next. > --- > .../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 2 +- > .../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml | 2 +- > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 6 +++--- > .../devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml | 2 +- > .../devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml | 2 +- > .../interrupt-controller/st,stih407-irq-syscfg.yaml | 4 ++-- > Documentation/devicetree/bindings/mmc/arm,pl18x.yaml | 2 +- > Documentation/devicetree/bindings/net/sff,sfp.yaml| 2 +- > .../devicetree/bindings/pci/toshiba,visconti-pcie.yaml| 2 +- > .../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 6 +++--- > .../devicetree/bindings/power/supply/richtek,rt9455.yaml | 8 > .../devicetree/bindings/regulator/mps,mp5416.yaml | 4 ++-- > .../devicetree/bindings/regulator/mps,mpq7920.yaml| 4 ++-- > .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8 > 14 files changed, 27 insertions(+), 27 deletions(-) > Applied, thanks!
Re: [PATCH v2 3/3] dt-bindings: usb: fsa4480: Add compatible for OCP96011
On Fri, 20 Oct 2023 11:33:20 +0200, Luca Weiss wrote: > The Orient-Chip OCP96011 is generally compatible with the FSA4480, add a > compatible for it with the fallback on fsa4480. > > However the AUX/SBU connections are expected to be swapped compared to > FSA4480, so document this in the data-lanes description. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml | 18 > ++ > 1 file changed, 14 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v2 1/3] dt-bindings: usb: fsa4480: Add data-lanes property to endpoint
On Fri, 20 Oct 2023 11:33:18 +0200, Luca Weiss wrote: > Allow specifying data-lanes to reverse the muxing orientation between > AUX+/- and SBU1/2 where necessary by the hardware design. > > In the mux there's a switch that needs to be controlled from the OS, and > it either connects AUX+ -> SBU1 and AUX- -> SBU2, or the reverse: AUX+ > -> SBU2 and AUX- -> SBU1, depending on the orientation of how the USB-C > connector is plugged in. > > With this data-lanes property we can now specify that AUX+ and AUX- > connections are swapped between the SoC and the mux, therefore the OS > needs to consider this and reverse the direction of this switch in the > mux. > > ___ ___ > | | | > |-- HP --| | > |-- MIC --| |or > SoC | | MUX |-- SBU1 ---> To the USB-C > Codec |-- AUX+ --| |-- SBU2 ---> connected > |-- AUX- --| | > __| |_| > > (thanks to Neil Armstrong for this ASCII art) > > Signed-off-by: Luca Weiss > --- > .../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 > +- > 1 file changed, 28 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: [PATCH] dt-bindings: Drop kernel copy of common reserved-memory bindings
On Fri, 13 Oct 2023 15:08:49 -0500, Rob Herring wrote: > The common reserved-memory bindings have recently been copied from the > kernel tree into dtschema. The preference is to host common, stable > bindings in dtschema. As reserved-memory is documented in the DT Spec, > it meets the criteria. > > The v2023.09 version of dtschema is what contains the reserved-memory > schemas we depend on, so bump the minimum version to that. Otherwise, > references to these schemas will generate errors. > > Signed-off-by: Rob Herring > --- > Documentation/devicetree/bindings/Makefile| 2 +- > .../remoteproc/renesas,rcar-rproc.yaml| 2 +- > .../bindings/reserved-memory/framebuffer.yaml | 52 - > .../reserved-memory/memory-region.yaml| 40 > .../reserved-memory/reserved-memory.txt | 2 +- > .../reserved-memory/reserved-memory.yaml | 181 -- > .../reserved-memory/shared-dma-pool.yaml | 97 -- > .../bindings/sound/mediatek,mt8188-afe.yaml | 2 +- > 8 files changed, 4 insertions(+), 374 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/memory-region.yaml > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml > Applied, thanks!
Re: [PATCH] dt-bindings: arm: cpus: Add Qualcomm Kryo 465
On Sat, 21 Oct 2023 09:16:19 +0200, David Wronek wrote: > Add a compatible for the Qualcomm Kryo 465 found in SM7125. > > Signed-off-by: David Wronek > --- > Documentation/devicetree/bindings/arm/cpus.yaml | 1 + > 1 file changed, 1 insertion(+) > Applied, thanks!
Re: [PATCH v5 3/4] arm64: dts: qcom: Add SM7125 device tree
On Thu, Aug 24, 2023 at 4:17 AM David Wronek wrote:
>
> The Snapdragon 720G (sm7125) is software-wise very similar to the
> Snapdragon 7c with minor differences in clock speeds and as added here,
> it uses the Kryo 465 instead of Kryo 468.
>
> Signed-off-by: David Wronek
> Reviewed-by: Konrad Dybcio
> ---
> arch/arm64/boot/dts/qcom/sm7125.dtsi | 16
> 1 file changed, 16 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/sm7125.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/sm7125.dtsi
> b/arch/arm64/boot/dts/qcom/sm7125.dtsi
> new file mode 100644
> index ..12dd72859a43
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm7125.dtsi
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include "sc7180.dtsi"
> +
> +/* SM7125 uses Kryo 465 instead of Kryo 468 */
> + { compatible = "qcom,kryo465"; };
> + { compatible = "qcom,kryo465"; };
> + { compatible = "qcom,kryo465"; };
> + { compatible = "qcom,kryo465"; };
> + { compatible = "qcom,kryo465"; };
> + { compatible = "qcom,kryo465"; };
> + { compatible = "qcom,kryo465"; };
> + { compatible = "qcom,kryo465"; };
This compatible is not documented. Please add it.
Rob
Re: [PATCH 1/3] dt-bindings: usb: fsa4480: Add data-lanes property to endpoint
On Mon, Oct 16, 2023 at 04:32:55PM +0200, Neil Armstrong wrote: > On 16/10/2023 16:22, Rob Herring wrote: > > On Fri, Oct 13, 2023 at 01:38:05PM +0200, Luca Weiss wrote: > > > Allow specifying data-lanes to reverse the SBU muxing orientation where > > > necessary by the hardware design. > > > > What situation in the hardware design makes this necessary. Please > > describe the problem. > > > > > > > > Signed-off-by: Luca Weiss > > > --- > > > .../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 > > > +- > > > 1 file changed, 28 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > > > b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > > > index f6e7a5c1ff0b..86f6d633c2fb 100644 > > > --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > > > +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > > > @@ -32,10 +32,37 @@ properties: > > > type: boolean > > > port: > > > -$ref: /schemas/graph.yaml#/properties/port > > > +$ref: /schemas/graph.yaml#/$defs/port-base > > > description: > > > A port node to link the FSA4480 to a TypeC controller for the > > > purpose of > > > handling altmode muxing and orientation switching. > > > +unevaluatedProperties: false > > > + > > > +properties: > > > + endpoint: > > > +$ref: /schemas/graph.yaml#/$defs/endpoint-base > > > +unevaluatedProperties: false > > > + > > > +properties: > > > + data-lanes: > > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > > +description: > > > + Specifies how the AUX+/- lines are connected to SBU1/2. > > > > Doesn't this depend on the connector orientation? Or it is both that and > > the lines can be swapped on the PCB? > > > > Seems like an abuse of data-lanes which already has a definition which > > is not about swapping + and - differential lanes. > > The FSA acts as a mux between DP AUX, Audio lanes on one side and > the USB-C SBU lanes on the other side. > ___ __ > | | | > |-- HP --| | > |-- MIC --| |or > SoC | | MUX |-- SBU1 ---> To the USB-C > Codec |-- AUX+ --| |-- SBU2 ---> connected > |-- AUX- --| | > __| | | > > The SBU1 & SBU2 are connected to the USB-C connector, and the actual > orientation > to the connected devices/cable/whatever is determined by the TPCM and the MUX > in > the FSA4480 with be dynamically changed according to the CC1/CC2 detection > and PD alt mode. > > But on the other side the orientation of the AUX+/AUX- connected to the SoC > is not tied to the USB-C orientation but how it's routed on the PCB. > > This describes how the AUX+/AUX- are physically routed to the FSA4480 chip. I'd hate for this ASCII art to go to waste. Please add this detail to the commit message. Rob
Re: [PATCH 1/3] dt-bindings: usb: fsa4480: Add data-lanes property to endpoint
On Fri, Oct 13, 2023 at 01:38:05PM +0200, Luca Weiss wrote: > Allow specifying data-lanes to reverse the SBU muxing orientation where > necessary by the hardware design. What situation in the hardware design makes this necessary. Please describe the problem. > > Signed-off-by: Luca Weiss > --- > .../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 > +- > 1 file changed, 28 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > index f6e7a5c1ff0b..86f6d633c2fb 100644 > --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml > @@ -32,10 +32,37 @@ properties: > type: boolean > >port: > -$ref: /schemas/graph.yaml#/properties/port > +$ref: /schemas/graph.yaml#/$defs/port-base > description: >A port node to link the FSA4480 to a TypeC controller for the purpose > of >handling altmode muxing and orientation switching. > +unevaluatedProperties: false > + > +properties: > + endpoint: > +$ref: /schemas/graph.yaml#/$defs/endpoint-base > +unevaluatedProperties: false > + > +properties: > + data-lanes: > +$ref: /schemas/types.yaml#/definitions/uint32-array > +description: > + Specifies how the AUX+/- lines are connected to SBU1/2. Doesn't this depend on the connector orientation? Or it is both that and the lines can be swapped on the PCB? Seems like an abuse of data-lanes which already has a definition which is not about swapping + and - differential lanes. Rob
[PATCH] dt-bindings: Drop kernel copy of common reserved-memory bindings
The common reserved-memory bindings have recently been copied from the
kernel tree into dtschema. The preference is to host common, stable
bindings in dtschema. As reserved-memory is documented in the DT Spec,
it meets the criteria.
The v2023.09 version of dtschema is what contains the reserved-memory
schemas we depend on, so bump the minimum version to that. Otherwise,
references to these schemas will generate errors.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings/Makefile| 2 +-
.../remoteproc/renesas,rcar-rproc.yaml| 2 +-
.../bindings/reserved-memory/framebuffer.yaml | 52 -
.../reserved-memory/memory-region.yaml| 40
.../reserved-memory/reserved-memory.txt | 2 +-
.../reserved-memory/reserved-memory.yaml | 181 --
.../reserved-memory/shared-dma-pool.yaml | 97 --
.../bindings/sound/mediatek,mt8188-afe.yaml | 2 +-
8 files changed, 4 insertions(+), 374 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
diff --git a/Documentation/devicetree/bindings/Makefile
b/Documentation/devicetree/bindings/Makefile
index 8b395893bd85..3e886194b043 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -6,7 +6,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
DT_SCHEMA_LINT = $(shell which yamllint || \
echo "warning: python package 'yamllint' not installed, skipping" >&2)
-DT_SCHEMA_MIN_VERSION = 2022.3
+DT_SCHEMA_MIN_VERSION = 2023.9
PHONY += check_dtschema_version
check_dtschema_version:
diff --git
a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
index 4bea679a0f61..5c280117dc93 100644
--- a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
@@ -31,7 +31,7 @@ properties:
remoteproc device. This is variable and describes the memories shared
with
the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
vrings, ...).
- (see ../reserved-memory/reserved-memory.yaml)
+ (see reserved-memory/reserved-memory.yaml in dtschema project)
required:
- compatible
diff --git a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
deleted file mode 100644
index 851ec24d6142..
--- a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
+++ /dev/null
@@ -1,52 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/reserved-memory/framebuffer.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: /reserved-memory framebuffer node
-
-maintainers:
- - devicetree-s...@vger.kernel.org
-
-allOf:
- - $ref: reserved-memory.yaml
-
-properties:
- compatible:
-const: framebuffer
-description: >
- This indicates a region of memory meant to be used as a framebuffer for
- a set of display devices. It can be used by an operating system to keep
- the framebuffer from being overwritten and use it as the backing memory
- for a display device (such as simple-framebuffer).
-
-unevaluatedProperties: false
-
-examples:
- - |
-/ {
-compatible = "foo";
-model = "foo";
-#address-cells = <1>;
-#size-cells = <1>;
-
-chosen {
-framebuffer {
-compatible = "simple-framebuffer";
-memory-region = <>;
-};
-};
-
-reserved-memory {
-#address-cells = <1>;
-#size-cells = <1>;
-ranges;
-
-fb: framebuffer@8000 {
-compatible = "framebuffer";
-reg = <0x8000 0x007e9000>;
-};
-};
-};
-...
diff --git
a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
b/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
deleted file mode 100644
index 592f180e6b0d..
--- a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
+++ /dev/null
@@ -1,40 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Reserved Memory Region
-
-maintainers:
- - devicetree-s...@vger.kernel.org
-
-description: |
- Regions in the /reserved-memory node
[PATCH] remoteproc: st: Use device_get_match_data()
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring
---
drivers/remoteproc/st_remoteproc.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/st_remoteproc.c
b/drivers/remoteproc/st_remoteproc.c
index e3ce01d98b4c..b0638f984842 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -16,10 +16,9 @@
#include
#include
#include
-#include
-#include
#include
#include
+#include
#include
#include
#include
@@ -341,7 +340,6 @@ static int st_rproc_parse_dt(struct platform_device *pdev)
static int st_rproc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- const struct of_device_id *match;
struct st_rproc *ddata;
struct device_node *np = dev->of_node;
struct rproc *rproc;
@@ -349,19 +347,15 @@ static int st_rproc_probe(struct platform_device *pdev)
int enabled;
int ret, i;
- match = of_match_device(st_rproc_match, dev);
- if (!match || !match->data) {
- dev_err(dev, "No device match found\n");
- return -ENODEV;
- }
-
rproc = rproc_alloc(dev, np->name, _rproc_ops, NULL, sizeof(*ddata));
if (!rproc)
return -ENOMEM;
rproc->has_iommu = false;
ddata = rproc->priv;
- ddata->config = (struct st_rproc_config *)match->data;
+ ddata->config = (struct st_rproc_config *)device_get_match_data(dev);
+ if (!ddata->config)
+ goto free_rproc;
platform_set_drvdata(pdev, rproc);
--
2.42.0
Re: [PATCH 1/2] dt-bindings: mfd: qcom,spmi-pmic: Update gpio example
On Mon, Oct 02, 2023 at 08:40:10AM +0200, Luca Weiss wrote:
> On Sat Sep 30, 2023 at 5:06 PM CEST, Krzysztof Kozlowski wrote:
> > On 29/09/2023 10:17, Luca Weiss wrote:
> > > As per commit ea25d61b448a ("arm64: dts: qcom: Use plural _gpios node
> > > label for PMIC gpios") all dts files now use the plural _gpios instead
> > > of the singular _gpio as label. Update the schema example also to match.
> > >
> > > Signed-off-by: Luca Weiss
> > > ---
> > > Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> > > b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> > > index 55e931ba5b47..e4842e1fbd65 100644
> > > --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> > > +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
> > > @@ -245,7 +245,7 @@ examples:
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > -pmi8998_gpio: gpio@c000 {
> > > +pmi8998_gpios: gpio@c000
> >
> > This does no make sense... you update label only here, but not in any
> > user of it which proves that label is not used. If it is not used, it
> > should be dropped, not changed...
>
> Okay, I will drop the label instead of updating it in v2.
Or just drop the patch and skip the trivial changes. If you want to fix
unused labels, fix it for the whole subsystem (mfd) or treewide.
Rob
Re: [PATCH] dt-bindings: remoteproc: mtk,scp: Add missing additionalProperties on child node schemas
On Thu, Sep 28, 2023 at 2:31 PM Mathieu Poirier wrote: > > Hi Rob, > > On Tue, Sep 26, 2023 at 11:45:08AM -0500, Rob Herring wrote: > > Just as unevaluatedProperties or additionalProperties are required at > > the top level of schemas, they should (and will) also be required for > > child node schemas. That ensures only documented properties are > > present for any node. > > > > Signed-off-by: Rob Herring > > --- > > Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > index 895415772d1d..24422fd56e83 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml > > @@ -91,6 +91,7 @@ allOf: > > > > additionalProperties: > >type: object > > + additionalProperties: false > > Things have changed in the remoteproc tree [1] and this patch doesn't apply. > Please see if it is still needed. It is not needed any more. Thanks, Rob
[PATCH] dt-bindings: remoteproc: mtk,scp: Add missing additionalProperties on child node schemas
Just as unevaluatedProperties or additionalProperties are required at the top level of schemas, they should (and will) also be required for child node schemas. That ensures only documented properties are present for any node. Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index 895415772d1d..24422fd56e83 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -91,6 +91,7 @@ allOf: additionalProperties: type: object + additionalProperties: false description: Subnodes of the SCP represent rpmsg devices. The names of the devices are not important. The properties of these nodes are defined by the -- 2.40.1
Re: [PATCH v6 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Wed, Sep 13, 2023 at 6:17 AM Hari Nagalla wrote: > > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > The remote processor's life cycle management and IPC mechanisms are > similar across the R5F and M4F cores from remote processor driver > point of view. However, there are subtle differences in image loading > and starting the M4F subsystems. > > The YAML binding document provides the various node properties to be > configured by the consumers of the M4F subsystem. > > Signed-off-by: Martyn Welch > Signed-off-by: Hari Nagalla > --- > Changes since v1: > - Spelling corrections > - Corrected to pass DT checks > > Changes since v2: > - Missed spelling correction to commit message > > Changes since v3: > - Removed unnecessary descriptions and used generic memory region names > - Made mboxes and memory-region optional > - Removed unrelated items from examples > > Changes since v4: > - Rebased to the latest kernel-next tree > - Added optional sram memory region for m4f device node > > Changes since v5: > - None > > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 136 ++ > 1 file changed, 136 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > > diff --git > a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > new file mode 100644 > index ..21b7f14d9dc4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > @@ -0,0 +1,136 @@ > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: TI K3 M4F processor subsystems > + > +maintainers: > + - Hari Nagalla > + - Mathieu Poirier > + > +description: | > + Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3 > + family with a M4F core. Typically safety oriented applications may use > + the M4F core in isolation without an IPC. Where as some industrial and > + home automation applications, may use the M4F core as a remote processor > + with IPC communications. > + > +$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# > + > +properties: > + > + compatible: > +enum: > + - ti,am64-m4fss > + > + power-domains: > +maxItems: 1 > + > + "#address-cells": > +const: 2 > + > + "#size-cells": > +const: 2 > + > + reg: > +items: > + - description: IRAM internal memory region > + - description: DRAM internal memory region > + > + reg-names: > +items: > + - const: iram > + - const: dram > + > + resets: > +maxItems: 1 > + > + firmware-name: > +$ref: /schemas/types.yaml#/definitions/string > +description: Name of firmware to load for the M4F core > + > + mboxes: > +description: | > + Mailbox specifier denoting the sub-mailbox, to be used for > communication > + with the remote processor. This property should match with the > + sub-mailbox node used in the firmware image. > +maxItems: 2 > + > + memory-region: > +description: | > + phandle to the reserved memory nodes to be associated with the > + remoteproc device. The reserved memory nodes should be carveout nodes, > + and should be defined with a "no-map" property as per the bindings in > + Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > + Optional memory regions available for firmware specific purposes. > +maxItems: 8 > +items: > + - description: regions used for DMA allocations like vrings, vring > buffers > + and memory dedicated to firmware's specific purposes. > +additionalItems: true > + > + sram: > +$ref: /schemas/types.yaml#/definitions/phandle-array > +minItems: 1 > +maxItems: 4 > +items: > + maxItems: 4 You are saying there are 1-4 entries and each entry is 4 cells. What's in the 4 cells? >From the description and example, looks like you only have 1 cell (a phandle) so maxItems should be 1. Your example should fail, but I'm not sure why it doesn't. Rob
Re: [PATCH v6 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On Wed, 13 Sep 2023 06:16:41 -0500, Hari Nagalla wrote: > K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. > The remote processor's life cycle management and IPC mechanisms are > similar across the R5F and M4F cores from remote processor driver > point of view. However, there are subtle differences in image loading > and starting the M4F subsystems. > > The YAML binding document provides the various node properties to be > configured by the consumers of the M4F subsystem. > > Signed-off-by: Martyn Welch > Signed-off-by: Hari Nagalla > --- > Changes since v1: > - Spelling corrections > - Corrected to pass DT checks > > Changes since v2: > - Missed spelling correction to commit message > > Changes since v3: > - Removed unnecessary descriptions and used generic memory region names > - Made mboxes and memory-region optional > - Removed unrelated items from examples > > Changes since v4: > - Rebased to the latest kernel-next tree > - Added optional sram memory region for m4f device node > > Changes since v5: > - None > > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 136 ++ > 1 file changed, 136 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/dma/stericsson,dma40.example.dtb: dma-controller@801c: sram:0: [4294967295, 4294967295] is too long from schema $id: http://devicetree.org/schemas/dma/stericsson,dma40.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230913111644.29889-2-hnaga...@ti.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
[PATCH] nvdimm: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring
---
drivers/nvdimm/of_pmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c
index 10dbdcdfb9ce..1b9f5b8a6167 100644
--- a/drivers/nvdimm/of_pmem.c
+++ b/drivers/nvdimm/of_pmem.c
@@ -2,11 +2,11 @@
#define pr_fmt(fmt) "of_pmem: " fmt
-#include
-#include
+#include
#include
#include
#include
+#include
#include
struct of_pmem_private {
--
2.40.1
Re: [PATCH 1/1] of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses
On Mon, Apr 19, 2021 at 9:03 PM Leonardo Bras wrote: > > On Mon, 2021-04-19 at 20:39 -0500, Rob Herring wrote: > > On Mon, Apr 19, 2021 at 7:35 PM Leonardo Bras wrote: > > > > > > On Mon, 2021-04-19 at 10:44 -0500, Rob Herring wrote: > > > > On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras > > > > wrote: > > > > > > > > > > Hello Rob, thanks for this feedback! > > > > > > > > > > On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote: > > > > > > +PPC and PCI lists > > > > > > > > > > > > On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras > > > > > > wrote: > > > > > > > > > > > > > > Many other resource flag parsers already add this flag when the > > > > > > > input > > > > > > > has bits 24 & 25 set, so update this one to do the same. > > > > > > > > > > > > Many others? Looks like sparc and powerpc to me. > > > > > > > > > > > > > > > > s390 also does that, but it look like it comes from a device-tree. > > > > > > > > I'm only looking at DT based platforms, and s390 doesn't use DT. > > > > > > Correct. > > > Sorry, I somehow write above the opposite of what I was thinking. > > > > > > > > > > > > > Those would be the > > > > > > ones I worry about breaking. Sparc doesn't use of/address.c so it's > > > > > > fine. Powerpc version of the flags code was only fixed in 2019, so I > > > > > > don't think powerpc will care either. > > > > > > > > > > In powerpc I reach this function with this stack, while configuring a > > > > > virtio-net device for a qemu/KVM pseries guest: > > > > > > > > > > pci_process_bridge_OF_ranges+0xac/0x2d4 > > > > > pSeries_discover_phbs+0xc4/0x158 > > > > > discover_phbs+0x40/0x60 > > > > > do_one_initcall+0x60/0x2d0 > > > > > kernel_init_freeable+0x308/0x3a8 > > > > > kernel_init+0x2c/0x168 > > > > > ret_from_kernel_thread+0x5c/0x70 > > > > > > > > > > For this, both MMIO32 and MMIO64 resources will have flags 0x200. > > > > > > > > Oh good, powerpc has 2 possible flags parsing functions. So in the > > > > above path, do we need to set PCI_BASE_ADDRESS_MEM_TYPE_64? > > > > > > > > Does pci_parse_of_flags() get called in your case? > > > > > > > > > > It's called in some cases, but not for the device I am debugging > > > (virtio-net pci@8002000). > > > > > > For the above device, here is an expanded stack trace: > > > > > > of_bus_pci_get_flags() (from parser->bus->get_flags()) > > > of_pci_range_parser_one() (from macro for_each_of_pci_range) > > > pci_process_bridge_OF_ranges+0xac/0x2d4 > > > pSeries_discover_phbs+0xc4/0x158 > > > discover_phbs+0x40/0x60 > > > do_one_initcall+0x60/0x2d0 > > > kernel_init_freeable+0x308/0x3a8 > > > kernel_init+0x2c/0x168 > > > ret_from_kernel_thread+0x5c/0x70 > > > > > > For other devices, I could also see the following stack trace: > > > ## device ethernet@8 > > > > > > pci_parse_of_flags() > > > of_create_pci_dev+0x7f0/0xa40 > > > __of_scan_bus+0x248/0x320 > > > pcibios_scan_phb+0x370/0x3b0 > > > pcibios_init+0x8c/0x12c > > > do_one_initcall+0x60/0x2d0 > > > kernel_init_freeable+0x308/0x3a8 > > > kernel_init+0x2c/0x168 > > > ret_from_kernel_thread+0x5c/0x70 > > > > > > Devices that get parsed with of_bus_pci_get_flags() appears first at > > > dmesg (around 0.015s in my test), while devices that get parsed by > > > pci_parse_of_flags() appears later (0.025s in my test). > > > > > > I am not really used to this code, but having the term "discover phbs" > > > in the first trace and the term "scan phb" in the second, makes me > > > wonder if the first trace is seen on devices that are seen/described in > > > the device-tree and the second trace is seen in devices not present in > > > the device-tree and found scanning pci bus. > > > > That was my guess as well. I think on pSeries that most PCI devices > > are in the DT whereas on Arm and other flattened DT (non OpenFirmware) > > platforms PCI devices ar
Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region
On Tue, Apr 20, 2021 at 11:10 AM Ard Biesheuvel wrote:
>
> On Tue, 20 Apr 2021 at 17:54, Rob Herring wrote:
> >
> > On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
> > wrote:
> > >
> > >
> > >
> > > On 4/20/21 4:45 PM, Rob Herring wrote:
> > > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > > > wrote:
> > > >>
> > > >> Hi,
> > > >
> > > > Greg or Sasha won't know what to do with this. Not sure who follows
> > > > the stable list either. Quentin sent the patch, but is not the author.
> > > > Given the patch in question is about consistency between EFI memory
> > > > map boot and DT memory map boot, copying EFI knowledgeable folks would
> > > > help (Ard B for starters).
> > >
> > > Ok thanks for the tips. I add Ard in the loop.
> >
> > Sigh. If it was only Ard I was suggesting I would have done that
> > myself. Now everyone on the patch in question and relevant lists are
> > Cc'ed.
> >
>
> Thanks for the cc.
>
> > >
> > > Ard, let me know if other people have to be directly added or if I have
> > > to resend to another mailing list.
> > >
> > > thanks
> > > alex
> > >
> > > >
> > > >>
> > > >> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> > > >> reserved-memory regions are no more "reserved" and make part of the
> > > >> kernel System RAM. This causes allocation failure for devices which try
> > > >> to take a reserved-memory region.
> > > >>
> > > >> It has been introduced by the following path:
> > > >>
> > > >> "fdt: Properly handle "no-map" field in the memory region
> > > >> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> > > >> which replace memblock_remove by memblock_mark_nomap in no-map case.
> > > >>
>
> Why was this backported? It doesn't look like a bugfix to me.
Probably because of commit 8a5a75e5e9e5 ("of/fdt: Make sure no-map
does not remove already reserved regions") which was in the same
series.
'Properly handle' implies before it was 'improperly handled', so
sounds like a fix.
Rob
Re: [PATCH 08/13] dt-bindings: net: document ptp_ref clk in dwmac
On Thu, 15 Apr 2021 12:10:32 +0200, Alexandre Torgue wrote: > ptp_ref clk has been added in DT but not documented which makes yaml > validation failed: > > ethernet@5800a000: clocks: [[6, 105], [6, 103], [6, 104], [6, 123], > [6, 169], [6, 112]] is too long > ethernet@5800a000: clock-names: ['stmmaceth', 'mac-clk-tx', 'mac-clk-rx', > 'eth-ck', 'ptp_ref', 'ethstp'] is too long > > Signed-off-by: Alexandre Torgue > Reviewed-by: Rob Herring
Re: [PATCH 04/13] dt-bindings: mfd: stm32-timers: remove #address/size cells from required properties
On Thu, 15 Apr 2021 12:10:28 +0200, Alexandre Torgue wrote: > address-cells and size-cells can't be declared as "required" properties > as they are not needed if subnodes don't have a "reg" entry. > > Signed-off-by: Alexandre Torgue > Acked-by: Rob Herring
Re: [PATCH 1/1] dt-bindings: serial: Add label property for pl011
On Thu, Apr 15, 2021 at 03:31:05PM +0800, Zhen Lei wrote:
> When there is more than one pl011 serial port present, the label property
> allows a custom name to be used for briefly describe the usage or position
> of each serial port.
>
> Without this "label" property, many dtbs_check warnings similar to the
> following are reported:
> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dt.yaml: \
> serial@ffd74000: Additional properties are not allowed ('label' was
> unexpected)
> From schema: Documentation/devicetree/bindings/serial/pl011.yaml
I think this should go into serial.yaml instead.
>
> Signed-off-by: Zhen Lei
> ---
> Documentation/devicetree/bindings/serial/pl011.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml
> b/Documentation/devicetree/bindings/serial/pl011.yaml
> index 1f8e9f2644b6b80..303c7746423f503 100644
> --- a/Documentation/devicetree/bindings/serial/pl011.yaml
> +++ b/Documentation/devicetree/bindings/serial/pl011.yaml
> @@ -34,6 +34,9 @@ properties:
>reg:
> maxItems: 1
>
> + label:
> +maxItems: 1
label is always a single string and so 'maxItems' is always 1. Just
need:
label: true
> +
>interrupts:
> maxItems: 1
>
> --
> 2.26.0.106.g9fadedd
>
>
Re: [PATCH v1 7/7] dt-bindings: iio: st,st-sensors: Add LSM9DS0 compatible string
On Wed, 14 Apr 2021 22:54:54 +0300, Andy Shevchenko wrote: > Enumerate LSM9DS0 (accelerometer and magnetometer parts) via > 'st,lsm9ds0-imu' compatible string. > > Signed-off-by: Andy Shevchenko > --- > Documentation/devicetree/bindings/iio/st,st-sensors.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH net-next v2 2/2] net: ethernet: mediatek: support custom GMAC label
On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
>
> For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
>
> Suggested-by: René van Dorst
> Signed-off-by: Ilya Lipnitskiy
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 6b00c12c6c43..df3cda63a8c5 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
>
> static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> {
> + const char *label = of_get_property(np, "label", NULL);
> const __be32 *_id = of_get_property(np, "reg", NULL);
> phy_interface_t phy_mode;
> struct phylink *phylink;
> @@ -2867,9 +2868,10 @@ static int mtk_add_mac(struct mtk_eth *eth, struct
> device_node *np)
> return -EINVAL;
> }
>
> - eth->netdev[id] = alloc_etherdev(sizeof(*mac));
> + eth->netdev[id] = alloc_netdev(sizeof(*mac), label ? label : "eth%d",
> +NET_NAME_UNKNOWN, ether_setup);
'label' is generally supposed to correspond to the sticker for the
device connector for a human to id. I can't really tell if that's the
case here. I don't see how 'gmacX' vs. 'ethX' maps to DSA master vs.
slave.
I don't think this should be handled within a specific driver either. If
we're going to have a way to name things, then fix it in
alloc_etherdev().
It can also be argued that device naming for userspace is a userspace
(udev) problem.
Rob
Re: [PATCH v2 1/2] dt-bindings: staging: iio: cdc: ad7746: add binding documentation for AD7746
On Sun, Apr 18, 2021 at 07:49:51PM -0300, Lucas Stankus wrote:
> Add device tree binding documentation for AD7746 cdc in YAML format.
>
> Signed-off-by: Lucas Stankus
> ---
>
> A minor note about the adi,excitation-vdd-permille property. Jonathan
> suggested the name to be adi,excitation-vdd-milicent, but I was unsure of
> the milicent naming. With a quick search I found out that the common way to
> call a thousandth is 'per mille'[1], but I didn't find any use of it in the
> kernel documentation. Any thoughts about it?
Seems okay to me.
> [1] https://en.wikipedia.org/wiki/Per_mille
>
> .../bindings/iio/cdc/adi,ad7746.yaml | 73 +++
> 1 file changed, 73 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
> b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
> new file mode 100644
> index ..a2a7eee674ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/cdc/adi,ad7746.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor
> +
> +maintainers:
> + - Michael Hennerich
> +
> +description: |
> + AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor
> +
> + Specifications about the part can be found at:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7291.pdf
> +
> +properties:
> + compatible:
> +enum:
> + - adi,ad7745
> + - adi,ad7746
> + - adi,ad7747
> +
> + reg:
> +maxItems: 1
> +
> + adi,excitation-vdd-permille:
> +description: |
> + Set VDD per mille to be used as the excitation voltage.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [125, 250, 375, 500]
> +
> + adi,exca-output-en:
> +description: Enables the EXCA pin as the excitation output.
> +type: boolean
> +
> + adi,exca-output-invert:
> +description: Inverts the excitation output in the EXCA pin.
> +type: boolean
'invert' assumes I know what the non-inverted signal is. Sometimes that
makes sense, but if you can define in terms of the inverse that would be
better. For example, for a normally active low signal, name the property
'foo-active-high'.
> +
> + adi,excb-output-en:
> +description: Enables the EXCB pin as the excitation output.
> +type: boolean
> +
> + adi,excb-output-invert:
> +description: Inverts the excitation output in the EXCB pin.
> +type: boolean
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ad7746: cdc@48 {
> +compatible = "adi,ad7746";
> +reg = <0x48>;
> +adi,excitation-vdd-permille = <125>;
> +
> +adi,exca-output-en;
> +adi,exca-output-invert;
> +adi,excb-output-en;
> +adi,excb-output-invert;
> + };
> +};
> +...
> --
> 2.31.1
>
Re: [PATCH v2 4/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kenzo
On Sat, 17 Apr 2021 00:40:51 +0800, Hsin-Yi Wang wrote: > Kenzo is known as Acer Chromebook 311. > > Signed-off-by: Hsin-Yi Wang > Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH v2 3/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-burnet
On Sat, 17 Apr 2021 00:40:50 +0800, Hsin-Yi Wang wrote: > Burnet is known as HP Chromebook x360 11MK G3 EE. > > Signed-off-by: Hsin-Yi Wang > Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 4 > 1 file changed, 4 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 2/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-willow
On Sat, 17 Apr 2021 00:40:49 +0800, Hsin-Yi Wang wrote: > Willow is known as Acer Chromebook 311 (C722/C722T). > > Signed-off-by: Hsin-Yi Wang > Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++ > 1 file changed, 7 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 1/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kappa
On Sat, 17 Apr 2021 00:40:48 +0800, Hsin-Yi Wang wrote: > Kappa is known as HP Chromebook 11a. > > Signed-off-by: Hsin-Yi Wang > Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 4 > 1 file changed, 4 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 2/4] memory: mediatek: add DRAM controller driver
On Fri, Apr 16, 2021 at 05:32:16PM +0800, Po-Kai Chi wrote:
> MediaTek DRAM controller (DRAMC) driver provides cross-platform features
> as below:
>
> 1. provide APIs for low power feature queries
> 2. create sysfs to pass the DRAM information to user-space
I'm hesistant with having both DT and sysfs vendor specific memory
properties. I think we need something common here.
>
> Signed-off-by: Po-Kai Chi
> ---
> drivers/memory/Kconfig |1 +
> drivers/memory/Makefile |1 +
> drivers/memory/mediatek/Kconfig |9 +
> drivers/memory/mediatek/Makefile|3 +
> drivers/memory/mediatek/mtk-dramc.c | 711
> +++
> include/memory/mediatek/dramc.h | 18 +
> 6 files changed, 743 insertions(+)
> create mode 100644 drivers/memory/mediatek/Kconfig
> create mode 100644 drivers/memory/mediatek/Makefile
> create mode 100644 drivers/memory/mediatek/mtk-dramc.c
> create mode 100644 include/memory/mediatek/dramc.h
>
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 72c0df1..056e906 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -225,6 +225,7 @@ config STM32_FMC2_EBI
> devices (like SRAM, ethernet adapters, FPGAs, LCD displays, ...) on
> SOCs containing the FMC2 External Bus Interface.
>
> +source "drivers/memory/mediatek/Kconfig"
> source "drivers/memory/samsung/Kconfig"
> source "drivers/memory/tegra/Kconfig"
>
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index bc7663e..cd4f8cf 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_PL353_SMC) += pl353-smc.o
> obj-$(CONFIG_RENESAS_RPCIF) += renesas-rpc-if.o
> obj-$(CONFIG_STM32_FMC2_EBI) += stm32-fmc2-ebi.o
>
> +obj-$(CONFIG_MTK_DRAMC) += mediatek/
> obj-$(CONFIG_SAMSUNG_MC) += samsung/
> obj-$(CONFIG_TEGRA_MC) += tegra/
> obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o
> diff --git a/drivers/memory/mediatek/Kconfig b/drivers/memory/mediatek/Kconfig
> new file mode 100644
> index 000..a1618b0
> --- /dev/null
> +++ b/drivers/memory/mediatek/Kconfig
> @@ -0,0 +1,9 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +config MTK_DRAMC
> + tristate "MediaTek DRAMC driver"
> + help
> + This selects the MediaTek(R) DRAMC driver.
> + Provide the API for DRAMC low power scenario, and the interface
> + for reporting DRAM information, e.g. DRAM mode register (MR) for
> + DRAM vendor ID, temperature, and density.
> diff --git a/drivers/memory/mediatek/Makefile
> b/drivers/memory/mediatek/Makefile
> new file mode 100644
> index 000..632be48
> --- /dev/null
> +++ b/drivers/memory/mediatek/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_MTK_DRAMC) += mtk-dramc.o
> diff --git a/drivers/memory/mediatek/mtk-dramc.c
> b/drivers/memory/mediatek/mtk-dramc.c
> new file mode 100644
> index 000..155b3b7
> --- /dev/null
> +++ b/drivers/memory/mediatek/mtk-dramc.c
> @@ -0,0 +1,711 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRAMC_DRV_NAME "mtk-dramc"
> +
> +struct mr_info_t {
> + unsigned int mr_index;
> + unsigned int mr_value;
> +};
> +
> +/*
> + * struct reg_ctrl_t - to describe the bits required in a register
> + * @offset: register address offset from a base
> + * @mask: bitmask of the target bits
> + * @shift: starting bit of the target bits
> + */
> +struct reg_ctrl_t {
> + unsigned int offset;
> + unsigned int mask;
> + unsigned int shift;
> +};
> +
> +struct fmeter_dev_t {
> + unsigned int crystal_freq;
> + unsigned int shu_of;
> + struct reg_ctrl_t shu_lv;
> + struct reg_ctrl_t pll_id;
> + struct reg_ctrl_t pll_md[2];
> + struct reg_ctrl_t sdmpcw[2];
> + struct reg_ctrl_t prediv[2];
> + struct reg_ctrl_t posdiv[2];
> + struct reg_ctrl_t ckdiv4[2];
> + struct reg_ctrl_t cldiv2[2];
> + struct reg_ctrl_t fbksel[2];
> + struct reg_ctrl_t dqopen[2];
> +};
> +
> +struct mr4_dev_t {
> + struct reg_ctrl_t mr4_rg;
> +};
> +
> +struct dramc_dev_t {
> + unsigned int dram_type;
> + unsigned int support_channel_cnt;
> + unsigned int channel_cnt;
> + unsigned int rank_cnt;
> + unsigned int mr_cnt;
> + unsigned int freq_cnt;
> + unsigned int *rank_size;
> + unsigned int *freq_step;
> + struct mr_info_t *mr_info_ptr;
> + void __iomem **dramc_chn_base_ao;
> + void __iomem **dramc_chn_base_nao;
> + void __iomem **ddrphy_chn_base_ao;
> + void *mr4_dev_ptr;
> + void *fmeter_dev_ptr;
> +};
> +
> +enum DRAM_TYPE {
> + TYPE_NONE = 0,
> + TYPE_DDR1,
> + TYPE_LPDDR2,
> + TYPE_LPDDR3,
> +
Re: [PATCH v3 10/11] dt-bindings: clock: stm32mp1 new compatible for secure rcc
On Mon, 19 Apr 2021 11:38:51 +0200, gabriel.fernan...@foss.st.com wrote: > From: Gabriel Fernandez > > Introduce new compatible string "st,stm32mp1-rcc-secure" for > stm32mp1 clock driver when the device is configured with RCC > security support hardened. > > Signed-off-by: Etienne Carriere > Signed-off-by: Gabriel Fernandez > --- > .../devicetree/bindings/clock/st,stm32mp1-rcc.yaml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > Acked-by: Rob Herring
Re: [PATCH v3 2/5] dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings
On Mon, 19 Apr 2021 09:32:41 +0200, Neil Armstrong wrote: > Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings. > > Signed-off-by: Neil Armstrong > --- > .../devicetree/bindings/display/mediatek/mediatek,cec.yaml | 1 + > .../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml | 1 + > .../devicetree/bindings/display/mediatek/mediatek,hdmi.yaml | 1 + > 3 files changed, 3 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v3 1/5] dt-bindings: display: mediatek, hdmi: Convert to use graph schema
On Mon, 19 Apr 2021 09:32:40 +0200, Neil Armstrong wrote: > Update the mediatek,dpi binding to use the graph schema. > > Signed-off-by: Neil Armstrong > --- > .../display/mediatek/mediatek,cec.yaml| 51 +++ > .../display/mediatek/mediatek,hdmi-ddc.yaml | 57 > .../display/mediatek/mediatek,hdmi.txt| 136 -- > .../display/mediatek/mediatek,hdmi.yaml | 132 + > 4 files changed, 240 insertions(+), 136 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > create mode 100644 > Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > Reviewed-by: Rob Herring
Re: [PATCH v4 1/2] dt-bindings: iio: accel: Add SCA3300 documentation
On Tue, 20 Apr 2021 16:23:32 +0300, Tomas Melin wrote: > initial DT bindings for Murata SCA3300 Accelerometer. > > Signed-off-by: Tomas Melin > --- > .../bindings/iio/accel/murata,sca3300.yaml| 44 +++ > 1 file changed, 44 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml > Reviewed-by: Rob Herring
Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region
On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
wrote:
>
>
>
> On 4/20/21 4:45 PM, Rob Herring wrote:
> > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > wrote:
> >>
> >> Hi,
> >
> > Greg or Sasha won't know what to do with this. Not sure who follows
> > the stable list either. Quentin sent the patch, but is not the author.
> > Given the patch in question is about consistency between EFI memory
> > map boot and DT memory map boot, copying EFI knowledgeable folks would
> > help (Ard B for starters).
>
> Ok thanks for the tips. I add Ard in the loop.
Sigh. If it was only Ard I was suggesting I would have done that
myself. Now everyone on the patch in question and relevant lists are
Cc'ed.
>
> Ard, let me know if other people have to be directly added or if I have
> to resend to another mailing list.
>
> thanks
> alex
>
> >
> >>
> >> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> >> reserved-memory regions are no more "reserved" and make part of the
> >> kernel System RAM. This causes allocation failure for devices which try
> >> to take a reserved-memory region.
> >>
> >> It has been introduced by the following path:
> >>
> >> "fdt: Properly handle "no-map" field in the memory region
> >> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> >> which replace memblock_remove by memblock_mark_nomap in no-map case.
> >>
> >> Reverting this patch it's fine.
> >>
> >> I add part of my DT (something is maybe wrong inside):
> >>
> >> memory@c000 {
> >> reg = <0xc000 0x2000>;
> >> };
> >>
> >> reserved-memory {
> >> #address-cells = <1>;
> >> #size-cells = <1>;
> >> ranges;
> >>
> >> gpu_reserved: gpu@d400 {
> >> reg = <0xd400 0x400>;
> >> no-map;
> >> };
> >> };
> >>
> >> Sorry if this issue has already been raised and discussed.
> >>
> >> Thanks
> >> alex
Re: [PATCH v9 13/15] dt-bindings: power: rockchip: Convert to json-schema
On Sat, 17 Apr 2021 13:29:50 +0200, Johan Jonker wrote: > From: Enric Balletbo i Serra > > Convert the soc/rockchip/power_domain.txt binding document to > json-schema and move to the power bindings directory. > > Signed-off-by: Enric Balletbo i Serra > Signed-off-by: Elaine Zhang > Signed-off-by: Johan Jonker > --- > Note for rob+dt: > A tag was not added on purpose, because: > Add "rockchip," prefix to the qos compatible name > in example. > Changed maintainers. > Size reg description is reduced. > Little style changes '' to "" > Restyle patternProperties > Please have a look at it again. > > For some SoC nodes this patch serie generates notifications > for undocumented "assigned-clocks" and "assigned-clock-parents" > properties till there is consensus of what to do with it. > --- > Changed V9: > Rename definitions to $defs > Restyle patternProperties > Changed V8: > Add pd-node ref schema > Changed V7: > Fix commit message and author format > Changed SPDX-License-Identifier back to GPL-2.0 > Remove "clocks", "assigned-clocks" and "assigned-clock-parents" > Fix indent example > Changed V6: > Changed author > Changed V5: > Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause > Remove a maintainer > Changed patternProperties to power-domain > Add "clocks", "assigned-clocks" and "assigned-clock-parents" > Changed V4: > Remove new compatible string > Style changes '' to "" > Changed V3: > Use Enric's conversion with rk3399 example > Changed V2: > Convert power_domain.txt to YAML with rk3568 example > --- > .../bindings/power/rockchip,power-controller.yaml | 246 > + > .../bindings/soc/rockchip/power_domain.txt | 136 ---- > 2 files changed, 246 insertions(+), 136 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > delete mode 100644 > Documentation/devicetree/bindings/soc/rockchip/power_domain.txt > Reviewed-by: Rob Herring
Re: [PATCH v2 4/5] dt-bindings: arm: qcom: Document MSM8226 SoC binding
On Sun, 18 Apr 2021 14:29:08 +0200, Bartosz Dudziak wrote: > Document the MSM8226 SoC device-tree binding. > > Signed-off-by: Bartosz Dudziak > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++ > 1 file changed, 6 insertions(+) > Acked-by: Rob Herring
Re: [PATCH v2 1/5] dt-bindings: clock: qcom: Add MSM8226 GCC clock bindings
On Sun, Apr 18, 2021 at 02:29:05PM +0200, Bartosz Dudziak wrote: > Add compatible device strings and the include files for the MSM8226 GCC. > > Signed-off-by: Bartosz Dudziak > --- > Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Acked-by: Rob Herring
Re: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config driver
On Tue, Apr 20, 2021 at 01:41:52PM +0530, Nava kishore Manne wrote:
> This patch adds the binding document for the zynqmp afi
> config driver.
Bindings are for h/w blocks, not drivers.
>
> Signed-off-by: Nava kishore Manne
> ---
> .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml | 136 ++
> 1 file changed, 136 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
>
> diff --git a/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> new file mode 100644
> index ..3ae22096b22a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/misc/xlnx,zynqmp-afi-fpga.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx ZynqMP AFI interface Manager.
> +
> +maintainers:
> + - Nava kishore Manne
> +
> +description: |
> + The Zynq UltraScale+ MPSoC Processing System core provides access from PL
> + masters to PS internal peripherals, and memory through AXI FIFO
> interface(AFI)
> + interfaces.
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - xlnx,zynqmp-afi-fpga
> +
> + config-afi:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: |
> + Pairs of
> + The possible values of regid and values are
> + regid - Regids of the register to be written possible values
If we wanted sequences of register accesses in DT, we'd have a
generic mechanism to do so.
> +0- AFIFM0_RDCTRL
> +1- AFIFM0_WRCTRL
> +2- AFIFM1_RDCTRL
> +3- AFIFM1_WRCTRL
> +4- AFIFM2_RDCTRL
> +5- AFIFM2_WRCTRL
> +6- AFIFM3_RDCTRL
> +7- AFIFM3_WRCTRL
> +8- AFIFM4_RDCTRL
> +9- AFIFM4_WRCTRL
> +10- AFIFM5_RDCTRL
> +11- AFIFM5_WRCTRL
> +12- AFIFM6_RDCTRL
> +13- AFIFM6_WRCTRL
> +14- AFIFS
> +15- AFIFS_SS2
> + value - Array of values to be written.
> +for FM0_RDCTRL(0) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM0_WRCTRL(1) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM1_RDCTRL(2) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM1_WRCTRL(3) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM2_RDCTRL(4) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM2_WRCTRL(5) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM3_RDCTRL(6) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM3_WRCTRL(7) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM4_RDCTRL(8) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM4_WRCTRL(9) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM5_RDCTRL(10) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM5_WRCTRL(11) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM6_RDCTRL(12) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for FM6_WRCTRL(13) the valid values-fabric width
> + 2 - 32-bit
> + 1 - 64-bit
> + 0 - 128-bit
> +for AFI_FA(14)
> + dw_ss1_sel bits (11:10)
> + dw_ss0_sel bits (9:8)
> +0x0 - 32-bit AXI data width
> +0x1 - 64-bit AXI data width
> +0x2 - 128-bit AXI data width
> +All other bits are 0 write ignored.
> +
> +for AFI_FA(15) selects for ss2AXI data width valid values
> + 0x000 - 32-bit AXI data width
> + 0x100 - 64-bit AXI data width
> + 0x200 - 128-bit AXI data width
> +minItems: 1
> +maxItems: 15
> +
> +required:
> + - compatible
> + - config-afi
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +firmware {
> + zynqmp_firmware: zynqmp-firmware {
> +compatible = "xlnx,zynqmp-firmware";
> +method = "smc";
> +afi0: afi {
> + compatible = "xlnx,afi-fpga";
> + config-afi = <0 2>, <1 1>, <2 1>;
> +};
> + };
> +};
> +
> +...
> --
Re: [PATCH 0/5] mtd: core: OTP nvmem provider support
On Fri, Apr 16, 2021 at 09:26:03PM +0200, Michael Walle wrote:
> Hi Rob,
>
> Am 2021-04-16 20:44, schrieb Rob Herring:
> > On Fri, Apr 16, 2021 at 01:49:23PM +0200, Michael Walle wrote:
> > > The goal is to fetch a (base) MAC address from the OTP region of a
> > > SPI NOR
> > > flash.
> > >
> > > This is the first part, where I try to add the nvmem provider
> > > support to
> > > the MTD core.
> > >
> > > I'm not sure about the device tree bindings. Consider the following
> > > two
> > > variants:
> > >
> > > (1)
> > > flash@0 {
> > > ..
> > >
> > > otp {
> > > compatible = "mtd-user-otp";
> >
> > mtd is a linuxism. Why not just 'nvmem-cells' here or as a fallback if
> > we come up with a better name?
>
> There are two different compatibles: "mtd-user-otp" and "mtd-factory-otp"
> to differentiate what kind of OTP should be used (and both are possible
> at the same time). Thus nvmem-cells alone won't be enough. We could drop
> the "mtd-" prefix though.
>
> Is there a benefit of having the following?
> compatible = "user-otp", "nvmem-cells";
Yes. I assume 'user-otp' tells you something about the region and
'nvmem-cells' tells you that there are child nodes of nvmem data. Of
course 'user-otp' could imply 'nvmem-cells' as you did. I'm fine with
either way.
Rob
Re: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config driver
On Tue, 20 Apr 2021 13:41:52 +0530, Nava kishore Manne wrote: > This patch adds the binding document for the zynqmp afi > config driver. > > Signed-off-by: Nava kishore Manne > --- > .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml | 136 ++ > 1 file changed, 136 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.example.dt.yaml:0:0: /example-0/firmware/zynqmp-firmware: failed to match any schema with compatible: ['xlnx,zynqmp-firmware'] Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.example.dt.yaml:0:0: /example-0/firmware/zynqmp-firmware/afi: failed to match any schema with compatible: ['xlnx,afi-fpga'] See https://patchwork.ozlabs.org/patch/1468230 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH 1/6] dt-bindings: PCI: ti,am65: Add PCIe host mode dt-bindings for TI's AM65 SoC
On Tue, Mar 30, 2021 at 4:29 AM Kishon Vijay Abraham I wrote: > > Hi Rob, > > On 26/03/21 5:08 am, Rob Herring wrote: > > On Thu, Mar 25, 2021 at 02:30:21PM +0530, Kishon Vijay Abraham I wrote: > >> Add PCIe host mode dt-bindings for TI's AM65 SoC. > >> > >> Signed-off-by: Kishon Vijay Abraham I > >> --- > >> .../bindings/pci/ti,am65-pci-host.yaml| 111 ++ > >> 1 file changed, 111 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml > >> > >> diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml > >> b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml > >> new file mode 100644 > >> index ..b77e492886fa > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml > >> @@ -0,0 +1,111 @@ > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >> +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/ > >> +%YAML 1.2 > >> +--- > >> +$id: "http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#; > >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > >> + > >> +title: TI AM65 PCI Host > >> + > >> +maintainers: > >> + - Kishon Vijay Abraham I > >> + > >> +allOf: > >> + - $ref: /schemas/pci/pci-bus.yaml# > >> + > >> +properties: > >> + compatible: > >> +enum: > >> + - ti,am654-pcie-rc > >> + > >> + reg: > >> +maxItems: 4 > >> + > >> + reg-names: > >> +items: > >> + - const: app > >> + - const: dbics > > > > Please use 'dbi' like everyone else if this isn't shared with the other > > TI DW PCI bindings. > > I'm just converting existing binding in pci-keystone.txt to yaml. > Documentation/devicetree/bindings/pci/pci-keystone.txt > > Device tree for AM65 is also already in the upstream kernel. > > I can try to remove the am65 specific part from pci-keystone.txt Can you remove pci-keystone.txt entirely. That's what 'converting' means. Rob
Re: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
On Mon, Jan 25, 2021 at 7:18 PM Nicolas Boichat wrote: > > Define a compatible string for the Mali Bifrost GPU found in > Mediatek's MT8183 SoCs. > > Signed-off-by: Nicolas Boichat > --- > > Changes in v11: > - binding: power-domain-names not power-domainS-names > > Changes in v10: > - Fix the binding to make sure sram-supply property can be provided. > > Changes in v9: None > Changes in v8: None > Changes in v7: None > Changes in v6: > - Rebased, actually tested with recent mesa driver. > > Changes in v5: > - Rename "2d" power domain to "core2" > > Changes in v4: > - Add power-domain-names description >(kept Alyssa's reviewed-by as the change is minor) > > Changes in v3: None > Changes in v2: None > > .../bindings/gpu/arm,mali-bifrost.yaml| 28 +++ > 1 file changed, 28 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > index 184492162e7e..3e758f88e2cd 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > @@ -17,6 +17,7 @@ properties: > items: >- enum: >- amlogic,meson-g12a-mali > + - mediatek,mt8183-mali >- realtek,rtd1619-mali >- rockchip,px30-mali >- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully > discoverable > @@ -41,6 +42,8 @@ properties: > >mali-supply: true > > + sram-supply: true > + >operating-points-v2: true > >power-domains: > @@ -87,6 +90,31 @@ allOf: > then: >required: > - resets > + - if: > + properties: > +compatible: > + contains: > +const: mediatek,mt8183-mali > +then: > + properties: > +power-domains: > + description: > +List of phandle and PM domain specifier as documented in > +Documentation/devicetree/bindings/power/power_domain.txt > + minItems: 3 > + maxItems: 3 This won't work because the top level schema restricts this to 1. The top level needs to say: power-domains: minItems: 1 maxItems: 3 And you need just 'minItems: 3' here and 'maxItems: 1' in the else clause. And drop the description. That's every 'power-domains' property. > +power-domain-names: > + items: > +- const: core0 > +- const: core1 > +- const: core2 Blank line > + required: > +- sram-supply > +- power-domains > +- power-domain-names > +else: > + properties: > +sram-supply: false > > examples: >- | > -- > 2.30.0.280.ga3ce27912f-goog >
Re: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
On Fri, Feb 5, 2021 at 9:02 PM Nicolas Boichat wrote: > > On Sat, Feb 6, 2021 at 1:55 AM Rob Herring wrote: > > > > On Tue, 26 Jan 2021 09:17:56 +0800, Nicolas Boichat wrote: > > > Define a compatible string for the Mali Bifrost GPU found in > > > Mediatek's MT8183 SoCs. > > > > > > Signed-off-by: Nicolas Boichat > > > --- > > > > > > Changes in v11: > > > - binding: power-domain-names not power-domainS-names > > > > > > Changes in v10: > > > - Fix the binding to make sure sram-supply property can be provided. > > > > > > Changes in v9: None > > > Changes in v8: None > > > Changes in v7: None > > > Changes in v6: > > > - Rebased, actually tested with recent mesa driver. > > > > > > Changes in v5: > > > - Rename "2d" power domain to "core2" > > > > > > Changes in v4: > > > - Add power-domain-names description > > >(kept Alyssa's reviewed-by as the change is minor) > > > > > > Changes in v3: None > > > Changes in v2: None > > > > > > .../bindings/gpu/arm,mali-bifrost.yaml| 28 +++ > > > 1 file changed, 28 insertions(+) > > > > > > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > > there's no need to repost patches *only* to add the tags. The upstream > > maintainer will do that for acks received on the version they apply. > > > > If a tag was not added on purpose, please state why and what changed. > > There were changes in v11, I thought you'd want to review again? Looked like a minor change from the changelog, so it would have been appropriate to keep. However, I see another issue. Rob
[PATCH v7 9/9] Documentation: arm64: Document PMU counters access from userspace
From: Raphael Gault Add documentation to describe the access to the pmu hardware counters from userspace. Signed-off-by: Raphael Gault Signed-off-by: Rob Herring --- v7: - Merge into existing arm64 perf.rst v6: - Update the chained event section with attr.config1 details v2: - Update links to test examples Changes from Raphael's v4: - Convert to rSt - Update chained event status - Add section for heterogeneous systems --- Documentation/arm64/perf.rst | 67 +++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/Documentation/arm64/perf.rst b/Documentation/arm64/perf.rst index b567f177d385..c40fc2adc451 100644 --- a/Documentation/arm64/perf.rst +++ b/Documentation/arm64/perf.rst @@ -2,7 +2,10 @@ .. _perf_index: -= + +Perf + + Perf Event Attributes = @@ -88,3 +91,65 @@ exclude_host. However when using !exclude_hv there is a small blackout window at the guest entry/exit where host events are not captured. On VHE systems there are no blackout windows. + +Perf Userspace PMU Hardware Counter Access +== + +Overview + +The perf userspace tool relies on the PMU to monitor events. It offers an +abstraction layer over the hardware counters since the underlying +implementation is cpu-dependent. +Arm64 allows userspace tools to have access to the registers storing the +hardware counters' values directly. + +This targets specifically self-monitoring tasks in order to reduce the overhead +by directly accessing the registers without having to go through the kernel. + +How-to +-- +The focus is set on the armv8 PMUv3 which makes sure that the access to the pmu +registers is enabled and that the userspace has access to the relevant +information in order to use them. + +In order to have access to the hardware counter it is necessary to open the event +using the perf tool interface: the sys_perf_event_open syscall returns a fd which +can subsequently be used with the mmap syscall in order to retrieve a page of +memory containing information about the event. +The PMU driver uses this page to expose to the user the hardware counter's +index and other necessary data. Using this index enables the user to access the +PMU registers using the `mrs` instruction. + +The userspace access is supported in libperf using the perf_evsel__mmap() +and perf_evsel__read() functions. See `tools/lib/perf/tests/test-evsel.c`_ for +an example. + +About heterogeneous systems +--- +On heterogeneous systems such as big.LITTLE, userspace PMU counter access can +only be enabled when the tasks are pinned to a homogeneous subset of cores and +the corresponding PMU instance is opened by specifying the 'type' attribute. +The use of generic event types is not supported in this case. + +Have a look at `tools/perf/arch/arm64/tests/user-events.c`_ for an example. It +can be run using the perf tool to check that the access to the registers works +correctly from userspace: + +.. code-block:: sh + + perf test -v user + +About chained events and 64-bit counters + +Chained events are not supported in conjunction with userspace counter +access. If a 64-bit counter is requested (attr.config1:0), then +userspace access must also be requested with attr.config1:1 set. This +will disable counter chaining. The 'pmc_width' in the user page will +indicate the actual width of the counter which could be only 32-bits +depending on event and PMU features. + +.. Links +.. _tools/perf/arch/arm64/tests/user-events.c: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm64/tests/user-events.c +.. _tools/lib/perf/tests/test-evsel.c: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/tests/test-evsel.c -- 2.27.0
[PATCH v7 7/9] perf: arm64: Add test for userspace counter access on heterogeneous systems
Userspace counter access only works on heterogeneous systems with some
restrictions. The userspace process must be pinned to a homogeneous
subset of CPUs and must open the corresponding PMU for those CPUs. This
commit adds a test implementing these requirements.
Signed-off-by: Rob Herring
---
v6:
- Add a check on cap_user_rdpmc
v5:
- Adapt to libperf mmap API changes
v4:
- Update perf_evsel__mmap params
v2:
- Drop all but heterogeneous test as others covered by libperf tests
- Rework to use libperf
---
tools/perf/arch/arm64/include/arch-tests.h | 7 +
tools/perf/arch/arm64/tests/Build | 1 +
tools/perf/arch/arm64/tests/arch-tests.c | 4 +
tools/perf/arch/arm64/tests/user-events.c | 177 +
4 files changed, 189 insertions(+)
create mode 100644 tools/perf/arch/arm64/tests/user-events.c
diff --git a/tools/perf/arch/arm64/include/arch-tests.h
b/tools/perf/arch/arm64/include/arch-tests.h
index 90ec4c8cb880..380ad34a3f09 100644
--- a/tools/perf/arch/arm64/include/arch-tests.h
+++ b/tools/perf/arch/arm64/include/arch-tests.h
@@ -2,11 +2,18 @@
#ifndef ARCH_TESTS_H
#define ARCH_TESTS_H
+#include
+
#ifdef HAVE_DWARF_UNWIND_SUPPORT
struct thread;
struct perf_sample;
+int test__arch_unwind_sample(struct perf_sample *sample,
+struct thread *thread);
#endif
extern struct test arch_tests[];
+int test__rd_pinned(struct test __maybe_unused *test,
+ int __maybe_unused subtest);
+
#endif
diff --git a/tools/perf/arch/arm64/tests/Build
b/tools/perf/arch/arm64/tests/Build
index a61c06bdb757..3f9a20c17fc6 100644
--- a/tools/perf/arch/arm64/tests/Build
+++ b/tools/perf/arch/arm64/tests/Build
@@ -1,4 +1,5 @@
perf-y += regs_load.o
perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
+perf-y += user-events.o
perf-y += arch-tests.o
diff --git a/tools/perf/arch/arm64/tests/arch-tests.c
b/tools/perf/arch/arm64/tests/arch-tests.c
index 5b1543c98022..80ce7bd3c16d 100644
--- a/tools/perf/arch/arm64/tests/arch-tests.c
+++ b/tools/perf/arch/arm64/tests/arch-tests.c
@@ -10,6 +10,10 @@ struct test arch_tests[] = {
.func = test__dwarf_unwind,
},
#endif
+ {
+ .desc = "Pinned CPU user counter access",
+ .func = test__rd_pinned,
+ },
{
.func = NULL,
},
diff --git a/tools/perf/arch/arm64/tests/user-events.c
b/tools/perf/arch/arm64/tests/user-events.c
new file mode 100644
index ..c8efc6b369e6
--- /dev/null
+++ b/tools/perf/arch/arm64/tests/user-events.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "pmu.h"
+#include "debug.h"
+#include "tests/tests.h"
+#include "arch-tests.h"
+
+static int run_test(struct perf_evsel *evsel)
+{
+ int n;
+ volatile int tmp = 0;
+ u64 delta, i, loops = 1000;
+ struct perf_counts_values counts = { .val = 0 };
+
+ for (n = 0; n < 6; n++) {
+ u64 stamp, now;
+
+ perf_evsel__read(evsel, 0, 0, );
+ stamp = counts.val;
+
+ for (i = 0; i < loops; i++)
+ tmp++;
+
+ perf_evsel__read(evsel, 0, 0, );
+ now = counts.val;
+ loops *= 10;
+
+ delta = now - stamp;
+ pr_debug("%14d: %14llu\n", n, (long long)delta);
+
+ if (!delta)
+ break;
+ }
+ return delta ? 0 : -1;
+}
+
+static struct perf_pmu *pmu_for_cpu(int cpu)
+{
+ int acpu, idx;
+ struct perf_pmu *pmu = NULL;
+
+ while ((pmu = perf_pmu__scan(pmu)) != NULL) {
+ if (pmu->is_uncore)
+ continue;
+ perf_cpu_map__for_each_cpu(acpu, idx, pmu->cpus)
+ if (acpu == cpu)
+ return pmu;
+ }
+ return NULL;
+}
+
+static bool pmu_is_homogeneous(void)
+{
+ int core_cnt = 0;
+ struct perf_pmu *pmu = NULL;
+
+ while ((pmu = perf_pmu__scan(pmu)) != NULL) {
+ if (!pmu->is_uncore && !perf_cpu_map__empty(pmu->cpus))
+ core_cnt++;
+ }
+ return core_cnt == 1;
+}
+
+static int libperf_print(enum libperf_print_level level,
+const char *fmt, va_list ap)
+{
+ (void)level;
+ return vfprintf(stderr, fmt, ap);
+}
+
+static struct perf_evsel *perf_init(struct perf_event_attr *attr)
+{
+ int err;
+ struct perf_thread_map *threads;
+ struct perf_evsel *evsel;
+ struct perf_event_mmap_page *pc;
+
+ libperf_init(libperf_print);
+
+ threads = perf_thread_map__new_dummy();
+ if (!threads) {
+ pr_err("failed to create threads\n");
+ return NULL;
+ }
+
+ perf_thread_map__set_pid(threa
[PATCH v7 8/9] perf: arm64: Add tests for 32-bit and 64-bit counter size userspace access
Add arm64 specific tests for 32-bit and 64-bit counter user access. On
arm64, counters default to 32-bit unless attr.config1:0 is set to 1. In
order to enable user access for 64-bit counters, attr.config1 must be set
to 3.
Signed-off-by: Rob Herring
---
v6:
- New patch
---
tools/perf/arch/arm64/include/arch-tests.h | 5 +++
tools/perf/arch/arm64/tests/arch-tests.c | 8 +
tools/perf/arch/arm64/tests/user-events.c | 38 ++
3 files changed, 51 insertions(+)
diff --git a/tools/perf/arch/arm64/include/arch-tests.h
b/tools/perf/arch/arm64/include/arch-tests.h
index 380ad34a3f09..ddfa7460e1e1 100644
--- a/tools/perf/arch/arm64/include/arch-tests.h
+++ b/tools/perf/arch/arm64/include/arch-tests.h
@@ -15,5 +15,10 @@ extern struct test arch_tests[];
int test__rd_pinned(struct test __maybe_unused *test,
int __maybe_unused subtest);
+int test__rd_64bit(struct test __maybe_unused *test,
+ int __maybe_unused subtest);
+
+int test__rd_32bit(struct test __maybe_unused *test,
+ int __maybe_unused subtest);
#endif
diff --git a/tools/perf/arch/arm64/tests/arch-tests.c
b/tools/perf/arch/arm64/tests/arch-tests.c
index 80ce7bd3c16d..bbdb81aa3229 100644
--- a/tools/perf/arch/arm64/tests/arch-tests.c
+++ b/tools/perf/arch/arm64/tests/arch-tests.c
@@ -14,6 +14,14 @@ struct test arch_tests[] = {
.desc = "Pinned CPU user counter access",
.func = test__rd_pinned,
},
+ {
+ .desc = "User 64-bit counter access",
+ .func = test__rd_64bit,
+ },
+ {
+ .desc = "User 32-bit counter access",
+ .func = test__rd_32bit,
+ },
{
.func = NULL,
},
diff --git a/tools/perf/arch/arm64/tests/user-events.c
b/tools/perf/arch/arm64/tests/user-events.c
index c8efc6b369e6..546323b5242c 100644
--- a/tools/perf/arch/arm64/tests/user-events.c
+++ b/tools/perf/arch/arm64/tests/user-events.c
@@ -175,3 +175,41 @@ int test__rd_pinned(struct test __maybe_unused *test,
perf_evsel__delete(evsel);
return ret;
}
+
+static int test__rd_counter_size(struct test __maybe_unused *test,
+int config1)
+{
+ int ret;
+ struct perf_evsel *evsel;
+ struct perf_event_attr attr = {
+ .type = PERF_TYPE_HARDWARE,
+ .config = PERF_COUNT_HW_INSTRUCTIONS,
+ .config1 = config1,
+ .exclude_kernel = 1,
+ };
+
+ if (!pmu_is_homogeneous())
+ return TEST_SKIP;
+
+ evsel = perf_init();
+ if (!evsel)
+ return -1;
+
+ ret = run_test(evsel);
+
+ perf_evsel__close(evsel);
+ perf_evsel__delete(evsel);
+ return ret;
+}
+
+int test__rd_64bit(struct test __maybe_unused *test,
+ int __maybe_unused subtest)
+{
+ return test__rd_counter_size(test, 0x3);
+}
+
+int test__rd_32bit(struct test __maybe_unused *test,
+ int __maybe_unused subtest)
+{
+ return test__rd_counter_size(test, 0x2);
+}
--
2.27.0
[PATCH v7 6/9] libperf: Add arm64 support to perf_mmap__read_self()
Add the arm64 variants for read_perf_counter() and read_timestamp().
Unfortunately the counter number is encoded into the instruction, so the
code is a bit verbose to enumerate all possible counters.
Signed-off-by: Rob Herring
---
v7:
- Move enabling of libperf user read test for arm64 to this patch
---
tools/lib/perf/mmap.c | 98 +++
tools/lib/perf/tests/test-evsel.c | 2 +-
2 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/tools/lib/perf/mmap.c b/tools/lib/perf/mmap.c
index 915469f00cf4..216e6c6212a2 100644
--- a/tools/lib/perf/mmap.c
+++ b/tools/lib/perf/mmap.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "internal.h"
void perf_mmap__init(struct perf_mmap *map, struct perf_mmap *prev,
@@ -294,6 +295,103 @@ static u64 read_timestamp(void)
return low | ((u64)high) << 32;
}
+#elif defined(__aarch64__)
+#define read_sysreg(r) ({ \
+ u64 __val; \
+ asm volatile("mrs %0, " __stringify(r) : "=r" (__val)); \
+ __val; \
+})
+
+static u64 read_pmccntr(void)
+{
+ return read_sysreg(pmccntr_el0);
+}
+
+#define PMEVCNTR_READ(idx) \
+ static u64 read_pmevcntr_##idx(void) { \
+ return read_sysreg(pmevcntr##idx##_el0);\
+ }
+
+PMEVCNTR_READ(0);
+PMEVCNTR_READ(1);
+PMEVCNTR_READ(2);
+PMEVCNTR_READ(3);
+PMEVCNTR_READ(4);
+PMEVCNTR_READ(5);
+PMEVCNTR_READ(6);
+PMEVCNTR_READ(7);
+PMEVCNTR_READ(8);
+PMEVCNTR_READ(9);
+PMEVCNTR_READ(10);
+PMEVCNTR_READ(11);
+PMEVCNTR_READ(12);
+PMEVCNTR_READ(13);
+PMEVCNTR_READ(14);
+PMEVCNTR_READ(15);
+PMEVCNTR_READ(16);
+PMEVCNTR_READ(17);
+PMEVCNTR_READ(18);
+PMEVCNTR_READ(19);
+PMEVCNTR_READ(20);
+PMEVCNTR_READ(21);
+PMEVCNTR_READ(22);
+PMEVCNTR_READ(23);
+PMEVCNTR_READ(24);
+PMEVCNTR_READ(25);
+PMEVCNTR_READ(26);
+PMEVCNTR_READ(27);
+PMEVCNTR_READ(28);
+PMEVCNTR_READ(29);
+PMEVCNTR_READ(30);
+
+/*
+ * Read a value direct from PMEVCNTR
+ */
+static u64 read_perf_counter(unsigned int counter)
+{
+ static u64 (* const read_f[])(void) = {
+ read_pmevcntr_0,
+ read_pmevcntr_1,
+ read_pmevcntr_2,
+ read_pmevcntr_3,
+ read_pmevcntr_4,
+ read_pmevcntr_5,
+ read_pmevcntr_6,
+ read_pmevcntr_7,
+ read_pmevcntr_8,
+ read_pmevcntr_9,
+ read_pmevcntr_10,
+ read_pmevcntr_11,
+ read_pmevcntr_13,
+ read_pmevcntr_12,
+ read_pmevcntr_14,
+ read_pmevcntr_15,
+ read_pmevcntr_16,
+ read_pmevcntr_17,
+ read_pmevcntr_18,
+ read_pmevcntr_19,
+ read_pmevcntr_20,
+ read_pmevcntr_21,
+ read_pmevcntr_22,
+ read_pmevcntr_23,
+ read_pmevcntr_24,
+ read_pmevcntr_25,
+ read_pmevcntr_26,
+ read_pmevcntr_27,
+ read_pmevcntr_28,
+ read_pmevcntr_29,
+ read_pmevcntr_30,
+ read_pmccntr
+ };
+
+ if (counter < ARRAY_SIZE(read_f))
+ return (read_f[counter])();
+
+ return 0;
+}
+
+static u64 read_timestamp(void) { return read_sysreg(cntvct_el0); }
+
#else
static u64 read_perf_counter(unsigned int counter) { return 0; }
static u64 read_timestamp(void) { return 0; }
diff --git a/tools/lib/perf/tests/test-evsel.c
b/tools/lib/perf/tests/test-evsel.c
index 288b5feaefe2..670fcdb6d6af 100644
--- a/tools/lib/perf/tests/test-evsel.c
+++ b/tools/lib/perf/tests/test-evsel.c
@@ -148,7 +148,7 @@ static int test_stat_user_read(int event)
pc = perf_evsel__mmap_base(evsel, 0, 0);
-#if defined(__i386__) || defined(__x86_64__)
+#if defined(__i386__) || defined(__x86_64__) || __defined(__aarch64__)
__T("userspace counter access not supported", pc->cap_user_rdpmc);
__T("userspace counter access not enabled", pc->index);
__T("userspace counter width not set", pc->pmc_width >= 32);
--
2.27.0
[PATCH v7 5/9] arm64: perf: Add userspace counter access disable switch
Like x86, some users may want to disable userspace PMU counter
altogether. Add a sysfs 'rdpmc' file to control userspace counter
access. The default is '1' which is enabled. Writing '0' disables
access.
In the case of multiple PMUs (i.e. big.LITTLE), the control is per PMU
and userspace must disable access on each PMU.
Note that x86 also supports writing '2' to globally enable user access.
As there's not existing userspace support to worry about, this shouldn't
be necessary for Arm. It could be added later if the need arises.
Signed-off-by: Rob Herring
---
arch/arm64/kernel/perf_event.c | 61 --
include/linux/perf/arm_pmu.h | 4 ++-
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index bfbb7f449aca..1ab6308ca89c 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -336,6 +336,54 @@ static const struct attribute_group
armv8_pmuv3_caps_attr_group = {
.attrs = armv8_pmuv3_caps_attrs,
};
+static void armv8pmu_disable_user_access(void *mm);
+
+static ssize_t get_attr_rdpmc(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct pmu *pmu = dev_get_drvdata(dev);
+ struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
+
+ return snprintf(buf, 40, "%d\n", cpu_pmu->attr_rdpmc);
+}
+
+static ssize_t set_attr_rdpmc(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pmu *pmu = dev_get_drvdata(dev);
+ struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
+ unsigned long val;
+ ssize_t ret;
+
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
+
+ if (val > 1)
+ return -EINVAL;
+
+ if (val != cpu_pmu->attr_rdpmc) {
+ cpu_pmu->attr_rdpmc = !!val;
+ if (!val)
+ on_each_cpu_mask(_pmu->supported_cpus,
armv8pmu_disable_user_access, NULL, 1);
+ }
+
+ return count;
+}
+
+static DEVICE_ATTR(rdpmc, S_IRUSR | S_IWUSR, get_attr_rdpmc, set_attr_rdpmc);
+
+static struct attribute *armv8_pmuv3_rdpmc_attrs[] = {
+ _attr_rdpmc.attr,
+ NULL,
+};
+
+static const struct attribute_group armv8_pmuv3_rdpmc_attr_group = {
+ .attrs = armv8_pmuv3_rdpmc_attrs,
+};
+
/*
* Perf Events' indices
*/
@@ -950,7 +998,8 @@ static void armv8pmu_sched_task(struct perf_event_context
*ctx, bool sched_in)
* If a new task has user access enabled, clear the dirty counters
* to prevent the potential leak.
*/
- if (ctx && current->mm &&
atomic_read(>mm->context.pmu_direct_access)) {
+ if (ctx && to_arm_pmu(ctx->pmu)->attr_rdpmc &&
+ current->mm &&
atomic_read(>mm->context.pmu_direct_access)) {
armv8pmu_enable_user_access();
armv8pmu_clear_dirty_counters(to_arm_pmu(ctx->pmu));
} else {
@@ -1093,7 +1142,8 @@ static int __armv8_pmuv3_map_event(struct perf_event
*event,
_pmuv3_perf_cache_map,
ARMV8_PMU_EVTYPE_EVENT);
- if (armv8pmu_event_want_user_access(event) ||
!armv8pmu_event_is_64bit(event))
+ if (armpmu->attr_rdpmc &&
+ (armv8pmu_event_want_user_access(event) ||
!armv8pmu_event_is_64bit(event)))
event->hw.flags |= ARMPMU_EL0_RD_CNTR;
/*
@@ -1218,7 +1268,9 @@ static int armv8pmu_probe_pmu(struct arm_pmu *cpu_pmu)
static int armv8pmu_undef_handler(struct pt_regs *regs, u32 insn)
{
- if (atomic_read(>mm->context.pmu_direct_access)) {
+ struct arm_pmu *armpmu = *this_cpu_ptr(_armpmu);
+
+ if (armpmu->attr_rdpmc &&
atomic_read(>mm->context.pmu_direct_access)) {
armv8pmu_enable_user_access();
return 0;
}
@@ -1277,6 +1329,9 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char
*name,
cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_CAPS] = caps ?
caps : _pmuv3_caps_attr_group;
+ cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_RDPMC] =
_pmuv3_rdpmc_attr_group;
+ cpu_pmu->attr_rdpmc = true;
+
return 0;
}
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 1daad3b2cce5..9303cd07ac57 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -82,6 +82,7 @@ enum armpmu_attr_groups {
ARMPMU_ATTR_GROUP_EVENTS,
ARMPMU_ATTR_GROUP_FORMATS,
ARMPMU_ATTR_GROUP_CAPS,
+ ARMPMU_ATTR_GROUP_RDPMC,
ARMPMU_NR_ATTR_GROUPS
};
@@ -107,7 +108,8 @@ struct arm_pmu {
int (*map_event)(stru
[PATCH v7 3/9] arm64: perf: Enable PMU counter direct access for perf event
From: Raphael Gault
Keep track of event opened with direct access to the hardware counters
and modify permissions while they are open.
The strategy used here is the same which x86 uses: every time an event
is mapped, the permissions are set if required. The atomic field added
in the mm_context helps keep track of the different event opened and
de-activate the permissions when all are unmapped.
We also need to update the permissions in the context switch code so
that tasks keep the right permissions.
In order to enable 64-bit counters for userspace when available, a new
config1 bit is added for userspace to indicate it wants userspace counter
access. This bit allows the kernel to decide if chaining should be
disabled and chaining and userspace access are incompatible.
The modes for config1 are as follows:
config1 = 0 or 2 : user access enabled and always 32-bit
config1 = 1 : user access disabled and always 64-bit (using chaining if needed)
config1 = 3 : user access enabled and counter size matches underlying counter.
User access is enabled with config1 == 0 so that we match x86 behavior
and don't need Arm specific code (outside the counter read).
Signed-off-by: Raphael Gault
Signed-off-by: Rob Herring
---
Peter Z says (event->oncpu == smp_processor_id()) in the user page
update is always true, but my testing says otherwise[1].
v7:
- Clear disabled counters when user access is enabled for a task to
avoid leaking other tasks counter data.
- Rework context switch handling utilizing sched_task callback
- Add armv8pmu_event_can_chain() helper
- Rework config1 flags handling structure
- Use ARMV8_IDX_CYCLE_COUNTER_USER define for remapped user cycle
counter index
v6:
- Add new attr.config1 rdpmc bit for userspace to hint it wants
userspace access when also requesting 64-bit counters.
v5:
- Only set cap_user_rdpmc if event is on current cpu
- Limit enabling/disabling access to CPUs associated with the PMU
(supported_cpus) and with the mm_struct matching current->active_mm.
v2:
- Move mapped/unmapped into arm64 code. Fixes arm32.
- Rebase on cap_user_time_short changes
Changes from Raphael's v4:
- Drop homogeneous check
- Disable access for chained counters
- Set pmc_width in user page
[1]
https://lore.kernel.org/lkml/cal_jsqk+ekef5navnbfarcjre3myhfbfe54f9yhkbstnwql...@mail.gmail.com/
---
arch/arm64/include/asm/mmu.h | 5 +
arch/arm64/kernel/perf_event.c | 179 +++--
include/linux/perf/arm_pmu.h | 6 ++
3 files changed, 183 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 75beffe2ee8a..ee08447455da 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -18,6 +18,11 @@
typedef struct {
atomic64_t id;
+ /*
+* non-zero if userspace have access to hardware
+* counters directly.
+*/
+ atomic_tpmu_direct_access;
#ifdef CONFIG_COMPAT
void*sigpage;
#endif
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 40cf59455ce8..bfbb7f449aca 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -8,9 +8,11 @@
* This code is based heavily on the ARMv7 perf event code.
*/
+#include
#include
#include
#include
+#include
#include
#include
@@ -288,15 +290,22 @@ static const struct attribute_group
armv8_pmuv3_events_attr_group = {
PMU_FORMAT_ATTR(event, "config:0-15");
PMU_FORMAT_ATTR(long, "config1:0");
+PMU_FORMAT_ATTR(rdpmc, "config1:1");
static inline bool armv8pmu_event_is_64bit(struct perf_event *event)
{
return event->attr.config1 & 0x1;
}
+static inline bool armv8pmu_event_want_user_access(struct perf_event *event)
+{
+ return event->attr.config1 & 0x2;
+}
+
static struct attribute *armv8_pmuv3_format_attrs[] = {
_attr_event.attr,
_attr_long.attr,
+ _attr_rdpmc.attr,
NULL,
};
@@ -344,6 +353,15 @@ static bool armv8pmu_has_long_event(struct arm_pmu
*cpu_pmu)
return (cpu_pmu->pmuver >= ID_AA64DFR0_PMUVER_8_5);
}
+static inline bool armv8pmu_event_can_chain(struct perf_event *event)
+{
+ struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
+
+ return !armv8pmu_event_want_user_access(event) &&
+ armv8pmu_event_is_64bit(event) &&
+ !armv8pmu_has_long_event(cpu_pmu);
+}
+
/*
* We must chain two programmable counters for 64 bit events,
* except when we have allocated the 64bit cycle counter (for CPU
@@ -353,11 +371,9 @@ static bool armv8pmu_has_long_event(struct arm_pmu
*cpu_pmu)
static inline bool armv8pmu_event_is_chained(struct perf_event *event)
{
int idx = event->hw.idx;
- struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
return !WARN_ON(idx < 0) &&
-
[PATCH v7 4/9] drivers/perf: arm_pmu: Export the per_cpu cpu_armpmu
The arm64 PMU driver needs to retrieve the struct arm_pmu pointer for
the current CPU. As the common code already maintains this with the
percpu cpu_armpmu, let's make it global.
Signed-off-by: Rob Herring
---
drivers/perf/arm_pmu.c | 2 +-
include/linux/perf/arm_pmu.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 2d10d84fb79c..6ac56280b9c7 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -99,7 +99,7 @@ static const struct pmu_irq_ops percpu_pmunmi_ops = {
.free_pmuirq = armpmu_free_percpu_pmunmi
};
-static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
+DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
static DEFINE_PER_CPU(int, cpu_irq);
static DEFINE_PER_CPU(const struct pmu_irq_ops *, cpu_irq_ops);
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 63af052e3909..1daad3b2cce5 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -127,6 +127,8 @@ struct arm_pmu {
#define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
+DECLARE_PER_CPU(struct arm_pmu *, cpu_armpmu);
+
u64 armpmu_event_update(struct perf_event *event);
int armpmu_event_set_period(struct perf_event *event);
--
2.27.0
[PATCH v7 2/9] arm64: pmu: Add function implementation to update event index in userpage
From: Raphael Gault
In order to be able to access the counter directly for userspace,
we need to provide the index of the counter using the userpage.
We thus need to override the event_idx function to retrieve and
convert the perf_event index to armv8 hardware index.
Since the arm_pmu driver can be used by any implementation, even
if not armv8, two components play a role into making sure the
behaviour is correct and consistent with the PMU capabilities:
* the ARMPMU_EL0_RD_CNTR flag which denotes the capability to access
counter from userspace.
* the event_idx call back, which is implemented and initialized by
the PMU implementation: if no callback is provided, the default
behaviour applies, returning 0 as index value.
Signed-off-by: Raphael Gault
Signed-off-by: Rob Herring
---
v7:
- Add define ARMV8_IDX_CYCLE_COUNTER_USER for userspace index
of cycle counter
---
arch/arm64/kernel/perf_event.c | 20 +++-
include/linux/perf/arm_pmu.h | 2 ++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 4658fcf88c2b..40cf59455ce8 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -332,7 +332,7 @@ static const struct attribute_group
armv8_pmuv3_caps_attr_group = {
*/
#defineARMV8_IDX_CYCLE_COUNTER 0
#defineARMV8_IDX_COUNTER0 1
-
+#defineARMV8_IDX_CYCLE_COUNTER_USER32
/*
* We unconditionally enable ARMv8.5-PMU long event counter support
@@ -871,6 +871,22 @@ static void armv8pmu_clear_event_idx(struct pmu_hw_events
*cpuc,
clear_bit(idx - 1, cpuc->used_mask);
}
+static int armv8pmu_access_event_idx(struct perf_event *event)
+{
+ if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
+ return 0;
+
+ /*
+* We remap the cycle counter index to 32 to
+* match the offset applied to the rest of
+* the counter indices.
+*/
+ if (event->hw.idx == ARMV8_IDX_CYCLE_COUNTER)
+ return ARMV8_IDX_CYCLE_COUNTER_USER;
+
+ return event->hw.idx;
+}
+
/*
* Add an event filter to a given event.
*/
@@ -1098,6 +1114,8 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char
*name,
cpu_pmu->set_event_filter = armv8pmu_set_event_filter;
cpu_pmu->filter_match = armv8pmu_filter_match;
+ cpu_pmu->pmu.event_idx = armv8pmu_access_event_idx;
+
cpu_pmu->name = name;
cpu_pmu->map_event = map_event;
cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_EVENTS] = events ?
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 505480217cf1..d29aa981d989 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -26,6 +26,8 @@
*/
/* Event uses a 64bit counter */
#define ARMPMU_EVT_64BIT 1
+/* Allow access to hardware counter from userspace */
+#define ARMPMU_EL0_RD_CNTR 2
#define HW_OP_UNSUPPORTED 0x
#define C(_x) PERF_COUNT_HW_CACHE_##_x
--
2.27.0
[PATCH v7 0/9] arm64 userspace counter access support
Hi all, Another version of arm64 userspace counter access support. I sent out the libperf bits separately and those are now applied (Thanks!), so this is just the arm64 bits. This originally resurrected Raphael's series[1] to enable userspace counter access on arm64. My previous versions are here[2][3][4][5][6][7]. A git branch is here[8]. Changes in v7: - Handling of dirty counter leakage and reworking of context switch and user access enabling. The .sched_task hook and undef instruction handler are now utilized. (Patch 3) - Add a userspace disable switch like x86. (Patch 5) Changes in v6: - Reworking of the handling of 64-bit counters and user access. There's a new config1 flag to request user access. This takes priority over the 64-bit flag and the user will get the maximum size the h/w supports without chaining. - The libperf evsel mmap struct is stored in its own xyarray - New tests for user 64-bit and 32-bit counters - Rebase to v5.12-rc2 Changes in v5: - Limit enabling/disabling access to CPUs associated with the PMU (supported_cpus) and with the mm_struct matching current->active_mm. The x86 method of using mm_cpumask doesn't work for arm64 as it is not updated. - Only set cap_user_rdpmc if event is on current cpu. See patch 2. - Create an mmap for every event in an evsel. This results in some changes to the libperf mmap API from the last version. - Rebase to v5.11-rc2 Changes in v4: - Dropped 'arm64: pmu: Add hook to handle pmu-related undefined instructions'. The onus is on userspace to pin itself to a homogeneous subset of CPUs and avoid any aborts on heterogeneous systems, so the hook is not needed. - Make perf_evsel__mmap() take pages rather than bytes for size - Fix building arm64 heterogeneous test. Changes in v3: - Dropped removing x86 rdpmc test until libperf tests can run via 'perf test' - Added verbose prints for tests - Split adding perf_evsel__mmap() to separate patch The following changes to the arm64 support have been made compared to Raphael's last version: The major change is support for heterogeneous systems with some restrictions. Specifically, userspace must pin itself to like CPUs, open a specific PMU by type, and use h/w specific events. The tests have been reworked to demonstrate this. Chained events are not supported. The problem with supporting chained events was there's no way to distinguish between a chained event and a native 64-bit counter. We could add some flag, but do self monitoring processes really need that? Native 64-bit counters are supported if the PMU h/w has support. As there's already an explicit ABI to request 64-bit counters, userspace can request 64-bit counters and if user access is not enabled, then it must retry with 32-bit counters. Prior versions broke the build on arm32 (surprisingly never caught by 0-day). As a result, event_mapped and event_unmapped implementations have been moved into the arm64 code. There was a bug in that pmc_width was not set in the user page. The tests now check for this. The documentation has been converted to rST. I've added sections on chained events and heterogeneous. The tests have been expanded to test the cycle counter access. Rob [1] https://lore.kernel.org/r/20190822144220.27860-1-raphael.ga...@arm.com/ [2] https://lore.kernel.org/r/20200707205333.624938-1-r...@kernel.org/ [3] https://lore.kernel.org/r/20200828205614.3391252-1-r...@kernel.org/ [4] https://lore.kernel.org/r/20200911215118.2887710-1-r...@kernel.org/ [5] https://lore.kernel.org/r/20201001140116.651970-1-r...@kernel.org/ [6] https://lore.kernel.org/r/20210114020605.3943992-1-r...@kernel.org/ [7] https://lore.kernel.org/r/20210311000837.3630499-1-r...@kernel.org/ [8] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git user-perf-event-v7 Raphael Gault (4): arm64: Restrict undef hook for cpufeature registers arm64: pmu: Add function implementation to update event index in userpage arm64: perf: Enable PMU counter direct access for perf event Documentation: arm64: Document PMU counters access from userspace Rob Herring (5): drivers/perf: arm_pmu: Export the per_cpu cpu_armpmu arm64: perf: Add userspace counter access disable switch libperf: Add arm64 support to perf_mmap__read_self() perf: arm64: Add test for userspace counter access on heterogeneous systems perf: arm64: Add tests for 32-bit and 64-bit counter size userspace access Documentation/arm64/perf.rst | 67 +- arch/arm64/include/asm/mmu.h | 5 + arch/arm64/kernel/cpufeature.c | 4 +- arch/arm64/kernel/perf_event.c | 254 - drivers/perf/arm_pmu.c | 2 +- include/linux/perf/arm_pmu.h | 14 +- tools/lib/perf/mmap.c | 98 tools/lib/perf/tests/test-evsel.c | 2 +- tools/perf/arch/arm64/include/arch-tests.h | 12 + tools/perf/arch/ar
[PATCH v7 1/9] arm64: Restrict undef hook for cpufeature registers
From: Raphael Gault
This commit modifies the mask of the mrs_hook declared in
arch/arm64/kernel/cpufeatures.c which emulates only feature register
access. This is necessary because this hook's mask was too large and
thus masking any mrs instruction, even if not related to the emulated
registers which made the pmu emulation inefficient.
Signed-off-by: Raphael Gault
Signed-off-by: Rob Herring
---
v7:
- Split off from Raphael's original undef hook patch as this change stands
on its own.
---
arch/arm64/kernel/cpufeature.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 066030717a4c..aa0777690ab1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2888,8 +2888,8 @@ static int emulate_mrs(struct pt_regs *regs, u32 insn)
}
static struct undef_hook mrs_hook = {
- .instr_mask = 0xfff0,
- .instr_val = 0xd530,
+ .instr_mask = 0x,
+ .instr_val = 0xd538,
.pstate_mask = PSR_AA32_MODE_MASK,
.pstate_val = PSR_MODE_EL0t,
.fn = emulate_mrs,
--
2.27.0
Re: [PATCH 1/1] of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses
On Mon, Apr 19, 2021 at 7:35 PM Leonardo Bras wrote: > > On Mon, 2021-04-19 at 10:44 -0500, Rob Herring wrote: > > On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras wrote: > > > > > > Hello Rob, thanks for this feedback! > > > > > > On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote: > > > > +PPC and PCI lists > > > > > > > > On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras > > > > wrote: > > > > > > > > > > Many other resource flag parsers already add this flag when the input > > > > > has bits 24 & 25 set, so update this one to do the same. > > > > > > > > Many others? Looks like sparc and powerpc to me. > > > > > > > > > > s390 also does that, but it look like it comes from a device-tree. > > > > I'm only looking at DT based platforms, and s390 doesn't use DT. > > Correct. > Sorry, I somehow write above the opposite of what I was thinking. > > > > > > > Those would be the > > > > ones I worry about breaking. Sparc doesn't use of/address.c so it's > > > > fine. Powerpc version of the flags code was only fixed in 2019, so I > > > > don't think powerpc will care either. > > > > > > In powerpc I reach this function with this stack, while configuring a > > > virtio-net device for a qemu/KVM pseries guest: > > > > > > pci_process_bridge_OF_ranges+0xac/0x2d4 > > > pSeries_discover_phbs+0xc4/0x158 > > > discover_phbs+0x40/0x60 > > > do_one_initcall+0x60/0x2d0 > > > kernel_init_freeable+0x308/0x3a8 > > > kernel_init+0x2c/0x168 > > > ret_from_kernel_thread+0x5c/0x70 > > > > > > For this, both MMIO32 and MMIO64 resources will have flags 0x200. > > > > Oh good, powerpc has 2 possible flags parsing functions. So in the > > above path, do we need to set PCI_BASE_ADDRESS_MEM_TYPE_64? > > > > Does pci_parse_of_flags() get called in your case? > > > > It's called in some cases, but not for the device I am debugging > (virtio-net pci@8002000). > > For the above device, here is an expanded stack trace: > > of_bus_pci_get_flags() (from parser->bus->get_flags()) > of_pci_range_parser_one() (from macro for_each_of_pci_range) > pci_process_bridge_OF_ranges+0xac/0x2d4 > pSeries_discover_phbs+0xc4/0x158 > discover_phbs+0x40/0x60 > do_one_initcall+0x60/0x2d0 > kernel_init_freeable+0x308/0x3a8 > kernel_init+0x2c/0x168 > ret_from_kernel_thread+0x5c/0x70 > > For other devices, I could also see the following stack trace: > ## device ethernet@8 > > pci_parse_of_flags() > of_create_pci_dev+0x7f0/0xa40 > __of_scan_bus+0x248/0x320 > pcibios_scan_phb+0x370/0x3b0 > pcibios_init+0x8c/0x12c > do_one_initcall+0x60/0x2d0 > kernel_init_freeable+0x308/0x3a8 > kernel_init+0x2c/0x168 > ret_from_kernel_thread+0x5c/0x70 > > Devices that get parsed with of_bus_pci_get_flags() appears first at > dmesg (around 0.015s in my test), while devices that get parsed by > pci_parse_of_flags() appears later (0.025s in my test). > > I am not really used to this code, but having the term "discover phbs" > in the first trace and the term "scan phb" in the second, makes me > wonder if the first trace is seen on devices that are seen/described in > the device-tree and the second trace is seen in devices not present in > the device-tree and found scanning pci bus. That was my guess as well. I think on pSeries that most PCI devices are in the DT whereas on Arm and other flattened DT (non OpenFirmware) platforms PCI devices are not in DT. Of course, for virtio devices, they would not be in DT in either case. > > > > I noticed both sparc and powerpc set PCI_BASE_ADDRESS_MEM_TYPE_64 in > > > > the flags. AFAICT, that's not set anywhere outside of arch code. So > > > > never for riscv, arm and arm64 at least. That leads me to > > > > pci_std_update_resource() which is where the PCI code sets BARs and > > > > just copies the flags in PCI_BASE_ADDRESS_MEM_MASK ignoring > > > > IORESOURCE_* flags. So it seems like 64-bit is still not handled and > > > > neither is prefetch. > > > > > > > > > > I am not sure if you mean here: > > > a) it's ok to add IORESOURCE_MEM_64 here, because it does not affect > > > anything else, or > > > b) it should be using PCI_BASE_ADDRESS_MEM_TYPE_64 > > > (or IORESOURCE_MEM_64 | PCI_BASE_ADDRESS_MEM_TYPE_64) instead, since > > > it's how it's added in powerpc/sparc, and else there is no point. > > >
Re: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access for perf event
On Mon, Apr 19, 2021 at 11:14 AM Will Deacon wrote: > > On Thu, Apr 08, 2021 at 01:38:17PM -0500, Rob Herring wrote: > > On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland wrote: > > > On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote: > > > > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote: > > > > > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon wrote: > > > > I guess I'm just worried about exposing the counters to userspace after > > > > the PMU driver (or perf core?) thinks that they're no longer exposed in > > > > case we leak other events. > > > > > > IMO that's not practically different from the single-PMU case (i.e. > > > multi-PMU isn't material, either we have a concern with leaking or we > > > don't); more on that below. > > Well, maybe. It looks the single-PMU case is exposed to the same issue, > but I think a solution needs to take into account the multi-PMU situation. > > > > While it looks odd to place this on the mm, I don't think it's the end > > > of the world. > > > > > > > However, I'm not sure how this is supposed to work normally: what > > > > happens if e.g. a privileged user has a per-cpu counter for a kernel > > > > event while a task has a counter with direct access -- can that task > > > > read the kernel event out of the PMU registers from userspace? > > > > > > Yes -- userspace could go read any counters even though it isn't > > > supposed to, and could potentially infer information from those. It > > > won't have access to the config registers or kernel data structures, so > > > it isn't guaranteed to know what the even is or when it is > > > context-switched/reprogrammed/etc. > > > > > > If we believe that's a problem, then it's difficult to do anything > > > robust other than denying userspace access entirely, since disabling > > > userspace access while in use would surprise applications, and denying > > > privileged events would need some global state that we consult at event > > > creation time (in addition to being an inversion of privilege). > > > > > > IIRC there was some fuss about this a while back on x86; I'll go dig and > > > see what I can find, unless Peter has a memory... > > > > Maybe this one[1]. > > > > Rob > > > > [1] > > https://lore.kernel.org/lkml/20200730123815.18518-1-kan.li...@linux.intel.com/ > > Going through the archives and talking to Peter, it looks like this is still > an active area of concern: > > - There are patches to clear "dirty" counters on context-switch. They were > queued for 5.13 but broke -tip on Friday: > > > https://lore.kernel.org/lkml/yhm%2fm4za2lpry...@hirez.programming.kicks-ass.net/ Yes, nice timing. I've reworked the arm64 support to do the same things (minus the breakage). And it looks like we can simplify things a bit by moving all the context switch handling into .sched_task() and out of switch_mm. Unless there's some case where that wouldn't work that I'm not aware of (entirely likely). > - Per-cpu events cannot be protected in software: > > > https://lore.kernel.org/lkml/calcetrvvpzud_hq8xoomhn_wwrqjuvroect2do4_d4rozoa...@mail.gmail.com/ > > so without hardware support, we need a way to disable user access for > people that care about this leakage > > x86 has an "rdpmc" file exposed for the PMU device in sysfs which allows > access to be disabled. I don't think these patches add such a thing, and > that's where the fun with multi-PMU machines would come into play. The fun is because sysfs will end up with multiple 'rdpmc' files or something else? Rob
Re: [PATCH 1/1] of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses
On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras wrote: > > Hello Rob, thanks for this feedback! > > On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote: > > +PPC and PCI lists > > > > On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras wrote: > > > > > > Many other resource flag parsers already add this flag when the input > > > has bits 24 & 25 set, so update this one to do the same. > > > > Many others? Looks like sparc and powerpc to me. > > > > s390 also does that, but it look like it comes from a device-tree. I'm only looking at DT based platforms, and s390 doesn't use DT. > > Those would be the > > ones I worry about breaking. Sparc doesn't use of/address.c so it's > > fine. Powerpc version of the flags code was only fixed in 2019, so I > > don't think powerpc will care either. > > In powerpc I reach this function with this stack, while configuring a > virtio-net device for a qemu/KVM pseries guest: > > pci_process_bridge_OF_ranges+0xac/0x2d4 > pSeries_discover_phbs+0xc4/0x158 > discover_phbs+0x40/0x60 > do_one_initcall+0x60/0x2d0 > kernel_init_freeable+0x308/0x3a8 > kernel_init+0x2c/0x168 > ret_from_kernel_thread+0x5c/0x70 > > For this, both MMIO32 and MMIO64 resources will have flags 0x200. Oh good, powerpc has 2 possible flags parsing functions. So in the above path, do we need to set PCI_BASE_ADDRESS_MEM_TYPE_64? Does pci_parse_of_flags() get called in your case? > > I noticed both sparc and powerpc set PCI_BASE_ADDRESS_MEM_TYPE_64 in > > the flags. AFAICT, that's not set anywhere outside of arch code. So > > never for riscv, arm and arm64 at least. That leads me to > > pci_std_update_resource() which is where the PCI code sets BARs and > > just copies the flags in PCI_BASE_ADDRESS_MEM_MASK ignoring > > IORESOURCE_* flags. So it seems like 64-bit is still not handled and > > neither is prefetch. > > > > I am not sure if you mean here: > a) it's ok to add IORESOURCE_MEM_64 here, because it does not affect > anything else, or > b) it should be using PCI_BASE_ADDRESS_MEM_TYPE_64 > (or IORESOURCE_MEM_64 | PCI_BASE_ADDRESS_MEM_TYPE_64) instead, since > it's how it's added in powerpc/sparc, and else there is no point. I'm wondering if a) is incomplete and PCI_BASE_ADDRESS_MEM_TYPE_64 also needs to be set. The question is ultimately are BARs getting set correctly for 64-bit? It looks to me like they aren't. Rob
Re: [PATCH v5 1/5] dt-bindings: mfd: Initial commit of silergy,sy7636a.yaml
On Mon, 19 Apr 2021 07:02:18 +1000, Alistair Francis wrote:
> Initial support for the Silergy SY7636A Power Management chip
> and regulator.
>
> Signed-off-by: Alistair Francis
> ---
> v5:
> - Improve the documentation
>
> .../bindings/mfd/silergy,sy7636a.yaml | 70 +++
> 1 file changed, 70 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml:
properties:regulators:properties:$ref: '/schemas/regulator/regulator.yaml#' is
not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml:
properties:regulators:properties: {'enum': ['$ref', 'additionalItems',
'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default',
'dependencies', 'deprecated', 'description', 'else', 'enum', 'if', 'items',
'maxItems', 'maximum', 'minItems', 'minimum', 'multipleOf', 'not', 'oneOf',
'pattern', 'patternProperties', 'properties', 'propertyNames', 'required',
'then', 'unevaluatedProperties']} is not allowed for '$ref'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml:
properties:regulators:properties: {'enum': ['$ref', 'additionalItems',
'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default',
'dependencies', 'deprecated', 'description', 'else', 'enum', 'if', 'items',
'maxItems', 'maximum', 'minItems', 'minimum', 'multipleOf', 'not', 'oneOf',
'pattern', 'patternProperties', 'properties', 'propertyNames', 'required',
'then', 'unevaluatedProperties']} is not allowed for 'additionalProperties'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml:
ignoring, error in schema: properties: regulators: properties: $ref
warning: no schema found in file:
./Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml
Documentation/devicetree/bindings/mfd/silergy,sy7636a.example.dt.yaml:0:0:
/example-0/i2c/pmic@62: failed to match any schema with compatible:
['silergy,sy7636a']
Documentation/devicetree/bindings/mfd/silergy,sy7636a.example.dt.yaml:0:0:
/example-0/i2c/pmic@62/regulators: failed to match any schema with compatible:
['silergy,sy7636a-regulator']
See https://patchwork.ozlabs.org/patch/1467830
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
Re: [PATCH V3] dt-bindings: mailbox: ti, secure-proxy: Convert to json schema
On Thu, 15 Apr 2021 19:59:53 -0500, Nishanth Menon wrote: > Convert the ti,secure-proxy to yaml for better checks and documentation. > Differences being mostly in the examples: > - Dropped the example usage of mailbox client, it is better done in > tisci node definition. > - Switched reg usage for address-cells and size-cells 1 - aligned with > schema checks as well. > - included header in example for a buildable example. > > While at this, lets make sure to support upto 100 rx threads even though > typically upto 1 threads is practically in use. > > NOTE: The following checkpatch warning is generated since we do include the > header > in the example, but this is a false positive warning. > WARNING: DT binding docs and includes should be a separate patch. See: > Documentation/devicetree/bindings/submitting-patches.rst > > Signed-off-by: Nishanth Menon > --- > > Changes since v2: > - Subject line rewording to indicate json schema rather than yaml > - Review comment: Dropped "-" in interrupt-names pattern so that it will > match all >entries > - Minor commit message formatting changes > > V2: https://lore.kernel.org/linux-arm-kernel/20210413224535.30910-1...@ti.com/ > V1: https://lore.kernel.org/linux-arm-kernel/20210413171230.5872-1...@ti.com/ > > .../bindings/mailbox/ti,secure-proxy.txt | 50 > .../bindings/mailbox/ti,secure-proxy.yaml | 79 +++ > 2 files changed, 79 insertions(+), 50 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt > create mode 100644 > Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml > Reviewed-by: Rob Herring
