* [PATCH 1/3] drm: lcdif: Set undocumented bit to clear FIFO at vsync
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
In-Reply-To: <20260330224619.2620782-1-paulk@sys-base.io>
There is an undocumented bit used in the NXP BSP to clear the FIFO
systematically at vsync. In normal operation, the FIFO should already
be empty but it doesn't hurt to add it as an extra safety measure.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
drivers/gpu/drm/mxsfb/lcdif_kms.c | 3 ++-
drivers/gpu/drm/mxsfb/lcdif_regs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index ef3250a5c54f..a00c4f6d63f4 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -338,7 +338,8 @@ static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
* Downstream set it to 256B burst size to improve the memory
* efficiency so set it here too.
*/
- ctrl = CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
+ ctrl = CTRLDESCL0_3_STATE_CLEAR_VSYNC |
+ CTRLDESCL0_3_P_SIZE(2) | CTRLDESCL0_3_T_SIZE(2) |
CTRLDESCL0_3_PITCH(lcdif->crtc.primary->state->fb->pitches[0]);
writel(ctrl, lcdif->base + LCDC_V8_CTRLDESCL0_3);
}
diff --git a/drivers/gpu/drm/mxsfb/lcdif_regs.h b/drivers/gpu/drm/mxsfb/lcdif_regs.h
index c55dfb236c1d..17882c593d27 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_regs.h
+++ b/drivers/gpu/drm/mxsfb/lcdif_regs.h
@@ -190,6 +190,7 @@
#define CTRLDESCL0_1_WIDTH(n) ((n) & 0xffff)
#define CTRLDESCL0_1_WIDTH_MASK GENMASK(15, 0)
+#define CTRLDESCL0_3_STATE_CLEAR_VSYNC BIT(23)
#define CTRLDESCL0_3_P_SIZE(n) (((n) << 20) & CTRLDESCL0_3_P_SIZE_MASK)
#define CTRLDESCL0_3_P_SIZE_MASK GENMASK(22, 20)
#define CTRLDESCL0_3_T_SIZE(n) (((n) << 16) & CTRLDESCL0_3_T_SIZE_MASK)
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] drm: lcdif: FIFO underrun/solid color bug fix
From: Paul Kocialkowski @ 2026-03-30 22:46 UTC (permalink / raw)
To: dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch, Liu Ying, Paul Kocialkowski
This series brings a fix for the FIFO underrun/solid color bug (in the
last commit) and two other changes that may help with reliability.
Paul Kocialkowski (3):
drm: lcdif: Set undocumented bit to clear FIFO at vsync
drm: lcdif: Use dedicated set/clr registers for polarity/edge
drm: lcdif: Wait for vblank before disabling DMA
drivers/gpu/drm/mxsfb/lcdif_kms.c | 42 ++++++++++++++++++++++++------
drivers/gpu/drm/mxsfb/lcdif_regs.h | 1 +
2 files changed, 35 insertions(+), 8 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH] spi: stm32-ospi: Fix resource leak in remove() callback
From: Mark Brown @ 2026-03-30 12:22 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Patrice Chotard, Felix Gu
Cc: linux-spi, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260329-ospi-v1-1-cc8cf1c82c4a@gmail.com>
On Sun, 29 Mar 2026 19:14:05 +0800, Felix Gu wrote:
> spi: stm32-ospi: Fix resource leak in remove() callback
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.0
Thanks!
[1/1] spi: stm32-ospi: Fix resource leak in remove() callback
https://git.kernel.org/broonie/sound/c/73cd1f97946a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2 0/2] regulator: mt6315: add regulator supplies
From: Mark Brown @ 2026-03-30 14:45 UTC (permalink / raw)
To: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Chen-Yu Tsai
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260326081050.1115201-1-wenst@chromium.org>
On Thu, 26 Mar 2026 16:10:47 +0800, Chen-Yu Tsai wrote:
> regulator: mt6315: add regulator supplies
>
> Hi,
>
> This is v2 of the "Add MT6315 regulator supplies" series.
>
> Changes since v1:
> - Link to v1: https://lore.kernel.org/all/20260324053030.4077453-1-wenst@chromium.org/
> - Move supplies to top level node, at the same level as the compatible
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[1/2] regulator: dt-bindings: mt6315: Add regulator supplies
https://git.kernel.org/broonie/regulator/c/d15d0f1a27b2
[2/2] regulator: mt6315: Add regulator supplies
https://git.kernel.org/broonie/regulator/c/292d64fb98a2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2 5/7] phy: ti: gmii-sel: add support for J722S SoC family
From: Vladimir Oltean @ 2026-03-30 22:37 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <5d00697f133cd33a1df62ac7ebf73e507e49ed2f.1774354734.git.nora.schiffer@ew.tq-group.com>
Hi Nora,
On Tue, Mar 24, 2026 at 01:29:41PM +0100, Nora Schiffer wrote:
> The J722S gmii-sel is mostly identical to the AM64's, but additionally
> supports SGMII.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> drivers/phy/ti/phy-gmii-sel.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
> index 6213c2b6005a5..4e242b1892334 100644
> --- a/drivers/phy/ti/phy-gmii-sel.c
> +++ b/drivers/phy/ti/phy-gmii-sel.c
> @@ -251,6 +251,13 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
> .regfields = phy_gmii_sel_fields_am654,
> };
>
> +static const
> +struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
> + .use_of_data = true,
> + .regfields = phy_gmii_sel_fields_am654,
> + .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
I'm not familiar with the hardware, but "mostly identical to AM64, but
additionally supports SGMII" does not explain why j722s does not inherit
the features that am654 has (PHY_GMII_SEL_RGMII_ID_MODE and
BIT(PHY_GMII_SEL_FIXED_TX_DELAY).
The phy-gmii-sel from j722s does support RGMII, right? Because in lack
of the PHY_GMII_SEL_RGMII_ID_MODE feature, phy_gmii_sel_mode() will just
silently skip the regmap_field_write(regfield, rgmii_id) call, and
return successfully despite an incomplete configuration.
We have the phy_validate() call and phy_ops::validate() through which
the PHY can report to the Ethernet controller which phy_interface_t it
supports and which it doesn't. If the j722s doesn't support RGMII, maybe
it should implement this method.
> +};
> +
^ permalink raw reply
* [PATCH] arm64: dts: imx8mp-phyboard-pollux: Add HDMI support
From: Paul Kocialkowski @ 2026-03-30 22:37 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel, linux-kernel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Paul Kocialkowski
The PHYTEC phyBOARD Pollux comes with a HDMI port on the base board.
Add the required device-tree nodes to enable support for it.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
.../freescale/imx8mp-phyboard-pollux-rdk.dts | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
index 0fe52c73fc8f..0d52f29813f1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-phyboard-pollux-rdk.dts
@@ -38,6 +38,18 @@ fan0: fan {
#cooling-cells = <2>;
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
panel_lvds1: panel-lvds1 {
/* compatible panel in overlay */
backlight = <&backlight_lvds1>;
@@ -201,6 +213,28 @@ &flexcan2 {
status = "okay";
};
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
&i2c2 {
clock-frequency = <400000>;
pinctrl-names = "default", "gpio";
@@ -244,6 +278,10 @@ &i2c3 {
scl-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
};
+&lcdif3 {
+ status = "okay";
+};
+
&ldb_lvds_ch1 {
remote-endpoint = <&panel1_in>;
};
@@ -444,6 +482,15 @@ MX8MP_IOMUXC_SAI5_RXD0__GPIO3_IO21 0x154
>;
};
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c3
+ MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c3
+ MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x19
+ MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x19
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RESEND v4 4/4] drm/rockchip: dw_hdmi_qp: Do not send HPD events for all connectors
From: Cristian Ciocaltea @ 2026-03-30 22:24 UTC (permalink / raw)
To: Heiko Stuebner, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sandy Huang, Andy Yan
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
Diederik de Haas, Maud Spierings
In-Reply-To: <47972235.fMDQidcC6G@phil>
On 3/30/26 7:56 PM, Heiko Stuebner wrote:
> Am Montag, 23. März 2026, 18:45:30 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> In order to optimize the HPD event handling and run the detect cycle on
>> the affected connector only, make use of
>> drm_connector_helper_hpd_irq_event() instead of
>> drm_helper_hpd_irq_event().
>>
>> Additionally, move devm_request_threaded_irq() after bridge connector
>> initialization.
>
> nit: Using "and", "additionally", etc in commit messages, is a strong
> indicator, things should be separate commits.
>
> Especially as the sentence above just explains the "what" but not the
> why (interrupt firing, before the device is actually there probably).
>
> If there are no other changes requested, they can stay together though,
> the "why" is somewhat obvious here.
Ack, will split this up in case a new revision is needed.
>
>
> Both changes themself look fine, so
>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Thanks for the review!
Regards,
Cristian
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: amlogic: Add new bindings for S6 S7 S7D
From: Martin Blumenstingl @ 2026-03-30 21:58 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, 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 7:35 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Junyi Zhao <junyi.zhao@amlogic.com>
>
> Amlogic S7/S7D/S6 different from the previous SoCs, a controller
> includes one pwm, at the same time, the controller has only one
> input clock source.
>
> Signed-off-by: Junyi Zhao <junyi.zhao@amlogic.com>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
With the two suggestions from Krzysztof added:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH 0/2] Add PWM support Amlogic S7 S7D S6
From: Martin Blumenstingl @ 2026-03-30 21:54 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, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <20260326-s6-s7-pwm-v1-0-67e2f72b98bc@amlogic.com>
Hi Xianwei Zhao,
thanks for your contribution!
On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> Add bindings and driver support Amlogic S7/S7D/S6 SoCs.
There is an old report that got lost, stating that the current
pwm-meson driver has an off-by-one error with the hi and lo fields:
[0]
Since you are working on bringing up a new platform: is this something
you can verify in your lab?
To be clear: I'm not expecting you to work on this ad-hoc or bring a
patch into this series. However, it would be great if you could verify
if the findings from [0] are correct and send an updated patch in
future.
Thank you and best regards
Martin
[0] https://lore.kernel.org/all/20241225105639.1787237-3-gnstark@salutedevices.com/
^ permalink raw reply
* Re: [PATCH] soc: brcmstb: consolidate initcall functions
From: Florian Fainelli @ 2026-03-30 21:54 UTC (permalink / raw)
To: bcm-kernel-feedback-list, justin.chen, linux-arm-kernel
Cc: Florian Fainelli, kees, florian.fainelli
In-Reply-To: <20260325174619.3761964-1-justin.chen@broadcom.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Wed, 25 Mar 2026 10:46:19 -0700, justin.chen@broadcom.com wrote:
> From: Justin Chen <justin.chen@broadcom.com>
>
> Merge the separate early_initcall and arch_initcall functions into a
> single early_initcall. This is possible thanks to commit 6e12db376b60
> ("base: soc: Allow early registration of a single SoC device"), which
> allows soc_device_register() to be called during early_initcall by
> deferring the actual registration until the soc_bus is ready.
>
> Replace static family_id/product_id variables with a dynamically
> allocated brcmstb_soc_info structure.
>
> Signed-off-by: Justin Chen <justin.chen@broadcom.com>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/drivers/next, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH] ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4
From: Kevin Hilman @ 2026-03-30 21:53 UTC (permalink / raw)
To: tony, Julian Braha
Cc: daniel.lezcano, linux, arnd, linux-kernel, linux-omap,
linux-arm-kernel, Thomas Gleixner
In-Reply-To: <20260329183018.519560-1-julianbraha@gmail.com>
On Sun, 29 Mar 2026 19:30:18 +0100, Julian Braha wrote:
> The same kconfig 'select OMAP_INTERCONNECT' appears twice for ARCH_OMAP4.
> I propose removing the second instance, as it is effectively dead code.
>
> This dead code was found by kconfirm, a static analysis tool for Kconfig.
Applied, thanks!
[1/1] ARM: omap2: dead code cleanup in kconfig for ARCH_OMAP4
commit: 9ceb17ccd15ea32f19c9066f5f1b340d8340bd0b
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH] ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX
From: Kevin Hilman @ 2026-03-30 21:53 UTC (permalink / raw)
To: Janusz Krzysztofik, Tony Lindgren, linux-omap, Aaro Koskinen
Cc: linux-arm-kernel, linux-kernel
In-Reply-To: <aca7HnXZ-aCSJPW7@darkstar.musicnaut.iki.fi>
On Fri, 27 Mar 2026 19:15:10 +0200, Aaro Koskinen wrote:
> On OMAP16XX, the UART enable bit shifts are written instead of the actual
> bits. This breaks the boot when DEBUG_LL and earlyprintk is enabled;
> the UART gets disabled and some random bits get enabled. Fix that.
Applied, thanks!
[1/1] ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX
commit: 7e74b606dd39c46d4378d6f6563f560a00ab8694
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Martin Blumenstingl @ 2026-03-30 21:47 UTC (permalink / raw)
To: Ronald Claveau
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
linux-amlogic, devicetree, linux-kernel, kernel test robot,
Krzysztof Kozlowski
In-Reply-To: <20260330-fix-invalid-property-v2-1-228c51c8de93@aliel.fr>
On Mon, Mar 30, 2026 at 2:15 PM Ronald Claveau
<linux-kernel-dev@aliel.fr> wrote:
>
> Fix introduced invalid property for Khadas VIM4 sdcard regulator.
>
> arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603290828.5gt393t6-lkp@intel.com/
> Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators")
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Dmitry Torokhov @ 2026-03-30 21:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <acrcDTPpXZ_5A4D8@ashevche-desk.local>
On Mon, Mar 30, 2026 at 11:24:45PM +0300, Andy Shevchenko wrote:
> On Mon, Mar 30, 2026 at 02:40:47PM +0200, Bartosz Golaszewski wrote:
> > Software nodes are currently initialized in a function registered as
> > a postcore_initcall(). However, some devices may want to register
> > software nodes earlier than that (or also in a postcore_initcall() where
> > they're at the merci of the link order). Move the initialization to
> > driver_init() making swnode available much earlier as well as making
> > their initialization time deterministic.
>
> ...
>
> > -static void __exit software_node_exit(void)
> > -{
> > - ida_destroy(&swnode_root_ids);
> > - kset_unregister(swnode_kset);
> > }
> > -__exitcall(software_node_exit);
>
>
> Why? What's wrong with the __exitcall?
>
It's dead code. Always was, always will be.
Maybe split in a separate patch, but I sometimes feel the idea of "one
change" is taken to extreme and adds to both developer's and maintainers
burden by needing to keep track of extra patches.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] pwm: meson: Add support for Amlogic S7
From: Martin Blumenstingl @ 2026-03-30 21:44 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, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic
In-Reply-To: <20260326-s6-s7-pwm-v1-2-67e2f72b98bc@amlogic.com>
Hi Xianwei Zhao,
On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Add support for Amlogic S7 PWM. Amlogic S7 different from the
> previous SoCs, a controller includes one pwm, at the same time,
> the controller has only one input clock source.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> drivers/pwm/pwm-meson.c | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> index 8c6bf3d49753..3d16694e254e 100644
> --- a/drivers/pwm/pwm-meson.c
> +++ b/drivers/pwm/pwm-meson.c
> @@ -113,6 +113,7 @@ struct meson_pwm_data {
> int (*channels_init)(struct pwm_chip *chip);
> bool has_constant;
> bool has_polarity;
> + bool single_pwm;
At first I wasn't sure about this and thought we should replace it
with a num_pwms (or similar) variable.
However, I think it will be hard to add a third (or even more)
channels to the PWM controller (not just from driver perspective but
also from hardware perspective). So I think this is good enough as the
choice will only be 1 or 2.
[...]
> +static const struct meson_pwm_data pwm_s7_data = {
> + .channels_init = meson_pwm_init_channels_s7,
I think you can use .channels_init = meson_pwm_init_channels_s4, if
you change the code inside that function from:
for (i = 0; i < MESON_NUM_PWMS; i++) {
to:
for (i = 0; i < chip->npwm; i++) {
[...]
> @@ -650,9 +674,13 @@ static int meson_pwm_probe(struct platform_device *pdev)
> {
> struct pwm_chip *chip;
> struct meson_pwm *meson;
> + const struct meson_pwm_data *pdata = of_device_get_match_data(&pdev->dev);
> int err;
>
> - chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
> + if (pdata->single_pwm)
> + chip = devm_pwmchip_alloc(&pdev->dev, 1, sizeof(*meson));
> + else
> + chip = devm_pwmchip_alloc(&pdev->dev, MESON_NUM_PWMS, sizeof(*meson));
I don't think this code is too bad for now.
However, I'm wondering if you want to make "channels" from struct
meson_pwm a flexible array member in a future patch. In that case it
will be helpful to have an "unsigned int npwm = pdata->single_pwm ? 1
: MESON_NUM_PWMS;" (or similar) variable to future-proof your code.
What do you think?
Best regards,
Martin
^ permalink raw reply
* [PATCHv3] ARM: omap2: simplify allocation for omap_device
From: Rosen Penev @ 2026-03-30 21:35 UTC (permalink / raw)
To: linux-omap
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM SUB-ARCHITECTURES, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Use a flexible array member (FAM) to combine hwmods array allocation
with the omap_device structure. This reduces the number of allocations
from two separate calls (one for the device, one for the array) to a
single allocation, improving efficiency and reducing memory fragmentation.
The FAM approach also enables bounds checking through __counted_by(),
which provides runtime verification that array accesses stay within
the allocated size. This improves security and helps catch bugs during
development.
Simplify error handling by removing the unnecessary multi-label goto
pattern. The new code is more straightforward: allocate, verify, copy
data, and either return success or error immediately.
Also removes the now-redundant kfree(od->hwmods) in omap_device_delete()
since the hwmods array is now embedded in the structure rather than
separately allocated.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v3: add a verbose description explaining why. Powered by Claude Sonnet
4.5.
v2: remove kfree and fix compilation.
arch/arm/mach-omap2/omap_device.c | 29 ++++++++++-------------------
arch/arm/mach-omap2/omap_device.h | 4 ++--
2 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 79db4c49ffc9..77a75b0b9ae6 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -307,35 +307,27 @@ static struct omap_device *omap_device_alloc(struct platform_device *pdev,
int ret = -ENOMEM;
struct omap_device *od;
int i;
- struct omap_hwmod **hwmods;
+ struct omap_hwmod *hwmod;
- od = kzalloc_obj(struct omap_device);
- if (!od)
- goto oda_exit1;
+ od = kzalloc_flex(*od, hwmods, oh_cnt);
+ if (!od) {
+ dev_err(&pdev->dev, "omap_device: build failed (%d)\n", ret);
+ return ERR_PTR(ret);
+ }
od->hwmods_cnt = oh_cnt;
+ memcpy(od->hwmods, ohs, oh_cnt * sizeof(*od->hwmods));
- hwmods = kmemdup_array(ohs, oh_cnt, sizeof(*hwmods), GFP_KERNEL);
- if (!hwmods)
- goto oda_exit2;
-
- od->hwmods = hwmods;
od->pdev = pdev;
pdev->archdata.od = od;
for (i = 0; i < oh_cnt; i++) {
- hwmods[i]->od = od;
- _add_hwmod_clocks_clkdev(od, hwmods[i]);
+ hwmod = od->hwmods[i];
+ hwmod->od = od;
+ _add_hwmod_clocks_clkdev(od, hwmod);
}
return od;
-
-oda_exit2:
- kfree(od);
-oda_exit1:
- dev_err(&pdev->dev, "omap_device: build failed (%d)\n", ret);
-
- return ERR_PTR(ret);
}
static void omap_device_delete(struct omap_device *od)
@@ -344,7 +336,6 @@ static void omap_device_delete(struct omap_device *od)
return;
od->pdev->archdata.od = NULL;
- kfree(od->hwmods);
kfree(od);
}
diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h
index aa8096ecb23c..fae09cfce137 100644
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -37,11 +37,11 @@
/**
* struct omap_device - omap_device wrapper for platform_devices
* @pdev: platform_device
- * @hwmods: (one .. many per omap_device)
* @hwmods_cnt: ARRAY_SIZE() of @hwmods
* @_state: one of OMAP_DEVICE_STATE_* (see above)
* @flags: device flags
* @_driver_status: one of BUS_NOTIFY_*_DRIVER from <linux/device.h>
+ * @hwmods: (one .. many per omap_device)
*
* Integrates omap_hwmod data into Linux platform_device.
*
@@ -51,11 +51,11 @@
*/
struct omap_device {
struct platform_device *pdev;
- struct omap_hwmod **hwmods;
unsigned long _driver_status;
u8 hwmods_cnt;
u8 _state;
u8 flags;
+ struct omap_hwmod *hwmods[] __counted_by(hwmods_cnt);
};
/* Device driver interface (call via platform_data fn ptrs) */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
From: Martin Blumenstingl @ 2026-03-30 21:25 UTC (permalink / raw)
To: Jun Yan
Cc: linux-kernel, linux-amlogic, linux-arm-kernel, devicetree, robh,
krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet
In-Reply-To: <20260330145111.115318-1-jerrysteve1101@gmail.com>
On Mon, Mar 30, 2026 at 4:53 PM Jun Yan <jerrysteve1101@gmail.com> wrote:
>
> Correct the interrupt number assigned to the Realtek PHY in the p230
>
> following the same logic as commit 3106507e1004 ("ARM64: dts: meson-gxm:
> fix q200 interrupt number"),as reported in [PATCH 0/2] Ethernet PHY
> interrupt improvements [1].
>
> [1] https://lore.kernel.org/all/20171202214037.17017-1-martin.blumenstingl@googlemail.com/
>
> Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms")
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Thank you! I don't have a matching device to verify this myself.
However, it's in line with commit 3106507e1004d ("ARM64: dts:
meson-gxm: fix q200 interrupt number") as IRQ 29 is GPIOZ_15 on GXBB
(but no longer on GXL/GXM). So this gets my:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCHv2] ARM: omap2: simplify allocation for omap_device
From: Kevin Hilman @ 2026-03-30 21:20 UTC (permalink / raw)
To: Rosen Penev, linux-omap
Cc: Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Russell King, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM SUB-ARCHITECTURES, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260327191104.206512-1-rosenp@gmail.com>
Rosen Penev <rosenp@gmail.com> writes:
> Use a flexible array member to combine allocations.
>
> Add __counted_by for extra runtime analysis.
>
> Remove goto paths as they are not really needed anymore.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Could you please add a bit more explanation about the *why* behind this
patch. Your description tells us *what* you are doing, but is a bit
light on the *why*.
Thanks,
Kevin
^ permalink raw reply
* Re: i.MX8MP: Fix HDMI LCDIF FIFO underruns
From: Paul Kocialkowski @ 2026-03-30 21:16 UTC (permalink / raw)
To: Lucas Stach
Cc: Krzysztof Hałasa, Liu Ying, Maxime Ripard, Marco Felsch,
Marek Vasut, Stefan Agner, Simona Vetter, imx, Fabio Estevam,
Pengutronix Kernel Team, Maarten Lankhorst, Sascha Hauer,
Frank Li, linux-kernel, dri-devel, Thomas Zimmermann,
David Airlie, linux-arm-kernel
In-Reply-To: <0e8863b39cc9cab3ef16aedde480c70a158c4cbe.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 5322 bytes --]
Hi Lucas,
On Mon 30 Mar 26, 18:44, Lucas Stach wrote:
> Am Montag, dem 30.03.2026 um 18:09 +0200 schrieb Paul Kocialkowski:
> > After weeks of investigation I finally narrowed it down to a part of the nxp
> > original code that is missing in the upstream driver:
> > https://github.com/phytec/linux-phytec-imx/blob/v6.6.23-2.0.0-phy/drivers/gpu/imx/lcdifv3/lcdifv3-common.c#L492
> >
> Thanks for tracking this down! It was also on my list of things to look
> at.
Glad that it helps :)
> > A big old sleep that waits for the DMA engine to finish handling the current
> > frame before it is disabled. When this delay is not respected, there seems to
> > be "unlucky" times when disabling the DMA engine too early will confuse the
> > unit and make it unable to resume proper operation later.
> >
> I think we can be a bit more clever than a indiscriminate sleep. If we
> set the shadow load enable bit in the disable sequence, we should be
> able to wait for this bit to be cleared by the hardware. All the DMA
> parameters (presumably including the enable state) should be applied by
> the hardware when this bit is cleared.
I just tried it out and it works fine, thanks! It polls for a variable delay
from < 1 ms to < 16 ms, which makes perfect sense for a 60 Hz mode.
This is much better than the hardcoded 25 ms. I'll add your Co-developed-by tag
to the final commit.
> I guess the read_poll_timeout in lcdif_disable_controller() was
> supposed to do exactly that wait, but as it was actually copied from
> the mxsfb driver, it's not working as intended. It's my understanding
> that the old lcdif HW only cleared the enable bit once it is actually
> done, but on the lcdifv3 on i.MX8MP those states are double buffered,
> so the bit in the register would be cleared instantaneously, rendering
> the wait in the current code a no-op. The only reliable indicator to
> see if the HW has updated it's internal state is to set the shadow load
> enable bit and wait for it to be cleared.
Sounds right to me. Thanks for the details! Are there resources about the
different generations/families used by nxp/freescale? They seem to be in-house
designs but with lots of different variations.
> > It is a bit surprising that the issue is not actually related to configuring
> > the display engine but to disabling it. This is why the first mode set always
> > works but subsequentil ones might fail. The crtc is essentially disabled and
> > re-enabled each time a new mode is applied.
> >
> > Adding the sleep solves the issue on my side and all mode sets now work
> > reliably. It does add a delay before returning to userspace when configuring
> > a new mode, but it seems legitimate to me if the underlying hardware is still
> > in-flight. I'm also unsure if it would apply to an async atomic commit.
> >
> This hardware doesn't support async commits. All DMA state changes are
> applied during vblank when the shadow load enable bit is set.
Ah sorry I meant non-blocking atomic commit, not async. Since this is in the
CRTC disable path, it probably makes the userspace process sleep even in the
case of a non-blocking commit (unless this happens in a kernel thread, I'm not
sure exactly). But I guess it is legitimate to block until the previous frame
is finished if it is mandatory.
All the best,
Paul
>
> Regards,
> Lucas
>
> > I will send a patch adding the delay and the undocumented fifo clear
> > bit that was discovered in this thread too.
> >
> > All the best,
> >
> > Paul
> >
> > Perhaps there is a more elegant way to handle this
> >
> >
> > > Interestingly, Weston usually starts fine in subsequent launches.
> > >
> > > How is this first (actually second - after the first VSYNC) frame
> > > different from all the others? Maybe we're programming UPDATE_SHADOW
> > > after the actual start of blanking period, but before DE, so it has no
> > > chance to reload registers, yet the DMA is somehow not ready?
> > >
> > > The manual (LCDIF display control Register (CTRL)) suggests that the DMA
> > > (with present settings) starts to fetch FB data at the end of the
> > > previous active video pixel time (DE and pixel data going inactive):
> > > fetch_start_option (bits 9-8): Indicates when to start fetching for new
> > > frame. This signals also decide the shadow load, fifo clear time
> > > 00b - fetch start as soon as FPV begins(as the end of the data_enable).
> > >
> > > This should leave a lot of time to fill the FIFO (before the next DE),
> > > shouldn't it?
> > >
> > > 297 MHz pixclk, 3840x2160, 30 Hz, H back porch 296 pixclks, Vfp 176,
> > > V back porch 72 lines, Hfp 8 lines, VSYNC 10 lines, HSYNC 88 pixclks.
> > > HTotal = 4400 pixels which makes Vactive time = 4400 * 2160/297e6 =
> > > 32 ms, with the remaining 1.3333 ms for all the V sync stuff.
> > > --
> > > Krzysztof "Chris" Hałasa
> > >
> > > Sieć Badawcza Łukasiewicz
> > > Przemysłowy Instytut Automatyki i Pomiarów PIAP
> > > Al. Jerozolimskie 202, 02-486 Warszawa
> >
>
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] dmaengine: st_fdma: simplify allocation
From: Rosen Penev @ 2026-03-30 21:15 UTC (permalink / raw)
To: dmaengine
Cc: Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Use a flexible array member to combine kzalloc and kcalloc to a single
allocation.
Add __counted_by for extra runtime analysis. Assign counting variable
after allocation as required by __counted_by.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/dma/st_fdma.c | 27 ++++++++-------------------
drivers/dma/st_fdma.h | 4 ++--
2 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index d9547017f3bd..3ec0d6731b8d 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -710,16 +710,6 @@ static const struct of_device_id st_fdma_match[] = {
};
MODULE_DEVICE_TABLE(of, st_fdma_match);
-static int st_fdma_parse_dt(struct platform_device *pdev,
- const struct st_fdma_driverdata *drvdata,
- struct st_fdma_dev *fdev)
-{
- snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
- drvdata->name, drvdata->id);
-
- return of_property_read_u32(pdev->dev.of_node, "dma-channels",
- &fdev->nr_channels);
-}
#define FDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
@@ -742,27 +732,26 @@ static int st_fdma_probe(struct platform_device *pdev)
struct st_fdma_dev *fdev;
struct device_node *np = pdev->dev.of_node;
const struct st_fdma_driverdata *drvdata;
+ u32 nr_channels;
int ret, i;
drvdata = device_get_match_data(&pdev->dev);
- fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
- if (!fdev)
- return -ENOMEM;
-
- ret = st_fdma_parse_dt(pdev, drvdata, fdev);
+ ret = of_property_read_u32(pdev->dev.of_node, "dma-channels", &nr_channels);
if (ret) {
dev_err(&pdev->dev, "unable to find platform data\n");
- goto err;
+ return ret;
}
- fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
- sizeof(struct st_fdma_chan), GFP_KERNEL);
- if (!fdev->chans)
+ fdev = devm_kzalloc(&pdev->dev, struct_size(fdev, chans, nr_channels), GFP_KERNEL);
+ if (!fdev)
return -ENOMEM;
+ fdev->nr_channels = nr_channels;
fdev->dev = &pdev->dev;
fdev->drvdata = drvdata;
+ snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf", drvdata->name, drvdata->id);
+
platform_set_drvdata(pdev, fdev);
fdev->irq = platform_get_irq(pdev, 0);
diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
index f1e746f7bc7d..27ded555879f 100644
--- a/drivers/dma/st_fdma.h
+++ b/drivers/dma/st_fdma.h
@@ -136,13 +136,13 @@ struct st_fdma_dev {
int irq;
- struct st_fdma_chan *chans;
-
spinlock_t dreq_lock;
unsigned long dreq_mask;
u32 nr_channels;
char fw_name[FW_NAME_SIZE];
+
+ struct st_fdma_chan chans[] __counted_by(nr_channels);
};
/* Peripheral Registers*/
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] ARM: dts: ti: Enable overlays for am335x BeagleBoard devicetrees
From: Kevin Hilman @ 2026-03-30 21:14 UTC (permalink / raw)
To: Kory Maincent
Cc: Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Russell King,
Thomas Petazzoni, linux-omap, devicetree, linux-kernel,
linux-arm-kernel, dri-devel, Luca Ceresoli, Bajjuri Praneeth,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Louis Chauvet
In-Reply-To: <20260324103934.7d259008@kmaincent-XPS-13-7390>
Kory Maincent <kory.maincent@bootlin.com> writes:
> Hello Kevin,
>
> On Thu, 05 Mar 2026 17:07:23 -0800
> Kevin Hilman <khilman@baylibre.com> wrote:
>
>> On Mon, 16 Feb 2026 17:55:52 +0100, Kory Maincent (TI) wrote:
>> > Allow overlays to be applied to am335x BeagleBoard boards. This adds
>> > around ~40% to the total size of the DTB files on average.
>> >
>> >
>>
>> Applied, thanks!
>>
>> [1/3] ARM: dts: ti: Enable overlays for am335x BeagleBoard devicetrees
>> commit: 18161bb01ede109fed41c66efa2624a4c27377f7
>>
>> Best regards,
>
> Thanks for merging it.
> I see that you have merged patch 1 and 2 in your for-next branch.
> Is there a reason to not merge the patch 3? Are you waiting for a dts
> maintainer ack?
>
> Maybe I can resend only the 3rd patch to ping the dts maintainers.
Not necessary. I'm not sure how/why I missed patch 3. It's now queued
in my tree.
Thanks for letting me know,
Kevin
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Christian Schrefl @ 2026-03-30 21:09 UTC (permalink / raw)
To: Miguel Ojeda, Russell King (Oracle), Alice Ryhl
Cc: Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, a.hindborg, acourbot, akpm, anton.ivanov, bjorn3_gh,
boqun.feng, dakr, david, gary, johannes, justinstitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, lossin, mark.rutland, mmaurer, morbo, nathan,
nick.desaulniers+lkml, nicolas.schier, nsc, peterz, richard,
rust-for-linux, tmgross, urezki
In-Reply-To: <CANiq72=b+cr7Stxph_hXQTmD5crCvwWTqdaGKOJ7W1-66v4i_w@mail.gmail.com>
On 3/26/26 6:30 PM, Miguel Ojeda wrote:
> On Thu, Mar 26, 2026 at 4:18 PM Russell King (Oracle)
> <linux@armlinux.org.uk> 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.
>>
>> Certianly, when Arm Ltd were proposing EABI, EABI had the latter
>> behaviour, and I think there were cases where Linux used "enum" in
>> its UAPI.
>
> Short enums? I see `c-enum-min-bits` in the armv7a-none-eabi built-in
> `rustc` target, and indeed:
>
> #![no_std]
>
> #[repr(C)]
> enum T {
> A,
> B,
> }
>
> pub static S: usize = core::mem::size_of::<T>();
>
> is 1 for that one, and 4 for the other.
I guess we could use a custom target spec, but I'm not
sure if that is worth the hassle of adding another one.
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH v2 3/8] tools build: Deduplicate test-libunwind for different architectures
From: Arnaldo Carvalho de Melo @ 2026-03-30 21:08 UTC (permalink / raw)
To: Ian Rogers
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260305221927.3237145-4-irogers@google.com>
On Thu, Mar 05, 2026 at 02:19:22PM -0800, Ian Rogers wrote:
> The separate test files only exist to pass a different #include,
> instead have a single source file and pass -include to $(CC) to
> include the relevant header file for the architecture being
> tested. Generate the rules using a foreach loop. Include tests for all
> current libunwind architectures.
Clever :-)
- Arnaldo
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/build/feature/Makefile | 38 +++++++++----------
> tools/build/feature/test-libunwind-aarch64.c | 27 -------------
> tools/build/feature/test-libunwind-arm.c | 28 --------------
> .../test-libunwind-debug-frame-aarch64.c | 17 ---------
> .../feature/test-libunwind-debug-frame-arm.c | 17 ---------
> .../feature/test-libunwind-debug-frame.c | 1 -
> tools/build/feature/test-libunwind-x86.c | 28 --------------
> tools/build/feature/test-libunwind-x86_64.c | 28 --------------
> tools/build/feature/test-libunwind.c | 1 -
> 9 files changed, 19 insertions(+), 166 deletions(-)
> delete mode 100644 tools/build/feature/test-libunwind-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-x86.c
> delete mode 100644 tools/build/feature/test-libunwind-x86_64.c
>
> diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
> index 1fbcb3ce74d2..a0b40e826688 100644
> --- a/tools/build/feature/Makefile
> +++ b/tools/build/feature/Makefile
> @@ -204,27 +204,27 @@ $(OUTPUT)test-numa_num_possible_cpus.bin:
> $(BUILD) -lnuma
>
> $(OUTPUT)test-libunwind.bin:
> - $(BUILD) -lelf -llzma
> + $(BUILD) -include libunwind.h -lelf -llzma -lunwind
>
> $(OUTPUT)test-libunwind-debug-frame.bin:
> - $(BUILD) -lelf -llzma
> -$(OUTPUT)test-libunwind-x86.bin:
> - $(BUILD) -lelf -llzma -lunwind-x86
> -
> -$(OUTPUT)test-libunwind-x86_64.bin:
> - $(BUILD) -lelf -llzma -lunwind-x86_64
> -
> -$(OUTPUT)test-libunwind-arm.bin:
> - $(BUILD) -lelf -llzma -lunwind-arm
> -
> -$(OUTPUT)test-libunwind-aarch64.bin:
> - $(BUILD) -lelf -llzma -lunwind-aarch64
> -
> -$(OUTPUT)test-libunwind-debug-frame-arm.bin:
> - $(BUILD) -lelf -llzma -lunwind-arm
> -
> -$(OUTPUT)test-libunwind-debug-frame-aarch64.bin:
> - $(BUILD) -lelf -llzma -lunwind-aarch64
> + $(BUILD) -include libunwind.h -lelf -llzma -lunwind
> +
> +LIBUNWIND_ARCHS:=aarch64 arm loongarch64 mips ppc32 ppc64 riscv s390x x86 x86_64
> +define LIBUNWIND_RULE
> +$$(OUTPUT)test-libunwind-$(1).bin:
> + $$(CC) $$(CFLAGS) -MD -Wall -Werror -include libunwind-$(1).h -o $$@ \
> + test-libunwind.c $$(LDFLAGS) -lelf -llzma -lunwind-$(1) \
> + > $$(@:.bin=.make.output) 2>&1
> +
> +$$(OUTPUT)test-libunwind-debug-frame-$(1).bin:
> + $$(CC) $$(CFLAGS) -MD -Wall -Werror -include libunwind-$(1).h -o $$@ \
> + test-libunwind-debug-frame.c $$(LDFLAGS) -lelf -llzma -lunwind-$(1) \
> + > $$(@:.bin=.make.output) 2>&1
> +
> +endef
> +$(foreach arch,$(LIBUNWIND_ARCHS), \
> + $(eval $(call LIBUNWIND_RULE,$(arch))) \
> +)
>
> $(OUTPUT)test-libslang.bin:
> $(BUILD) -lslang
> diff --git a/tools/build/feature/test-libunwind-aarch64.c b/tools/build/feature/test-libunwind-aarch64.c
> deleted file mode 100644
> index 323803f49212..000000000000
> --- a/tools/build/feature/test-libunwind-aarch64.c
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-aarch64.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-arm.c b/tools/build/feature/test-libunwind-arm.c
> deleted file mode 100644
> index cb378b7d6866..000000000000
> --- a/tools/build/feature/test-libunwind-arm.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-arm.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-debug-frame-aarch64.c b/tools/build/feature/test-libunwind-debug-frame-aarch64.c
> deleted file mode 100644
> index 36d6646c185e..000000000000
> --- a/tools/build/feature/test-libunwind-debug-frame-aarch64.c
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-aarch64.h>
> -#include <stdlib.h>
> -
> -extern int
> -UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
> - unw_word_t ip, unw_word_t segbase,
> - const char *obj_name, unw_word_t start,
> - unw_word_t end);
> -
> -#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
> -
> -int main(void)
> -{
> - dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-debug-frame-arm.c b/tools/build/feature/test-libunwind-debug-frame-arm.c
> deleted file mode 100644
> index 8696e48e1268..000000000000
> --- a/tools/build/feature/test-libunwind-debug-frame-arm.c
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-arm.h>
> -#include <stdlib.h>
> -
> -extern int
> -UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
> - unw_word_t ip, unw_word_t segbase,
> - const char *obj_name, unw_word_t start,
> - unw_word_t end);
> -
> -#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
> -
> -int main(void)
> -{
> - dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-debug-frame.c b/tools/build/feature/test-libunwind-debug-frame.c
> index efb55cdd8d01..4c57e37004b3 100644
> --- a/tools/build/feature/test-libunwind-debug-frame.c
> +++ b/tools/build/feature/test-libunwind-debug-frame.c
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include <libunwind.h>
> #include <stdlib.h>
>
> extern int
> diff --git a/tools/build/feature/test-libunwind-x86.c b/tools/build/feature/test-libunwind-x86.c
> deleted file mode 100644
> index e5e0f6c89637..000000000000
> --- a/tools/build/feature/test-libunwind-x86.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-x86.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind-x86_64.c b/tools/build/feature/test-libunwind-x86_64.c
> deleted file mode 100644
> index 62ae4db597dc..000000000000
> --- a/tools/build/feature/test-libunwind-x86_64.c
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include <libunwind-x86_64.h>
> -#include <stdlib.h>
> -
> -extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> - unw_word_t ip,
> - unw_dyn_info_t *di,
> - unw_proc_info_t *pi,
> - int need_unwind_info, void *arg);
> -
> -
> -#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)
> -
> -static unw_accessors_t accessors;
> -
> -int main(void)
> -{
> - unw_addr_space_t addr_space;
> -
> - addr_space = unw_create_addr_space(&accessors, 0);
> - if (addr_space)
> - return 0;
> -
> - unw_init_remote(NULL, addr_space, NULL);
> - dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
> -
> - return 0;
> -}
> diff --git a/tools/build/feature/test-libunwind.c b/tools/build/feature/test-libunwind.c
> index 53fd26614ff0..5af5dc3a73d4 100644
> --- a/tools/build/feature/test-libunwind.c
> +++ b/tools/build/feature/test-libunwind.c
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include <libunwind.h>
> #include <stdlib.h>
>
> extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
> --
> 2.53.0.473.g4a7958ca14-goog
>
^ permalink raw reply
* Re: [PATCH v2 2/8] perf build loongarch: Remove reference to missing file
From: Arnaldo Carvalho de Melo @ 2026-03-30 21:05 UTC (permalink / raw)
To: Ian Rogers
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260305221927.3237145-3-irogers@google.com>
On Thu, Mar 05, 2026 at 02:19:21PM -0800, Ian Rogers wrote:
> The file was removed in commit e62fae9d9e85 ("perf unwind-libdw: Fix a
> cross-arch unwinding bug") but the Build file not updated.
>
> Fixes: commit e62fae9d9e85 ("perf unwind-libdw: Fix a cross-arch unwinding bug")
Removing the 'commit' part.
- Arnaldo
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/arch/loongarch/util/Build | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/perf/arch/loongarch/util/Build b/tools/perf/arch/loongarch/util/Build
> index 3ad73d0289f3..8d91e78d31c9 100644
> --- a/tools/perf/arch/loongarch/util/Build
> +++ b/tools/perf/arch/loongarch/util/Build
> @@ -1,4 +1,3 @@
> perf-util-y += header.o
>
> perf-util-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
> -perf-util-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
> --
> 2.53.0.473.g4a7958ca14-goog
^ permalink raw reply
* Re: [PATCH v13 10/48] arm64: RMI: Ensure that the RMM has GPT entries for memory
From: Mathieu Poirier @ 2026-03-30 20:58 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Aneesh Kumar K . V,
Emi Kisanuki, Vishal Annapurve
In-Reply-To: <20260318155413.793430-11-steven.price@arm.com>
Hi,
On Wed, Mar 18, 2026 at 03:53:34PM +0000, Steven Price wrote:
> The RMM may not be tracking all the memory of the system at boot. Create
> the necessary tracking state and GPTs within the RMM so that all boot
> memory can be delegated to the RMM as needed during runtime.
>
> Note: support is currently missing for SROs which means that if the RMM
> needs memory donating this will fail (and render CCA unusable in Linux).
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> New patch for v13
> ---
> arch/arm64/kvm/rmi.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 9590dff9a2c1..80aedc85e94a 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -4,6 +4,7 @@
> */
>
> #include <linux/kvm_host.h>
> +#include <linux/memblock.h>
>
> #include <asm/kvm_pgtable.h>
> #include <asm/rmi_cmds.h>
> @@ -56,6 +57,18 @@ static int rmi_check_version(void)
> return 0;
> }
>
> +/*
> + * These are the 'default' sizes when passing 0 as the tracking_region_size.
> + * TODO: Support other granule sizes
> + */
> +#ifdef CONFIG_PAGE_SIZE_4KB
> +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
> +#elif defined(CONFIG_PAGE_SIZE_16KB)
> +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
> +#elif defined(CONFIG_PAGE_SIZE_64KB)
> +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
> +#endif
> +
> static int rmi_configure(void)
> {
> struct rmm_config *config __free(free_page) = NULL;
> @@ -95,6 +108,80 @@ static int rmi_configure(void)
> return 0;
> }
>
> +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
> +{
> + start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
This will produce an error on systems where the start of system memory is not
aligned to RMM_GRANULE_TRACKING_SIZE. For instance, on QEMU-SBSA the system
memory starts at 0x100_4300_0000. With the above and RMM_GRANULE_TRACKING_SIZE
set to SZ_1G, @start becomes 0x100_4000_0000, which falls outside the memory map
known to the TF-A. I fixed it with these modifications:
LINUX:
diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
index 10ff1c3bddaf..21bfbbe2f047 100644
--- a/arch/arm64/kvm/rmi.c
+++ b/arch/arm64/kvm/rmi.c
@@ -424,7 +424,9 @@ static int rmi_configure(void)
static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
{
- start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
+ phys_addr_t offset;
+
+ offset = start - ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
while (start < end) {
@@ -439,7 +441,13 @@ static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
start);
return -ENODEV;
}
- start += RMM_GRANULE_TRACKING_SIZE;
+
+ if (offset) {
+ start += (RMM_GRANULE_TRACKING_SIZE - offset);
+ offset = 0;
+ } else {
+ start += RMM_GRANULE_TRACKING_SIZE;
+ }
}
return 0;
RMM:
diff --git a/runtime/rmi/granule.c b/runtime/rmi/granule.c
index cef521fc0869..60358d9ee81e 100644
--- a/runtime/rmi/granule.c
+++ b/runtime/rmi/granule.c
@@ -209,9 +209,11 @@ void smc_granule_tracking_get(unsigned long addr,
return;
}
+#if 0
if (!ALIGNED(addr, RMM_INTERNAL_TRACKING_REGION_SIZE)) {
return;
}
+#endif
g = find_granule(addr);
if (g != NULL) {
This is likely not the right fix but hopefully provides some guidance. Send me
your patches when you have an idea and I'll test them.
Thanks,
Mathieu
> + end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
> +
> + while (start < end) {
> + unsigned long ret, category, state;
> +
> + ret = rmi_granule_tracking_get(start, &category, &state);
> + if (ret != RMI_SUCCESS ||
> + state != RMI_TRACKING_FINE ||
> + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
> + /* TODO: Set granule tracking in this case */
> + kvm_err("Granule tracking for region isn't fine/conventional: %llx",
> + start);
> + return -ENODEV;
> + }
> + start += RMM_GRANULE_TRACKING_SIZE;
> + }
> +
> + return 0;
> +}
> +
> +static unsigned long rmi_l0gpt_size(void)
> +{
> + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
> + rmm_feat_reg1));
> +}
> +
> +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
> +{
> + unsigned long l0gpt_sz = rmi_l0gpt_size();
> +
> + start = ALIGN_DOWN(start, l0gpt_sz);
> + end = ALIGN(end, l0gpt_sz);
> +
> + while (start < end) {
> + int ret = rmi_gpt_l1_create(start);
> +
> + if (ret && ret != RMI_ERROR_GPT) {
> + /*
> + * FIXME: Handle SRO so that memory can be donated for
> + * the tables.
> + */
> + kvm_err("GPT Level1 table missing for %llx\n", start);
> + return -ENOMEM;
> + }
> + start += l0gpt_sz;
> + }
> +
> + return 0;
> +}
> +
> +static int rmi_init_metadata(void)
> +{
> + phys_addr_t start, end;
> + const struct memblock_region *r;
> +
> + for_each_mem_region(r) {
> + int ret;
> +
> + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
> + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
> + ret = rmi_verify_memory_tracking(start, end);
> + if (ret)
> + return ret;
> + ret = rmi_create_gpts(start, end);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int rmm_check_features(void)
> {
> if (kvm_lpa2_is_enabled() && !rmi_has_feature(RMI_FEATURE_REGISTER_0_LPA2)) {
> @@ -120,6 +207,8 @@ void kvm_init_rmi(void)
> return;
> if (rmi_configure())
> return;
> + if (rmi_init_metadata())
> + return;
>
> /* Future patch will enable static branch kvm_rmi_is_available */
> }
> --
> 2.43.0
>
>
^ permalink raw reply related
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