* Re: (subset) [PATCH v8 00/10] pmdomain: samsung: add support for Google GS101
From: Ulf Hansson @ 2026-03-31 9:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, André Draszik, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <c4d6b758-474b-409d-b553-fa4ec1df494e@kernel.org>
On Mon, 30 Mar 2026 at 15:38, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 30/03/2026 15:30, Ulf Hansson wrote:
> >
> > Usually we want bindings to go along with their respective drivers on
> > a subsystem basis.
> >
> > Both patch2 and patch4 updates DT bindings for the power-domain providers.
>
> Patch 2 yes. Patch 4 not. That's why I did not take patch 2.
>
> >
> > Why shouldn't the bindings go along with the driver changes here?
>
> Patch #2 is pmdomain, so with pmdomain drivers thus your tree. Patch #4
> is not pmdomain, so not with pmdomain drivers, so not your tree... At
> least I do not see any pmdomain parts in that patch #4. It's a Samsung
> SoC PMU driver and none of further driver patches touch that PMU driver.
Yes, you are right that the PMU driver isn't touched.
Although, the PMU DT description added in patch3 and extended in
patch4, allows power-domain providers to be described in its child
nodes. Those child nodes use the same compatible string as the
power-domain providers described in patch2.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: imx91-var-dart-sonata: add RGB select supply for PCA6408
From: Stefano Radaelli @ 2026-03-31 9:02 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <acqLWgY1_G7e0qOI@lizhi-Precision-Tower-5810>
On Mon, Mar 30, 2026 at 10:40:26AM -0400, Frank Li wrote:
> > Yes, it is exactly the second case!
> > It's just an EN pin, that enables a buffer to route RGB signals used on
> > the DART-MX91 som only.
> > That's why I think regulator is the right way for this case.
>
> Okay, it'd better to emphrase it in commit message because _SEL is miss
> leasing.
>
Thank you Frank,
I'm sending new version with correct commit message.
Best Regards,
Stefano
^ permalink raw reply
* Re: [PATCH 1/3] drm: lcdif: Set undocumented bit to clear FIFO at vsync
From: Lucas Stach @ 2026-03-31 9:07 UTC (permalink / raw)
To: Paul Kocialkowski, 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,
Krzysztof Hałasa, Marco Felsch, Liu Ying
In-Reply-To: <20260330224619.2620782-2-paulk@sys-base.io>
Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> 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>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> 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)
^ permalink raw reply
* Re: [PATCH 2/3] drm: lcdif: Use dedicated set/clr registers for polarity/edge
From: Lucas Stach @ 2026-03-31 9:09 UTC (permalink / raw)
To: Paul Kocialkowski, 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,
Krzysztof Hałasa, Marco Felsch, Liu Ying
In-Reply-To: <20260330224619.2620782-3-paulk@sys-base.io>
Hi Paul,
Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> The lcdif v3 hardware comes with dedicated registers to set and clear
> polarity bits in the CTRL register. It is unclear if there is a
> difference with writing to the CTRL register directly.
>
> Follow the NXP BSP reference by using these registers, in case there is
> a subtle difference caused by using them.
>
I don't really like that patch, as it blows up what is currently a
single register access to three separate ones. If there is no clear
benefit (as in it has been shown to fix any issue), I would prefer this
code to stay as-is.
Regards,
Lucas
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> index a00c4f6d63f4..1aac354041c7 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -296,18 +296,27 @@ static void lcdif_set_formats(struct lcdif_drm_private *lcdif,
> static void lcdif_set_mode(struct lcdif_drm_private *lcdif, u32 bus_flags)
> {
> struct drm_display_mode *m = &lcdif->crtc.state->adjusted_mode;
> - u32 ctrl = 0;
> + u32 ctrl;
>
> if (m->flags & DRM_MODE_FLAG_NHSYNC)
> - ctrl |= CTRL_INV_HS;
> + writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_SET);
> + else
> + writel(CTRL_INV_HS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
> +
> if (m->flags & DRM_MODE_FLAG_NVSYNC)
> - ctrl |= CTRL_INV_VS;
> + writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_SET);
> + else
> + writel(CTRL_INV_VS, lcdif->base + LCDC_V8_CTRL + REG_CLR);
> +
> if (bus_flags & DRM_BUS_FLAG_DE_LOW)
> - ctrl |= CTRL_INV_DE;
> - if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> - ctrl |= CTRL_INV_PXCK;
> + writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_SET);
> + else
> + writel(CTRL_INV_DE, lcdif->base + LCDC_V8_CTRL + REG_CLR);
>
> - writel(ctrl, lcdif->base + LCDC_V8_CTRL);
> + if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> + writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_SET);
> + else
> + writel(CTRL_INV_PXCK, lcdif->base + LCDC_V8_CTRL + REG_CLR);
>
> writel(DISP_SIZE_DELTA_Y(m->vdisplay) |
> DISP_SIZE_DELTA_X(m->hdisplay),
^ permalink raw reply
* [PATCH 0/3] ARM: pxa: attach software nodes to the GPIO controllers
From: Bartosz Golaszewski @ 2026-03-31 9:10 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
I was looking for a use-case where automatic secondary fwnode assignment
would make sense for a DT platform. With the paz00 issue having been
addressed by Dmitry, PXA looked like the last one that could match the
idea but it turned out that we can just easily attach the software nodes
to their controllers enabling fwnode lookup of GPIOs.
After that the only GPIO consumers that still use label lookup with
dangling software nodes are ACPI platform devices and a single PCI
use-case. In that case, I won't be doing anything OF-related and will
limit the x86 tablets series to an ACPI-centric solution.
With that being said: here's a series attaching software nodes to GPIO
controllers on the PXA platform. Since everything happens in a
bord-file, it's quite straightforward.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Bartosz Golaszewski (3):
ARM: pxa: spitz: attach software nodes to their target GPIO controllers
ARM: pxa: pxa25x: attach software node to its target GPIO controller
ARM: pxa: pxa27x: attach software node to its target GPIO controller
arch/arm/mach-pxa/pxa25x.c | 5 ++++-
arch/arm/mach-pxa/pxa27x.c | 5 ++++-
arch/arm/mach-pxa/spitz.c | 7 ++++++-
3 files changed, 14 insertions(+), 3 deletions(-)
---
base-commit: fd74e29ef736c1098bd2ea77e3129b532383bbe7
change-id: 20260330-pxa-gpio-swnodes-132a81af10e3
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/3] ARM: pxa: spitz: attach software nodes to their target GPIO controllers
From: Bartosz Golaszewski @ 2026-03-31 9:10 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260331-pxa-gpio-swnodes-v1-0-f66d86d10d8d@oss.qualcomm.com>
Software nodes describing the GPIO controllers for the spitz platform
are currently "dangling" - they're not actually attached to the relevant
controllers and don't allow real fwnode lookup. Attach them either by
directly assigning them to the struct device or by using the i2c board
info struct.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/spitz.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index c0b1f7e6be87411359b0020257ff12c73bbcbae3..99deb672999c675c25c9d03b0320618f571aa0c5 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -204,11 +204,15 @@ struct platform_device spitz_scoop_2_device = {
static void __init spitz_scoop_init(void)
{
+ spitz_scoop_1_device.dev.fwnode = software_node_fwnode(&spitz_scoop_1_gpiochip_node);
platform_device_register(&spitz_scoop_1_device);
/* Akita doesn't have the second SCOOP chip */
- if (!machine_is_akita())
+ if (!machine_is_akita()) {
+ spitz_scoop_2_device.dev.fwnode = software_node_fwnode(
+ &spitz_scoop_2_gpiochip_node);
platform_device_register(&spitz_scoop_2_device);
+ }
}
/* Power control is shared with between one of the CF slots and SD */
@@ -988,6 +992,7 @@ static struct i2c_board_info spitz_i2c_devs[] = {
.type = "max7310",
.addr = 0x18,
.platform_data = &akita_pca953x_pdata,
+ .swnode = &akita_max7310_gpiochip_node,
},
};
--
2.47.3
^ permalink raw reply related
* [PATCH 3/3] ARM: pxa: pxa27x: attach software node to its target GPIO controller
From: Bartosz Golaszewski @ 2026-03-31 9:10 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260331-pxa-gpio-swnodes-v1-0-f66d86d10d8d@oss.qualcomm.com>
Software node describing the GPIO controller for the pxa27x platforms is
currently "dangling" - it's not actually attached to the relevant
controller and doesn't allow real fwnode lookup. Attach it once it's
registered as a firmware node before adding the platform device.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/pxa27x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index ff63619790383859ba111e3efe7619aa6cbd248e..bacfd50939fd447ffa11d398867dea7fa638988b 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -277,7 +277,6 @@ void __init pxa27x_set_i2c_power_info(struct i2c_pxa_platform_data *info)
}
static struct platform_device *devices[] __initdata = {
- &pxa27x_device_gpio,
&pxa27x_device_udc,
&pxa_device_pmu,
&pxa_device_i2s,
@@ -342,6 +341,10 @@ static int __init pxa27x_init(void)
if (!of_have_populated_dt()) {
software_node_register(&pxa2xx_gpiochip_node);
+ pxa27x_device_gpio.dev.fwnode = software_node_fwnode(
+ &pxa2xx_gpiochip_node);
+ platform_device_register(&pxa27x_device_gpio);
+
pxa2xx_set_dmac_info(&pxa27x_dma_pdata);
ret = platform_add_devices(devices,
ARRAY_SIZE(devices));
--
2.47.3
^ permalink raw reply related
* [PATCH 2/3] ARM: pxa: pxa25x: attach software node to its target GPIO controller
From: Bartosz Golaszewski @ 2026-03-31 9:10 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260331-pxa-gpio-swnodes-v1-0-f66d86d10d8d@oss.qualcomm.com>
Software node describing the GPIO controller for the pxa25x platforms is
currently "dangling" - it's not actually attached to the relevant
controller and doesn't allow real fwnode lookup. Attach it once it's
registered as a firmware node before adding the platform device.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/pxa25x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 70509a5998142ec6b9c484e5f094751eda6db6cd..6875774f2cae1db4798d18c813f445bdc31b15de 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -179,7 +179,6 @@ void __init pxa25x_map_io(void)
}
static struct platform_device *pxa25x_devices[] __initdata = {
- &pxa25x_device_gpio,
&pxa25x_device_udc,
&pxa_device_pmu,
&pxa_device_i2s,
@@ -240,6 +239,10 @@ static int __init pxa25x_init(void)
if (!of_have_populated_dt()) {
software_node_register(&pxa2xx_gpiochip_node);
+ pxa25x_device_gpio.dev.fwnode = software_node_fwnode(
+ &pxa2xx_gpiochip_node);
+ platform_device_register(&pxa25x_device_gpio);
+
pxa2xx_set_dmac_info(&pxa25x_dma_pdata);
ret = platform_add_devices(pxa25x_devices,
ARRAY_SIZE(pxa25x_devices));
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Lucas Stach @ 2026-03-31 9:14 UTC (permalink / raw)
To: Paul Kocialkowski, 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,
Krzysztof Hałasa, Marco Felsch, Liu Ying
In-Reply-To: <20260330224619.2620782-4-paulk@sys-base.io>
Am Dienstag, dem 31.03.2026 um 00:46 +0200 schrieb Paul Kocialkowski:
> It is necessary to wait for the full frame to finish streaming
> through the DMA engine before we can safely disable it by removing
> the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> hardware confused and unable to resume streaming for the next frame.
>
> This causes the FIFO underrun and empty status bits to be set and
> a single solid color to be shown on the display, coming from one of
> the pixels of the previous frame. The issue occurs sporadically when
> a new mode is set, which triggers the crtc disable and enable paths.
>
> Setting the shadow load bit and waiting for it to be cleared by the
> DMA engine allows waiting for completion.
>
> The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
>
> Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> index 1aac354041c7..7dce7f48d938 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
> if (ret)
> drm_err(lcdif->drm, "Failed to disable controller!\n");
>
You can drop this no-op poll above...
> + /*
> + * It is necessary to wait for the full frame to finish streaming
> + * through the DMA engine before we can safely disable it by removing
> + * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> + * hardware confused and unable to resume streaming for the next frame.
> + */
> + reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
> + reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
> + writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
> +
.. then setting the shadow load enable bit can be merged with the
access clearing the DMA enable bit.
> + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> + 0, 36000); /* Wait ~2 frame times max */
I know this is just a copy from the existing poll, but I don't think
the busy looping makes a lot of sense. I guess relaxing the poll by a
100us or even 200us wait between checks wouldn't hurt.
> + if (ret)
> + drm_err(lcdif->drm, "Failed to disable controller!\n");
> +
> reg = readl(lcdif->base + LCDC_V8_DISP_PARA);
> reg &= ~DISP_PARA_DISP_ON;
> writel(reg, lcdif->base + LCDC_V8_DISP_PARA);
^ permalink raw reply
* [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 9:17 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Maxime Coquelin,
Alexandre Torgue, linux-arm-msm, linux-clk, linux-kernel,
linux-stm32, linux-arm-kernel
Cc: Krzysztof Kozlowski
The static 'struct qcom_cc_driver_data' contains probe match-like data
and is not modified: neither by the driver defining it nor by common.c
code using it.
Make it const for code safety and code readability.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/clk/qcom/apss-ipq5424.c | 2 +-
drivers/clk/qcom/cambistmclkcc-kaanapali.c | 2 +-
drivers/clk/qcom/cambistmclkcc-sm8750.c | 2 +-
drivers/clk/qcom/camcc-kaanapali.c | 2 +-
drivers/clk/qcom/camcc-milos.c | 2 +-
drivers/clk/qcom/camcc-qcs615.c | 2 +-
drivers/clk/qcom/camcc-sc8180x.c | 2 +-
drivers/clk/qcom/camcc-sm8450.c | 2 +-
drivers/clk/qcom/camcc-sm8550.c | 2 +-
drivers/clk/qcom/camcc-sm8650.c | 2 +-
drivers/clk/qcom/camcc-sm8750.c | 2 +-
drivers/clk/qcom/camcc-x1e80100.c | 2 +-
drivers/clk/qcom/common.h | 2 +-
drivers/clk/qcom/dispcc-eliza.c | 2 +-
drivers/clk/qcom/dispcc-glymur.c | 2 +-
drivers/clk/qcom/dispcc-kaanapali.c | 2 +-
drivers/clk/qcom/dispcc-milos.c | 2 +-
drivers/clk/qcom/dispcc-qcs615.c | 2 +-
drivers/clk/qcom/gcc-eliza.c | 2 +-
drivers/clk/qcom/gcc-glymur.c | 2 +-
drivers/clk/qcom/gcc-kaanapali.c | 2 +-
drivers/clk/qcom/gcc-milos.c | 2 +-
drivers/clk/qcom/gcc-sc8180x.c | 2 +-
drivers/clk/qcom/gpucc-glymur.c | 2 +-
drivers/clk/qcom/gpucc-kaanapali.c | 2 +-
drivers/clk/qcom/gpucc-milos.c | 2 +-
drivers/clk/qcom/gpucc-qcs615.c | 2 +-
drivers/clk/qcom/videocc-glymur.c | 2 +-
drivers/clk/qcom/videocc-kaanapali.c | 2 +-
drivers/clk/qcom/videocc-milos.c | 2 +-
drivers/clk/qcom/videocc-qcs615.c | 2 +-
drivers/clk/qcom/videocc-sm8450.c | 2 +-
drivers/clk/qcom/videocc-sm8750.c | 2 +-
33 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/clk/qcom/apss-ipq5424.c b/drivers/clk/qcom/apss-ipq5424.c
index 2d622c1fe5d0..1662c83058bc 100644
--- a/drivers/clk/qcom/apss-ipq5424.c
+++ b/drivers/clk/qcom/apss-ipq5424.c
@@ -211,7 +211,7 @@ static struct clk_alpha_pll *ipa5424_apss_plls[] = {
&ipq5424_apss_pll,
};
-static struct qcom_cc_driver_data ipa5424_apss_driver_data = {
+static const struct qcom_cc_driver_data ipa5424_apss_driver_data = {
.alpha_plls = ipa5424_apss_plls,
.num_alpha_plls = ARRAY_SIZE(ipa5424_apss_plls),
};
diff --git a/drivers/clk/qcom/cambistmclkcc-kaanapali.c b/drivers/clk/qcom/cambistmclkcc-kaanapali.c
index 6ad912403b8b..77adb453ab21 100644
--- a/drivers/clk/qcom/cambistmclkcc-kaanapali.c
+++ b/drivers/clk/qcom/cambistmclkcc-kaanapali.c
@@ -395,7 +395,7 @@ static const struct regmap_config cam_bist_mclk_cc_kaanapali_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_bist_mclk_cc_kaanapali_driver_data = {
+static const struct qcom_cc_driver_data cam_bist_mclk_cc_kaanapali_driver_data = {
.alpha_plls = cam_bist_mclk_cc_kaanapali_plls,
.num_alpha_plls = ARRAY_SIZE(cam_bist_mclk_cc_kaanapali_plls),
.clk_cbcrs = cam_bist_mclk_cc_kaanapali_critical_cbcrs,
diff --git a/drivers/clk/qcom/cambistmclkcc-sm8750.c b/drivers/clk/qcom/cambistmclkcc-sm8750.c
index d889a8f6561d..f0d7e3b7c532 100644
--- a/drivers/clk/qcom/cambistmclkcc-sm8750.c
+++ b/drivers/clk/qcom/cambistmclkcc-sm8750.c
@@ -414,7 +414,7 @@ static const struct regmap_config cam_bist_mclk_cc_sm8750_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_bist_mclk_cc_sm8750_driver_data = {
+static const struct qcom_cc_driver_data cam_bist_mclk_cc_sm8750_driver_data = {
.alpha_plls = cam_bist_mclk_cc_sm8750_plls,
.num_alpha_plls = ARRAY_SIZE(cam_bist_mclk_cc_sm8750_plls),
.clk_cbcrs = cam_bist_mclk_cc_sm8750_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-kaanapali.c b/drivers/clk/qcom/camcc-kaanapali.c
index c848ca99e9df..acf5f476955b 100644
--- a/drivers/clk/qcom/camcc-kaanapali.c
+++ b/drivers/clk/qcom/camcc-kaanapali.c
@@ -2615,7 +2615,7 @@ static const struct regmap_config cam_cc_kaanapali_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_kaanapali_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_kaanapali_driver_data = {
.alpha_plls = cam_cc_kaanapali_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_kaanapali_plls),
.clk_cbcrs = cam_cc_kaanapali_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-milos.c b/drivers/clk/qcom/camcc-milos.c
index 0077c9c9249f..556c3c33c106 100644
--- a/drivers/clk/qcom/camcc-milos.c
+++ b/drivers/clk/qcom/camcc-milos.c
@@ -2117,7 +2117,7 @@ static const struct regmap_config cam_cc_milos_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_milos_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_milos_driver_data = {
.alpha_plls = cam_cc_milos_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_milos_plls),
.clk_cbcrs = cam_cc_milos_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-qcs615.c b/drivers/clk/qcom/camcc-qcs615.c
index c063a3bfacd0..8377126c2cfe 100644
--- a/drivers/clk/qcom/camcc-qcs615.c
+++ b/drivers/clk/qcom/camcc-qcs615.c
@@ -1556,7 +1556,7 @@ static const struct regmap_config cam_cc_qcs615_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_qcs615_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_qcs615_driver_data = {
.alpha_plls = cam_cc_qcs615_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_qcs615_plls),
};
diff --git a/drivers/clk/qcom/camcc-sc8180x.c b/drivers/clk/qcom/camcc-sc8180x.c
index 0291e2f3ea80..bd06d271928e 100644
--- a/drivers/clk/qcom/camcc-sc8180x.c
+++ b/drivers/clk/qcom/camcc-sc8180x.c
@@ -2842,7 +2842,7 @@ static const struct regmap_config cam_cc_sc8180x_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_sc8180x_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_sc8180x_driver_data = {
.alpha_plls = cam_cc_sc8180x_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_sc8180x_plls),
.clk_cbcrs = cam_cc_sc8180x_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-sm8450.c b/drivers/clk/qcom/camcc-sm8450.c
index ef8cf54d0eed..430b436a673e 100644
--- a/drivers/clk/qcom/camcc-sm8450.c
+++ b/drivers/clk/qcom/camcc-sm8450.c
@@ -3030,7 +3030,7 @@ static struct gdsc *cam_cc_sm8450_gdscs[] = {
[TITAN_TOP_GDSC] = &titan_top_gdsc,
};
-static struct qcom_cc_driver_data cam_cc_sm8450_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_sm8450_driver_data = {
.alpha_plls = cam_cc_sm8450_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_sm8450_plls),
.clk_cbcrs = cam_cc_sm8450_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-sm8550.c b/drivers/clk/qcom/camcc-sm8550.c
index b8ece8a57a8a..8c42ae7544aa 100644
--- a/drivers/clk/qcom/camcc-sm8550.c
+++ b/drivers/clk/qcom/camcc-sm8550.c
@@ -3530,7 +3530,7 @@ static const struct regmap_config cam_cc_sm8550_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_sm8550_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_sm8550_driver_data = {
.alpha_plls = cam_cc_sm8550_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_sm8550_plls),
.clk_cbcrs = cam_cc_sm8550_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-sm8650.c b/drivers/clk/qcom/camcc-sm8650.c
index 8b388904f56f..c0055fb08f62 100644
--- a/drivers/clk/qcom/camcc-sm8650.c
+++ b/drivers/clk/qcom/camcc-sm8650.c
@@ -3548,7 +3548,7 @@ static const struct regmap_config cam_cc_sm8650_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_sm8650_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_sm8650_driver_data = {
.alpha_plls = cam_cc_sm8650_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_sm8650_plls),
.clk_cbcrs = cam_cc_sm8650_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-sm8750.c b/drivers/clk/qcom/camcc-sm8750.c
index a797b783d4a9..9b6d49981267 100644
--- a/drivers/clk/qcom/camcc-sm8750.c
+++ b/drivers/clk/qcom/camcc-sm8750.c
@@ -2666,7 +2666,7 @@ static const struct regmap_config cam_cc_sm8750_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_sm8750_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_sm8750_driver_data = {
.alpha_plls = cam_cc_sm8750_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_sm8750_plls),
.clk_cbcrs = cam_cc_sm8750_critical_cbcrs,
diff --git a/drivers/clk/qcom/camcc-x1e80100.c b/drivers/clk/qcom/camcc-x1e80100.c
index cbcc1c9fcb34..387420533125 100644
--- a/drivers/clk/qcom/camcc-x1e80100.c
+++ b/drivers/clk/qcom/camcc-x1e80100.c
@@ -2447,7 +2447,7 @@ static const struct regmap_config cam_cc_x1e80100_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data cam_cc_x1e80100_driver_data = {
+static const struct qcom_cc_driver_data cam_cc_x1e80100_driver_data = {
.alpha_plls = cam_cc_x1e80100_plls,
.num_alpha_plls = ARRAY_SIZE(cam_cc_x1e80100_plls),
.clk_cbcrs = cam_cc_x1e80100_critical_cbcrs,
diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
index 953c91f7b145..69c4b21333e5 100644
--- a/drivers/clk/qcom/common.h
+++ b/drivers/clk/qcom/common.h
@@ -49,7 +49,7 @@ struct qcom_cc_desc {
size_t num_icc_hws;
unsigned int icc_first_node_id;
bool use_rpm;
- struct qcom_cc_driver_data *driver_data;
+ const struct qcom_cc_driver_data *driver_data;
};
/**
diff --git a/drivers/clk/qcom/dispcc-eliza.c b/drivers/clk/qcom/dispcc-eliza.c
index 062be01c1b01..60de3c743621 100644
--- a/drivers/clk/qcom/dispcc-eliza.c
+++ b/drivers/clk/qcom/dispcc-eliza.c
@@ -2076,7 +2076,7 @@ static void clk_eliza_regs_configure(struct device *dev, struct regmap *regmap)
regmap_set_bits(regmap, DISP_CC_MISC_CMD, BIT(4));
}
-static struct qcom_cc_driver_data disp_cc_eliza_driver_data = {
+static const struct qcom_cc_driver_data disp_cc_eliza_driver_data = {
.alpha_plls = disp_cc_eliza_plls,
.num_alpha_plls = ARRAY_SIZE(disp_cc_eliza_plls),
.clk_cbcrs = disp_cc_eliza_critical_cbcrs,
diff --git a/drivers/clk/qcom/dispcc-glymur.c b/drivers/clk/qcom/dispcc-glymur.c
index fd085cb90667..aae60291b55e 100644
--- a/drivers/clk/qcom/dispcc-glymur.c
+++ b/drivers/clk/qcom/dispcc-glymur.c
@@ -1934,7 +1934,7 @@ static const struct regmap_config disp_cc_glymur_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data disp_cc_glymur_driver_data = {
+static const struct qcom_cc_driver_data disp_cc_glymur_driver_data = {
.alpha_plls = disp_cc_glymur_plls,
.num_alpha_plls = ARRAY_SIZE(disp_cc_glymur_plls),
.clk_cbcrs = disp_cc_glymur_critical_cbcrs,
diff --git a/drivers/clk/qcom/dispcc-kaanapali.c b/drivers/clk/qcom/dispcc-kaanapali.c
index 5ec4d2ab6b67..ffdb4de3a33e 100644
--- a/drivers/clk/qcom/dispcc-kaanapali.c
+++ b/drivers/clk/qcom/dispcc-kaanapali.c
@@ -1907,7 +1907,7 @@ static void clk_kaanapali_regs_configure(struct device *dev, struct regmap *regm
regmap_update_bits(regmap, DISP_CC_MISC_CMD, BIT(4), BIT(4));
}
-static struct qcom_cc_driver_data disp_cc_kaanapali_driver_data = {
+static const struct qcom_cc_driver_data disp_cc_kaanapali_driver_data = {
.alpha_plls = disp_cc_kaanapali_plls,
.num_alpha_plls = ARRAY_SIZE(disp_cc_kaanapali_plls),
.clk_cbcrs = disp_cc_kaanapali_critical_cbcrs,
diff --git a/drivers/clk/qcom/dispcc-milos.c b/drivers/clk/qcom/dispcc-milos.c
index 0a483fb6683a..17ff10cb2f6b 100644
--- a/drivers/clk/qcom/dispcc-milos.c
+++ b/drivers/clk/qcom/dispcc-milos.c
@@ -926,7 +926,7 @@ static void disp_cc_milos_clk_regs_configure(struct device *dev, struct regmap *
}
-static struct qcom_cc_driver_data disp_cc_milos_driver_data = {
+static const struct qcom_cc_driver_data disp_cc_milos_driver_data = {
.alpha_plls = disp_cc_milos_plls,
.num_alpha_plls = ARRAY_SIZE(disp_cc_milos_plls),
.clk_cbcrs = disp_cc_milos_critical_cbcrs,
diff --git a/drivers/clk/qcom/dispcc-qcs615.c b/drivers/clk/qcom/dispcc-qcs615.c
index 4a6d78466098..21974e2574f5 100644
--- a/drivers/clk/qcom/dispcc-qcs615.c
+++ b/drivers/clk/qcom/dispcc-qcs615.c
@@ -751,7 +751,7 @@ static const struct regmap_config disp_cc_qcs615_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data disp_cc_qcs615_driver_data = {
+static const struct qcom_cc_driver_data disp_cc_qcs615_driver_data = {
.alpha_plls = disp_cc_qcs615_plls,
.num_alpha_plls = ARRAY_SIZE(disp_cc_qcs615_plls),
.clk_cbcrs = disp_cc_qcs615_critical_cbcrs,
diff --git a/drivers/clk/qcom/gcc-eliza.c b/drivers/clk/qcom/gcc-eliza.c
index 06ee1469badd..9356c5bf0a03 100644
--- a/drivers/clk/qcom/gcc-eliza.c
+++ b/drivers/clk/qcom/gcc-eliza.c
@@ -3050,7 +3050,7 @@ static void clk_eliza_regs_configure(struct device *dev, struct regmap *regmap)
qcom_branch_set_force_mem_core(regmap, gcc_ufs_phy_ice_core_clk, true);
}
-static struct qcom_cc_driver_data gcc_eliza_driver_data = {
+static const struct qcom_cc_driver_data gcc_eliza_driver_data = {
.clk_cbcrs = gcc_eliza_critical_cbcrs,
.num_clk_cbcrs = ARRAY_SIZE(gcc_eliza_critical_cbcrs),
.dfs_rcgs = gcc_eliza_dfs_clocks,
diff --git a/drivers/clk/qcom/gcc-glymur.c b/drivers/clk/qcom/gcc-glymur.c
index 1a5d3d182705..7a199e1bd493 100644
--- a/drivers/clk/qcom/gcc-glymur.c
+++ b/drivers/clk/qcom/gcc-glymur.c
@@ -8561,7 +8561,7 @@ static void clk_glymur_regs_configure(struct device *dev, struct regmap *regmap)
qcom_branch_set_force_mem_core(regmap, gcc_ufs_phy_ice_core_clk, true);
}
-static struct qcom_cc_driver_data gcc_glymur_driver_data = {
+static const struct qcom_cc_driver_data gcc_glymur_driver_data = {
.clk_cbcrs = gcc_glymur_critical_cbcrs,
.num_clk_cbcrs = ARRAY_SIZE(gcc_glymur_critical_cbcrs),
.dfs_rcgs = gcc_dfs_clocks,
diff --git a/drivers/clk/qcom/gcc-kaanapali.c b/drivers/clk/qcom/gcc-kaanapali.c
index 210ec7afbb67..44275bac095e 100644
--- a/drivers/clk/qcom/gcc-kaanapali.c
+++ b/drivers/clk/qcom/gcc-kaanapali.c
@@ -3485,7 +3485,7 @@ static void clk_kaanapali_regs_configure(struct device *dev, struct regmap *regm
qcom_branch_set_force_mem_core(regmap, gcc_ufs_phy_ice_core_clk, true);
}
-static struct qcom_cc_driver_data gcc_kaanapali_driver_data = {
+static const struct qcom_cc_driver_data gcc_kaanapali_driver_data = {
.clk_cbcrs = gcc_kaanapali_critical_cbcrs,
.num_clk_cbcrs = ARRAY_SIZE(gcc_kaanapali_critical_cbcrs),
.dfs_rcgs = gcc_dfs_clocks,
diff --git a/drivers/clk/qcom/gcc-milos.c b/drivers/clk/qcom/gcc-milos.c
index 81fa09ec55d7..3438fb9039ee 100644
--- a/drivers/clk/qcom/gcc-milos.c
+++ b/drivers/clk/qcom/gcc-milos.c
@@ -3171,7 +3171,7 @@ static const struct regmap_config gcc_milos_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data gcc_milos_driver_data = {
+static const struct qcom_cc_driver_data gcc_milos_driver_data = {
.clk_cbcrs = gcc_milos_critical_cbcrs,
.num_clk_cbcrs = ARRAY_SIZE(gcc_milos_critical_cbcrs),
.dfs_rcgs = gcc_milos_dfs_clocks,
diff --git a/drivers/clk/qcom/gcc-sc8180x.c b/drivers/clk/qcom/gcc-sc8180x.c
index 88b95d5326d9..35c2e9d555b8 100644
--- a/drivers/clk/qcom/gcc-sc8180x.c
+++ b/drivers/clk/qcom/gcc-sc8180x.c
@@ -4675,7 +4675,7 @@ static void clk_sc8180x_regs_configure(struct device *dev, struct regmap *regmap
regmap_update_bits(regmap, 0x71028, 0x3, 0x3);
}
-static struct qcom_cc_driver_data gcc_sc8180x_driver_data = {
+static const struct qcom_cc_driver_data gcc_sc8180x_driver_data = {
.clk_cbcrs = gcc_sc8180x_critical_cbcrs,
.num_clk_cbcrs = ARRAY_SIZE(gcc_sc8180x_critical_cbcrs),
.dfs_rcgs = gcc_sc8180x_dfs_clocks,
diff --git a/drivers/clk/qcom/gpucc-glymur.c b/drivers/clk/qcom/gpucc-glymur.c
index 1a1d946347d0..824b4e09c3f9 100644
--- a/drivers/clk/qcom/gpucc-glymur.c
+++ b/drivers/clk/qcom/gpucc-glymur.c
@@ -574,7 +574,7 @@ static const struct regmap_config gpu_cc_glymur_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data gpu_cc_glymur_driver_data = {
+static const struct qcom_cc_driver_data gpu_cc_glymur_driver_data = {
.alpha_plls = gpu_cc_glymur_plls,
.num_alpha_plls = ARRAY_SIZE(gpu_cc_glymur_plls),
.clk_cbcrs = gpu_cc_glymur_critical_cbcrs,
diff --git a/drivers/clk/qcom/gpucc-kaanapali.c b/drivers/clk/qcom/gpucc-kaanapali.c
index d93d06067fbf..94f0feb254b3 100644
--- a/drivers/clk/qcom/gpucc-kaanapali.c
+++ b/drivers/clk/qcom/gpucc-kaanapali.c
@@ -437,7 +437,7 @@ static const struct regmap_config gpu_cc_kaanapali_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data gpu_cc_kaanapali_driver_data = {
+static const struct qcom_cc_driver_data gpu_cc_kaanapali_driver_data = {
.alpha_plls = gpu_cc_kaanapali_plls,
.num_alpha_plls = ARRAY_SIZE(gpu_cc_kaanapali_plls),
.clk_cbcrs = gpu_cc_kaanapali_critical_cbcrs,
diff --git a/drivers/clk/qcom/gpucc-milos.c b/drivers/clk/qcom/gpucc-milos.c
index 4ee09879156e..7a8a3917db9b 100644
--- a/drivers/clk/qcom/gpucc-milos.c
+++ b/drivers/clk/qcom/gpucc-milos.c
@@ -518,7 +518,7 @@ static const struct regmap_config gpu_cc_milos_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data gpu_cc_milos_driver_data = {
+static const struct qcom_cc_driver_data gpu_cc_milos_driver_data = {
.alpha_plls = gpu_cc_milos_plls,
.num_alpha_plls = ARRAY_SIZE(gpu_cc_milos_plls),
.clk_cbcrs = gpu_cc_milos_critical_cbcrs,
diff --git a/drivers/clk/qcom/gpucc-qcs615.c b/drivers/clk/qcom/gpucc-qcs615.c
index ec6739c08425..8233136db4d8 100644
--- a/drivers/clk/qcom/gpucc-qcs615.c
+++ b/drivers/clk/qcom/gpucc-qcs615.c
@@ -485,7 +485,7 @@ static void clk_qcs615_regs_crc_configure(struct device *dev, struct regmap *reg
regmap_update_bits(regmap, 0x1024, 0x00800000, 0x00800000);
}
-static struct qcom_cc_driver_data gpu_cc_qcs615_driver_data = {
+static const struct qcom_cc_driver_data gpu_cc_qcs615_driver_data = {
.alpha_plls = gpu_cc_qcs615_plls,
.num_alpha_plls = ARRAY_SIZE(gpu_cc_qcs615_plls),
.clk_cbcrs = gpu_cc_qcs615_critical_cbcrs,
diff --git a/drivers/clk/qcom/videocc-glymur.c b/drivers/clk/qcom/videocc-glymur.c
index ea20605dd1e5..4f1ad0db30e5 100644
--- a/drivers/clk/qcom/videocc-glymur.c
+++ b/drivers/clk/qcom/videocc-glymur.c
@@ -487,7 +487,7 @@ static void clk_glymur_regs_configure(struct device *dev, struct regmap *regmap)
regmap_update_bits(regmap, 0x9f24, BIT(0), BIT(0));
}
-static struct qcom_cc_driver_data video_cc_glymur_driver_data = {
+static const struct qcom_cc_driver_data video_cc_glymur_driver_data = {
.alpha_plls = video_cc_glymur_plls,
.num_alpha_plls = ARRAY_SIZE(video_cc_glymur_plls),
.clk_cbcrs = video_cc_glymur_critical_cbcrs,
diff --git a/drivers/clk/qcom/videocc-kaanapali.c b/drivers/clk/qcom/videocc-kaanapali.c
index 835a59536ba7..b060ee34e8a4 100644
--- a/drivers/clk/qcom/videocc-kaanapali.c
+++ b/drivers/clk/qcom/videocc-kaanapali.c
@@ -776,7 +776,7 @@ static void clk_kaanapali_regs_configure(struct device *dev, struct regmap *regm
regmap_set_bits(regmap, 0x8158, ACCU_CFG_MASK);
}
-static struct qcom_cc_driver_data video_cc_kaanapali_driver_data = {
+static const struct qcom_cc_driver_data video_cc_kaanapali_driver_data = {
.alpha_plls = video_cc_kaanapali_plls,
.num_alpha_plls = ARRAY_SIZE(video_cc_kaanapali_plls),
.clk_cbcrs = video_cc_kaanapali_critical_cbcrs,
diff --git a/drivers/clk/qcom/videocc-milos.c b/drivers/clk/qcom/videocc-milos.c
index acc9df295d4f..012a13f8fb0b 100644
--- a/drivers/clk/qcom/videocc-milos.c
+++ b/drivers/clk/qcom/videocc-milos.c
@@ -359,7 +359,7 @@ static const struct regmap_config video_cc_milos_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data video_cc_milos_driver_data = {
+static const struct qcom_cc_driver_data video_cc_milos_driver_data = {
.alpha_plls = video_cc_milos_plls,
.num_alpha_plls = ARRAY_SIZE(video_cc_milos_plls),
.clk_cbcrs = video_cc_milos_critical_cbcrs,
diff --git a/drivers/clk/qcom/videocc-qcs615.c b/drivers/clk/qcom/videocc-qcs615.c
index 1b41fa44c17e..338ab803d56a 100644
--- a/drivers/clk/qcom/videocc-qcs615.c
+++ b/drivers/clk/qcom/videocc-qcs615.c
@@ -295,7 +295,7 @@ static const struct regmap_config video_cc_qcs615_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data video_cc_qcs615_driver_data = {
+static const struct qcom_cc_driver_data video_cc_qcs615_driver_data = {
.alpha_plls = video_cc_qcs615_plls,
.num_alpha_plls = ARRAY_SIZE(video_cc_qcs615_plls),
.clk_cbcrs = video_cc_qcs615_critical_cbcrs,
diff --git a/drivers/clk/qcom/videocc-sm8450.c b/drivers/clk/qcom/videocc-sm8450.c
index dc168ce199cc..acd0928be1f6 100644
--- a/drivers/clk/qcom/videocc-sm8450.c
+++ b/drivers/clk/qcom/videocc-sm8450.c
@@ -427,7 +427,7 @@ static const struct regmap_config video_cc_sm8450_regmap_config = {
.fast_io = true,
};
-static struct qcom_cc_driver_data video_cc_sm8450_driver_data = {
+static const struct qcom_cc_driver_data video_cc_sm8450_driver_data = {
.alpha_plls = video_cc_sm8450_plls,
.num_alpha_plls = ARRAY_SIZE(video_cc_sm8450_plls),
.clk_cbcrs = video_cc_sm8450_critical_cbcrs,
diff --git a/drivers/clk/qcom/videocc-sm8750.c b/drivers/clk/qcom/videocc-sm8750.c
index 5c1034dd5f57..7e77822c132c 100644
--- a/drivers/clk/qcom/videocc-sm8750.c
+++ b/drivers/clk/qcom/videocc-sm8750.c
@@ -407,7 +407,7 @@ static void clk_sm8750_regs_configure(struct device *dev, struct regmap *regmap)
regmap_update_bits(regmap, 0x9f24, BIT(0), BIT(0));
}
-static struct qcom_cc_driver_data video_cc_sm8750_driver_data = {
+static const struct qcom_cc_driver_data video_cc_sm8750_driver_data = {
.alpha_plls = video_cc_sm8750_plls,
.num_alpha_plls = ARRAY_SIZE(video_cc_sm8750_plls),
.clk_cbcrs = video_cc_sm8750_critical_cbcrs,
--
2.51.0
^ permalink raw reply related
* [PATCH 2/2] clk: qcom: Constify list of critical CBCR registers
From: Krzysztof Kozlowski @ 2026-03-31 9:17 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Maxime Coquelin,
Alexandre Torgue, linux-arm-msm, linux-clk, linux-kernel,
linux-stm32, linux-arm-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260331091721.61613-3-krzysztof.kozlowski@oss.qualcomm.com>
The static array 'xxx_critical_cbcrs' contains probe match-like data and
is not modified: neither by the driver defining it nor by common.c code
using it.
Make it const for code safety and code readability.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/clk/qcom/cambistmclkcc-kaanapali.c | 2 +-
drivers/clk/qcom/cambistmclkcc-sm8750.c | 2 +-
drivers/clk/qcom/camcc-kaanapali.c | 2 +-
drivers/clk/qcom/camcc-milos.c | 2 +-
drivers/clk/qcom/camcc-sc8180x.c | 2 +-
drivers/clk/qcom/camcc-sm8450.c | 2 +-
drivers/clk/qcom/camcc-sm8550.c | 2 +-
drivers/clk/qcom/camcc-sm8650.c | 2 +-
drivers/clk/qcom/camcc-sm8750.c | 2 +-
drivers/clk/qcom/camcc-x1e80100.c | 2 +-
drivers/clk/qcom/common.h | 2 +-
drivers/clk/qcom/dispcc-eliza.c | 2 +-
drivers/clk/qcom/dispcc-glymur.c | 2 +-
drivers/clk/qcom/dispcc-kaanapali.c | 2 +-
drivers/clk/qcom/dispcc-milos.c | 2 +-
drivers/clk/qcom/dispcc-qcs615.c | 2 +-
drivers/clk/qcom/gcc-eliza.c | 2 +-
drivers/clk/qcom/gcc-glymur.c | 2 +-
drivers/clk/qcom/gcc-kaanapali.c | 2 +-
drivers/clk/qcom/gcc-milos.c | 2 +-
drivers/clk/qcom/gcc-sc8180x.c | 2 +-
drivers/clk/qcom/gpucc-glymur.c | 2 +-
drivers/clk/qcom/gpucc-kaanapali.c | 2 +-
drivers/clk/qcom/gpucc-milos.c | 2 +-
drivers/clk/qcom/gpucc-qcs615.c | 2 +-
drivers/clk/qcom/videocc-glymur.c | 2 +-
drivers/clk/qcom/videocc-kaanapali.c | 2 +-
drivers/clk/qcom/videocc-milos.c | 2 +-
drivers/clk/qcom/videocc-qcs615.c | 2 +-
drivers/clk/qcom/videocc-sm8450.c | 2 +-
drivers/clk/qcom/videocc-sm8550.c | 4 ++--
drivers/clk/qcom/videocc-sm8750.c | 2 +-
32 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/clk/qcom/cambistmclkcc-kaanapali.c b/drivers/clk/qcom/cambistmclkcc-kaanapali.c
index 77adb453ab21..6028d8f6959c 100644
--- a/drivers/clk/qcom/cambistmclkcc-kaanapali.c
+++ b/drivers/clk/qcom/cambistmclkcc-kaanapali.c
@@ -383,7 +383,7 @@ static struct clk_alpha_pll *cam_bist_mclk_cc_kaanapali_plls[] = {
&cam_bist_mclk_cc_pll0,
};
-static u32 cam_bist_mclk_cc_kaanapali_critical_cbcrs[] = {
+static const u32 cam_bist_mclk_cc_kaanapali_critical_cbcrs[] = {
0x40e0, /* CAM_BIST_MCLK_CC_SLEEP_CLK */
};
diff --git a/drivers/clk/qcom/cambistmclkcc-sm8750.c b/drivers/clk/qcom/cambistmclkcc-sm8750.c
index f0d7e3b7c532..5df12aced4a5 100644
--- a/drivers/clk/qcom/cambistmclkcc-sm8750.c
+++ b/drivers/clk/qcom/cambistmclkcc-sm8750.c
@@ -402,7 +402,7 @@ static struct clk_alpha_pll *cam_bist_mclk_cc_sm8750_plls[] = {
&cam_bist_mclk_cc_pll0,
};
-static u32 cam_bist_mclk_cc_sm8750_critical_cbcrs[] = {
+static const u32 cam_bist_mclk_cc_sm8750_critical_cbcrs[] = {
0x40f8, /* CAM_BIST_MCLK_CC_SLEEP_CLK */
};
diff --git a/drivers/clk/qcom/camcc-kaanapali.c b/drivers/clk/qcom/camcc-kaanapali.c
index acf5f476955b..af5486418492 100644
--- a/drivers/clk/qcom/camcc-kaanapali.c
+++ b/drivers/clk/qcom/camcc-kaanapali.c
@@ -2600,7 +2600,7 @@ static struct clk_alpha_pll *cam_cc_kaanapali_plls[] = {
&cam_cc_pll7,
};
-static u32 cam_cc_kaanapali_critical_cbcrs[] = {
+static const u32 cam_cc_kaanapali_critical_cbcrs[] = {
0x21398, /* CAM_CC_DRV_AHB_CLK */
0x21390, /* CAM_CC_DRV_XO_CLK */
0x21364, /* CAM_CC_GDSC_CLK */
diff --git a/drivers/clk/qcom/camcc-milos.c b/drivers/clk/qcom/camcc-milos.c
index 556c3c33c106..409d47098c10 100644
--- a/drivers/clk/qcom/camcc-milos.c
+++ b/drivers/clk/qcom/camcc-milos.c
@@ -2104,7 +2104,7 @@ static struct clk_alpha_pll *cam_cc_milos_plls[] = {
&cam_cc_pll6,
};
-static u32 cam_cc_milos_critical_cbcrs[] = {
+static const u32 cam_cc_milos_critical_cbcrs[] = {
0x25038, /* CAM_CC_GDSC_CLK */
0x2505c, /* CAM_CC_SLEEP_CLK */
};
diff --git a/drivers/clk/qcom/camcc-sc8180x.c b/drivers/clk/qcom/camcc-sc8180x.c
index bd06d271928e..016f37d08468 100644
--- a/drivers/clk/qcom/camcc-sc8180x.c
+++ b/drivers/clk/qcom/camcc-sc8180x.c
@@ -2829,7 +2829,7 @@ static struct clk_alpha_pll *cam_cc_sc8180x_plls[] = {
&cam_cc_pll6,
};
-static u32 cam_cc_sc8180x_critical_cbcrs[] = {
+static const u32 cam_cc_sc8180x_critical_cbcrs[] = {
0xc1e4, /* CAM_CC_GDSC_CLK */
0xc200, /* CAM_CC_SLEEP_CLK */
};
diff --git a/drivers/clk/qcom/camcc-sm8450.c b/drivers/clk/qcom/camcc-sm8450.c
index 430b436a673e..1891262a559b 100644
--- a/drivers/clk/qcom/camcc-sm8450.c
+++ b/drivers/clk/qcom/camcc-sm8450.c
@@ -2915,7 +2915,7 @@ static struct clk_alpha_pll *cam_cc_sm8450_plls[] = {
&cam_cc_pll8,
};
-static u32 cam_cc_sm8450_critical_cbcrs[] = {
+static const u32 cam_cc_sm8450_critical_cbcrs[] = {
0x1320c, /* CAM_CC_GDSC_CLK */
};
diff --git a/drivers/clk/qcom/camcc-sm8550.c b/drivers/clk/qcom/camcc-sm8550.c
index 8c42ae7544aa..34d53e2ffad7 100644
--- a/drivers/clk/qcom/camcc-sm8550.c
+++ b/drivers/clk/qcom/camcc-sm8550.c
@@ -3517,7 +3517,7 @@ static struct clk_alpha_pll *cam_cc_sm8550_plls[] = {
&cam_cc_pll12,
};
-static u32 cam_cc_sm8550_critical_cbcrs[] = {
+static const u32 cam_cc_sm8550_critical_cbcrs[] = {
0x1419c, /* CAM_CC_GDSC_CLK */
0x142cc, /* CAM_CC_SLEEP_CLK */
};
diff --git a/drivers/clk/qcom/camcc-sm8650.c b/drivers/clk/qcom/camcc-sm8650.c
index c0055fb08f62..9dea43e74cb6 100644
--- a/drivers/clk/qcom/camcc-sm8650.c
+++ b/drivers/clk/qcom/camcc-sm8650.c
@@ -3533,7 +3533,7 @@ static struct clk_alpha_pll *cam_cc_sm8650_plls[] = {
&cam_cc_pll10,
};
-static u32 cam_cc_sm8650_critical_cbcrs[] = {
+static const u32 cam_cc_sm8650_critical_cbcrs[] = {
0x132ec, /* CAM_CC_GDSC_CLK */
0x13308, /* CAM_CC_SLEEP_CLK */
0x13314, /* CAM_CC_DRV_XO_CLK */
diff --git a/drivers/clk/qcom/camcc-sm8750.c b/drivers/clk/qcom/camcc-sm8750.c
index 9b6d49981267..6618b074c90e 100644
--- a/drivers/clk/qcom/camcc-sm8750.c
+++ b/drivers/clk/qcom/camcc-sm8750.c
@@ -2651,7 +2651,7 @@ static struct clk_alpha_pll *cam_cc_sm8750_plls[] = {
&cam_cc_pll6,
};
-static u32 cam_cc_sm8750_critical_cbcrs[] = {
+static const u32 cam_cc_sm8750_critical_cbcrs[] = {
0x113c4, /* CAM_CC_DRV_AHB_CLK */
0x113c0, /* CAM_CC_DRV_XO_CLK */
0x1137c, /* CAM_CC_GDSC_CLK */
diff --git a/drivers/clk/qcom/camcc-x1e80100.c b/drivers/clk/qcom/camcc-x1e80100.c
index 387420533125..81f579ff6993 100644
--- a/drivers/clk/qcom/camcc-x1e80100.c
+++ b/drivers/clk/qcom/camcc-x1e80100.c
@@ -2434,7 +2434,7 @@ static struct clk_alpha_pll *cam_cc_x1e80100_plls[] = {
&cam_cc_pll8,
};
-static u32 cam_cc_x1e80100_critical_cbcrs[] = {
+static const u32 cam_cc_x1e80100_critical_cbcrs[] = {
0x13a9c, /* CAM_CC_GDSC_CLK */
0x13ab8, /* CAM_CC_SLEEP_CLK */
};
diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
index 69c4b21333e5..6f2406f8839e 100644
--- a/drivers/clk/qcom/common.h
+++ b/drivers/clk/qcom/common.h
@@ -28,7 +28,7 @@ struct qcom_icc_hws_data {
struct qcom_cc_driver_data {
struct clk_alpha_pll **alpha_plls;
size_t num_alpha_plls;
- u32 *clk_cbcrs;
+ const u32 *clk_cbcrs;
size_t num_clk_cbcrs;
const struct clk_rcg_dfs_data *dfs_rcgs;
size_t num_dfs_rcgs;
diff --git a/drivers/clk/qcom/dispcc-eliza.c b/drivers/clk/qcom/dispcc-eliza.c
index 60de3c743621..479f26e0dde2 100644
--- a/drivers/clk/qcom/dispcc-eliza.c
+++ b/drivers/clk/qcom/dispcc-eliza.c
@@ -2063,7 +2063,7 @@ static struct clk_alpha_pll *disp_cc_eliza_plls[] = {
&disp_cc_pll2,
};
-static u32 disp_cc_eliza_critical_cbcrs[] = {
+static const u32 disp_cc_eliza_critical_cbcrs[] = {
0xe07c, /* DISP_CC_SLEEP_CLK */
0xe05c, /* DISP_CC_XO_CLK */
0xc00c, /* DISP_CC_MDSS_RSCC_AHB_CLK */
diff --git a/drivers/clk/qcom/dispcc-glymur.c b/drivers/clk/qcom/dispcc-glymur.c
index aae60291b55e..c4bb328d432f 100644
--- a/drivers/clk/qcom/dispcc-glymur.c
+++ b/drivers/clk/qcom/dispcc-glymur.c
@@ -1921,7 +1921,7 @@ static struct clk_alpha_pll *disp_cc_glymur_plls[] = {
&disp_cc_pll1,
};
-static u32 disp_cc_glymur_critical_cbcrs[] = {
+static const u32 disp_cc_glymur_critical_cbcrs[] = {
0xe07c, /* DISP_CC_SLEEP_CLK */
0xe05c, /* DISP_CC_XO_CLK */
};
diff --git a/drivers/clk/qcom/dispcc-kaanapali.c b/drivers/clk/qcom/dispcc-kaanapali.c
index ffdb4de3a33e..42912c617c31 100644
--- a/drivers/clk/qcom/dispcc-kaanapali.c
+++ b/drivers/clk/qcom/dispcc-kaanapali.c
@@ -1886,7 +1886,7 @@ static struct clk_alpha_pll *disp_cc_kaanapali_plls[] = {
&disp_cc_pll2,
};
-static u32 disp_cc_kaanapali_critical_cbcrs[] = {
+static const u32 disp_cc_kaanapali_critical_cbcrs[] = {
0xe064, /* DISP_CC_SLEEP_CLK */
0xe05c, /* DISP_CC_XO_CLK */
0xc00c, /* DISP_CC_MDSS_RSCC_AHB_CLK */
diff --git a/drivers/clk/qcom/dispcc-milos.c b/drivers/clk/qcom/dispcc-milos.c
index 17ff10cb2f6b..dfffb6d14b0e 100644
--- a/drivers/clk/qcom/dispcc-milos.c
+++ b/drivers/clk/qcom/dispcc-milos.c
@@ -906,7 +906,7 @@ static struct clk_alpha_pll *disp_cc_milos_plls[] = {
&disp_cc_pll0,
};
-static u32 disp_cc_milos_critical_cbcrs[] = {
+static const u32 disp_cc_milos_critical_cbcrs[] = {
0xe06c, /* DISP_CC_SLEEP_CLK */
0xe04c, /* DISP_CC_XO_CLK */
};
diff --git a/drivers/clk/qcom/dispcc-qcs615.c b/drivers/clk/qcom/dispcc-qcs615.c
index 21974e2574f5..637698e6dc2b 100644
--- a/drivers/clk/qcom/dispcc-qcs615.c
+++ b/drivers/clk/qcom/dispcc-qcs615.c
@@ -739,7 +739,7 @@ static struct clk_alpha_pll *disp_cc_qcs615_plls[] = {
&disp_cc_pll0,
};
-static u32 disp_cc_qcs615_critical_cbcrs[] = {
+static const u32 disp_cc_qcs615_critical_cbcrs[] = {
0x6054, /* DISP_CC_XO_CLK */
};
diff --git a/drivers/clk/qcom/gcc-eliza.c b/drivers/clk/qcom/gcc-eliza.c
index 9356c5bf0a03..42a83be34e01 100644
--- a/drivers/clk/qcom/gcc-eliza.c
+++ b/drivers/clk/qcom/gcc-eliza.c
@@ -3005,7 +3005,7 @@ static const struct qcom_reset_map gcc_eliza_resets[] = {
[GCC_VIDEO_BCR] = { 0x32000 },
};
-static u32 gcc_eliza_critical_cbcrs[] = {
+static const u32 gcc_eliza_critical_cbcrs[] = {
0xa0004, /* GCC_CAM_BIST_MCLK_AHB_CLK */
0x26004, /* GCC_CAMERA_AHB_CLK */
0x26034, /* GCC_CAMERA_XO_CLK */
diff --git a/drivers/clk/qcom/gcc-glymur.c b/drivers/clk/qcom/gcc-glymur.c
index 7a199e1bd493..2736465efdea 100644
--- a/drivers/clk/qcom/gcc-glymur.c
+++ b/drivers/clk/qcom/gcc-glymur.c
@@ -8538,7 +8538,7 @@ static const struct clk_rcg_dfs_data gcc_dfs_clocks[] = {
DEFINE_RCG_DFS(gcc_qupv3_wrap2_s7_clk_src),
};
-static u32 gcc_glymur_critical_cbcrs[] = {
+static const u32 gcc_glymur_critical_cbcrs[] = {
0x26004, /* GCC_CAMERA_AHB_CLK */
0x26040, /* GCC_CAMERA_XO_CLK */
0x27004, /* GCC_DISP_AHB_CLK */
diff --git a/drivers/clk/qcom/gcc-kaanapali.c b/drivers/clk/qcom/gcc-kaanapali.c
index 44275bac095e..6e628b51f38c 100644
--- a/drivers/clk/qcom/gcc-kaanapali.c
+++ b/drivers/clk/qcom/gcc-kaanapali.c
@@ -3457,7 +3457,7 @@ static const struct clk_rcg_dfs_data gcc_dfs_clocks[] = {
DEFINE_RCG_DFS(gcc_qupv3_wrap4_s4_clk_src),
};
-static u32 gcc_kaanapali_critical_cbcrs[] = {
+static const u32 gcc_kaanapali_critical_cbcrs[] = {
0xa0004, /* GCC_CAM_BIST_MCLK_AHB_CLK */
0x26004, /* GCC_CAMERA_AHB_CLK */
0x2603c, /* GCC_CAMERA_XO_CLK */
diff --git a/drivers/clk/qcom/gcc-milos.c b/drivers/clk/qcom/gcc-milos.c
index 3438fb9039ee..67d0eee8ef35 100644
--- a/drivers/clk/qcom/gcc-milos.c
+++ b/drivers/clk/qcom/gcc-milos.c
@@ -3152,7 +3152,7 @@ static struct gdsc *gcc_milos_gdscs[] = {
[USB3_PHY_GDSC] = &usb3_phy_gdsc,
};
-static u32 gcc_milos_critical_cbcrs[] = {
+static const u32 gcc_milos_critical_cbcrs[] = {
0x26004, /* GCC_CAMERA_AHB_CLK */
0x26018, /* GCC_CAMERA_HF_XO_CLK */
0x2601c, /* GCC_CAMERA_SF_XO_CLK */
diff --git a/drivers/clk/qcom/gcc-sc8180x.c b/drivers/clk/qcom/gcc-sc8180x.c
index 35c2e9d555b8..e6b7f1a5dcef 100644
--- a/drivers/clk/qcom/gcc-sc8180x.c
+++ b/drivers/clk/qcom/gcc-sc8180x.c
@@ -4647,7 +4647,7 @@ static struct gdsc *gcc_sc8180x_gdscs[] = {
[HLOS1_VOTE_TURING_MMU_TBU1_GDSC] = &hlos1_vote_turing_mmu_tbu1_gdsc,
};
-static u32 gcc_sc8180x_critical_cbcrs[] = {
+static const u32 gcc_sc8180x_critical_cbcrs[] = {
0xb004, /* GCC_VIDEO_AHB_CLK */
0xb008, /* GCC_CAMERA_AHB_CLK */
0xb00c, /* GCC_DISP_AHB_CLK */
diff --git a/drivers/clk/qcom/gpucc-glymur.c b/drivers/clk/qcom/gpucc-glymur.c
index 824b4e09c3f9..54cc3127718a 100644
--- a/drivers/clk/qcom/gpucc-glymur.c
+++ b/drivers/clk/qcom/gpucc-glymur.c
@@ -560,7 +560,7 @@ static struct clk_alpha_pll *gpu_cc_glymur_plls[] = {
&gpu_cc_pll0,
};
-static u32 gpu_cc_glymur_critical_cbcrs[] = {
+static const u32 gpu_cc_glymur_critical_cbcrs[] = {
0x93a4, /* GPU_CC_CB_CLK */
0x9008, /* GPU_CC_CXO_AON_CLK */
0x9004, /* GPU_CC_RSCC_XO_AON_CLK */
diff --git a/drivers/clk/qcom/gpucc-kaanapali.c b/drivers/clk/qcom/gpucc-kaanapali.c
index 94f0feb254b3..7f6013b348ad 100644
--- a/drivers/clk/qcom/gpucc-kaanapali.c
+++ b/drivers/clk/qcom/gpucc-kaanapali.c
@@ -423,7 +423,7 @@ static struct clk_alpha_pll *gpu_cc_kaanapali_plls[] = {
&gpu_cc_pll0,
};
-static u32 gpu_cc_kaanapali_critical_cbcrs[] = {
+static const u32 gpu_cc_kaanapali_critical_cbcrs[] = {
0x9008, /* GPU_CC_CXO_AON_CLK */
0x93e8, /* GPU_CC_RSCC_HUB_AON_CLK */
0x9004, /* GPU_CC_RSCC_XO_AON_CLK */
diff --git a/drivers/clk/qcom/gpucc-milos.c b/drivers/clk/qcom/gpucc-milos.c
index 7a8a3917db9b..1448d95cb1dc 100644
--- a/drivers/clk/qcom/gpucc-milos.c
+++ b/drivers/clk/qcom/gpucc-milos.c
@@ -500,7 +500,7 @@ static struct clk_alpha_pll *gpu_cc_milos_plls[] = {
&gpu_cc_pll0,
};
-static u32 gpu_cc_milos_critical_cbcrs[] = {
+static const u32 gpu_cc_milos_critical_cbcrs[] = {
0x93a4, /* GPU_CC_CB_CLK */
0x9008, /* GPU_CC_CXO_AON_CLK */
0x9010, /* GPU_CC_DEMET_CLK */
diff --git a/drivers/clk/qcom/gpucc-qcs615.c b/drivers/clk/qcom/gpucc-qcs615.c
index 8233136db4d8..91919cdb75ae 100644
--- a/drivers/clk/qcom/gpucc-qcs615.c
+++ b/drivers/clk/qcom/gpucc-qcs615.c
@@ -459,7 +459,7 @@ static struct clk_alpha_pll *gpu_cc_qcs615_plls[] = {
&gpu_cc_pll1,
};
-static u32 gpu_cc_qcs615_critical_cbcrs[] = {
+static const u32 gpu_cc_qcs615_critical_cbcrs[] = {
0x1078, /* GPU_CC_AHB_CLK */
};
diff --git a/drivers/clk/qcom/videocc-glymur.c b/drivers/clk/qcom/videocc-glymur.c
index 4f1ad0db30e5..bbf13f4ba82d 100644
--- a/drivers/clk/qcom/videocc-glymur.c
+++ b/drivers/clk/qcom/videocc-glymur.c
@@ -467,7 +467,7 @@ static struct clk_alpha_pll *video_cc_glymur_plls[] = {
&video_cc_pll0,
};
-static u32 video_cc_glymur_critical_cbcrs[] = {
+static const u32 video_cc_glymur_critical_cbcrs[] = {
0x80e0, /* VIDEO_CC_AHB_CLK */
0x8138, /* VIDEO_CC_SLEEP_CLK */
0x8110, /* VIDEO_CC_XO_CLK */
diff --git a/drivers/clk/qcom/videocc-kaanapali.c b/drivers/clk/qcom/videocc-kaanapali.c
index b060ee34e8a4..b29e3da465e5 100644
--- a/drivers/clk/qcom/videocc-kaanapali.c
+++ b/drivers/clk/qcom/videocc-kaanapali.c
@@ -741,7 +741,7 @@ static struct clk_alpha_pll *video_cc_kaanapali_plls[] = {
&video_cc_pll3,
};
-static u32 video_cc_kaanapali_critical_cbcrs[] = {
+static const u32 video_cc_kaanapali_critical_cbcrs[] = {
0x817c, /* VIDEO_CC_AHB_CLK */
0x81bc, /* VIDEO_CC_SLEEP_CLK */
0x81b0, /* VIDEO_CC_TS_XO_CLK */
diff --git a/drivers/clk/qcom/videocc-milos.c b/drivers/clk/qcom/videocc-milos.c
index 012a13f8fb0b..3cce34e8c71a 100644
--- a/drivers/clk/qcom/videocc-milos.c
+++ b/drivers/clk/qcom/videocc-milos.c
@@ -345,7 +345,7 @@ static struct clk_alpha_pll *video_cc_milos_plls[] = {
&video_cc_pll0,
};
-static u32 video_cc_milos_critical_cbcrs[] = {
+static const u32 video_cc_milos_critical_cbcrs[] = {
0x80f4, /* VIDEO_CC_AHB_CLK */
0x8140, /* VIDEO_CC_SLEEP_CLK */
0x8124, /* VIDEO_CC_XO_CLK */
diff --git a/drivers/clk/qcom/videocc-qcs615.c b/drivers/clk/qcom/videocc-qcs615.c
index 338ab803d56a..3203cb938ad1 100644
--- a/drivers/clk/qcom/videocc-qcs615.c
+++ b/drivers/clk/qcom/videocc-qcs615.c
@@ -283,7 +283,7 @@ static struct clk_alpha_pll *video_cc_qcs615_plls[] = {
&video_pll0,
};
-static u32 video_cc_qcs615_critical_cbcrs[] = {
+static const u32 video_cc_qcs615_critical_cbcrs[] = {
0xab8, /* VIDEO_CC_XO_CLK */
};
diff --git a/drivers/clk/qcom/videocc-sm8450.c b/drivers/clk/qcom/videocc-sm8450.c
index acd0928be1f6..18b191f598b5 100644
--- a/drivers/clk/qcom/videocc-sm8450.c
+++ b/drivers/clk/qcom/videocc-sm8450.c
@@ -413,7 +413,7 @@ static struct clk_alpha_pll *video_cc_sm8450_plls[] = {
&video_cc_pll1,
};
-static u32 video_cc_sm8450_critical_cbcrs[] = {
+static const u32 video_cc_sm8450_critical_cbcrs[] = {
0x80e4, /* VIDEO_CC_AHB_CLK */
0x8114, /* VIDEO_CC_XO_CLK */
0x8130, /* VIDEO_CC_SLEEP_CLK */
diff --git a/drivers/clk/qcom/videocc-sm8550.c b/drivers/clk/qcom/videocc-sm8550.c
index 32a6505abe26..4e35964f0803 100644
--- a/drivers/clk/qcom/videocc-sm8550.c
+++ b/drivers/clk/qcom/videocc-sm8550.c
@@ -536,13 +536,13 @@ static struct clk_alpha_pll *video_cc_sm8550_plls[] = {
&video_cc_pll1,
};
-static u32 video_cc_sm8550_critical_cbcrs[] = {
+static const u32 video_cc_sm8550_critical_cbcrs[] = {
0x80f4, /* VIDEO_CC_AHB_CLK */
0x8124, /* VIDEO_CC_XO_CLK */
0x8140, /* VIDEO_CC_SLEEP_CLK */
};
-static u32 video_cc_sm8650_critical_cbcrs[] = {
+static const u32 video_cc_sm8650_critical_cbcrs[] = {
0x80f4, /* VIDEO_CC_AHB_CLK */
0x8124, /* VIDEO_CC_XO_CLK */
0x8150, /* VIDEO_CC_SLEEP_CLK */
diff --git a/drivers/clk/qcom/videocc-sm8750.c b/drivers/clk/qcom/videocc-sm8750.c
index 7e77822c132c..e9414390a3cc 100644
--- a/drivers/clk/qcom/videocc-sm8750.c
+++ b/drivers/clk/qcom/videocc-sm8750.c
@@ -392,7 +392,7 @@ static struct clk_alpha_pll *video_cc_sm8750_plls[] = {
&video_cc_pll0,
};
-static u32 video_cc_sm8750_critical_cbcrs[] = {
+static const u32 video_cc_sm8750_critical_cbcrs[] = {
0x80a4, /* VIDEO_CC_AHB_CLK */
0x80f8, /* VIDEO_CC_SLEEP_CLK */
0x80d4, /* VIDEO_CC_XO_CLK */
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Pandey, Radhey Shyam @ 2026-03-31 9:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel, linux-usb, devicetree, linux-arm-kernel, linux-kernel,
git
In-Reply-To: <20260331-jellyfish-of-pragmatic-prowess-a230fc@quoll>
> On Tue, Mar 31, 2026 at 12:33:01AM +0530, Radhey Shyam Pandey wrote:
>> Versal Gen2 platform multimedia integrated (MMI) module has a USB3.2 Gen
>> 2x1 Dual Role Device IP. Introduce a new compatibility string to support
>> it. The USB wrapper registers reside in the MMI UDH system-level control
>> registers (SLCR) block, so instead of a dedicated reg property, add
>> xlnx,usb-syscon phandle with four cells specifying register offsets for
>> USB2 PHY, USB3 PHY, USB DRD, and USB power configuration within the SLCR.
>>
>> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>> ---
>> Changes for v2:
>> - Add blank line after compatible as suggested by Krzysztof.
>> - Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
>> IP from Synopsys is part of the dedicated Multimedia Interface. The
>> Versal Gen2 platform also includes a separate USB 2.0 controller,
>> and the mmi suffix uniquely distinguishes between the two USB
>> controllers. MMI is an independent subsystem particularly targeted for
>> deployment in Multi-Media related applications. The MMI block include
>> following submodules: UDH: USB3.2 Gen 2x1 Dual Role Device, DisplayPort
>> Transmit Controller, Security Module (ESM) for DisplayPort and HDMI
>> Controllers, DP AUX-I2C PHY.
>> - For MMI USB define parent address space i.e UDH block.
>> - Fix inconsistent MHz spacing to use SI convention with spaces.
>> - Move description before $ref and items in xlnx,usb-syscon property.
>> - Restore original zynqmp-dwc3 example, add new versal2-mmi-dwc3 example.
>> - Use 'usb' node name (without unit address) for versal2 example since
>> it has no reg property.
>> - Use 1/1 address/size configuration in versal2 example, use lowercase
>> hex in syscon offsets.
>> ---
>> .../devicetree/bindings/usb/dwc3-xilinx.yaml | 70 ++++++++++++++++++-
>> 1 file changed, 67 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>> index d6823ef5f9a7..5e31b961aff7 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>> +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
>> @@ -15,6 +15,8 @@ properties:
>> - enum:
>> - xlnx,zynqmp-dwc3
>> - xlnx,versal-dwc3
>> + - xlnx,versal2-mmi-dwc3
> I am not going to ask the same questions.
I have provided the explanation in v2 changelog.
Retain the mmi suffix in the compatible string, as this USB 3.2 Gen2
IP from Synopsys is part of the dedicated Multimedia Interface. The
Versal Gen2 platform also includes a separate USB 2.0 controller,
and the mmi suffix uniquely distinguishes between the two USB
controllers.
Let me know if you still have reservation in this approach (using
<vendor>,<soc>-<subsystem>-<ip>). Or any other alternative
based on IP version etc please suggest.
Thanks,
Radhey
^ permalink raw reply
* [PATCH v2 1/1] arm64: dts: imx91-var-dart-sonata: add RGB enable supply for PCA6408
From: Stefano Radaelli @ 2026-03-31 9:21 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
From: Stefano Radaelli <stefano.r@variscite.com>
RGB enable pin, labeled as RGBSEL, is a board-level enable signal on
the Sonata carrier board.
The two PCA6408 GPIO expanders depend on this signal being asserted, so
model it as a fixed regulator and use it as their vcc-supply.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Fixed commit message and RGB pin references.
arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
index afa39dab240a..3f0fd321d95f 100644
--- a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
@@ -90,6 +90,13 @@ reg_vref_1v8: regulator-adc-vref {
regulator-max-microvolt = <1800000>;
};
+ reg_rgb_sel: regulator-rgb-enable {
+ compatible = "regulator-fixed";
+ regulator-name = "RGBSEL";
+ gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -195,6 +202,7 @@ pca6408_1: gpio@20 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca6408_2: gpio@21 {
@@ -204,6 +212,7 @@ pca6408_2: gpio@21 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca9534: gpio@22 {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: James Clark @ 2026-03-31 9:26 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <207b78e5-ed6b-4caf-b9ce-546cf33d6dfd@oss.qualcomm.com>
On 31/03/2026 4:18 am, Jie Gan wrote:
> Hi James,
>
> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>
>> Hi James,
>>
>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>
>>>
>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>> to userspace to support trace data parsing.
>>>>
>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>> to the connected TPDA device.
>>>>
>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>> ---
>>>> Changes in v3:
>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>> enabled.
>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>
>>>> Changes in V2:
>>>> 1. Use sysfs_emit instead of sprintf.
>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>>>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>> ---
>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 ++++++++++++++++
>>>> + + +++++++++-
>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/
>>>> hwtracing/coresight/coresight-tpdm.c
>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>> *drvdata)
>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>> perf_event *event,
>>>> enum cs_mode mode,
>>>> - __maybe_unused struct coresight_path *path)
>>>> + struct coresight_path *path)
>>>> {
>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>> >dev.parent);
>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>> *csdev, struct perf_event *event,
>>>> }
>>>> __tpdm_enable(drvdata);
>>>> + drvdata->traceid = path->trace_id;
>>>> drvdata->enable = true;
>>>> spin_unlock(&drvdata->spinlock);
>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>> .attrs = tpdm_attrs,
>>>> };
>>>> +static ssize_t traceid_show(struct device *dev,
>>>> + struct device_attribute *attr, char *buf)
>>>> +{
>>>> + unsigned long val;
>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> +
>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>> + return -EINVAL;
>>>> +
>>>> + val = drvdata->traceid;
>>>
>>> You probably need to take the coresight_mutex here otherwise you
>>> could still return an invalid or stale value despite checking the mode.
>>>
>>
>> Acked. I have missed this potential race condition.
>>
>>> There might also be some value in it returning the last used trace ID
>>> even if the mode isn't enabled anymore. Because you can still read
>>> out of the sink after disabling, so it makes more sense for a script
>>> to read it at that point rather than when it's enabled. Also, you
>>> probably don't want to be doing other things in your script in the
>>> point between enabling and disabling.
>>
>> That's making sense. I shouldnt add such restriction for the read
>> process.
>>
>
> I missed one point in last message.
>
> Is that acceptable to export the coresight_mutex from the core module?
> Currently, the coresight_mutex is used within the module only.
>
> Thanks,
> Jie
>
If the plan is to only check for non-zero trace ID and not check the
mode any more then you don't need to lock. Maybe lets see what Suzuki
thinks about returning the last trace ID though as it was his idea to
add -EINVAL.
>> Scenarios for reading:
>> 1. device is enabled -> trace ID is valid
>> 2. device is enabled then disabled -> trace ID is valid for the last
>> trace event
>> 3. device is never enabled -> invalid trace ID (value 0)
>>
>> we only need to check the validation of the trace ID.
>>
>> mutex_lock(&coresight_mutex);
>> val = drvdata->traceid;
>> mutex_unlock(&coresight_mutex);
>>
>> if (!val)
>> return -EINVAL;
>>
>> return sysfs_emit(buf, "%#lx\n", val);
>>
>> Thanks,
>> Jie
>>
>>>
>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>> +}
>>>> +static DEVICE_ATTR_RO(traceid);
>>>> +
>>>> +static struct attribute *traceid_attrs[] = {
>>>> + &dev_attr_traceid.attr,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static struct attribute_group traceid_attr_grp = {
>>>> + .attrs = traceid_attrs,
>>>> +};
>>>> +
>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>> struct device_attribute *attr,
>>>> char *buf)
>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>> *tpdm_attr_grps[] = {
>>>> &tpdm_cmb_patt_grp,
>>>> &tpdm_cmb_msr_grp,
>>>> &tpdm_mcmb_attr_grp,
>>>> + &traceid_attr_grp,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>> + &traceid_attr_grp,
>>>> NULL,
>>>> };
>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>> struct resource *res)
>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>> if (res)
>>>> desc.groups = tpdm_attr_grps;
>>>> + else
>>>> + desc.groups = static_tpdm_attr_grps;
>>>> drvdata->csdev = coresight_register(&desc);
>>>> if (IS_ERR(drvdata->csdev))
>>>> return PTR_ERR(drvdata->csdev);
>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/
>>>> hwtracing/coresight/coresight-tpdm.h
>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>> * @cmb Specifics associated to TPDM CMB.
>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>> + * @traceid Trace ID of the path.
>>>> */
>>>> struct tpdm_drvdata {
>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>> struct cmb_dataset *cmb;
>>>> u32 dsb_msr_num;
>>>> u32 cmb_msr_num;
>>>> + u8 traceid;
>>>> };
>>>> /* Enumerate members of various datasets */
>>>>
>>>> ---
>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>
>>>> Best regards,
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v3] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-31 9:28 UTC (permalink / raw)
To: Vincent Donnefort
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <acs0Qbjfdmlkvd1e@google.com>
On Tue, Mar 31, 2026 at 3:41 AM Vincent Donnefort <vdonnefort@google.com> wrote:
>
> On Mon, Mar 30, 2026 at 10:54:41AM +0000, Sebastian Ene wrote:
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field un-handled in pKVM when an SMC instruction is
> > trapped.
> > Since the HVC is a private interface between EL2 and the host,
> > enforce the host kernel running under pKVM to use an immediate value
> > of 0 only when using SMCs to make it clear for non-compliant software
> > talking to Trustzone that we only use SMCCC.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
>
Hello,
> Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
>
Thanks for reviewing,
Sebastian
> > ---
> > v2 -> current:
> > - move the ESR decoding of the imm16 in the handle_host_smc where it
> > was supposed to be
> > - updated the commit message to include the reason behind while we are
> > not doing for HVCs as well
> > - updated the commit message to clarify that pKVM is not handling the
> > imm16
> >
> > v1 -> v2:
> > - Dropped injecting an UNDEF and return an error instead
> > (SMCCC_RET_NOT_SUPPORTED)
> > - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> > - Updated the title of the commit message from:
> > "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> > smc with imm16 != 0"
> >
> > Link to v2:
> > https://lore.kernel.org/all/20260325113138.4171430-1-sebastianene@google.com/
> > Link to v1:
> > https://lore.kernel.org/all/20260324135728.3532400-1-sebastianene@google.com/
> >
> > ---
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index e7790097db93..461cf5cb5ac7 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -676,8 +676,14 @@ static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
> > static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> > {
> > DECLARE_REG(u64, func_id, host_ctxt, 0);
> > + u64 esr = read_sysreg_el2(SYS_ESR);
> > bool handled;
> >
> > + if (esr & ESR_ELx_xVC_IMM_MASK) {
> > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> > + goto exit_skip_instr;
> > + }
> > +
> > func_id &= ~ARM_SMCCC_CALL_HINTS;
> >
> > handled = kvm_host_psci_handler(host_ctxt, func_id);
> > @@ -686,6 +692,7 @@ static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
> > if (!handled)
> > default_host_smc_handler(host_ctxt);
> >
> > +exit_skip_instr:
> > /* SMC was trapped, move ELR past the current PC. */
> > kvm_skip_host_instr();
> > }
> > --
> > 2.53.0.1018.g2bb0e51243-goog
> >
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 9:33 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260331091721.61613-3-krzysztof.kozlowski@oss.qualcomm.com>
On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
> The static 'struct qcom_cc_driver_data' contains probe match-like data
> and is not modified: neither by the driver defining it nor by common.c
> code using it.
>
> Make it const for code safety and code readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
[...]
> --- a/drivers/clk/qcom/common.h
> +++ b/drivers/clk/qcom/common.h
> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
> size_t num_icc_hws;
> unsigned int icc_first_node_id;
> bool use_rpm;
> - struct qcom_cc_driver_data *driver_data;
> + const struct qcom_cc_driver_data *driver_data;
This can be a const ptr to const data, even
Konrad
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 9:33 UTC (permalink / raw)
To: James Clark, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <7abe93fa-3748-4077-b75a-d28296862654@linaro.org>
On 3/31/2026 5:26 PM, James Clark wrote:
>
>
> On 31/03/2026 4:18 am, Jie Gan wrote:
>> Hi James,
>>
>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>
>>> Hi James,
>>>
>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>
>>>>
>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>> to userspace to support trace data parsing.
>>>>>
>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>> to the connected TPDA device.
>>>>>
>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>> ---
>>>>> Changes in v3:
>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>> enabled.
>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>
>>>>> Changes in V2:
>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>>>>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>> ---
>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++
>>>>> + + + +++++++++-
>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>> *drvdata)
>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>> perf_event *event,
>>>>> enum cs_mode mode,
>>>>> - __maybe_unused struct coresight_path *path)
>>>>> + struct coresight_path *path)
>>>>> {
>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>> >dev.parent);
>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>> *csdev, struct perf_event *event,
>>>>> }
>>>>> __tpdm_enable(drvdata);
>>>>> + drvdata->traceid = path->trace_id;
>>>>> drvdata->enable = true;
>>>>> spin_unlock(&drvdata->spinlock);
>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>> .attrs = tpdm_attrs,
>>>>> };
>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>> + struct device_attribute *attr, char *buf)
>>>>> +{
>>>>> + unsigned long val;
>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +
>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + val = drvdata->traceid;
>>>>
>>>> You probably need to take the coresight_mutex here otherwise you
>>>> could still return an invalid or stale value despite checking the mode.
>>>>
>>>
>>> Acked. I have missed this potential race condition.
>>>
>>>> There might also be some value in it returning the last used trace
>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>> read out of the sink after disabling, so it makes more sense for a
>>>> script to read it at that point rather than when it's enabled. Also,
>>>> you probably don't want to be doing other things in your script in
>>>> the point between enabling and disabling.
>>>
>>> That's making sense. I shouldnt add such restriction for the read
>>> process.
>>>
>>
>> I missed one point in last message.
>>
>> Is that acceptable to export the coresight_mutex from the core module?
>> Currently, the coresight_mutex is used within the module only.
>>
>> Thanks,
>> Jie
>>
>
> If the plan is to only check for non-zero trace ID and not check the
> mode any more then you don't need to lock. Maybe lets see what Suzuki
> thinks about returning the last trace ID though as it was his idea to
> add -EINVAL.
>
Sure. The trace ID is allocated during TPDA device probe and remains
unchanged for the entire lifetime of the device.
Thanks,
Jie
>>> Scenarios for reading:
>>> 1. device is enabled -> trace ID is valid
>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>> trace event
>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>
>>> we only need to check the validation of the trace ID.
>>>
>>> mutex_lock(&coresight_mutex);
>>> val = drvdata->traceid;
>>> mutex_unlock(&coresight_mutex);
>>>
>>> if (!val)
>>> return -EINVAL;
>>>
>>> return sysfs_emit(buf, "%#lx\n", val);
>>>
>>> Thanks,
>>> Jie
>>>
>>>>
>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>> +}
>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>> +
>>>>> +static struct attribute *traceid_attrs[] = {
>>>>> + &dev_attr_traceid.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>> + .attrs = traceid_attrs,
>>>>> +};
>>>>> +
>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>> struct device_attribute *attr,
>>>>> char *buf)
>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>> *tpdm_attr_grps[] = {
>>>>> &tpdm_cmb_patt_grp,
>>>>> &tpdm_cmb_msr_grp,
>>>>> &tpdm_mcmb_attr_grp,
>>>>> + &traceid_attr_grp,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>> + &traceid_attr_grp,
>>>>> NULL,
>>>>> };
>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>> struct resource *res)
>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>> if (res)
>>>>> desc.groups = tpdm_attr_grps;
>>>>> + else
>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>> drvdata->csdev = coresight_register(&desc);
>>>>> if (IS_ERR(drvdata->csdev))
>>>>> return PTR_ERR(drvdata->csdev);
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>> + * @traceid Trace ID of the path.
>>>>> */
>>>>> struct tpdm_drvdata {
>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>> struct cmb_dataset *cmb;
>>>>> u32 dsb_msr_num;
>>>>> u32 cmb_msr_num;
>>>>> + u8 traceid;
>>>>> };
>>>>> /* Enumerate members of various datasets */
>>>>>
>>>>> ---
>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>
>>>>> Best regards,
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [GIT PULL 6/7] arm64: tegra: Device tree changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 9:35 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <acuE-URAuRvmtd4u@orome>
On 31/03/2026 10:43, Thierry Reding wrote:
>>>> Maybe they had more time for previous versions, but
>>>> nevertheless it is also part of other patchset, so it will get into the
>>>> kernel other tree and nothing on v3 posting:
>>>> https://lore.kernel.org/all/20260326135855.2795149-4-thierry.reding@kernel.org/
>>>> gives hints that there will be cross tree merge.
>>>
>>> Maybe look at the cover letter:
>>>
>>> https://lore.kernel.org/all/20260326135855.2795149-1-thierry.reding@kernel.org/
>>>
>>> I clearly pointed out the build dependencies and suggested a shared
>>> branch to resolve them in both trees. Given that the bindings were
>>
>> No problem, that's a valid solution. Can you point me with a lore link
>> to the shared branch posting (these tags/pull requests must be posted on
>> the lists)? Or to an ack from PCI maintainers?
>>
>> The commit itself does not have an Ack, but maybe was just missed.
>
> Yes, the DT bindings patch does not have an Acked-by, but again, I
> didn't think that was necessary, especially since we were going to have
> a cross-merge anyway.
>
> Here's the PR for PCI:
>
> https://lore.kernel.org/linux-tegra/20260329155040.1448158-1-thierry.reding@kernel.org/
Thanks, this solves my question. A note in the pull message (not
necessarily in the tag) would also solve it, BTW.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Suzuki K Poulose @ 2026-03-31 9:42 UTC (permalink / raw)
To: James Clark, Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <7abe93fa-3748-4077-b75a-d28296862654@linaro.org>
On 31/03/2026 10:26, James Clark wrote:
>
>
> On 31/03/2026 4:18 am, Jie Gan wrote:
>> Hi James,
>>
>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>
>>> Hi James,
>>>
>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>
>>>>
>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>> to userspace to support trace data parsing.
>>>>>
>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>> to the connected TPDA device.
>>>>>
>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>> ---
>>>>> Changes in v3:
>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>> enabled.
>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>
>>>>> Changes in V2:
>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-
>>>>> for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>> ---
>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++
>>>>> + + + +++++++++-
>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>> *drvdata)
>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>> perf_event *event,
>>>>> enum cs_mode mode,
>>>>> - __maybe_unused struct coresight_path *path)
>>>>> + struct coresight_path *path)
>>>>> {
>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>> >dev.parent);
>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>> *csdev, struct perf_event *event,
>>>>> }
>>>>> __tpdm_enable(drvdata);
>>>>> + drvdata->traceid = path->trace_id;
>>>>> drvdata->enable = true;
>>>>> spin_unlock(&drvdata->spinlock);
>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>> .attrs = tpdm_attrs,
>>>>> };
>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>> + struct device_attribute *attr, char *buf)
>>>>> +{
>>>>> + unsigned long val;
>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>> +
>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + val = drvdata->traceid;
>>>>
>>>> You probably need to take the coresight_mutex here otherwise you
>>>> could still return an invalid or stale value despite checking the mode.
>>>>
>>>
>>> Acked. I have missed this potential race condition.
>>>
>>>> There might also be some value in it returning the last used trace
>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>> read out of the sink after disabling, so it makes more sense for a
>>>> script to read it at that point rather than when it's enabled. Also,
>>>> you probably don't want to be doing other things in your script in
>>>> the point between enabling and disabling.
>>>
>>> That's making sense. I shouldnt add such restriction for the read
>>> process.
>>>
>>
>> I missed one point in last message.
>>
>> Is that acceptable to export the coresight_mutex from the core module?
>> Currently, the coresight_mutex is used within the module only.
>>
>> Thanks,
>> Jie
>>
>
> If the plan is to only check for non-zero trace ID and not check the
> mode any more then you don't need to lock. Maybe lets see what Suzuki
> thinks about returning the last trace ID though as it was his idea to
> add -EINVAL.
>
I think there is value in reading out the traceid that was used. Also,
I assume TPDM is always connected to a TPDA port and the traceID
wouldn't change, ever ?
I am happy with the proposal
Suzuki
>>> Scenarios for reading:
>>> 1. device is enabled -> trace ID is valid
>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>> trace event
>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>
>>> we only need to check the validation of the trace ID.
>>>
>>> mutex_lock(&coresight_mutex);
>>> val = drvdata->traceid;
>>> mutex_unlock(&coresight_mutex);
>>>
>>> if (!val)
>>> return -EINVAL;
>>>
>>> return sysfs_emit(buf, "%#lx\n", val);
>>>
>>> Thanks,
>>> Jie
>>>
>>>>
>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>> +}
>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>> +
>>>>> +static struct attribute *traceid_attrs[] = {
>>>>> + &dev_attr_traceid.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>> + .attrs = traceid_attrs,
>>>>> +};
>>>>> +
>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>> struct device_attribute *attr,
>>>>> char *buf)
>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>> *tpdm_attr_grps[] = {
>>>>> &tpdm_cmb_patt_grp,
>>>>> &tpdm_cmb_msr_grp,
>>>>> &tpdm_mcmb_attr_grp,
>>>>> + &traceid_attr_grp,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>> + &traceid_attr_grp,
>>>>> NULL,
>>>>> };
>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>> struct resource *res)
>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>> if (res)
>>>>> desc.groups = tpdm_attr_grps;
>>>>> + else
>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>> drvdata->csdev = coresight_register(&desc);
>>>>> if (IS_ERR(drvdata->csdev))
>>>>> return PTR_ERR(drvdata->csdev);
>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>> + * @traceid Trace ID of the path.
>>>>> */
>>>>> struct tpdm_drvdata {
>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>> struct cmb_dataset *cmb;
>>>>> u32 dsb_msr_num;
>>>>> u32 cmb_msr_num;
>>>>> + u8 traceid;
>>>>> };
>>>>> /* Enumerate members of various datasets */
>>>>>
>>>>> ---
>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>
>>>>> Best regards,
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive
From: Marc Zyngier @ 2026-03-31 9:42 UTC (permalink / raw)
To: Vishnu Pajjuri
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Christoffer Dall, Mark Brown, kvm, linux-arm-kernel,
kvmarm
In-Reply-To: <1e050b67-2276-41ad-9265-796ba853dc7c@os.amperecomputing.com>
On Tue, 31 Mar 2026 07:31:54 +0100,
Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
>
> Hi Marc,
> Many thanks for your reply.
>
> On 30-03-2026 17:47, Marc Zyngier wrote:
> > On Mon, 30 Mar 2026 12:51:51 +0100,
> > Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
> >>
> >> Hi Fuad Tabba,
> >
> > To be brutally honest, I doubt Fuad really cares about NV,
>
> I see Tested-by: fuad Tabba on this patch so tried to reach out him.
Rather than the author of the patch?
>
> >
> >> I'm trying to run nested VMs on Ampere platforms after this patch
> >> series(v6.19+) but nested VMs are not booting and triggering soft
> >> lockups on L0 and L0 hang. But just before this patch I could able to
> >> successfully boot the Nested VMs.
> >
> > So the host dies? There isn't much here that interacts with the host
> > at all. Worse case, the L1 dies by not making progress.
>
> Initially L1 become unresponsive then L0 becomes unresponsive, soft
> lockups and L0 hang.
I've never seen this in the past 6 months. Doesn't mean there is no
bug, but so far I haven't seen any of that.
[...]
> >> Were you able to boot Nested VMs successfully after v6.19+?
> >
> > I boot L3s every day.
>
> Do you mean L2s or L3s on top of L2s?
I'm running an L0 host, itself running L1 guests, themselves running
L2 guests, themselves running L3 guests. That's what "running L3s"
means.
> I running L1 and L2 using latest QEMU, do you use QEMU or kvmtool run
> L1 and L2 in your regression tests?
Both. And that really shouldn't matter.
>
>
> >
> >> LOG:
> >> [ 164.647367] Call trace:
> >> [ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P)
> >> [ 164.647372] smp_call_function_many+0x20/0x40
> >> [ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8
> >> [ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8
> >> [ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0
> >> [ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400
> >> [ 164.647386] kvm_vm_ioctl+0x7b8/0xc88
> >> [ 164.647389] __arm64_sys_ioctl+0xb4/0x118
> >> [ 164.647393] invoke_syscall+0x6c/0x100
> >> [ 164.647397] el0_svc_common.constprop.0+0x48/0xf0
> >> [ 164.647398] do_el0_svc+0x24/0x38
> >> [ 164.647400] el0_svc+0x3c/0x170
> >> [ 164.647403] el0t_64_sync_handler+0xa0/0xe8
> >> [ 164.647405] el0t_64_sync+0x1b0/0x1b8
> >
> > This trace is about interrupt injection from userspace, not
> > deactivation of a HW interrupt.
> > None of that makes much sense.
>
> Although this behavior is puzzling, it matches the trace I typically
> observe on L0. After reverting the patch, I was able to boot L2 guests
> successfully.
Well, this patch fixes real bugs, so it isn't going anywhere.
The patch you are reverting addresses the deactivation of a HW
interrupt, which is likely to be a timer (that's the only one we
support). The stacktrace points to the userspace injection of an SPI.
If we need to broadcast IPI, that's because there is no other SPI
currently in flight. But if a CPU is not responding to the IPI, what
is it doing? How does this interact with the patch you are reverting?
Given that I don't know what you're running, how you are running it,
that I don't have access to whatever HW you are using, and that you
are providing no useful information that'd help me debug this, I will
leave it up to you to debug it and come back with a detailed analysis
of the problem.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: James Clark @ 2026-03-31 9:44 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <f038fd7c-d563-4583-ad6f-666e2816fdb7@oss.qualcomm.com>
On 31/03/2026 10:33 am, Jie Gan wrote:
>
>
> On 3/31/2026 5:26 PM, James Clark wrote:
>>
>>
>> On 31/03/2026 4:18 am, Jie Gan wrote:
>>> Hi James,
>>>
>>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>>
>>>> Hi James,
>>>>
>>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>>
>>>>>
>>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>>> to userspace to support trace data parsing.
>>>>>>
>>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>>> to the connected TPDA device.
>>>>>>
>>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>>> ---
>>>>>> Changes in v3:
>>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>>> enabled.
>>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>>
>>>>>> Changes in V2:
>>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-
>>>>>> show- for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>>> ---
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 ++++++++++++++
>>>>>> + + + + +++++++++-
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>>> *drvdata)
>>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>>> perf_event *event,
>>>>>> enum cs_mode mode,
>>>>>> - __maybe_unused struct coresight_path *path)
>>>>>> + struct coresight_path *path)
>>>>>> {
>>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>>> >dev.parent);
>>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>>> *csdev, struct perf_event *event,
>>>>>> }
>>>>>> __tpdm_enable(drvdata);
>>>>>> + drvdata->traceid = path->trace_id;
>>>>>> drvdata->enable = true;
>>>>>> spin_unlock(&drvdata->spinlock);
>>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>>> .attrs = tpdm_attrs,
>>>>>> };
>>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>>> + struct device_attribute *attr, char *buf)
>>>>>> +{
>>>>>> + unsigned long val;
>>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +
>>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + val = drvdata->traceid;
>>>>>
>>>>> You probably need to take the coresight_mutex here otherwise you
>>>>> could still return an invalid or stale value despite checking the
>>>>> mode.
>>>>>
>>>>
>>>> Acked. I have missed this potential race condition.
>>>>
>>>>> There might also be some value in it returning the last used trace
>>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>>> read out of the sink after disabling, so it makes more sense for a
>>>>> script to read it at that point rather than when it's enabled.
>>>>> Also, you probably don't want to be doing other things in your
>>>>> script in the point between enabling and disabling.
>>>>
>>>> That's making sense. I shouldnt add such restriction for the read
>>>> process.
>>>>
>>>
>>> I missed one point in last message.
>>>
>>> Is that acceptable to export the coresight_mutex from the core module?
>>> Currently, the coresight_mutex is used within the module only.
>>>
>>> Thanks,
>>> Jie
>>>
>>
>> If the plan is to only check for non-zero trace ID and not check the
>> mode any more then you don't need to lock. Maybe lets see what Suzuki
>> thinks about returning the last trace ID though as it was his idea to
>> add -EINVAL.
>>
>
> Sure. The trace ID is allocated during TPDA device probe and remains
> unchanged for the entire lifetime of the device.
>
> Thanks,
> Jie
>
>
Oh I missed that because it's assigned every time in tpdm_enable(). In
that case I don't see why it can't be just:
val = drvdata->traceid;
if (!val)
return -EINVAL;
return sysfs_emit(...)
>>>> Scenarios for reading:
>>>> 1. device is enabled -> trace ID is valid
>>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>>> trace event
>>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>>
>>>> we only need to check the validation of the trace ID.
>>>>
>>>> mutex_lock(&coresight_mutex);
>>>> val = drvdata->traceid;
>>>> mutex_unlock(&coresight_mutex);
>>>>
>>>> if (!val)
>>>> return -EINVAL;
>>>>
>>>> return sysfs_emit(buf, "%#lx\n", val);
>>>>
>>>> Thanks,
>>>> Jie
>>>>
>>>>>
>>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>>> +}
>>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>>> +
>>>>>> +static struct attribute *traceid_attrs[] = {
>>>>>> + &dev_attr_traceid.attr,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>>> + .attrs = traceid_attrs,
>>>>>> +};
>>>>>> +
>>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>>> struct device_attribute *attr,
>>>>>> char *buf)
>>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>>> *tpdm_attr_grps[] = {
>>>>>> &tpdm_cmb_patt_grp,
>>>>>> &tpdm_cmb_msr_grp,
>>>>>> &tpdm_mcmb_attr_grp,
>>>>>> + &traceid_attr_grp,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>>> + &traceid_attr_grp,
>>>>>> NULL,
>>>>>> };
>>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>>> struct resource *res)
>>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>>> if (res)
>>>>>> desc.groups = tpdm_attr_grps;
>>>>>> + else
>>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>>> drvdata->csdev = coresight_register(&desc);
>>>>>> if (IS_ERR(drvdata->csdev))
>>>>>> return PTR_ERR(drvdata->csdev);
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>>> + * @traceid Trace ID of the path.
>>>>>> */
>>>>>> struct tpdm_drvdata {
>>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>>> struct cmb_dataset *cmb;
>>>>>> u32 dsb_msr_num;
>>>>>> u32 cmb_msr_num;
>>>>>> + u8 traceid;
>>>>>> };
>>>>>> /* Enumerate members of various datasets */
>>>>>>
>>>>>> ---
>>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>>
>>>>>> Best regards,
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v3] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 9:48 UTC (permalink / raw)
To: Suzuki K Poulose, James Clark
Cc: coresight, linux-arm-kernel, linux-kernel, Mike Leach, Leo Yan,
Alexander Shishkin, Tingwei Zhang
In-Reply-To: <04214197-f521-47d6-88a1-94be1a8b1981@arm.com>
On 3/31/2026 5:42 PM, Suzuki K Poulose wrote:
> On 31/03/2026 10:26, James Clark wrote:
>>
>>
>> On 31/03/2026 4:18 am, Jie Gan wrote:
>>> Hi James,
>>>
>>> On 3/31/2026 9:29 AM, Jie Gan wrote:
>>>>
>>>> Hi James,
>>>>
>>>> On 3/30/2026 10:55 PM, James Clark wrote:
>>>>>
>>>>>
>>>>> On 25/03/2026 3:10 am, Jie Gan wrote:
>>>>>> Save the trace ID in drvdata during TPDM enablement and expose it
>>>>>> to userspace to support trace data parsing.
>>>>>>
>>>>>> The TPDM device’s trace ID corresponds to the trace ID allocated
>>>>>> to the connected TPDA device.
>>>>>>
>>>>>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>>>>>> ---
>>>>>> Changes in v3:
>>>>>> 1. Only allow user to read the traceid while the TPDM device is
>>>>>> enabled.
>>>>>> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-
>>>>>> for- tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>>>>>>
>>>>>> Changes in V2:
>>>>>> 1. Use sysfs_emit instead of sprintf.
>>>>>> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-
>>>>>> show- for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
>>>>>> ---
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 34 ++++++++++++++
>>>>>> + + + + +++++++++-
>>>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
>>>>>> 2 files changed, 35 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.c
>>>>>> index da77bdaad0a4..c8339b973bfc 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
>>>>>> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata
>>>>>> *drvdata)
>>>>>> static int tpdm_enable(struct coresight_device *csdev, struct
>>>>>> perf_event *event,
>>>>>> enum cs_mode mode,
>>>>>> - __maybe_unused struct coresight_path *path)
>>>>>> + struct coresight_path *path)
>>>>>> {
>>>>>> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev-
>>>>>> >dev.parent);
>>>>>> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device
>>>>>> *csdev, struct perf_event *event,
>>>>>> }
>>>>>> __tpdm_enable(drvdata);
>>>>>> + drvdata->traceid = path->trace_id;
>>>>>> drvdata->enable = true;
>>>>>> spin_unlock(&drvdata->spinlock);
>>>>>> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
>>>>>> .attrs = tpdm_attrs,
>>>>>> };
>>>>>> +static ssize_t traceid_show(struct device *dev,
>>>>>> + struct device_attribute *attr, char *buf)
>>>>>> +{
>>>>>> + unsigned long val;
>>>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>>>> +
>>>>>> + if (coresight_get_mode(drvdata->csdev) == CS_MODE_DISABLED)
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + val = drvdata->traceid;
>>>>>
>>>>> You probably need to take the coresight_mutex here otherwise you
>>>>> could still return an invalid or stale value despite checking the
>>>>> mode.
>>>>>
>>>>
>>>> Acked. I have missed this potential race condition.
>>>>
>>>>> There might also be some value in it returning the last used trace
>>>>> ID even if the mode isn't enabled anymore. Because you can still
>>>>> read out of the sink after disabling, so it makes more sense for a
>>>>> script to read it at that point rather than when it's enabled.
>>>>> Also, you probably don't want to be doing other things in your
>>>>> script in the point between enabling and disabling.
>>>>
>>>> That's making sense. I shouldnt add such restriction for the read
>>>> process.
>>>>
>>>
>>> I missed one point in last message.
>>>
>>> Is that acceptable to export the coresight_mutex from the core module?
>>> Currently, the coresight_mutex is used within the module only.
>>>
>>> Thanks,
>>> Jie
>>>
>>
>> If the plan is to only check for non-zero trace ID and not check the
>> mode any more then you don't need to lock. Maybe lets see what Suzuki
>> thinks about returning the last trace ID though as it was his idea to
>> add -EINVAL.
>>
>
> I think there is value in reading out the traceid that was used. Also,
> I assume TPDM is always connected to a TPDA port and the traceID
> wouldn't change, ever ?
>
Yes.
> I am happy with the proposal
>
James also agrees this proposal in other thread. I will submit a new
patch to address it.
ABI document missed in this patch also, I will add it in the new patch.
Thanks,
Jie
> Suzuki
>
>>>> Scenarios for reading:
>>>> 1. device is enabled -> trace ID is valid
>>>> 2. device is enabled then disabled -> trace ID is valid for the last
>>>> trace event
>>>> 3. device is never enabled -> invalid trace ID (value 0)
>>>>
>>>> we only need to check the validation of the trace ID.
>>>>
>>>> mutex_lock(&coresight_mutex);
>>>> val = drvdata->traceid;
>>>> mutex_unlock(&coresight_mutex);
>>>>
>>>> if (!val)
>>>> return -EINVAL;
>>>>
>>>> return sysfs_emit(buf, "%#lx\n", val);
>>>>
>>>> Thanks,
>>>> Jie
>>>>
>>>>>
>>>>>> + return sysfs_emit(buf, "%#lx\n", val);
>>>>>> +}
>>>>>> +static DEVICE_ATTR_RO(traceid);
>>>>>> +
>>>>>> +static struct attribute *traceid_attrs[] = {
>>>>>> + &dev_attr_traceid.attr,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static struct attribute_group traceid_attr_grp = {
>>>>>> + .attrs = traceid_attrs,
>>>>>> +};
>>>>>> +
>>>>>> static ssize_t dsb_mode_show(struct device *dev,
>>>>>> struct device_attribute *attr,
>>>>>> char *buf)
>>>>>> @@ -1367,6 +1391,12 @@ static const struct attribute_group
>>>>>> *tpdm_attr_grps[] = {
>>>>>> &tpdm_cmb_patt_grp,
>>>>>> &tpdm_cmb_msr_grp,
>>>>>> &tpdm_mcmb_attr_grp,
>>>>>> + &traceid_attr_grp,
>>>>>> + NULL,
>>>>>> +};
>>>>>> +
>>>>>> +static const struct attribute_group *static_tpdm_attr_grps[] = {
>>>>>> + &traceid_attr_grp,
>>>>>> NULL,
>>>>>> };
>>>>>> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev,
>>>>>> struct resource *res)
>>>>>> desc.access = CSDEV_ACCESS_IOMEM(base);
>>>>>> if (res)
>>>>>> desc.groups = tpdm_attr_grps;
>>>>>> + else
>>>>>> + desc.groups = static_tpdm_attr_grps;
>>>>>> drvdata->csdev = coresight_register(&desc);
>>>>>> if (IS_ERR(drvdata->csdev))
>>>>>> return PTR_ERR(drvdata->csdev);
>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/
>>>>>> drivers/ hwtracing/coresight/coresight-tpdm.h
>>>>>> index 2867f3ab8186..11da64e1ade8 100644
>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
>>>>>> @@ -300,6 +300,7 @@ struct cmb_dataset {
>>>>>> * @cmb Specifics associated to TPDM CMB.
>>>>>> * @dsb_msr_num Number of MSR supported by DSB TPDM
>>>>>> * @cmb_msr_num Number of MSR supported by CMB TPDM
>>>>>> + * @traceid Trace ID of the path.
>>>>>> */
>>>>>> struct tpdm_drvdata {
>>>>>> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
>>>>>> struct cmb_dataset *cmb;
>>>>>> u32 dsb_msr_num;
>>>>>> u32 cmb_msr_num;
>>>>>> + u8 traceid;
>>>>>> };
>>>>>> /* Enumerate members of various datasets */
>>>>>>
>>>>>> ---
>>>>>> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
>>>>>> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>>>>>>
>>>>>> Best regards,
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [GIT PULL 1/7] dt-bindings: Changes for v7.1-rc1
From: Krzysztof Kozlowski @ 2026-03-31 9:50 UTC (permalink / raw)
To: Thierry Reding
Cc: arm, soc, Thierry Reding, Jon Hunter, linux-tegra,
linux-arm-kernel
In-Reply-To: <act9hqxjL6wZ25dP@orome>
On 31/03/2026 10:25, Thierry Reding wrote:
>
>>> dt-bindings: phy: tegra-xusb: Document Type C support
>>
>> No acks, but that is waiting for one month so it is fine.
>
> It's got a Reviewed-by from Rob and there were no corresponding driver
> changes associated with it. There's literally no reason for this to go
> in through a subsystem tree.
There are reasons - process and technical:
1. It's a subsystem maintainer's patch, not yours. You rather should
have reason to take someone else's patches.
2. Conflict in that file.
>
>>> dt-bindings: clock: tegra124-dfll: Convert to json-schema
>>> dt-bindings: interrupt-controller: tegra: Fix reg entries
>>> dt-bindings: arm: tegra: Add missing compatible strings
>>> dt-bindings: phy: tegra: Document Tegra210 USB PHY
>>> dt-bindings: memory: Add Tegra210 memory controller bindings
>>> dt-bindings: memory: tegra210: Mark EMC as cooling device
>>
>> That's even my subsystem and I did not ack it. You did not even sent it
>> to me as requested by MAINTAINERS file (+dt is ignore alias), so
>> obviously I did not even had a chance to ack it.
>
> Ugh... really? I was Cc'ed to you as a DT maintainer as well as the
> devicetree mailing list, so I'm sure you've seen it. This had also been
Really, you are supposed to use get_maintainers.pl. Not invent the CC
list, not come with own filtered list.
I understand that my non dt address disappears when running
get_maintainers.pl on entire set.
But if you sent that patch targetting subsystem instead of combining 6
or 7 subsystems at once, it would pop up.
And yes, you are not supposed to mix 7 different subsystems in single
patchset. That's basic!
But sure, let's skip memory controllers patch cc list and:
> reviewed by Rob a long time ago, and honestly, it's also quite trivial.
> It's been on the list for a month and there were no objections, so it
> does pass all of the criteria you mentioned before.
No objections because you did not cc people. How can you claim "no
objections from person foo" if you do not cc person "foo", because you
do not use get_maintainers.pl?
Look, find me here phy mantainers:
https://lore.kernel.org/all/20260223143305.3771383-7-thierry.reding@kernel.org/
>
>> And we even had few days ago talk were I explained you how these
>> bindings must go. Seeing pull request completely ignoring that
>> discussion is just huge surprise.
>>
>> No, it cannot go in. Send patches to proper maintainers first.
>
> Stop making these baseless accusations, Krzysztof. You were on Cc and
Not using get_maintainers.pl so not ccing right address is not baseless.
This is the fact.
Neither phy, nor interrupts, nor clocks were sent to right people.
You mixed 6 or 7 different subsystems in on patchset, but you call my
remarks as baseless. You use several adjectives "trivial", "baseless",
but no actual facts.
Final commentary:
Stop taking patches from other subsystems, just because you want to
streamline your DTS. You are bypassing other subsystems review, other
people trees, and that's not acceptable.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] Enable Mali G310 GPU support on i.MX952 board
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
IP as the instance on i.MX95 boards.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
---
Guangliu Ding (2):
dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
arm64: dts: imx952: Describe Mali G310 GPU
.../bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 ++++++++++++++++++++++
2 files changed, 37 insertions(+)
---
base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
change-id: 20260331-master-7ec7ff0fe1b2
Best regards,
--
Guangliu Ding <guangliu.ding@nxp.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
In-Reply-To: <20260331-master-v1-0-65c8e318d462@nxp.com>
Add compatible string of Mali G310 GPU on i.MX952 board.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
---
Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index 8eccd4338a2b..6a10843a26e2 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -20,6 +20,7 @@ properties:
- enum:
- mediatek,mt8196-mali
- nxp,imx95-mali # G310
+ - nxp,imx952-mali # G310
- rockchip,rk3588-mali
- const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
--
2.34.1
^ 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