* Re: [PATCH v5] MAINTAINERS: Add Axiado reviewer and Maintainers
From: Krzysztof Kozlowski @ 2026-03-27 6:54 UTC (permalink / raw)
To: Karthikeyan Mitran, Arnd Bergmann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Prasad Bolisetty, Tzu-Hao Wei,
Axiado Reviewers
Cc: devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni,
Drew Fustini, Linus Walleij, Harshit Shah
In-Reply-To: <20260326-maintainers-addition-and-axiado-ax3000_dtsi-update-v5-1-648dfe9bff29@axiado.com>
On 26/03/2026 21:50, Karthikeyan Mitran wrote:
> From: Prasad Bolisetty <pbolisetty@axiado.com>
>
> Adding 3 new maintainers Prasad,Tzu-Hao, and Karthikeyan
> and adding a group reviewer entry for review coverage,
> Removed previous maintainer as the previous maintainer moved from project
...
> ---
> MAINTAINERS | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 55af015174a5..49f47e8c2ec3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2605,7 +2605,10 @@ F: arch/arm/mach-aspeed/
> N: aspeed
>
> ARM/AXIADO ARCHITECTURE
> -M: Harshit Shah <hshah@axiado.com>
> +M: Prasad Bolisetty <pbolisetty@axiado.com>
> +M: Tzu-Hao Wei <twei@axiado.com>
> +M: Karthikeyan Mitran <kmitran@axiado.com>
> +R: Axiado Reviewers <linux-maintainer@axiado.com>
How many entries do you need? You already have three, so who is in
Axiado reviewers? And what is "review coverage" you mentioned in the
commit msg.
I skimmed through https://lore.kernel.org/all/?q=f%3Aaxiado.com and I do
not see reviews from any of these addresses, so it all looks like you
add some corporate structure, because some managers want to see what is
posted.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: anacapa: Enable MCTP and FRU for NIC
From: Andy Chung via B4 Relay @ 2026-03-27 6:59 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Andy Chung, Andy Chung
From: Andy Chung <Andy.Chung@amd.com>
Add the mctp-controller property to enable frontend NIC management
via PLDM over MCTP.
Also add EEPROM device for NIC FRU.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
---
Add the mctp-controller property to enable frontend NIC management
via PLDM over MCTP.
Also add EEPROM device for NIC FRU.
---
.../dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 67 +++++++++++++++++++++-
1 file changed, 65 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 221af858cb6b..138b081be049 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -584,38 +584,67 @@ eeprom@56 {
// R Bridge Board
&i2c10 {
status = "okay";
+ multi-master;
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
- i2c-mux-idle-disconnect;
i2c10mux0ch0: i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
};
i2c10mux0ch1: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch2: i2c@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch3: i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch4: i2c@4 {
reg = <4>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c10mux0ch5: i2c@5 {
reg = <5>;
@@ -661,38 +690,72 @@ i2c10mux0ch7: i2c@7 {
// L Bridge Board
&i2c11 {
status = "okay";
+ multi-master;
+ mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
i2c-mux@71 {
compatible = "nxp,pca9548";
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
- i2c-mux-idle-disconnect;
i2c11mux0ch0: i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // FE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch1: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch2: i2c@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch3: i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch4: i2c@4 {
reg = <4>;
#address-cells = <1>;
#size-cells = <0>;
+ mctp-controller;
+ // BE NIC FRU
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
};
i2c11mux0ch5: i2c@5 {
reg = <5>;
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260327-dts_enable_nic_mctp-e35a5765b176
Best regards,
--
Andy Chung <Andy.Chung@amd.com>
^ permalink raw reply related
* [PATCH v11] arm64: dts: imx8ulp: Add CSI and ISI Nodes
From: guoniu.zhou @ 2026-03-27 7:11 UTC (permalink / raw)
To: Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel, Frank Li
Cc: linux-media, devicetree, imx, linux-arm-kernel, linux-kernel,
G . N . Zhou
From: Guoniu Zhou <guoniu.zhou@nxp.com>
The CSI-2 in the i.MX8ULP is almost identical to the version present
in the i.MX8QXP/QM and is routed to the ISI. Add both the ISI and CSI
nodes and mark them as disabled by default since capture is dependent
on an attached camera.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
---
This was previously sent as patch 5/5 in the v10 series based on media
tree [1]. Patches 1-4 have already been applied to linux-next tree, but
not yet to media tree . This v11 addresses the conflict with the removal
of include/dt-bindings/reset/imx8ulp-pcc-reset.h.
Changes in v11:
- Rebased on latest media/next
- Removed #include <dt-bindings/reset/imx8ulp-pcc-reset.h> which was
deleted by Rob's dt-bindings cleanup series [2]
- Replaced reset macros with numeric values and added comments to
document the reset indices
- Link to v10: https://lore.kernel.org/r/20251205-csi2_imx8ulp-v10-5-190cdadb20a3@nxp.com
Changes in v6:
- Update compatible string in dts for csi node.
- Link to v5: https://lore.kernel.org/r/20250901-csi2_imx8ulp-v5-4-67964d1471f3@nxp.com
Changes in v4:
- Change csr clock name to pclk which is more readability.
- Link to v3: https://lore.kernel.org/all/20250825-csi2_imx8ulp-v3-4-35885aba62bc@nxp.com
Changes in v3:
- Change pclk clock name to csr to match IP port name.
- Link to v2: https://lore.kernel.org/all/20250822-csi2_imx8ulp-v2-4-26a444394965@nxp.com
Changes in v2:
- Move dts patch as the last one.
- Add "fsl,imx8qxp-mipi-csi2" to compatible string list of csi node.
- Link to v1: https://lore.kernel.org/all/20250812081923.1019345-3-guoniu.zhou@oss.nxp.com
[1] https://lore.kernel.org/all/20251205-csi2_imx8ulp-v10-0-190cdadb20a3@nxp.com/
[2] https://lore.kernel.org/all/20251212231203.727227-1-robh@kernel.org/
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 66 ++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 9b5d98766512..84f05c83c702 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -859,6 +859,72 @@ spdif: spdif@2dab0000 {
dma-names = "rx", "tx";
status = "disabled";
};
+
+ isi: isi@2dac0000 {
+ compatible = "fsl,imx8ulp-isi";
+ reg = <0x2dac0000 0x10000>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc5 IMX8ULP_CLK_ISI>,
+ <&cgc2 IMX8ULP_CLK_LPAV_AXI_DIV>;
+ clock-names = "axi", "apb";
+ power-domains = <&scmi_devpd IMX8ULP_PD_ISI>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ isi_in: endpoint {
+ remote-endpoint = <&mipi_csi_out>;
+ };
+ };
+ };
+ };
+
+ mipi_csi: csi@2daf0000 {
+ compatible = "fsl,imx8ulp-mipi-csi2";
+ reg = <0x2daf0000 0x10000>,
+ <0x2dad0000 0x10000>;
+ clocks = <&pcc5 IMX8ULP_CLK_CSI>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
+ <&pcc5 IMX8ULP_CLK_CSI_REGS>;
+ clock-names = "core", "esc", "ui", "pclk";
+ assigned-clocks = <&pcc5 IMX8ULP_CLK_CSI>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
+ <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
+ <&pcc5 IMX8ULP_CLK_CSI_REGS>;
+ assigned-clock-parents = <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV1>,
+ <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV2>,
+ <&cgc2 IMX8ULP_CLK_PLL4_PFD0_DIV1>;
+ assigned-clock-rates = <200000000>,
+ <80000000>,
+ <100000000>,
+ <79200000>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_MIPI_CSI>;
+ resets = <&pcc5 5>, /* PCC5_CSI_REGS_SWRST */
+ <&pcc5 6>; /* PCC5_CSI_SWRST> */
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_csi_out: endpoint {
+ remote-endpoint = <&isi_in>;
+ };
+ };
+ };
+ };
};
gpiod: gpio@2e200000 {
--
2.34.1
^ permalink raw reply related
* [GIT,PULL] hisilicon: driver updates for v7.1
From: Wei Xu @ 2026-03-27 7:16 UTC (permalink / raw)
To: soc, arm
Cc: linux-arm-kernel, Arnd Bergmann, xuwei5, zhangyi.ac,
Wuliebao (Joab, Turing Solution), Shenqingchun(DanielShen),
huangdaode, liguozhu, Zengtao (B), lihuisong (C),
Jonathan Cameron, shiju.jose, salil.mehta
Hi ARM SoC maintainers,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://github.com/hisilicon/linux-hisi.git tags/hisi-drivers-for-7.1
for you to fetch changes up to a8f5c98517c7c89947024f79e5854e6b09766b79:
soc: hisilicon: kunpeng_hccs: Remove unused input parameter (2026-03-21 03:55:35 +0000)
----------------------------------------------------------------
HiSilicon driver updates for v7.1
- Fix two compiler warnings on kunpeng_hccs driver
----------------------------------------------------------------
Huisong Li (2):
soc: hisilicon: kunpeng_hccs: Fix discard ‘const’ qualifier compiling warning
soc: hisilicon: kunpeng_hccs: Remove unused input parameter
drivers/soc/hisilicon/kunpeng_hccs.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] drm: Introduce DRM_MODE_DUMB_KERNEL_MAP flag
From: Thomas Zimmermann @ 2026-03-27 7:21 UTC (permalink / raw)
To: Chen-Yu Tsai, Maarten Lankhorst, Maxime Ripard, David Airlie,
Simona Vetter
Cc: Rob Herring, dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20260326100248.1171828-2-wenst@chromium.org>
Hi
Am 26.03.26 um 11:01 schrieb Chen-Yu Tsai:
> From: Rob Herring <robh@kernel.org>
>
> Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> drm_mode_create_dumb. This flag is for internal kernel use to indicate
> if dumb buffer allocation needs a kernel mapping. This is needed only for
> GEM DMA where creating a kernel mapping or not has to be decided at
> allocation time because creating a mapping on demand (with vmap()) is not
> guaranteed to work.
I still don't understand what you're trying to achieve. As I pointed
out, ever driver's memory manager potentially requires a vmap. Passing
around flags will not solve that problem. If vmap is not possible, the
driver should not provide the vmap callbacks in the first place.
Best regards
Thomas
>
> Several drivers are using reimplementing the GEM DMA helpers because
> they distinguish between kernel and userspace allocations to create a
> kernel mapping or not. Adding a flag allows migrating these drivers
> to the helpers while preserving their existing behavior. These include
> exynos, rockchip, and previously mediatek.
>
> Update the callers of drm_mode_dumb_create() to set
> drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
> be set to anything by userspace, but is unused within the kernel. Let's
> force flags to zero (no kernel mapping) for userspace callers by default.
> For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
> can override this as needed.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> [wenst@chromium.org: Emit warning (once) if args->flags is not zero]
> [wenst@chromium.org: Moved flag def. to include/drm/drm_dumb_buffers.h]
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v2:
> - Switched to drm_warn_once()
> - Moved flag definition from include/uapi/ to include/drm/drm_dumb_buffers.h
> - Reworded commit message
>
> Changes since v1:
> - Emit warning if args->flags is not zero
> ---
> drivers/gpu/drm/drm_client.c | 2 ++
> drivers/gpu/drm/drm_dumb_buffers.c | 4 ++++
> include/drm/drm_dumb_buffers.h | 3 +++
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 46c465bce98c..3d3e61823cc1 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -14,6 +14,7 @@
> #include <drm/drm_client_event.h>
> #include <drm/drm_device.h>
> #include <drm/drm_drv.h>
> +#include <drm/drm_dumb_buffers.h>
> #include <drm/drm_file.h>
> #include <drm/drm_fourcc.h>
> #include <drm/drm_framebuffer.h>
> @@ -404,6 +405,7 @@ drm_client_buffer_create_dumb(struct drm_client_dev *client, u32 width, u32 heig
> dumb_args.width = width;
> dumb_args.height = height;
> dumb_args.bpp = drm_format_info_bpp(info, 0);
> + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
> ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
> if (ret)
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
> index e2b62e5fb891..60f4c2d08641 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -233,6 +233,10 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> struct drm_mode_create_dumb *args = data;
> int err;
>
> + if (args->flags)
> + drm_warn_once(dev, "drm_mode_create_dumb.flags is not zero.\n");
> + args->flags = 0;
> +
> err = drm_mode_create_dumb(dev, args, file_priv);
> if (err) {
> args->handle = 0;
> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
> index 1f3a8236fb3d..4657e44533f4 100644
> --- a/include/drm/drm_dumb_buffers.h
> +++ b/include/drm/drm_dumb_buffers.h
> @@ -6,6 +6,9 @@
> struct drm_device;
> struct drm_mode_create_dumb;
>
> +/* drm_mode_create_dumb flags for internal use */
> +#define DRM_MODE_DUMB_KERNEL_MAP (1<<0)
> +
> int drm_mode_size_dumb(struct drm_device *dev,
> struct drm_mode_create_dumb *args,
> unsigned long hw_pitch_align,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-27 7:23 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <20260326092645.1053261-2-jian.hu@amlogic.com>
On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>
> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Best regards,
Krzysztof
^ permalink raw reply
* [GIT,PULL] arm64: dts: hisilicon: fixes for v7.0
From: Wei Xu @ 2026-03-27 7:23 UTC (permalink / raw)
To: soc, arm
Cc: linux-arm-kernel, Arnd Bergmann, xuwei5, zhangyi.ac,
Wuliebao (Joab, Turing Solution), Shenqingchun(DanielShen),
huangdaode, liguozhu, Zengtao (B), Jonathan Cameron, shiju.jose,
salil.mehta, Shawn Guo
Hi ARM SoC maintainers,
Please consider to pull the following changes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
https://github.com/hisilicon/linux-hisi.git tags/hisi-dts-fixes-for-7.0
for you to fetch changes up to 1af997cad473d505248df6d9577183bb91f69670:
arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges (2026-03-21 03:38:11 +0000)
----------------------------------------------------------------
HiSilicon dts fixes for v7.0
- Correct the PCIe reset GPIO polarity for hi3798cv200-poplar
- Add the missing dma-ranges for hi3798cv200
----------------------------------------------------------------
Shawn Guo (2):
arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity
arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges
arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts | 2 +-
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v3 3/3] drm/gem-dma: Support DRM_MODE_DUMB_KERNEL_MAP flag
From: Thomas Zimmermann @ 2026-03-27 7:29 UTC (permalink / raw)
To: Chen-Yu Tsai, Maarten Lankhorst, Maxime Ripard, David Airlie,
Simona Vetter
Cc: Rob Herring, dri-devel, linux-kernel, linux-arm-kernel,
Sasha Finkelstein, Janne Grunau, Liviu Dudau, Paul Kocialkowski,
Neil Armstrong, Laurent Pinchart, Tomi Valkeinen, Kieran Bingham,
Biju Das, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Jernej Skrabec, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance, Icenowy Zheng, Laurent Pinchart,
Tomi Valkeinen
In-Reply-To: <20260326100248.1171828-4-wenst@chromium.org>
Hi
Am 26.03.26 um 11:01 schrieb Chen-Yu Tsai:
> From: Rob Herring <robh@kernel.org>
>
> Add support in DMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_dma_dumb_create() always creates a kernel mapping as
> before. drm_gem_dma_dumb_create_internal() lets the caller set the flags
> as desired.
>
> drm_gem_dma_dumb_create_internal() users have DRM_MODE_DUMB_KERNEL_MAP
> added to preserve existing behavior.
>
> A dumb buffer allocated from these devices can be shared (exported) to
> another device. The consuming device may require the kernel mapping to
> scan out the buffer to its own display. Such devices include DisplayLink
> and various MIPI DBI based displays. Therefore altering the behavior
> should be given much consideration.
NAK on this whole thing. Please do not clutter the sources with these
flags and tests. If drivers cannot use the gem-cma helpers, they should
not do so. Maybe these drivers _are_ different. Then give them different
interfaces or even a different memory manager, if necessary.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> [wenst@chromium.org: Rebase onto renamed GEM DMA helpers]
> [wenst@chromium.org: show "vaddr=(no mapping)" in drm_gem_dma_print_info()]
> [wenst@chromium.org: Add DRM_MODE_DUMB_KERNEL_MAP to new drivers]
> [wenst@chromium.org: Add flags field to drm_gem_dma_create_with_handle()
> kerneldoc]
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v2:
> - Added back DRM_MODE_DUMB_KERNEL_MAP flag to all drivers calling
> drm_gem_dma_dumb_create_internal()
> - Expanded commit message to cover display drivers needing the kernel
> mapping to do scan out
>
> Changes since v1:
> - Rebased onto renamed GEM DMA helpers
> - Added check in drm_fb_dma_get_scanout_buffer() and drm_gem_dma_vmap().
> - Made drm_gem_dma_print_info() show "vaddr=(no mapping)" for objects
> allocated without kernel mapping
> - Dropped existing DRM_MODE_DUMB_KERNEL_MAP flag addition in various
> drivers
> - Added DRM_MODE_DUMB_KERNEL_MAP flag to adp_drm_gem_dumb_create()
> - Added flags field kerneldoc for drm_gem_dma_create_with_handle()
>
> Cc: Sasha Finkelstein <fnkl.kernel@gmail.com>
> Cc: Janne Grunau <j@jannau.net>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Paul Kocialkowski <paulk@sys-base.io>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> Cc: Biju Das <biju.das.jz@bp.renesas.com>
> Cc: Yannick Fertre <yannick.fertre@foss.st.com>
> Cc: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
> Cc: Philippe Cornu <philippe.cornu@foss.st.com>
> Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Cc: "Maíra Canal" <mcanal@igalia.com>
> Cc: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
> Cc: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
> drivers/gpu/drm/adp/adp_drv.c | 1 +
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 1 +
> drivers/gpu/drm/arm/malidp_drv.c | 1 +
> drivers/gpu/drm/drm_fb_dma_helper.c | 4 ++
> drivers/gpu/drm/drm_gem_dma_helper.c | 67 ++++++++++++-------
> drivers/gpu/drm/logicvc/logicvc_drm.c | 1 +
> drivers/gpu/drm/meson/meson_drv.c | 1 +
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 2 +
> drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 1 +
> drivers/gpu/drm/stm/drv.c | 3 +-
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> drivers/gpu/drm/vc4/vc4_drv.c | 2 +
> drivers/gpu/drm/verisilicon/vs_drm.c | 2 +
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +
> 14 files changed, 63 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/adp/adp_drv.c b/drivers/gpu/drm/adp/adp_drv.c
> index 4554cf75565e..c549b44b3814 100644
> --- a/drivers/gpu/drm/adp/adp_drv.c
> +++ b/drivers/gpu/drm/adp/adp_drv.c
> @@ -95,6 +95,7 @@ static int adp_drm_gem_dumb_create(struct drm_file *file_priv,
> {
> args->height = ALIGN(args->height, 64);
> args->size = args->pitch * args->height;
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
>
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> }
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 6ed504099188..2c096ebaea33 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -29,6 +29,7 @@ static int komeda_gem_dma_dumb_create(struct drm_file *file,
> struct komeda_dev *mdev = dev->dev_private;
> u32 pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = ALIGN(pitch, mdev->chip.bus_width);
>
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index b765f6c9eea4..5519f48a27c0 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -464,6 +464,7 @@ static int malidp_dumb_create(struct drm_file *file_priv,
> /* allocate for the worst case scenario, i.e. rotated buffers */
> u8 alignment = malidp_hw_get_pitch_align(malidp->dev, 1);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), alignment);
>
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c b/drivers/gpu/drm/drm_fb_dma_helper.c
> index fd71969d2fb1..12a44accc48c 100644
> --- a/drivers/gpu/drm/drm_fb_dma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_dma_helper.c
> @@ -187,6 +187,10 @@ int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
> if (!dma_obj->vaddr)
> return -ENODEV;
>
> + /* Buffer was allocated with NO_KERNEL_MAPPING */
> + if (dma_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> + return -ENODEV;
This is a good example of what I'm talking about. A driver that cannot
provide a scanout buffer should not set the callback in the first place.
Best regards
Thomas
> +
> iosys_map_set_vaddr(&sb->map[0], dma_obj->vaddr);
> sb->format = fb->format;
> sb->height = fb->height;
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
> index 9722c9fc86f3..281fb563f061 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -116,26 +116,8 @@ __drm_gem_dma_create(struct drm_device *drm, size_t size, bool private)
> return ERR_PTR(ret);
> }
>
> -/**
> - * drm_gem_dma_create - allocate an object with the given size
> - * @drm: DRM device
> - * @size: size of the object to allocate
> - *
> - * This function creates a DMA GEM object and allocates memory as backing store.
> - * The allocated memory will occupy a contiguous chunk of bus address space.
> - *
> - * For devices that are directly connected to the memory bus then the allocated
> - * memory will be physically contiguous. For devices that access through an
> - * IOMMU, then the allocated memory is not expected to be physically contiguous
> - * because having contiguous IOVAs is sufficient to meet a devices DMA
> - * requirements.
> - *
> - * Returns:
> - * A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
> - * error code on failure.
> - */
> -struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> - size_t size)
> +static struct drm_gem_dma_object *
> +drm_gem_dma_create_flags(struct drm_device *drm, size_t size, u32 flags)
> {
> struct drm_gem_dma_object *dma_obj;
> int ret;
> @@ -146,6 +128,9 @@ struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> if (IS_ERR(dma_obj))
> return dma_obj;
>
> + if (!(flags & DRM_MODE_DUMB_KERNEL_MAP))
> + dma_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
> +
> if (dma_obj->map_noncoherent) {
> dma_obj->vaddr = dma_alloc_noncoherent(drm_dev_dma_dev(drm),
> size,
> @@ -171,6 +156,30 @@ struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> drm_gem_object_put(&dma_obj->base);
> return ERR_PTR(ret);
> }
> +
> +/**
> + * drm_gem_dma_create - allocate an object with the given size
> + * @drm: DRM device
> + * @size: size of the object to allocate
> + *
> + * This function creates a DMA GEM object and allocates memory as backing store.
> + * The allocated memory will occupy a contiguous chunk of bus address space.
> + *
> + * For devices that are directly connected to the memory bus then the allocated
> + * memory will be physically contiguous. For devices that access through an
> + * IOMMU, then the allocated memory is not expected to be physically contiguous
> + * because having contiguous IOVAs is sufficient to meet a devices DMA
> + * requirements.
> + *
> + * Returns:
> + * A struct drm_gem_dma_object * on success or an ERR_PTR()-encoded negative
> + * error code on failure.
> + */
> +struct drm_gem_dma_object *drm_gem_dma_create(struct drm_device *drm,
> + size_t size)
> +{
> + return drm_gem_dma_create_flags(drm, size, DRM_MODE_DUMB_KERNEL_MAP);
> +}
> EXPORT_SYMBOL_GPL(drm_gem_dma_create);
>
> /**
> @@ -179,6 +188,7 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_create);
> * @file_priv: DRM file-private structure to register the handle for
> * @drm: DRM device
> * @size: size of the object to allocate
> + * @flags: DRM_MODE_DUMB_* flags if any
> * @handle: return location for the GEM handle
> *
> * This function creates a DMA GEM object, allocating a chunk of memory as
> @@ -194,14 +204,14 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_create);
> */
> static struct drm_gem_dma_object *
> drm_gem_dma_create_with_handle(struct drm_file *file_priv,
> - struct drm_device *drm, size_t size,
> + struct drm_device *drm, size_t size, u32 flags,
> uint32_t *handle)
> {
> struct drm_gem_dma_object *dma_obj;
> struct drm_gem_object *gem_obj;
> int ret;
>
> - dma_obj = drm_gem_dma_create(drm, size);
> + dma_obj = drm_gem_dma_create_flags(drm, size, DRM_MODE_DUMB_KERNEL_MAP);
> if (IS_ERR(dma_obj))
> return dma_obj;
>
> @@ -283,7 +293,7 @@ int drm_gem_dma_dumb_create_internal(struct drm_file *file_priv,
> args->size = args->pitch * args->height;
>
> dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
> - &args->handle);
> + args->flags, &args->handle);
> return PTR_ERR_OR_ZERO(dma_obj);
> }
> EXPORT_SYMBOL_GPL(drm_gem_dma_dumb_create_internal);
> @@ -313,12 +323,13 @@ int drm_gem_dma_dumb_create(struct drm_file *file_priv,
> struct drm_gem_dma_object *dma_obj;
> int ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> ret = drm_mode_size_dumb(drm, args, 0, 0);
> if (ret)
> return ret;
>
> dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
> - &args->handle);
> + args->flags, &args->handle);
> return PTR_ERR_OR_ZERO(dma_obj);
> }
> EXPORT_SYMBOL_GPL(drm_gem_dma_dumb_create);
> @@ -412,7 +423,10 @@ void drm_gem_dma_print_info(const struct drm_gem_dma_object *dma_obj,
> struct drm_printer *p, unsigned int indent)
> {
> drm_printf_indent(p, indent, "dma_addr=%pad\n", &dma_obj->dma_addr);
> - drm_printf_indent(p, indent, "vaddr=%p\n", dma_obj->vaddr);
> + if (dma_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> + drm_printf_indent(p, indent, "vaddr=(no mapping)\n");
> + else
> + drm_printf_indent(p, indent, "vaddr=%p\n", dma_obj->vaddr);
> }
> EXPORT_SYMBOL(drm_gem_dma_print_info);
>
> @@ -511,6 +525,9 @@ EXPORT_SYMBOL_GPL(drm_gem_dma_prime_import_sg_table);
> int drm_gem_dma_vmap(struct drm_gem_dma_object *dma_obj,
> struct iosys_map *map)
> {
> + if (dma_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> + return -ENOMEM;
> +
> iosys_map_set_vaddr(map, dma_obj->vaddr);
>
> return 0;
> diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c
> index bbebf4fc7f51..595a71163cb5 100644
> --- a/drivers/gpu/drm/logicvc/logicvc_drm.c
> +++ b/drivers/gpu/drm/logicvc/logicvc_drm.c
> @@ -39,6 +39,7 @@ static int logicvc_drm_gem_dma_dumb_create(struct drm_file *file_priv,
> {
> struct logicvc_drm *logicvc = logicvc_drm(drm_dev);
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> /* Stride is always fixed to its configuration value. */
> args->pitch = logicvc->config.row_stride * DIV_ROUND_UP(args->bpp, 8);
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> index 49ff9f1f16d3..9fa339d6e273 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -83,6 +83,7 @@ static irqreturn_t meson_irq(int irq, void *arg)
> static int meson_dumb_create(struct drm_file *file, struct drm_device *dev,
> struct drm_mode_create_dumb *args)
> {
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> /*
> * We need 64bytes aligned stride, and PAGE aligned size
> */
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index 60e6f43b8ab2..611fe3d4a4d8 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -424,6 +424,8 @@ int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> }
>
> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> index 87f171145a23..359f85bd84eb 100644
> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> @@ -184,6 +184,7 @@ int rzg2l_du_dumb_create(struct drm_file *file, struct drm_device *dev,
> unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> unsigned int align = 16 * args->bpp / 8;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> args->pitch = roundup(min_pitch, align);
>
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 56d53ac3082d..a0bc2e215adb 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -51,8 +51,9 @@ static int stm_gem_dma_dumb_create(struct drm_file *file,
> * in order to optimize data transfer, pitch is aligned on
> * 128 bytes, height is aligned on 4 bytes
> */
> - args->pitch = roundup(min_pitch, 128);
> args->height = roundup(args->height, 4);
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> + args->pitch = roundup(min_pitch, 128);
>
> return drm_gem_dma_dumb_create_internal(file, dev, args);
> }
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 8a409eee1dca..d3ff53ce2450 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -36,6 +36,7 @@ static int drm_sun4i_gem_dumb_create(struct drm_file *file_priv,
> struct drm_device *drm,
> struct drm_mode_create_dumb *args)
> {
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> /* The hardware only allows even pitches for YUV buffers. */
> args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8), 2);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index a14ecb769461..7a04cf52f511 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -87,6 +87,8 @@ static int vc5_dumb_create(struct drm_file *file_priv,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file_priv, dev, args);
> }
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c b/drivers/gpu/drm/verisilicon/vs_drm.c
> index fd259d53f49f..fe3591244d02 100644
> --- a/drivers/gpu/drm/verisilicon/vs_drm.c
> +++ b/drivers/gpu/drm/verisilicon/vs_drm.c
> @@ -44,6 +44,8 @@ static int vs_gem_dumb_create(struct drm_file *file_priv,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> }
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> index 02f3a7d78cf8..aa3822b3cb08 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
> @@ -371,6 +371,8 @@ static int zynqmp_dpsub_dumb_create(struct drm_file *file_priv,
> if (ret)
> return ret;
>
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> +
> return drm_gem_dma_dumb_create_internal(file_priv, drm, args);
> }
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [PATCH net V2 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-27 7:32 UTC (permalink / raw)
To: Radhey Shyam Pandey, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Sean Anderson, Daniel Borkmann, Ariane Keller,
netdev, linux-arm-kernel, linux-kernel
This patch series fixes two issues in the Xilinx AXI Ethernet driver:
1. Corrects the BD length masks to match the AXIDMA IP spec.
2. Fixes BQL accounting for multi-BD TX packets.
---
Changes in V2:
- Define BD length masks with GENMASK(25, 0) per PG021.
- Credit BQL using skb->len on packet completion instead of summing
per-BD actual lengths from descriptor status.
---
Suraj Gupta (2):
net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 ++++-----
2 files changed, 6 insertions(+), 7 deletions(-)
--
2.49.1
^ permalink raw reply
* [PATCH net V2 1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
From: Suraj Gupta @ 2026-03-27 7:32 UTC (permalink / raw)
To: Radhey Shyam Pandey, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Sean Anderson, Daniel Borkmann, Ariane Keller,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-1-suraj.gupta2@amd.com>
The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK
macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP
product guide (PG021) specifies the buffer length field as bits 25:0
(26 bits). Update both masks to match the IP documentation.
In practice this had no functional impact, since Ethernet frames are
far smaller than 2^23 bytes and the extra bits were always zero, but
the masks should still reflect the hardware specification.
Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 5ff742103beb..fcd3aaef27fc 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -105,7 +105,7 @@
#define XAXIDMA_BD_HAS_DRE_MASK 0xF00 /* Whether has DRE mask */
#define XAXIDMA_BD_WORDLEN_MASK 0xFF /* Whether has DRE mask */
-#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
+#define XAXIDMA_BD_CTRL_LENGTH_MASK GENMASK(25, 0) /* Requested len */
#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
@@ -130,7 +130,7 @@
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
-#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
+#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK GENMASK(25, 0) /* Actual len */
#define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
#define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
#define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
--
2.49.1
^ permalink raw reply related
* [PATCH net V2 2/2] net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-27 7:32 UTC (permalink / raw)
To: Radhey Shyam Pandey, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Michal Simek, Sean Anderson, Daniel Borkmann, Ariane Keller,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-1-suraj.gupta2@amd.com>
When a TX packet spans multiple buffer descriptors (scatter-gather),
axienet_free_tx_chain sums the per-BD actual length from descriptor
status into a caller-provided accumulator. That sum is reset on each
NAPI poll. If the BDs for a single packet complete across different
polls, the earlier bytes are lost and never credited to BQL. This
causes BQL to think bytes are permanently in-flight, eventually
stalling the TX queue.
The SKB pointer is stored only on the last BD of a packet. When that
BD completes, use skb->len for the byte count instead of summing
per-BD status lengths. This matches netdev_sent_queue(), which debits
skb->len, and naturally survives across polls because no partial
packet contributes to the accumulator.
Fixes: c900e49d58eb ("net: xilinx: axienet: Implement BQL")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index b06e4c37ff61..263c4b67fd5a 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -770,8 +770,8 @@ static int axienet_device_reset(struct net_device *ndev)
* @first_bd: Index of first descriptor to clean up
* @nr_bds: Max number of descriptors to clean up
* @force: Whether to clean descriptors even if not complete
- * @sizep: Pointer to a u32 filled with the total sum of all bytes
- * in all cleaned-up descriptors. Ignored if NULL.
+ * @sizep: Pointer to a u32 accumulating the total byte count of
+ * completed packets (using skb->len). Ignored if NULL.
* @budget: NAPI budget (use 0 when not called from NAPI poll)
*
* Would either be called after a successful transmit operation, or after
@@ -805,6 +805,8 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
DMA_TO_DEVICE);
if (cur_p->skb && (status & XAXIDMA_BD_STS_COMPLETE_MASK)) {
+ if (sizep)
+ *sizep += cur_p->skb->len;
napi_consume_skb(cur_p->skb, budget);
packets++;
}
@@ -818,9 +820,6 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
wmb();
cur_p->cntrl = 0;
cur_p->status = 0;
-
- if (sizep)
- *sizep += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
}
if (!force) {
--
2.49.1
^ permalink raw reply related
* Re: [PATCH v3 4/5] KVM: arm64: Enable HDBSS support and handle HDBSSF events
From: Tian Zheng @ 2026-03-27 7:35 UTC (permalink / raw)
To: Leonardo Bras
Cc: maz, oupton, catalin.marinas, corbet, pbonzini, will, yuzenghui,
wangzhou1, liuyonglong, Jonathan.Cameron, yezhenyu2, linuxarm,
joey.gouly, kvmarm, kvm, linux-arm-kernel, linux-doc,
linux-kernel, skhan, suzuki.poulose
In-Reply-To: <acQj5grOdZT8LUGp@devkitleo>
On 3/26/2026 2:05 AM, Leonardo Bras wrote:
> Hello Tian,
>
> I am currently working on HACDBS enablement(which will be rebased on top of
> this patchset) and due to the fact HACDBS and HDBSS are kind of
> complementary I will sometimes come with some questions for issues I have
> faced myself on that part. :)
>
> (see below)
Of course! Happy to exchange ideas and learn together.
>
> On Wed, Feb 25, 2026 at 12:04:20PM +0800, Tian Zheng wrote:
>> From: eillon <yezhenyu2@huawei.com>
>>
>> HDBSS is enabled via an ioctl from userspace (e.g. QEMU) at the start of
>> migration. This feature is only supported in VHE mode.
>>
>> Initially, S2 PTEs doesn't contain the DBM attribute. During migration,
>> write faults are handled by user_mem_abort, which relaxes permissions
>> and adds the DBM bit when HDBSS is active. Once DBM is set, subsequent
>> writes no longer trap, as the hardware automatically transitions the page
>> from writable-clean to writable-dirty.
>>
>> KVM does not scan S2 page tables to consume DBM. Instead, when HDBSS is
>> enabled, the hardware observes the clean->dirty transition and records
>> the corresponding page into the HDBSS buffer.
>>
>> During sync_dirty_log, KVM kicks all vCPUs to force VM-Exit, ensuring
>> that check_vcpu_requests flushes the HDBSS buffer and propagates the
>> accumulated dirty information into the userspace-visible dirty bitmap.
>>
>> Add fault handling for HDBSS including buffer full, external abort, and
>> general protection fault (GPF).
>>
>> Signed-off-by: eillon <yezhenyu2@huawei.com>
>> Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
>> ---
>> arch/arm64/include/asm/esr.h | 5 ++
>> arch/arm64/include/asm/kvm_host.h | 17 +++++
>> arch/arm64/include/asm/kvm_mmu.h | 1 +
>> arch/arm64/include/asm/sysreg.h | 11 ++++
>> arch/arm64/kvm/arm.c | 102 ++++++++++++++++++++++++++++++
>> arch/arm64/kvm/hyp/vhe/switch.c | 19 ++++++
>> arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++++
>> arch/arm64/kvm/reset.c | 3 +
>> 8 files changed, 228 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
>> index 81c17320a588..2e6b679b5908 100644
>> --- a/arch/arm64/include/asm/esr.h
>> +++ b/arch/arm64/include/asm/esr.h
>> @@ -437,6 +437,11 @@
>> #ifndef __ASSEMBLER__
>> #include <asm/types.h>
>>
>> +static inline bool esr_iss2_is_hdbssf(unsigned long esr)
>> +{
>> + return ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF;
>> +}
>> +
>> static inline unsigned long esr_brk_comment(unsigned long esr)
>> {
>> return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 5d5a3bbdb95e..57ee6b53e061 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -55,12 +55,17 @@
>> #define KVM_REQ_GUEST_HYP_IRQ_PENDING KVM_ARCH_REQ(9)
>> #define KVM_REQ_MAP_L1_VNCR_EL2 KVM_ARCH_REQ(10)
>> #define KVM_REQ_VGIC_PROCESS_UPDATE KVM_ARCH_REQ(11)
>> +#define KVM_REQ_FLUSH_HDBSS KVM_ARCH_REQ(12)
>>
>> #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
>> KVM_DIRTY_LOG_INITIALLY_SET)
>>
>> #define KVM_HAVE_MMU_RWLOCK
>>
>> +/* HDBSS entry field definitions */
>> +#define HDBSS_ENTRY_VALID BIT(0)
>> +#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
>> +
>> /*
>> * Mode of operation configurable with kvm-arm.mode early param.
>> * See Documentation/admin-guide/kernel-parameters.txt for more information.
>> @@ -84,6 +89,7 @@ int __init kvm_arm_init_sve(void);
>> u32 __attribute_const__ kvm_target_cpu(void);
>> void kvm_reset_vcpu(struct kvm_vcpu *vcpu);
>> void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu);
>> +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
>>
>> struct kvm_hyp_memcache {
>> phys_addr_t head;
>> @@ -405,6 +411,8 @@ struct kvm_arch {
>> * the associated pKVM instance in the hypervisor.
>> */
>> struct kvm_protected_vm pkvm;
>> +
>> + bool enable_hdbss;
>> };
>>
>> struct kvm_vcpu_fault_info {
>> @@ -816,6 +824,12 @@ struct vcpu_reset_state {
>> bool reset;
>> };
>>
>> +struct vcpu_hdbss_state {
>> + phys_addr_t base_phys;
>> + u32 size;
>> + u32 next_index;
>> +};
>> +
>> struct vncr_tlb;
>>
>> struct kvm_vcpu_arch {
>> @@ -920,6 +934,9 @@ struct kvm_vcpu_arch {
>>
>> /* Per-vcpu TLB for VNCR_EL2 -- NULL when !NV */
>> struct vncr_tlb *vncr_tlb;
>> +
>> + /* HDBSS registers info */
>> + struct vcpu_hdbss_state hdbss;
>> };
>>
>> /*
>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>> index d968aca0461a..3fea8cfe8869 100644
>> --- a/arch/arm64/include/asm/kvm_mmu.h
>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>> @@ -183,6 +183,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>>
>> int kvm_handle_guest_sea(struct kvm_vcpu *vcpu);
>> int kvm_handle_guest_abort(struct kvm_vcpu *vcpu);
>> +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
>>
>> phys_addr_t kvm_mmu_get_httbr(void);
>> phys_addr_t kvm_get_idmap_vector(void);
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index f4436ecc630c..d11f4d0dd4e7 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -1039,6 +1039,17 @@
>>
>> #define GCS_CAP(x) ((((unsigned long)x) & GCS_CAP_ADDR_MASK) | \
>> GCS_CAP_VALID_TOKEN)
>> +
>> +/*
>> + * Definitions for the HDBSS feature
>> + */
>> +#define HDBSS_MAX_SIZE HDBSSBR_EL2_SZ_2MB
>> +
>> +#define HDBSSBR_EL2(baddr, sz) (((baddr) & GENMASK(55, 12 + sz)) | \
>> + FIELD_PREP(HDBSSBR_EL2_SZ_MASK, sz))
>> +
>> +#define HDBSSPROD_IDX(prod) FIELD_GET(HDBSSPROD_EL2_INDEX_MASK, prod)
>> +
>> /*
>> * Definitions for GICv5 instructions]
>> */
>> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
>> index 29f0326f7e00..d64da05e25c4 100644
>> --- a/arch/arm64/kvm/arm.c
>> +++ b/arch/arm64/kvm/arm.c
>> @@ -125,6 +125,87 @@ int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
>> return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
>> }
>>
>> +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu)
>> +{
>> + struct page *hdbss_pg;
>> +
>> + hdbss_pg = phys_to_page(vcpu->arch.hdbss.base_phys);
>> + if (hdbss_pg)
>> + __free_pages(hdbss_pg, vcpu->arch.hdbss.size);
>> +
>> + vcpu->arch.hdbss.size = 0;
>> +}
>> +
>> +static int kvm_cap_arm_enable_hdbss(struct kvm *kvm,
>> + struct kvm_enable_cap *cap)
>> +{
>> + unsigned long i;
>> + struct kvm_vcpu *vcpu;
>> + struct page *hdbss_pg = NULL;
>> + __u64 size = cap->args[0];
>> + bool enable = cap->args[1] ? true : false;
>> +
>> + if (!system_supports_hdbss())
>> + return -EINVAL;
>> +
>> + if (size > HDBSS_MAX_SIZE)
>> + return -EINVAL;
>> +
>> + if (!enable && !kvm->arch.enable_hdbss) /* Already Off */
>> + return 0;
>> +
>> + if (enable && kvm->arch.enable_hdbss) /* Already On, can't set size */
>> + return -EINVAL;
>> +
>> + if (!enable) { /* Turn it off */
>> + kvm->arch.mmu.vtcr &= ~(VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA);
>> +
>> + kvm_for_each_vcpu(i, vcpu, kvm) {
>> + /* Kick vcpus to flush hdbss buffer. */
>> + kvm_vcpu_kick(vcpu);
>> +
>> + kvm_arm_vcpu_free_hdbss(vcpu);
>> + }
>> +
>> + kvm->arch.enable_hdbss = false;
>> +
>> + return 0;
>> + }
>> +
>> + /* Turn it on */
>> + kvm_for_each_vcpu(i, vcpu, kvm) {
>> + hdbss_pg = alloc_pages(GFP_KERNEL_ACCOUNT, size);
>> + if (!hdbss_pg)
>> + goto error_alloc;
>> +
>> + vcpu->arch.hdbss = (struct vcpu_hdbss_state) {
>> + .base_phys = page_to_phys(hdbss_pg),
>> + .size = size,
>> + .next_index = 0,
>> + };
>> + }
>> +
>> + kvm->arch.enable_hdbss = true;
>> + kvm->arch.mmu.vtcr |= VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA;
>> +
>> + /*
>> + * We should kick vcpus out of guest mode here to load new
>> + * vtcr value to vtcr_el2 register when re-enter guest mode.
>> + */
>> + kvm_for_each_vcpu(i, vcpu, kvm)
>> + kvm_vcpu_kick(vcpu);
>> +
>> + return 0;
>> +
>> +error_alloc:
>> + kvm_for_each_vcpu(i, vcpu, kvm) {
>> + if (vcpu->arch.hdbss.base_phys)
>> + kvm_arm_vcpu_free_hdbss(vcpu);
>> + }
>> +
>> + return -ENOMEM;
>> +}
>> +
>> int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
>> struct kvm_enable_cap *cap)
>> {
>> @@ -182,6 +263,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
>> r = 0;
>> set_bit(KVM_ARCH_FLAG_EXIT_SEA, &kvm->arch.flags);
>> break;
>> + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
>> + mutex_lock(&kvm->lock);
>> + r = kvm_cap_arm_enable_hdbss(kvm, cap);
>> + mutex_unlock(&kvm->lock);
>> + break;
>> default:
>> break;
>> }
>> @@ -471,6 +557,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>> r = kvm_supports_cacheable_pfnmap();
>> break;
>>
>> + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
>> + r = system_supports_hdbss();
>> + break;
>> default:
>> r = 0;
>> }
>> @@ -1120,6 +1209,9 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu)
>> if (kvm_dirty_ring_check_request(vcpu))
>> return 0;
>>
>> + if (kvm_check_request(KVM_REQ_FLUSH_HDBSS, vcpu))
>> + kvm_flush_hdbss_buffer(vcpu);
>> +
>> check_nested_vcpu_requests(vcpu);
>> }
>>
>> @@ -1898,7 +1990,17 @@ long kvm_arch_vcpu_unlocked_ioctl(struct file *filp, unsigned int ioctl,
>>
>> void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
>> {
>> + /*
>> + * Flush all CPUs' dirty log buffers to the dirty_bitmap. Called
>> + * before reporting dirty_bitmap to userspace. Send a request with
>> + * KVM_REQUEST_WAIT to flush buffer synchronously.
>> + */
>> + struct kvm_vcpu *vcpu;
>> +
>> + if (!kvm->arch.enable_hdbss)
>> + return;
>>
>> + kvm_make_all_cpus_request(kvm, KVM_REQ_FLUSH_HDBSS);
>> }
>>
>> static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
>> diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
>> index 9db3f11a4754..600cbc4f8ae9 100644
>> --- a/arch/arm64/kvm/hyp/vhe/switch.c
>> +++ b/arch/arm64/kvm/hyp/vhe/switch.c
>> @@ -213,6 +213,23 @@ static void __vcpu_put_deactivate_traps(struct kvm_vcpu *vcpu)
>> local_irq_restore(flags);
>> }
>>
>> +static void __load_hdbss(struct kvm_vcpu *vcpu)
>> +{
>> + struct kvm *kvm = vcpu->kvm;
>> + u64 br_el2, prod_el2;
>> +
>> + if (!kvm->arch.enable_hdbss)
>> + return;
>> +
>> + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
>> + prod_el2 = vcpu->arch.hdbss.next_index;
>> +
>> + write_sysreg_s(br_el2, SYS_HDBSSBR_EL2);
>> + write_sysreg_s(prod_el2, SYS_HDBSSPROD_EL2);
>> +
>> + isb();
>> +}
>> +
> I see in the code below you trust that the tracking will happen with
> PAGE_SIZE granularity (you track with PAGE_SHIFT).
>
> That may be a problem when we have guest memory backed by hugepages or
> transparent huge pages.
>
> When we are using HDBSS, there is no fault happening, so we have no way of
> doing on-demand block splitting, so we need to make use of eager block
> splitting, _before_ we start to track anything, or else we may have
> different-sized pages in the HDBSS buffer, which is harder to deal with.
>
> Suggestion: do the eager splitting before we enable HDBSS.
>
> For this to happen, we have to enable the EAGER_SPLIT_CHUNK_SIZE
> capability, which can only be enabled when all memslots are empty.
>
> I suggest doing that at kvm_init_stage2_mmu(), and checking if HDBSS is
> in which case we set mmu->split_page_chunk_size to PAGESIZE.
>
> I will send a patch you can put before this one to make sure it works :)
>
> Thanks!
> Leo
Hi Leo,
Thanks for the helpful suggestion. I had previously traced the
hugepage-splitting path
during live migration and found that when migration starts, enabling
dirty logging
triggers the splitting path. I also tested HDBSS with traditional
hugepages and haven't
observed any issues yet.
However, your concern is valid — there may be cases not covered,
especially when the
VMM uses transparent hugepages. I'll integrate your patch into the next
version and
run some tests.
For reference, here's the path I traced:
```
- userspace, e.g., QEMU
kvm_log_start
+-> kvm_section_update_flags
+-> kvm_slot_update_flags
|
| // For each memory region, QEMU issues a
KVM_SET_USER_MEMORY_REGION ioctl.
| // Before issuing it, flags are updated to include
KVM_MEM_LOG_DIRTY_PAGES.
+-> kvm_mem_flags
+-> kvm_set_user_memory_region // ioctl that enables dirty
logging on the memslot
- KVM
KVM_SET_USER_MEMORY_REGION
+-> kvm_vm_ioctl_set_memory_region
+-> kvm_set_memory_region / __kvm_set_memory_region
+-> kvm_set_memslot
+-> kvm_commit_memory_region
+-> kvm_arch_commit_memory_region
+-> kvm_mmu_split_memory_region
// Splits Stage-2 hugepages/contiguous mappings
into 4KB PTEs.
+-> kvm_mmu_split_huge_pages
+-> kvm_pgtable_stage2_split
```
Thanks again for the detailed explanation and for sending the patch.
>> void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
>> {
>> host_data_ptr(host_ctxt)->__hyp_running_vcpu = vcpu;
>> @@ -220,10 +237,12 @@ void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
>> __vcpu_load_switch_sysregs(vcpu);
>> __vcpu_load_activate_traps(vcpu);
>> __load_stage2(vcpu->arch.hw_mmu, vcpu->arch.hw_mmu->arch);
>> + __load_hdbss(vcpu);
>> }
>>
>> void kvm_vcpu_put_vhe(struct kvm_vcpu *vcpu)
>> {
>> + kvm_flush_hdbss_buffer(vcpu);
>> __vcpu_put_deactivate_traps(vcpu);
>> __vcpu_put_switch_sysregs(vcpu);
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 070a01e53fcb..42b0710a16ce 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -1896,6 +1896,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> if (writable)
>> prot |= KVM_PGTABLE_PROT_W;
>>
>> + if (writable && kvm->arch.enable_hdbss && logging_active)
>> + prot |= KVM_PGTABLE_PROT_DBM;
>> +
>> if (exec_fault)
>> prot |= KVM_PGTABLE_PROT_X;
>>
>> @@ -2033,6 +2036,70 @@ int kvm_handle_guest_sea(struct kvm_vcpu *vcpu)
>> return 0;
>> }
>>
>> +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu)
>> +{
>> + int idx, curr_idx;
>> + u64 br_el2;
>> + u64 *hdbss_buf;
>> + struct kvm *kvm = vcpu->kvm;
>> +
>> + if (!kvm->arch.enable_hdbss)
>> + return;
>> +
>> + curr_idx = HDBSSPROD_IDX(read_sysreg_s(SYS_HDBSSPROD_EL2));
>> + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
>> +
>> + /* Do nothing if HDBSS buffer is empty or br_el2 is NULL */
>> + if (curr_idx == 0 || br_el2 == 0)
>> + return;
>> +
>> + hdbss_buf = page_address(phys_to_page(vcpu->arch.hdbss.base_phys));
>> + if (!hdbss_buf)
>> + return;
>> +
>> + guard(write_lock_irqsave)(&vcpu->kvm->mmu_lock);
>> + for (idx = 0; idx < curr_idx; idx++) {
>> + u64 gpa;
>> +
>> + gpa = hdbss_buf[idx];
>> + if (!(gpa & HDBSS_ENTRY_VALID))
>> + continue;
>> +
>> + gpa &= HDBSS_ENTRY_IPA;
>> + kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
>> + }
> Here ^
Thanks!
Tian
>
>> +
>> + /* reset HDBSS index */
>> + write_sysreg_s(0, SYS_HDBSSPROD_EL2);
>> + vcpu->arch.hdbss.next_index = 0;
>> + isb();
>> +}
>> +
>> +static int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu)
>> +{
>> + u64 prod;
>> + u64 fsc;
>> +
>> + prod = read_sysreg_s(SYS_HDBSSPROD_EL2);
>> + fsc = FIELD_GET(HDBSSPROD_EL2_FSC_MASK, prod);
>> +
>> + switch (fsc) {
>> + case HDBSSPROD_EL2_FSC_OK:
>> + /* Buffer full, which is reported as permission fault. */
>> + kvm_flush_hdbss_buffer(vcpu);
>> + return 1;
>> + case HDBSSPROD_EL2_FSC_ExternalAbort:
>> + case HDBSSPROD_EL2_FSC_GPF:
>> + return -EFAULT;
>> + default:
>> + /* Unknown fault. */
>> + WARN_ONCE(1,
>> + "Unexpected HDBSS fault type, FSC: 0x%llx (prod=0x%llx, vcpu=%d)\n",
>> + fsc, prod, vcpu->vcpu_id);
>> + return -EFAULT;
>> + }
>> +}
>> +
>> /**
>> * kvm_handle_guest_abort - handles all 2nd stage aborts
>> * @vcpu: the VCPU pointer
>> @@ -2071,6 +2138,9 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>>
>> is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
>>
>> + if (esr_iss2_is_hdbssf(esr))
>> + return kvm_handle_hdbss_fault(vcpu);
>> +
>> if (esr_fsc_is_translation_fault(esr)) {
>> /* Beyond sanitised PARange (which is the IPA limit) */
>> if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index 959532422d3a..c03a4b310b53 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -161,6 +161,9 @@ void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu)
>> free_page((unsigned long)vcpu->arch.ctxt.vncr_array);
>> kfree(vcpu->arch.vncr_tlb);
>> kfree(vcpu->arch.ccsidr);
>> +
>> + if (vcpu->kvm->arch.enable_hdbss)
>> + kvm_arm_vcpu_free_hdbss(vcpu);
>> }
>>
>> static void kvm_vcpu_reset_sve(struct kvm_vcpu *vcpu)
>> --
>> 2.33.0
>>
^ permalink raw reply
* Re: [PATCH] arm64/kvm: Enable eager hugepage splitting if HDBSS is available
From: Tian Zheng @ 2026-03-27 7:40 UTC (permalink / raw)
To: Leonardo Bras
Cc: maz, oupton, catalin.marinas, corbet, pbonzini, will, yuzenghui,
wangzhou1, liuyonglong, Jonathan.Cameron, yezhenyu2, linuxarm,
joey.gouly, kvmarm, kvm, linux-arm-kernel, linux-doc,
linux-kernel, skhan, suzuki.poulose
In-Reply-To: <acQna2hLwdr1juTN@devkitleo>
On 3/26/2026 2:20 AM, Leonardo Bras wrote:
> FEAT_HDBSS speeds up guest memory dirty tracking by avoiding a page fault
> and saving the entry in a tracking structure.
>
> That may be a problem when we have guest memory backed by hugepages or
> transparent huge pages, as it's not possible to do on-demand hugepage
> splitting, relying only on eager hugepage splitting.
>
> So, at stage2 initialization, enable eager hugepage splitting with
> chunk = PAGE_SIZE if the system supports HDBSS.
>
> Signed-off-by: Leonardo Bras <leo.bras@arm.com>
> ---
> arch/arm64/kvm/mmu.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 070a01e53fcb..bdfa72b7c073 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -993,22 +993,26 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
>
> mmu->last_vcpu_ran = alloc_percpu(typeof(*mmu->last_vcpu_ran));
> if (!mmu->last_vcpu_ran) {
> err = -ENOMEM;
> goto out_destroy_pgtable;
> }
>
> for_each_possible_cpu(cpu)
> *per_cpu_ptr(mmu->last_vcpu_ran, cpu) = -1;
>
> - /* The eager page splitting is disabled by default */
> - mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
> + /* The eager page splitting is disabled by default if system has no HDBSS */
> + if (system_supports_hacdbs())
> + mmu->split_page_chunk_size = PAGE_SIZE;
> + else
> + mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
> +
> mmu->split_page_cache.gfp_zero = __GFP_ZERO;
>
> mmu->pgd_phys = __pa(pgt->pgd);
>
> if (kvm_is_nested_s2_mmu(kvm, mmu))
> kvm_init_nested_s2_mmu(mmu);
>
> return 0;
>
> out_destroy_pgtable:
Thanks again for sending this patch. I'll integrate it into the next
version and run some tests.
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Geert Uytterhoeven @ 2026-03-27 7:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King, Christian Schrefl, Miguel Ojeda, Alice Ryhl,
Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, Andreas Hindborg, acourbot, Andrew Morton,
Anton Ivanov, Björn Roy Baron, Boqun Feng, Danilo Krummrich,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
John Paul Adrian Glaubitz
In-Reply-To: <641592e3-2354-4238-9eb8-a1f5c2a13126@app.fastmail.com>
Hi Arnd,
On Thu, 26 Mar 2026 at 22:34, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Mar 26, 2026, at 16:18, Russell King (Oracle) wrote:
> > On Thu, Mar 26, 2026 at 03:31:26PM +0100, Christian Schrefl wrote:
> >> On 3/26/26 2:47 PM, Miguel Ojeda wrote:
> >> > On Thu, Mar 26, 2026 at 11:10 AM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > I'm not sure if this is still true, but I believe it used to be the case
> > that the -linux-gnueabi target has one behaviour for enums (fixed size)
> > whereas -none-eabi, the size of the type depends on the range of values
> > included in the enum.
>
> I checked Debian's arm-none-eabi-gcc, which indeed still has this behavior:
>
> $ echo 'enum { A, B } x = sizeof(x);' | arm-none-eabi-gcc -xc - -O2 -o- -S | grep -A1 x:
> x:
> .byte 1
>
> and I see the same thing for the hexagon target in clang, but none
> of the other targets that Linux runs on. In particular, clang always
> behaves like linux-gnueabi even when targeting plain eabi.
>
> $ echo 'enum { A, B } x = sizeof(x);' | clang --target=arm-none-eabi -xc - -O2 -o- -S | grep -A1 x:
> x:
> .long 4
>
> I noticed a similar issue with m68k-linux, which has a bitfield
> alignment different from anything else on gcc, but uses the normal
> behavior on clang.
Ugh, I wasn't aware of that. Adrian, did you know?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 0/4] module: force sh_addr=0 for arch-specific sections
From: Petr Pavlu @ 2026-03-27 7:58 UTC (permalink / raw)
To: Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Sami Tolvanen
Cc: Alexandre Ghiti, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Aaron Tomlin, Joe Lawrence, linux-arm-kernel, linux-m68k,
linux-riscv, linux-modules, linux-kernel
When linking modules with 'ld.bfd -r', sections defined without an address
inherit the location counter, resulting in non-zero sh_addr values in the
resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
all sections. Non-zero addresses are confusing in this context, typically
worse compressible, and may cause tools to misbehave [1].
Joe Lawrence previously addressed the same issue in the main
scripts/module.lds.S file [2] and we discussed that the same fix should be
also applied to architecture-specific module sections. This series
implements these changes.
The series can later be merged through the modules tree, or individual
patches can be applied through the architecture-specific trees.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=33958
[2] https://lore.kernel.org/linux-modules/20260305015237.299727-1-joe.lawrence@redhat.com/
Petr Pavlu (4):
module, arm: force sh_addr=0 for arch-specific sections
module, arm64: force sh_addr=0 for arch-specific sections
module, m68k: force sh_addr=0 for arch-specific sections
module, riscv: force sh_addr=0 for arch-specific sections
arch/arm/include/asm/module.lds.h | 4 ++--
arch/arm64/include/asm/module.lds.h | 4 ++--
arch/m68k/include/asm/module.lds.h | 2 +-
arch/riscv/include/asm/module.lds.h | 6 +++---
4 files changed, 8 insertions(+), 8 deletions(-)
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.53.0
^ permalink raw reply
* [PATCH 1/4] module, arm: force sh_addr=0 for arch-specific sections
From: Petr Pavlu @ 2026-03-27 7:59 UTC (permalink / raw)
To: Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Sami Tolvanen
Cc: Alexandre Ghiti, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Aaron Tomlin, Joe Lawrence, linux-arm-kernel, linux-m68k,
linux-riscv, linux-modules, linux-kernel
In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com>
When linking modules with 'ld.bfd -r', sections defined without an address
inherit the location counter, resulting in non-zero sh_addr values in the
resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
all sections. Non-zero addresses are confusing in this context, typically
worse compressible, and may cause tools to misbehave [1].
Force sh_addr=0 for all arm-specific module sections.
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1]
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
arch/arm/include/asm/module.lds.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/module.lds.h b/arch/arm/include/asm/module.lds.h
index 0e7cb4e314b4..f9ad774b2889 100644
--- a/arch/arm/include/asm/module.lds.h
+++ b/arch/arm/include/asm/module.lds.h
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
#ifdef CONFIG_ARM_MODULE_PLTS
SECTIONS {
- .plt : { BYTE(0) }
- .init.plt : { BYTE(0) }
+ .plt 0 : { BYTE(0) }
+ .init.plt 0 : { BYTE(0) }
}
#endif
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] module, arm64: force sh_addr=0 for arch-specific sections
From: Petr Pavlu @ 2026-03-27 7:59 UTC (permalink / raw)
To: Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Sami Tolvanen
Cc: Alexandre Ghiti, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Aaron Tomlin, Joe Lawrence, linux-arm-kernel, linux-m68k,
linux-riscv, linux-modules, linux-kernel
In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com>
When linking modules with 'ld.bfd -r', sections defined without an address
inherit the location counter, resulting in non-zero sh_addr values in the
resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
all sections. Non-zero addresses are confusing in this context, typically
worse compressible, and may cause tools to misbehave [1].
Force sh_addr=0 for all arm64-specific module sections.
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1]
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
Note that the definition of .text.hot hasn't matched any input sections
since commit 1ba9f8979426 ("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and
related macros"), and even before that with CONFIG_LTO_CLANG=y.
The preceding comment also explains that the directive is necessary to
merge section groups. However, this approach seems suboptimal. A better
method would be to link modules using --force-group-allocation to retain
only one copy of each group.
I plan to look at this separately.
---
arch/arm64/include/asm/module.lds.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/module.lds.h b/arch/arm64/include/asm/module.lds.h
index fb944b46846d..0b3aacd22c59 100644
--- a/arch/arm64/include/asm/module.lds.h
+++ b/arch/arm64/include/asm/module.lds.h
@@ -14,7 +14,7 @@ SECTIONS {
* directive to force them into a single section and silence the
* warning.
*/
- .text.hot : { *(.text.hot) }
+ .text.hot 0 : { *(.text.hot) }
#endif
#ifdef CONFIG_UNWIND_TABLES
@@ -22,6 +22,6 @@ SECTIONS {
* Currently, we only use unwind info at module load time, so we can
* put it into the .init allocation.
*/
- .init.eh_frame : { *(.eh_frame) }
+ .init.eh_frame 0 : { *(.eh_frame) }
#endif
}
--
2.53.0
^ permalink raw reply related
* [PATCH 4/4] module, riscv: force sh_addr=0 for arch-specific sections
From: Petr Pavlu @ 2026-03-27 7:59 UTC (permalink / raw)
To: Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Sami Tolvanen
Cc: Alexandre Ghiti, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Aaron Tomlin, Joe Lawrence, linux-arm-kernel, linux-m68k,
linux-riscv, linux-modules, linux-kernel
In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com>
When linking modules with 'ld.bfd -r', sections defined without an address
inherit the location counter, resulting in non-zero sh_addr values in the
resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
all sections. Non-zero addresses are confusing in this context, typically
worse compressible, and may cause tools to misbehave [1].
Force sh_addr=0 for all riscv-specific module sections.
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1]
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
arch/riscv/include/asm/module.lds.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/include/asm/module.lds.h b/arch/riscv/include/asm/module.lds.h
index 1075beae1ac6..9ced27c8ccb6 100644
--- a/arch/riscv/include/asm/module.lds.h
+++ b/arch/riscv/include/asm/module.lds.h
@@ -2,8 +2,8 @@
/* Copyright (C) 2017 Andes Technology Corporation */
#ifdef CONFIG_MODULE_SECTIONS
SECTIONS {
- .plt : { BYTE(0) }
- .got : { BYTE(0) }
- .got.plt : { BYTE(0) }
+ .plt 0 : { BYTE(0) }
+ .got 0 : { BYTE(0) }
+ .got.plt 0 : { BYTE(0) }
}
#endif
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] module, m68k: force sh_addr=0 for arch-specific sections
From: Petr Pavlu @ 2026-03-27 7:59 UTC (permalink / raw)
To: Russell King, Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Sami Tolvanen
Cc: Alexandre Ghiti, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Aaron Tomlin, Joe Lawrence, linux-arm-kernel, linux-m68k,
linux-riscv, linux-modules, linux-kernel
In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com>
When linking modules with 'ld.bfd -r', sections defined without an address
inherit the location counter, resulting in non-zero sh_addr values in the
resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
all sections. Non-zero addresses are confusing in this context, typically
worse compressible, and may cause tools to misbehave [1].
Force sh_addr=0 for all m68k-specific module sections.
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=33958 [1]
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
arch/m68k/include/asm/module.lds.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/include/asm/module.lds.h b/arch/m68k/include/asm/module.lds.h
index fda94fa38243..fcd08689b282 100644
--- a/arch/m68k/include/asm/module.lds.h
+++ b/arch/m68k/include/asm/module.lds.h
@@ -1,5 +1,5 @@
SECTIONS {
- .m68k_fixup : {
+ .m68k_fixup 0 : {
__start_fixup = .;
*(.m68k_fixup)
__stop_fixup = .;
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] Qualcomm Arm64 DeviceTree fixes for v7.0
From: Krzysztof Kozlowski @ 2026-03-27 8:01 UTC (permalink / raw)
To: Bjorn Andersson, arm, soc
Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Sumit Garg,
Loic Poulain, Daniel J Blueman, Ravi Hothi
In-Reply-To: <20260326133845.66761-1-andersson@kernel.org>
On 26/03/2026 14:38, Bjorn Andersson wrote:
>
> ----------------------------------------------------------------
> Daniel J Blueman (1):
> arm64: dts: qcom: hamoa/x1: fix idle exit latency
>
> Loic Poulain (2):
> arm64: dts: qcom: monaco: Fix UART10 pinconf
> arm64: dts: qcom: monaco: Reserve full Gunyah metadata region
>
> Ravi Hothi (1):
> arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity
>
> Sumit Garg (3):
> dt-bindings: display: msm: qcm2290-mdss: Fix iommus property
This introduces a known warning, which I already reported and pinged you
TWICE on IRC, including yesterday. I did not indicate that my fix is for
current cycle, because I did not know that troubling commit is part of
the fixes branch.
No, I am not taking a known warning without fix, especially that the fix
is right there.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Miguel Ojeda @ 2026-03-27 8:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Miguel Ojeda, Marek Szyprowski, Robin Murphy, Danilo Krummrich,
Abdiel Janulgue, Daniel Almeida, Andreas Hindborg,
Christoph Hellwig, iommu, driver-core, acourbot, Andrew Morton,
Alice Ryhl, Anton Ivanov, Björn Roy Baron, Boqun Feng,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
Russell King, llvm, Benno Lossin, Mark Rutland, mmaurer,
Bill Wendling, Nathan Chancellor, Nick Desaulniers,
Nicolas Schier, Nicolas Schier, Peter Zijlstra,
Richard Weinberger, rust-for-linux, Trevor Gross,
Uladzislau Rezki (Sony), Will Deacon, Geert Uytterhoeven
In-Reply-To: <7ad8bdf9-5eff-4443-ad15-c05355d793d1@app.fastmail.com>
On Thu, Mar 26, 2026 at 10:13 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> I have an older patch to drop CONFIG_NO_DMA entirely, which
> may be better here, since we know that nobody cares about the
> empty stubs.
In case it helps / for future reference: the patch I sent to Marek is
already in mainline: commit 2cdaff22ed26 ("dma-mapping: add missing
`inline` for `dma_free_attrs`").
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Krzysztof Kozlowski @ 2026-03-27 8:06 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260324-belligerent-armadillo-of-camouflage-e52f7b@quoll>
On 24/03/2026 10:30, Krzysztof Kozlowski wrote:
> On Mon, Mar 23, 2026 at 07:08:08PM +0530, Gopi Krishna Menon wrote:
>> +properties:
>> + compatible:
>> + const: st,thermal-spear1340
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + st,thermal-flags:
>> + description: flags used to enable thermal sensor
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - st,thermal-flags
>> +
>> +unevaluatedProperties: false
>
> additionalProperties: true
Thanks for pinging me on IRC about this - it should be:
additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Hongxing Zhu @ 2026-03-27 8:12 UTC (permalink / raw)
To: Frank Li
Cc: l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, robh@kernel.org,
bhelgaas@google.com, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <abwFVpxrriV7Bt2L@lizhi-Precision-Tower-5810>
> -----Original Message-----
> From: Frank Li <frank.li@nxp.com>
> Sent: 2026年3月19日 22:17
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: l.stach@pengutronix.de; lpieralisi@kernel.org; kwilczynski@kernel.org;
> mani@kernel.org; robh@kernel.org; bhelgaas@google.com;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> i.MX7D/i.MX8M
>
> On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > The MSI trigger mechanism for endpoint devices connected to i.MX7D,
> > i.MX8MM, and i.MX8MQ PCIe root complex ports depends on the MSI
> > capability register settings in the root complex. Removing the MSI
> > capability breaks MSI functionality for these endpoints.
> >
> > Preserve the MSI capability for i.MX7D/i.MX8M PCIe root complex to
> > maintain MSI functionality.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: f5cd8a929c825 ("PCI: dwc: Remove MSI/MSIX capability for Root
> > Port if iMSI-RX is used as MSI controller")
>
> I think it'd better add another varible to check in f5cd8a929c825 if
> (pp->has_msi_ctrl && !pp->xxx_broken) or direct use IP version, which
> already auto detected.
>
> Previous patch have not consider this old version controller.
Hi Frank:
From what I've observed, this behavior seems tied to the specific controller
design. For example, neither the i.MX6Q nor the i.MX6SX exhibit this issue.
The intention of commit f5cd8a929c825 is to remove the MSI capability from the
Root Complex (RC). From the author's perspective, this change should not
affect the Endpoint's (EP) MSI functionality.
I'm not sure do this check (pp->has_msi_ctrl && !pp->msi_broken) is proper or not.
Best Regards
Richard Zhu
>
> Frank
>
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > v2 changes:
> > CC stable tree.
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 20dafd2710a3..0b0d6a210406 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -41,6 +41,7 @@
> > #define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> > #define IMX8MQ_GPR_PCIE_VREG_BYPASS BIT(12)
> > #define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPE GENMASK(11, 8)
> > +#define IMX8MM_PCIE_MSI_CAP_OFFSET 0x50
> >
> > #define IMX95_PCIE_PHY_GEN_CTRL 0x0
> > #define IMX95_PCIE_REF_USE_PAD BIT(17)
> > @@ -117,6 +118,7 @@ enum imx_pcie_variants {
> > #define IMX_PCIE_FLAG_HAS_LUT BIT(10)
> > #define IMX_PCIE_FLAG_8GT_ECN_ERR051586 BIT(11)
> > #define IMX_PCIE_FLAG_SKIP_L23_READY BIT(12)
> > +#define IMX_PCIE_FLAG_KEEP_MSI_CAP BIT(13)
> >
> > #define imx_check_flag(pci, val) (pci->drvdata->flags & val)
> >
> > @@ -976,10 +978,17 @@ static int imx_pcie_start_link(struct dw_pcie
> > *pci) {
> > struct imx_pcie *imx_pcie = to_imx_pcie(pci);
> > struct device *dev = pci->dev;
> > - u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> > + u8 offset;
> > u32 tmp;
> > int ret;
> >
> > + if (imx_pcie->drvdata->flags & IMX_PCIE_FLAG_KEEP_MSI_CAP) {
> > + offset = dw_pcie_find_capability(pci, PCI_CAP_ID_PM);
> > + dw_pcie_dbi_ro_wr_en(pci);
> > + dw_pcie_writeb_dbi(pci, offset + 1,
> IMX8MM_PCIE_MSI_CAP_OFFSET);
> > + dw_pcie_dbi_ro_wr_dis(pci);
> > + }
> > +
> > if (!(imx_pcie->drvdata->flags &
> > IMX_PCIE_FLAG_SPEED_CHANGE_WORKAROUND)) {
> > imx_pcie_ltssm_enable(dev);
> > @@ -991,6 +1000,7 @@ static int imx_pcie_start_link(struct dw_pcie *pci)
> > * started in Gen2 mode, there is a possibility the devices on the
> > * bus will not be detected at all. This happens with PCIe switches.
> > */
> > + offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> > dw_pcie_dbi_ro_wr_en(pci);
> > tmp = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCAP);
> > tmp &= ~PCI_EXP_LNKCAP_SLS;
> > @@ -1897,6 +1907,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> > [IMX7D] = {
> > .variant = IMX7D,
> > .flags = IMX_PCIE_FLAG_SUPPORTS_SUSPEND |
> > + IMX_PCIE_FLAG_KEEP_MSI_CAP |
> > IMX_PCIE_FLAG_HAS_APP_RESET |
> > IMX_PCIE_FLAG_SKIP_L23_READY |
> > IMX_PCIE_FLAG_HAS_PHY_RESET,
> > @@ -1909,6 +1920,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> > [IMX8MQ] = {
> > .variant = IMX8MQ,
> > .flags = IMX_PCIE_FLAG_HAS_APP_RESET |
> > + IMX_PCIE_FLAG_KEEP_MSI_CAP |
> > IMX_PCIE_FLAG_HAS_PHY_RESET |
> > IMX_PCIE_FLAG_SUPPORTS_SUSPEND,
> > .gpr = "fsl,imx8mq-iomuxc-gpr",
> > @@ -1923,6 +1935,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
> > [IMX8MM] = {
> > .variant = IMX8MM,
> > .flags = IMX_PCIE_FLAG_SUPPORTS_SUSPEND |
> > + IMX_PCIE_FLAG_KEEP_MSI_CAP |
> > IMX_PCIE_FLAG_HAS_PHYDRV |
> > IMX_PCIE_FLAG_HAS_APP_RESET,
> > .gpr = "fsl,imx8mm-iomuxc-gpr",
> > --
> > 2.37.1
> >
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Marek Szyprowski @ 2026-03-27 8:16 UTC (permalink / raw)
To: Arnd Bergmann, Miguel Ojeda, Robin Murphy, Danilo Krummrich,
Abdiel Janulgue, Daniel Almeida, Andreas Hindborg,
Christoph Hellwig
Cc: iommu, driver-core, acourbot, Andrew Morton, Alice Ryhl,
Anton Ivanov, Björn Roy Baron, Boqun Feng, David Gow,
Gary Guo, Johannes Berg, Justin Stitt, linux-arm-kernel,
linux-kbuild, linux-kernel, linux-mm, linux-um, Russell King,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
Will Deacon, Geert Uytterhoeven
In-Reply-To: <7ad8bdf9-5eff-4443-ad15-c05355d793d1@app.fastmail.com>
On 26.03.2026 22:12, Arnd Bergmann wrote:
> On Sun, Mar 22, 2026, at 20:46, Miguel Ojeda wrote:
>> On Sun, 22 Mar 2026 20:21:59 +0100 Miguel Ojeda <ojeda@kernel.org> wrote:
>> BINDGEN rust/bindings/bindings_generated.rs - due to target
>> missing
>> In file included from rust/helpers/helpers.c:59:
>> rust/helpers/dma.c:17:2: warning: static function 'dma_free_attrs'
>> is used in an inline function with external linkage [-Wstatic-in-inline]
>> 17 | dma_free_attrs(dev, size, cpu_addr, dma_handle,
>> attrs);
>> | ^
>> rust/helpers/dma.c:12:1: note: use 'static' to give inline function
>> 'rust_helper_dma_free_attrs' internal linkage
>> 12 | __rust_helper void rust_helper_dma_free_attrs(struct device
>> *dev, size_t size,
>> | ^
>> | static
>>
>> For some reason, `dma_free_attrs` is not marked `inline` in
>> `include/linux/dma-mapping.h` to begin with, unlike the rest.
>>
>> Unless I am missing something and there is a reason for that, it looks
>> like it has just been missing since it was added in commit ed6ccf10f24b
>> ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA").
>>
>> Do you want a patch?
> I have an older patch to drop CONFIG_NO_DMA entirely, which
> may be better here, since we know that nobody cares about the
> empty stubs.
The inline fix is already merged to v7.0-rc, but I'm fine with stubs
removal and I can queue them to -next. Could You send a proper patch
separately so I can easily apply it?
> The only targets that 'select NO_DMA' today are m68k (sun3
> and dragonball), sh2 and um, which are some of the targets
> that don't have any DMA masters, but there is little downside
> of enabling the DMA mapping interfaces on those as well.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 11835eb59d94..19fb556357fc 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -38,7 +38,6 @@ config M68K
> select MMU_GATHER_NO_RANGE if MMU
> select MODULES_USE_ELF_REL
> select MODULES_USE_ELF_RELA
> - select NO_DMA if !MMU && !COLDFIRE
> select OLD_SIGACTION
> select OLD_SIGSUSPEND3
> select UACCESS_MEMCPY if !MMU
> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> index c9a7e602d8a4..adc50396b87d 100644
> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -38,7 +38,6 @@ config SUN3
> depends on MMU
> select HAVE_ARCH_PFN_VALID
> select LEGACY_TIMER_TICK
> - select NO_DMA
> select M68020
> help
> This option enables support for the Sun 3 series of workstations
> @@ -558,4 +557,4 @@ config COLDFIRE_COHERENT_DMA
> config M68K_NONCOHERENT_DMA
> bool
> default y
> - depends on HAS_DMA && !COLDFIRE_COHERENT_DMA
> + depends on HAS_DMA && !COLDFIRE_COHERENT_DMA && !SUN3
> diff --git a/arch/m68k/include/asm/pgtable_mm.h b/arch/m68k/include/asm/pgtable_mm.h
> index 7501ff030c63..d095ae6c19f9 100644
> --- a/arch/m68k/include/asm/pgtable_mm.h
> +++ b/arch/m68k/include/asm/pgtable_mm.h
> @@ -159,8 +159,10 @@ static inline void update_mmu_cache_range(struct vm_fault *vmf,
> ? (__pgprot((pgprot_val(prot) & _CACHEMASK040) | _PAGE_NOCACHE_S)) \
> : (prot)))
>
> +#ifndef CONFIG_SUN3
> pgprot_t pgprot_dmacoherent(pgprot_t prot);
> #define pgprot_dmacoherent(prot) pgprot_dmacoherent(prot)
> +#endif
>
> #endif /* CONFIG_COLDFIRE */
> #endif /* !__ASSEMBLER__ */
> diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
> index 16063783aa80..c52584e024af 100644
> --- a/arch/m68k/kernel/dma.c
> +++ b/arch/m68k/kernel/dma.c
> @@ -8,7 +8,7 @@
> #include <linux/kernel.h>
> #include <asm/cacheflush.h>
>
> -#ifndef CONFIG_COLDFIRE
> +#if !defined(CONFIG_COLDFIRE) && !defined(CONFIG_SUN3)
> void arch_dma_prep_coherent(struct page *page, size_t size)
> {
> cache_push(page_to_phys(page), size);
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index d5795067befa..e246f295ec48 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -63,7 +63,6 @@ config SUPERH
> select LOCK_MM_AND_FIND_VMA
> select MODULES_USE_ELF_RELA
> select NEED_SG_DMA_LENGTH
> - select NO_DMA if !MMU && !DMA_COHERENT
> select NO_GENERIC_PCI_IOPORT_MAP if PCI
> select OLD_SIGACTION
> select OLD_SIGSUSPEND
> @@ -133,10 +132,10 @@ config SWAP_IO_SPACE
> bool
>
> config DMA_COHERENT
> - bool
> + def_bool !MMU
>
> config DMA_NONCOHERENT
> - def_bool !NO_DMA && !DMA_COHERENT
> + def_bool !DMA_COHERENT
> select ARCH_HAS_DMA_PREP_COHERENT
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> select DMA_DIRECT_REMAP
> diff --git a/arch/um/Kconfig b/arch/um/Kconfig
> index 098cda44db22..dd3428a49614 100644
> --- a/arch/um/Kconfig
> +++ b/arch/um/Kconfig
> @@ -25,7 +25,6 @@ config UML
> select HAVE_DEBUG_KMEMLEAK
> select HAVE_DEBUG_BUGVERBOSE
> select HAVE_PAGE_SIZE_4KB
> - select NO_DMA if !UML_DMA_EMULATION
> select OF_EARLY_FLATTREE if OF
> select GENERIC_IRQ_SHOW
> select GENERIC_CPU_DEVICES
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 677c51ab7510..a96a22f857f1 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -138,7 +138,6 @@ static inline void debug_dma_map_single(struct device *dev, const void *addr,
> }
> #endif /* CONFIG_DMA_API_DEBUG */
>
> -#ifdef CONFIG_HAS_DMA
> static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
> {
> debug_dma_mapping_error(dev, dma_addr);
> @@ -200,146 +199,6 @@ void *dma_vmap_noncontiguous(struct device *dev, size_t size,
> void dma_vunmap_noncontiguous(struct device *dev, void *vaddr);
> int dma_mmap_noncontiguous(struct device *dev, struct vm_area_struct *vma,
> size_t size, struct sg_table *sgt);
> -#else /* CONFIG_HAS_DMA */
> -static inline dma_addr_t dma_map_page_attrs(struct device *dev,
> - struct page *page, size_t offset, size_t size,
> - enum dma_data_direction dir, unsigned long attrs)
> -{
> - return DMA_MAPPING_ERROR;
> -}
> -static inline void dma_unmap_page_attrs(struct device *dev, dma_addr_t addr,
> - size_t size, enum dma_data_direction dir, unsigned long attrs)
> -{
> -}
> -static inline dma_addr_t dma_map_phys(struct device *dev, phys_addr_t phys,
> - size_t size, enum dma_data_direction dir, unsigned long attrs)
> -{
> - return DMA_MAPPING_ERROR;
> -}
> -static inline void dma_unmap_phys(struct device *dev, dma_addr_t addr,
> - size_t size, enum dma_data_direction dir, unsigned long attrs)
> -{
> -}
> -static inline unsigned int dma_map_sg_attrs(struct device *dev,
> - struct scatterlist *sg, int nents, enum dma_data_direction dir,
> - unsigned long attrs)
> -{
> - return 0;
> -}
> -static inline void dma_unmap_sg_attrs(struct device *dev,
> - struct scatterlist *sg, int nents, enum dma_data_direction dir,
> - unsigned long attrs)
> -{
> -}
> -static inline int dma_map_sgtable(struct device *dev, struct sg_table *sgt,
> - enum dma_data_direction dir, unsigned long attrs)
> -{
> - return -EOPNOTSUPP;
> -}
> -static inline dma_addr_t dma_map_resource(struct device *dev,
> - phys_addr_t phys_addr, size_t size, enum dma_data_direction dir,
> - unsigned long attrs)
> -{
> - return DMA_MAPPING_ERROR;
> -}
> -static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
> - size_t size, enum dma_data_direction dir, unsigned long attrs)
> -{
> -}
> -static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
> -{
> - return -ENOMEM;
> -}
> -static inline void *dma_alloc_attrs(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t flag, unsigned long attrs)
> -{
> - return NULL;
> -}
> -static inline void dma_free_attrs(struct device *dev, size_t size,
> - void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> -{
> -}
> -static inline void *dmam_alloc_attrs(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> -{
> - return NULL;
> -}
> -static inline void dmam_free_coherent(struct device *dev, size_t size,
> - void *vaddr, dma_addr_t dma_handle)
> -{
> -}
> -static inline int dma_get_sgtable_attrs(struct device *dev,
> - struct sg_table *sgt, void *cpu_addr, dma_addr_t dma_addr,
> - size_t size, unsigned long attrs)
> -{
> - return -ENXIO;
> -}
> -static inline int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
> - void *cpu_addr, dma_addr_t dma_addr, size_t size,
> - unsigned long attrs)
> -{
> - return -ENXIO;
> -}
> -static inline bool dma_can_mmap(struct device *dev)
> -{
> - return false;
> -}
> -static inline bool dma_pci_p2pdma_supported(struct device *dev)
> -{
> - return false;
> -}
> -static inline int dma_set_mask(struct device *dev, u64 mask)
> -{
> - return -EIO;
> -}
> -static inline int dma_set_coherent_mask(struct device *dev, u64 mask)
> -{
> - return -EIO;
> -}
> -static inline u64 dma_get_required_mask(struct device *dev)
> -{
> - return 0;
> -}
> -static inline bool dma_addressing_limited(struct device *dev)
> -{
> - return false;
> -}
> -static inline size_t dma_max_mapping_size(struct device *dev)
> -{
> - return 0;
> -}
> -static inline size_t dma_opt_mapping_size(struct device *dev)
> -{
> - return 0;
> -}
> -static inline unsigned long dma_get_merge_boundary(struct device *dev)
> -{
> - return 0;
> -}
> -static inline struct sg_table *dma_alloc_noncontiguous(struct device *dev,
> - size_t size, enum dma_data_direction dir, gfp_t gfp,
> - unsigned long attrs)
> -{
> - return NULL;
> -}
> -static inline void dma_free_noncontiguous(struct device *dev, size_t size,
> - struct sg_table *sgt, enum dma_data_direction dir)
> -{
> -}
> -static inline void *dma_vmap_noncontiguous(struct device *dev, size_t size,
> - struct sg_table *sgt)
> -{
> - return NULL;
> -}
> -static inline void dma_vunmap_noncontiguous(struct device *dev, void *vaddr)
> -{
> -}
> -static inline int dma_mmap_noncontiguous(struct device *dev,
> - struct vm_area_struct *vma, size_t size, struct sg_table *sgt)
> -{
> - return -EINVAL;
> -}
> -#endif /* CONFIG_HAS_DMA */
>
> #ifdef CONFIG_IOMMU_DMA
> /**
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 0748091339f7..228a3566d344 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -1,12 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -config NO_DMA
> - bool
> -
> config HAS_DMA
> - bool
> - depends on !NO_DMA
> - default y
> + def_bool y
>
> config DMA_OPS_HELPERS
> bool
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: amlogic: Add new bindings for S6 S7 S7D
From: Krzysztof Kozlowski @ 2026-03-27 8:25 UTC (permalink / raw)
To: Xianwei Zhao
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-pwm, devicetree,
linux-kernel, linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <20260326-s6-s7-pwm-v1-1-67e2f72b98bc@amlogic.com>
On Thu, Mar 26, 2026 at 06:35:38AM +0000, Xianwei Zhao wrote:
> + - items:
> + - enum:
> + - amlogic,s6-pwm
> + - amlogic,s7d-pwm
> + - const: amlogic,s7-pwm
> - items:
> - enum:
> - amlogic,meson8b-pwm-v2
> @@ -146,6 +152,20 @@ allOf:
> clock-names: false
> required:
> - clocks
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - amlogic,s7-pwm
> + then:
> + properties:
> + clocks:
> + items:
> + - description: input clock of PWM
so simpler: "maxItems: 1"
> + clock-names: false
> + required:
> + - clocks
>
> - if:
> properties:
> @@ -182,3 +202,10 @@ examples:
> clocks = <&pwm_src_a>, <&pwm_src_b>;
> #pwm-cells = <3>;
> };
> + - |
> + pwm@1000 {
> + compatible = "amlogic,s7-pwm";
You already have three examples, don't add more.
With these changes:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox