* Re: [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from the linear map
From: Ard Biesheuvel @ 2026-06-09 6:31 UTC (permalink / raw)
To: Marek Szyprowski, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh
In-Reply-To: <6a9c0f55-fe98-4063-864b-8f7e1f4fefd7@samsung.com>
On Tue, 9 Jun 2026, at 08:28, Marek Szyprowski wrote:
> On 09.06.2026 08:22, Marek Szyprowski wrote:
>> On 29.05.2026 17:02, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>
>>> The linear aliases of the kernel text and rodata are also mapped
>>> read-only in the linear map. Given that the contents of these regions
>>> are mostly identical to the version in the loadable image, mapping them
>>> read-only and leaving their contents visible is a reasonable hardening
>>> measure.
>>>
>>> Data and bss, however, are now also mapped read-only but the contents of
>>> these regions are more likely to contain data that we'd rather not leak.
>>> So let's unmap these entirely in the linear map when the kernel is
>>> running normally.
>>>
>>> When going into hibernation or waking up from it, these regions need to
>>> be mapped, so map the region initially, and toggle the valid bit so
>>> map/unmap the region as needed.
>>>
>>> Doing so is required because pages covering the kernel image are marked
>>> as PageReserved, and therefore disregarded for snapshotting by the
>>> hibernate logic unless they are mapped.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>> This commit landed in yesterday's linux-next as commit 63e0b6a5b693
>> ("arm64: mm: Unmap kernel data/bss entirely from the linear map").
>> In my tests I found that it breaks booting of RaspberryPi3 and
>> RaspberryPi4 boards with the following kernel panic:
> One more comment - reverting 63e0b6a5b693 and 53205d56212c (dependent
> change) on top of next-20260608 fixes this issue.
>
Thanks for the report, and for the confirmation that those reverts fix
the issue - this was reported here as well:
https://lore.kernel.org/all/aicVyebkEMs6w6UV@sirena.co.uk/
^ permalink raw reply
* Re: [PATCH v3 04/15] clk: imx: scu: use clk_determine_rate_noop()
From: Abel Vesa @ 2026-06-09 6:32 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-kernel,
Abel Vesa, Frank Li, Sascha Hauer, Peng Fan,
Pengutronix Kernel Team, Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260505-clk-determine-rate-noop-v3-4-f3f829fbacdf@redhat.com>
On 26-05-05 20:49:00, Brian Masney wrote:
> Drop the driver-specific empty determine_rate() function and use the new
> shared clk_determine_rate_noop() helper.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
Acked-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3] clk: imx: Add audio PLL debugfs for K-divider control
From: Abel Vesa @ 2026-06-09 6:32 UTC (permalink / raw)
To: Jacky Bai
Cc: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd,
Brian Masney, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-clk, imx, linux-arm-kernel
In-Reply-To: <20260604-imx8m_pll_debugfs-v3-1-4e331ebc85d7@nxp.com>
On 26-06-04 21:48:01, Jacky Bai wrote:
> Add debugfs support for runtime tuning of the audio PLL K divider,
> which enables fine-grained frequency adjustments for audio PLL.
> This is used for:
> - Audio clock calibration and testing
> - Debugging audio synchronization issues
>
> Two debug interfaces are exported to userspace:
> - delta_k: It is used to adjust the K divider in PLL based on small
> steps
> - pll_parameter: It is used for get PLL's current M-divider,
> P-divider, S-divider & K-divider setting in PLL register
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH 3/3] dt-bindings: perf: marvell: Extend CN10K TAD PMU binding for CN20K
From: Geethasowjanya Akula @ 2026-06-09 6:36 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
mark.rutland@arm.com, will@kernel.org, krzk+dt@kernel.org
In-Reply-To: <20260608-spiral-unsterile-66189c3241f8@spud>
>-----Original Message-----
>From: Conor Dooley <conor@kernel.org>
>Sent: Monday, June 8, 2026 11:05 PM
>To: Geethasowjanya Akula <gakula@marvell.com>
>Cc: linux-perf-users@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
>kernel@lists.infradead.org; devicetree@vger.kernel.org;
>mark.rutland@arm.com; will@kernel.org; krzk+dt@kernel.org
>Subject: [EXTERNAL] Re: [PATCH 3/3] dt-bindings: perf: marvell: Extend CN10K
>TAD PMU binding for CN20K
>
>On Sun, Jun 07, 2026 at 06:21:01PM +0530, Geetha sowjanya wrote:
>> Allow marvell,cn20k-tad-pmu alongside marvell,cn10k-tad-pmu, document
>> CN20K in the title and description, add a maintainer, and include a
>> CN20K example node with the same required properties as CN10K.
>
>This is great and all, but is evident from the diff (other than the fact it talks
>about an example that does not exist).
>What is missing is an explanation of why a fallback comaptible is not usable.
CN20K requires a distinct compatible because the PFC/PRF register offsets relative to each TAD base differ from CN10K, and these offsets are not described via DT properties.
In addition, CN20K introduces new events that are not supported on CN10K.
Due to these differences, using marvell,cn10k-tad-pmu as a fallback would result in incorrect configuration.
I will update the commit message in the next revision to clarify this.
Thanks,
Geetha
>pw-bot: changes-requested
>
>Thanks,
>Conor.
>
>>
>> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
>> ---
>> .../bindings/perf/marvell-cn10k-tad.yaml | 20 +++++++++++--------
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> b/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> index 362142252667..1612052b59ae 100644
>> --- a/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> +++ b/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml
>> @@ -4,23 +4,27 @@
>> $id: http://devicetree.org/schemas/perf/marvell-cn10k-tad.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Marvell CN10K LLC-TAD performance monitor
>> +title: Marvell CN10K / CN20K LLC-TAD performance monitor
>>
>> maintainers:
>> - Bhaskara Budiredla <bbudiredla@marvell.com>
>> + - Geetha sowjanya <gakula@marvell.com>
>>
>> description: |
>> - The Tag-and-Data units (TADs) maintain coherence and contain CN10K
>> - shared on-chip last level cache (LLC). The tad pmu measures the
>> - performance of last-level cache. Each tad pmu supports up to eight
>> - counters.
>> + The Tag-and-Data units (TADs) maintain coherence and contain the
>> + shared on-chip last level cache (LLC) on Marvell CN10K and CN20K SoCs.
>> + The TAD PMU measures last-level cache performance. Each TAD PMU
>> + supports up to eight counters.
>>
>> - The DT setup comprises of number of tad blocks, the sizes of pmu
>> - regions, tad blocks and overall base address of the HW.
>> + The DT setup describes the number of TAD blocks, the sizes of PMU
>> + regions and TAD pages, and the overall MMIO base of the hardware.
>>
>> properties:
>> compatible:
>> - const: marvell,cn10k-tad-pmu
>> + items:
>> + - enum:
>> + - marvell,cn10k-tad-pmu
>> + - marvell,cn20k-tad-pmu
>>
>> reg:
>> maxItems: 1
>> --
>> 2.25.1
>>
>>
^ permalink raw reply
* Re: [PATCH v4] i2c: cadence: Add shutdown handler
From: Andi Shyti @ 2026-06-09 6:39 UTC (permalink / raw)
To: Ajay Neeli
Cc: git, linux-arm-kernel, linux-i2c, linux-kernel, michal.simek,
srinivas.goud, radhey.shyam.pandey
In-Reply-To: <20260430053050.3590173-1-ajay.neeli@amd.com>
Hi Ajay,
On Thu, Apr 30, 2026 at 11:00:50AM +0530, Ajay Neeli wrote:
> During system reboot or kexec, in-flight I2C transfers can cause
> spurious interrupts or leave the bus in an undefined state. Add a
> shutdown handler that marks the adapter suspended and resets the
> controller, ensuring a clean handoff.
>
> Signed-off-by: Ajay Neeli <ajay.neeli@amd.com>
Michal's ack was missing here.
Merged to i2c/i2c-host.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v4] i2c: cadence: Add shutdown handler
From: Michal Simek @ 2026-06-09 6:44 UTC (permalink / raw)
To: Andi Shyti, Ajay Neeli
Cc: git, linux-arm-kernel, linux-i2c, linux-kernel, srinivas.goud,
radhey.shyam.pandey
In-Reply-To: <aiez0H0PPX2NYkyv@zenone.zhora.eu>
On 6/9/26 08:39, Andi Shyti wrote:
> Hi Ajay,
>
> On Thu, Apr 30, 2026 at 11:00:50AM +0530, Ajay Neeli wrote:
>> During system reboot or kexec, in-flight I2C transfers can cause
>> spurious interrupts or leave the bus in an undefined state. Add a
>> shutdown handler that marks the adapter suspended and resets the
>> controller, ensuring a clean handoff.
>>
>> Signed-off-by: Ajay Neeli <ajay.neeli@amd.com>
>
> Michal's ack was missing here.
>
> Merged to i2c/i2c-host.
I have reviewed this patch internally too.
Just checking why I missed it.
Anyway the patch is fine for me.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Krzysztof Kozlowski @ 2026-06-09 6:44 UTC (permalink / raw)
To: Joakim Zhang, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <SEYPR06MB622609AFF7C23086A0D53E12821D2@SEYPR06MB6226.apcprd06.prod.outlook.com>
On 09/06/2026 08:25, Joakim Zhang wrote:
>>>
>>> + clock-controller:
>>> + $ref: /schemas/clock/cix,sky1-audss-clock.yaml#
>>> + description:
>>> + AUDSS internal clock provider (cix,sky1-audss-system-control only).
>>
>> Are you sure this patch builds? Your cover letter should explain merging
>> dependencies/strategy/constraints in the first chapter. You start with THE MOST
>> important information.
> yes, I build yaml with below cmd:
> make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/clock/cix,sky1-audss-clock.yaml
> make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- dt_binding_check CHECK_DTBS=y W=1 cix/sky1-orion-o6.dtb
>
> It's also possible that I compiled the entire patch set after it was completed. This is incorrect because there are dependencies involved. I will check it again carefully.
I want to know about this patch alone. I am pretty sure it does not and
it simply fails because it is non-bisectable.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 14/78] drm/bridge: imx8mp-hdmi-pvi: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:47 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-14-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:56PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Liu Ying <victor.liu@nxp.com>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 15/78] drm/bridge: imx8qm-ldb: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:51 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-15-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:57PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qm-ldb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
> index a6ca4f5c6cc6..a654c27356a7 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
> @@ -387,11 +387,11 @@ imx8qm_ldb_bridge_mode_valid(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qm_ldb_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .mode_valid = imx8qm_ldb_bridge_mode_valid,
> .attach = ldb_bridge_attach_helper,
> .atomic_check = imx8qm_ldb_bridge_atomic_check,
> .mode_set = imx8qm_ldb_bridge_mode_set,
> .atomic_enable = imx8qm_ldb_bridge_atomic_enable,
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 16/78] drm/bridge: imx8qxp-ldb: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-16-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:58PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
> index a7906314ade1..1c71697a2083 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
> @@ -402,11 +402,11 @@ imx8qxp_ldb_bridge_mode_valid(struct drm_bridge *bridge,
>
> static const struct drm_bridge_funcs imx8qxp_ldb_bridge_funcs = {
> .destroy = imx8qxp_ldb_bridge_destroy,
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .mode_valid = imx8qxp_ldb_bridge_mode_valid,
> .attach = ldb_bridge_attach_helper,
> .atomic_check = imx8qxp_ldb_bridge_atomic_check,
> .mode_set = imx8qxp_ldb_bridge_mode_set,
> .atomic_pre_enable = imx8qxp_ldb_bridge_atomic_pre_enable,
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 17/78] drm/bridge: imx8qxp-pixel-combiner: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-17-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:35:59PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> index e0ee51a9ca7f..941ce2f91e9e 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> @@ -249,11 +249,11 @@ imx8qxp_pc_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qxp_pc_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .mode_valid = imx8qxp_pc_bridge_mode_valid,
> .attach = imx8qxp_pc_bridge_attach,
> .mode_set = imx8qxp_pc_bridge_mode_set,
> .atomic_disable = imx8qxp_pc_bridge_atomic_disable,
> .atomic_get_input_bus_fmts =
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 18/78] drm/bridge: imx8qxp-pixel-link: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-18-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:36:00PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> index ee6b6dbbe952..92b8b1ac35d0 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> @@ -227,11 +227,11 @@ imx8qxp_pixel_link_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qxp_pixel_link_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .attach = imx8qxp_pixel_link_bridge_attach,
> .mode_set = imx8qxp_pixel_link_bridge_mode_set,
> .atomic_enable = imx8qxp_pixel_link_bridge_atomic_enable,
> .atomic_disable = imx8qxp_pixel_link_bridge_atomic_disable,
> .atomic_get_input_bus_fmts =
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 19/78] drm/bridge: imx8qxp-pxl2dpi: Switch to atomic_create_state
From: Liu Ying @ 2026-06-09 6:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
dri-devel, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-19-0a91018bf886@kernel.org>
On Mon, Jun 08, 2026 at 04:36:01PM +0200, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Liu Ying <victor.liu@nxp.com>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> index 87305d3e0c39..2fc9831f7e61 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> @@ -208,11 +208,11 @@ imx8qxp_pxl2dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> }
>
> static const struct drm_bridge_funcs imx8qxp_pxl2dpi_bridge_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> - .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_create_state = drm_atomic_helper_bridge_create_state,
Nit: drop a tab after .atomic_create_state to align '=' characters vertically.
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> .attach = imx8qxp_pxl2dpi_bridge_attach,
> .destroy = imx8qxp_pxl2dpi_bridge_destroy,
> .atomic_check = imx8qxp_pxl2dpi_bridge_atomic_check,
> .mode_set = imx8qxp_pxl2dpi_bridge_mode_set,
> .atomic_disable = imx8qxp_pxl2dpi_bridge_atomic_disable,
>
> --
> 2.54.0
>
--
Regards,
Liu Ying
^ permalink raw reply
* [PATCH v6 15/21] RISC-V: perf: Use config2/vendor table for event to counter mapping
From: Atish Patra @ 2026-06-09 6:01 UTC (permalink / raw)
To: James Clark, Rob Herring, Atish Patra, Arnaldo Carvalho de Melo,
Jiri Olsa, Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers
Cc: linux-riscv, linux-kernel, linux-perf-users, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <20260608-counter_delegation-v6-0-285b72ed65a9@meta.com>
From: Atish Patra <atishp@rivosinc.com>
The counter restriction specified in the json file is passed to
the drivers via config2 paarameter in perf attributes. This allows
any platform vendor to define their custom mapping between event and
hpmcounters without any rules defined in the ISA.
For legacy events, the platform vendor may define the mapping in
the driver in the vendor event table.
The fixed cycle and instruction counters are fixed (0 and 2
respectively) by the ISA and maps to the legacy events. The platform
vendor must specify this in the driver if intended to be used while
profiling. Otherwise, they can just specify the alternate hpmcounters
that may monitor and/or sample the cycle/instruction counts.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
drivers/perf/riscv_pmu_sbi.c | 90 ++++++++++++++++++++++++++++++++++--------
include/linux/perf/riscv_pmu.h | 2 +
2 files changed, 76 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 5bfcd3821f57..4b4f151a0744 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -76,6 +76,7 @@ static ssize_t __maybe_unused rvpmu_format_show(struct device *dev, struct devic
RVPMU_ATTR_ENTRY(_name, rvpmu_format_show, (char *)_config)
PMU_FORMAT_ATTR(firmware, "config:62-63");
+PMU_FORMAT_ATTR(counterid_mask, "config2:0-31");
static bool sbi_v2_available;
static bool sbi_v3_available;
@@ -120,6 +121,7 @@ static const struct attribute_group *riscv_sbi_pmu_attr_groups[] = {
static struct attribute *riscv_cdeleg_pmu_formats_attr[] = {
RVPMU_FORMAT_ATTR_ENTRY(event, RVPMU_CDELEG_PMU_FORMAT_ATTR),
&format_attr_firmware.attr,
+ &format_attr_counterid_mask.attr,
NULL,
};
@@ -1480,24 +1482,80 @@ static int rvpmu_deleg_find_ctrs(void)
return num_hw_ctr;
}
+/*
+ * The json file must correctly specify counter 0 or counter 2 is available
+ * in the counter lists for cycle/instret events. Otherwise, the drivers have
+ * no way to figure out if a fixed counter must be used and pick a programmable
+ * counter if available.
+ */
static int get_deleg_fixed_hw_idx(struct cpu_hw_events *cpuc, struct perf_event *event)
{
- return -EINVAL;
+ struct hw_perf_event *hwc = &event->hw;
+ bool guest_events = event->attr.config1 & RISCV_PMU_CONFIG1_GUEST_EVENTS;
+
+ if (guest_events) {
+ if (hwc->event_base == SBI_PMU_HW_CPU_CYCLES)
+ return 0;
+ if (hwc->event_base == SBI_PMU_HW_INSTRUCTIONS)
+ return 2;
+ else
+ return -EINVAL;
+ }
+
+ if (!event->attr.config2)
+ return -EINVAL;
+
+ if (event->attr.config2 & RISCV_PMU_CYCLE_FIXED_CTR_MASK)
+ return 0; /* CY counter */
+ else if (event->attr.config2 & RISCV_PMU_INSTRUCTION_FIXED_CTR_MASK)
+ return 2; /* IR counter */
+ else
+ return -EINVAL;
}
static int get_deleg_next_hpm_hw_idx(struct cpu_hw_events *cpuc, struct perf_event *event)
{
- unsigned long hw_ctr_mask = 0;
+ u32 hw_ctr_mask = 0, temp_mask = 0;
+ u32 type = event->attr.type;
+ u64 config = event->attr.config;
+ int ret;
- /*
- * TODO: Treat every hpmcounter can monitor every event for now.
- * The event to counter mapping should come from the json file.
- * The mapping should also tell if sampling is supported or not.
- */
+ /* Select only available hpmcounters */
+ hw_ctr_mask = cmask & (~0x7) & ~(cpuc->used_hw_ctrs[0]);
+
+ switch (type) {
+ case PERF_TYPE_HARDWARE:
+ temp_mask = current_pmu_hw_event_map[config].counter_mask;
+ break;
+ case PERF_TYPE_HW_CACHE:
+ ret = cdeleg_pmu_event_find_cache(config, NULL, &temp_mask);
+ if (ret)
+ return ret;
+ break;
+ case PERF_TYPE_RAW:
+ /*
+ * Mask off the counters that can't monitor this event (specified via json)
+ * The counter mask for this event is set in config2 via the property 'Counter'
+ * in the json file or manual configuration of config2. If the config2 is not set,
+ * it is assumed all the available hpmcounters can monitor this event.
+ * Note: This assumption may fail for virtualization use case where they hypervisor
+ * (e.g. KVM) virtualizes the counter. Any event to counter mapping provided by the
+ * guest is meaningless from a hypervisor perspective. Thus, the hypervisor doesn't
+ * set config2 when creating kernel counter and relies default host mapping.
+ */
+ if (event->attr.config2)
+ temp_mask = event->attr.config2;
+ break;
+ default:
+ break;
+ }
+
+ if (temp_mask)
+ hw_ctr_mask &= temp_mask;
+
+ if (!hw_ctr_mask)
+ return -EINVAL;
- /* Select only hpmcounters */
- hw_ctr_mask = cmask & (~0x7);
- hw_ctr_mask &= ~(cpuc->used_hw_ctrs[0]);
return __ffs(hw_ctr_mask);
}
@@ -1526,10 +1584,6 @@ static int rvpmu_deleg_ctr_get_idx(struct perf_event *event)
u64 priv_filter;
int idx;
- /*
- * TODO: We should not rely on SBI Perf encoding to check if the event
- * is a fixed one or not.
- */
if (!is_sampling_event(event)) {
idx = get_deleg_fixed_hw_idx(cpuc, event);
if (idx == 0 || idx == 2) {
@@ -1547,10 +1601,14 @@ static int rvpmu_deleg_ctr_get_idx(struct perf_event *event)
goto out_err;
found_idx:
priv_filter = get_deleg_priv_filter_bits(event);
+ if (test_and_set_bit(idx, cpuc->used_hw_ctrs))
+ goto out_err;
update_deleg_hpmevent(idx, hwc->config, priv_filter);
+ return idx;
skip_update:
- if (!test_and_set_bit(idx, cpuc->used_hw_ctrs))
- return idx;
+ if (test_and_set_bit(idx, cpuc->used_hw_ctrs))
+ goto out_err;
+ return idx;
out_err:
return -ENOENT;
}
diff --git a/include/linux/perf/riscv_pmu.h b/include/linux/perf/riscv_pmu.h
index f6a710c83a4c..06171e7aadfb 100644
--- a/include/linux/perf/riscv_pmu.h
+++ b/include/linux/perf/riscv_pmu.h
@@ -30,6 +30,8 @@
#define RISCV_PMU_CONFIG1_GUEST_EVENTS 0x1
#define RISCV_PMU_DELEG_RAW_EVENT_MASK GENMASK_ULL(55, 0)
+#define RISCV_PMU_CYCLE_FIXED_CTR_MASK 0x01
+#define RISCV_PMU_INSTRUCTION_FIXED_CTR_MASK 0x04
#define HW_OP_UNSUPPORTED 0xFFFF
#define CACHE_OP_UNSUPPORTED 0xFFFF
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH v3] clocksource: move NXP timer selection to drivers/clocksource
From: Enric Balletbo i Serra @ 2026-06-09 6:57 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Russell King, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Lezcano, Thomas Gleixner, linux-arm-kernel,
imx, linux-kernel
In-Reply-To: <20260514-fix-nxp-timer-v3-1-a3e68fdb505e@redhat.com>
Hi all,
On Thu, May 14, 2026 at 1:14 PM Enric Balletbo i Serra
<eballetbo@kernel.org> wrote:
>
> From: Enric Balletbo i Serra <eballetb@redhat.com>
>
> The Kconfig logic for selecting the scheduler clocksource on
> NXP Vybrid (VF610) uses a `choice` block restricted to 32-bit ARM. This
> prevents 64-bit architectures, such as the NXP S32 family, from enabling
> the NXP Periodic Interrupt Timer (PIT) driver (CONFIG_NXP_PIT_TIMER).
>
> Relocate the NXP clocksource selection from arch/arm/mach-imx/Kconfig to
> drivers/clocksource/Kconfig. This allows the configuration to be shared
> across different architectures.
>
> Update the selection to include support for ARCH_S32 and add a "None"
> option restricted to ARCH_S32, since Vybrid lacks the ARM Architected
> Timer. The Vybrid Global Timer option is restricted to ARCH_MULTI_V7
> SOC_VF610 platforms to prevent it from being visible on Cortex-M4 builds,
> which lack the ARM Global Timer hardware.
>
> Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support")
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
Now that Frank [1] has created a merge request for Linux 7.1-rc1 and
the request includes
arm64: dts: s32g: add PIT support for s32g2 and s32g3
If this patch is ok, would it make sense to pick that patch?
Otherwise, we won't be able to select the PIT timer for aarch64 only
builds.
Thanks.,
Enric
[1] From: Frank.Li@nxp.com
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git
tags/imx-dt64-7.2
for you to fetch changes up to c10cfc952215644956284a42fa7b7860dfbcb5f5:
> ---
> Changes in v3:
> - Restrict VF_TIMER_NONE to ARCH_S32 to prevent selecting it on Vybrid
> platforms which lack the ARM Architected Timer
> - Link to v2: https://lore.kernel.org/r/20260513-fix-nxp-timer-v2-1-533b99c57b67@redhat.com
>
> Changes in v2:
> - Fix VF_USE_ARM_GLOBAL_TIMER dependency: use ARCH_MULTI_V7 instead of
> ARM to prevent the option from being visible on Cortex-M4 builds
> (Sashiko AI review)
> - Link to v1: https://lore.kernel.org/r/20260302-fix-nxp-timer-v1-1-af4bc62d4ffa@redhat.com
> ---
> arch/arm/mach-imx/Kconfig | 21 ---------------------
> drivers/clocksource/Kconfig | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 6ea1bd55acf8..a361840d7a04 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -227,27 +227,6 @@ config SOC_VF610
> help
> This enables support for Freescale Vybrid VF610 processor.
>
> -choice
> - prompt "Clocksource for scheduler clock"
> - depends on SOC_VF610
> - default VF_USE_ARM_GLOBAL_TIMER
> -
> - config VF_USE_ARM_GLOBAL_TIMER
> - bool "Use ARM Global Timer"
> - depends on ARCH_MULTI_V7
> - select ARM_GLOBAL_TIMER
> - select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
> - help
> - Use the ARM Global Timer as clocksource
> -
> - config VF_USE_PIT_TIMER
> - bool "Use PIT timer"
> - select NXP_PIT_TIMER
> - help
> - Use SoC Periodic Interrupt Timer (PIT) as clocksource
> -
> -endchoice
> -
> endif
>
> endif
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index d1a33a231a44..d9c76dd443f8 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -793,4 +793,35 @@ config RTK_SYSTIMER
> this option only when building for a Realtek platform or for compilation
> testing.
>
> +choice
> + prompt "NXP clocksource for scheduler clock"
> + depends on SOC_VF610 || ARCH_S32
> + # Default to Global Timer for Vybrid (32-bit)
> + default VF_USE_ARM_GLOBAL_TIMER if SOC_VF610
> + # Default to None for S32 (64-bit)
> + default VF_TIMER_NONE if ARCH_S32
> +
> + config VF_USE_ARM_GLOBAL_TIMER
> + bool "Use NXP Vybrid Global Timer"
> + depends on ARCH_MULTI_V7 && SOC_VF610
> + select ARM_GLOBAL_TIMER
> + select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
> + help
> + Use the NXP Vybrid Global Timer as clocksource.
> +
> + config VF_USE_PIT_TIMER
> + bool "Use NXP PIT timer"
> + select NXP_PIT_TIMER
> + help
> + Use NXP Periodic Interrupt Timer (PIT) as clocksource.
> +
> + config VF_TIMER_NONE
> + bool "None (Use standard Arch Timer)"
> + depends on ARCH_S32
> + help
> + Do not use any specific NXP timer driver. Use the standard
> + ARM Architected Timer instead.
> +
> +endchoice
> +
> endmenu
>
> ---
> base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
> change-id: 20260302-fix-nxp-timer-9cb1fbd7afcd
>
> Best regards,
> --
> Enric Balletbo i Serra <eballetb@redhat.com>
>
^ permalink raw reply
* Re: [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum
From: Ashish Mhetre @ 2026-06-09 7:07 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, robin.murphy, joro, nicolinc, linux-arm-kernel,
iommu, linux-kernel, linux-tegra
In-Reply-To: <20260605141053.GF2487554@ziepe.ca>
On 6/5/2026 7:40 PM, Jason Gunthorpe wrote:
> External email: Use caution opening links or attachments
>
>
> On Fri, Jun 05, 2026 at 07:35:35PM +0530, Ashish Mhetre wrote:
>>>> +{
>>>> + if (!(smmu->options & ARM_SMMU_OPT_TLBI_TWICE))
>>>> + return false;
>>> Maybe we should make this a static key?
>> Okay. Shall I add just static key and remove option bit, or
>> have static key alongside existing option bit such that
>> static_branch_unlikely will precede the option bit check?
> You'd have the static key and the options. Keep it simple, enable the
> static key once if any driver probes to set TWICE. Check the key
> before options to get the best code gen
Okay, I'll incorporate this in V4 and send.
> But IDK if it is really worth it, there are already lots of branches
> on the performance tlbi flow, and we didn't do this for other tlbi
> affecting errata..
>
> IDK if we really care about branches we should also be doing things
> like disabling the range/non-range paths and ATC based on what is
> actually in use..
>
> Jason
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Krzysztof Kozlowski @ 2026-06-09 7:08 UTC (permalink / raw)
To: Can Guo
Cc: bvanassche, beanhuo, peter.wang, martin.petersen, mani,
linux-scsi, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Zhaoming Luo, Ram Kumar Dwivedi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek
In-Reply-To: <64bd6272-6111-4ffa-8a4a-366d0c287693@oss.qualcomm.com>
On 31/05/2026 06:48, Can Guo wrote:
>>>> is the minimal encoding that covers both.
>>> Again, why do you need to encode '0'?
>> The tuple is still needed because Precoding is configured per
>> transmitter-receiver pair,
>> so each lane has two independent states:
>> - Host_TX -> Device_RX
>> - Device_TX -> Host_RX
>> A lane-only enabled list cannot represent directional combinations
>> like lane0 =
>> (on, off) vs (off, on).
> How about we split into two properties, something like below?
> tx-precode-enable-g6-host-lanes = <0 1>
> tx-precode-enable-g6-device-lanes = <1>
>
> Only listed lanes are enabled; unlisted lanes are disabled by default.
>
> Are you OK with this approach?
Yes, I do prefer this, because we don't have empty entries (<0, 0>, <0,
1> ....).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RESEND v4 0/8] can: flexcan: Add NXP S32N79 SoC support
From: Ciprian Marian Costea @ 2026-06-09 7:19 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol
Cc: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, linux-can, devicetree,
linux-kernel, imx, linux-arm-kernel, NXP S32 Linux Team,
Christophe Lizzi, Alberto Ruiz, Eric Chanudet
In-Reply-To: <CALE0LRuqZhm03QbYg-ZOJcKe0XqCLqVZ8j-4o07QuBF-OqX9BA@mail.gmail.com>
On 6/3/2026 1:28 PM, Enric Balletbo i Serra wrote:
> Hi Ciprian,
>
> Sorry in advance for the noise, for some strange reason I didn't get
> or find the cover until now, so I added my tested patch in 1. Doing it
> now properly.
>
> On Wed, Jun 3, 2026 at 11:44 AM Bough Chen <haibo.chen@oss.nxp.com> wrote:
Hello Marc and Vincent,
Sorry for bothering. Do you expect any more changes to this V4 patchset ?
Best Regards,
Ciprian
>>
>> On Wed, Jun 03, 2026 at 09:13:34AM +0200, Ciprian Costea wrote:
>>> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>>>
>>> This patch series adds FlexCAN support for the NXP S32N79 SoC.
>>>
>>> The S32N79 is an automotive-grade processor from NXP with multiple
>>> FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
>>> other SoCs in the interrupt routing - it uses two separate interrupt
>>> lines:
>>> - one interrupt for mailboxes 0-127
>>> - one interrupt for bus error detection and device state changes
>>>
>>> The CAN controllers are connected through an irqsteer interrupt
>>> controller in the RCU (Resource Control Unit) domain.
>>>
>>> This series:
>>> 1. Splits flexcan_irq() into dedicated handlers for multi-IRQ platforms
>>> 2. Adds dt-bindings documentation for S32N79 FlexCAN
>>> 3. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
>>> configuration
>>> 4. Adds S32N79 device data and compatible string to the driver
>>> 5. Adds FlexCAN device tree nodes for S32N79 SoC
>>> 6. Enables FlexCAN devices on the S32N79-RDB board
>>>
>>> Tested on S32N79-RDB board with CAN and CAN FD communication.
>>
>> Tested on imx95-19x19-evk board with CAN and CAN FD communication. No issue found.
>> This means this patch set do not impact the original platforms.
>>
>> For this patch set, feel free to add tag:
>> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
>>
>> Regards
>> Haibo Chen
>
> Tested-by: Enric Balletbo i Serra <eballetb@.redhat.com>
>
> Tested on the NXP S32G399A-RDB3 with loopback and high-rate traffic.
> No regressions observed:
> CAN frames transmit and receive correctly, with no duplicates.
> Frame reception showed no errors during stress testing.
>
> Regards,
> Enric Balletbo
>
>>>
>>> This is a resend of v4 with no changes.
>>>
>>> v4 -> v3
>>> - flexcan_chip_interrupts_enable(): disable/enable all IRQ lines
>>> (not just dev->irq) during IMASK register writes
>>> - Split rx/tx masks per mailbox IRQ line (struct flexcan_mb_irq) so
>>> each handler on S32G2 only processes its own MB range
>>> - Added received Acked-by tag on DT bindings patch
>>>
>>> v3 -> v2
>>> - Split flexcan_irq() into dedicated handlers (flexcan_irq_mb,
>>> flexcan_irq_boff, flexcan_irq_berr) to fix duplicate event
>>> processing when multiple IRQ lines run concurrently (new patch).
>>> - Added flexcan_irq_esr() handler composing state + berr for S32N79
>>> - Ordered quirks used by s32n devtype data by value.
>>>
>>> v2 -> v1
>>> - Renamed FLEXCAN_QUIRK_NR_IRQ_2 to FLEXCAN_QUIRK_IRQ_BERR to better
>>> describe the actual hardware feature
>>> - Appended new quirk at the end
>>> - Switched from platform_get_irq to platform_get_irq_byname usage
>>> - Updated interrupt description in dt-bindings
>>>
>>> Ciprian Marian Costea (8):
>>> can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
>>> can: flexcan: disable all IRQ lines in
>>> flexcan_chip_interrupts_enable()
>>> can: flexcan: split rx/tx masks per mailbox IRQ line
>>> dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
>>> can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
>>> can: flexcan: add NXP S32N79 SoC support
>>> arm64: dts: s32n79: add FlexCAN nodes
>>> arm64: dts: s32n79: enable FlexCAN devices
>>>
>>> .../bindings/net/can/fsl,flexcan.yaml | 30 ++-
>>> arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 +
>>> arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 ++++
>>> drivers/net/can/flexcan/flexcan-core.c | 249 +++++++++++++++---
>>> drivers/net/can/flexcan/flexcan.h | 12 +-
>>> 5 files changed, 316 insertions(+), 37 deletions(-)
>>>
>>> --
>>> 2.43.0
>>>
>>
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb
From: Marc Zyngier @ 2026-06-09 7:25 UTC (permalink / raw)
To: Yosry Ahmed
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu
In-Reply-To: <aicqzM4W4NN-GndT@google.com>
On Mon, 08 Jun 2026 21:55:25 +0100,
Yosry Ahmed <yosry@kernel.org> wrote:
>
> On Mon, Jun 08, 2026 at 09:11:08AM +0100, Marc Zyngier wrote:
> > Sashiko reports that there is a race between initialising vncr_tlb
> > and making use of it, as we don't hold the mmu_lock at this point.
> >
> > Additionally, it identifies a memory leak, should userspace repeatedly
> > invokes the KVM_RUN ioctl after a failure of kvm_arch_vcpu_run_pid_change(),
> > as we assign vncr_tlb blindly on first run, irrespective of prior
> > allocations.
> >
> > Slap the two bugs in one go by taking the kvm->mmu_lock on assigning
> > vncr_tlb, preventing the race for good, and by checking that vncr_tlb
> > is indeed NULL prior to allocation.
> >
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Link: https://lore.kernel.org/r/20260607180815.85FBC1F00893@smtp.kernel.org
> > ---
> > arch/arm64/kvm/nested.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 690b8e8564166..d11e36b3cfcc2 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> > @@ -1253,8 +1253,14 @@ int kvm_vcpu_allocate_vncr_tlb(struct kvm_vcpu *vcpu)
> > if (!kvm_has_feat(vcpu->kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY))
> > return 0;
> >
> > - vcpu->arch.vncr_tlb = kzalloc_obj(*vcpu->arch.vncr_tlb,
> > - GFP_KERNEL_ACCOUNT);
> > + if (!vcpu->arch.vncr_tlb) {
> > + struct vncr_tlb *vt = kzalloc_obj(*vcpu->arch.vncr_tlb,
> > + GFP_KERNEL_ACCOUNT);
> > +
> > + scoped_guard(write_lock, &vcpu->kvm->mmu_lock)
> > + vcpu->arch.vncr_tlb = vt;
> > + }
>
> (I am not familiar with this code at all, so apologies in advance if I
> am making an idiot out of myself here)
>
> IIUC, the point of holding the lock here is *not* to protect against
> concurrent initialization, as in this case the NULL check needs to be
> done under the lock.
>
> Rather, the goal is to prevent re-ordering of zeroing from kzalloc and
> the assignment to vcpu->arch.vncr_tlb, by depending on the barriers
> provided by the lock. The lock is held by the readers so holding it here
> conviently means we do not need to add any barriers to the readers.
>
> Is my understanding correct?
It is correct.
>
> If yes, I think the code looks confusing, at least to a layman like
> myself. It initially seems like the lock protects against concurrent
> initializations, but then the NULL check is not done again under the
> lock. The goal of the lock is not clear without the original report.
>
> Mayeb it's clearer to explicitly use barriers if the goal is preventing
> reordering?
This would require both the initialisation of vncr_tlb to use a store
release, *and* all the other call sites to use a load acquire.
I really don't think it is worth the churn, nor the (very small)
burden on the readers.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v6 17/21] RISC-V: perf: Add Qemu virt machine events
From: Atish Patra @ 2026-06-09 6:01 UTC (permalink / raw)
To: James Clark, Rob Herring, Atish Patra, Arnaldo Carvalho de Melo,
Jiri Olsa, Will Deacon, Mark Rutland, Anup Patel, Namhyung Kim,
Paul Walmsley, Krzysztof Kozlowski, Ian Rogers
Cc: linux-riscv, linux-kernel, linux-perf-users, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <20260608-counter_delegation-v6-0-285b72ed65a9@meta.com>
From: Atish Patra <atishp@rivosinc.com>
Qemu virt machine supports a very minimal set of legacy perf events.
Add them to the vendor table so that users can use them when
counter delegation is enabled.
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/vendorid_list.h | 4 ++++
drivers/perf/riscv_pmu_sbi.c | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/riscv/include/asm/vendorid_list.h b/arch/riscv/include/asm/vendorid_list.h
index 7f5030ee1fcf..603aa2b21c0b 100644
--- a/arch/riscv/include/asm/vendorid_list.h
+++ b/arch/riscv/include/asm/vendorid_list.h
@@ -11,4 +11,8 @@
#define SIFIVE_VENDOR_ID 0x489
#define THEAD_VENDOR_ID 0x5b7
+#define QEMU_VIRT_VENDOR_ID 0x000
+#define QEMU_VIRT_IMPL_ID 0x000
+#define QEMU_VIRT_ARCH_ID 0x000
+
#endif
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index 00b84b28117a..74acac54328e 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -26,6 +26,7 @@
#include <asm/sbi.h>
#include <asm/cpufeature.h>
#include <asm/vendor_extensions.h>
+#include <asm/vendorid_list.h>
#include <asm/vendor_extensions/andes.h>
#include <asm/hwcap.h>
#include <asm/csr_ind.h>
@@ -453,7 +454,42 @@ struct riscv_vendor_pmu_events {
.hw_event_map = _hw_event_map, .cache_event_map = _cache_event_map, \
.attrs_events = _attrs },
+/* QEMU virt PMU events */
+static const struct riscv_pmu_event qemu_virt_hw_event_map[PERF_COUNT_HW_MAX] = {
+ PERF_MAP_ALL_UNSUPPORTED,
+ [PERF_COUNT_HW_CPU_CYCLES] = {0x01, 0xFFFFFFF8},
+ [PERF_COUNT_HW_INSTRUCTIONS] = {0x02, 0xFFFFFFF8}
+};
+
+static const struct riscv_pmu_event qemu_virt_cache_event_map[PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+ PERF_CACHE_MAP_ALL_UNSUPPORTED,
+ [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = {0x10019, 0xFFFFFFF8},
+ [C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)] = {0x1001B, 0xFFFFFFF8},
+
+ [C(ITLB)][C(OP_READ)][C(RESULT_MISS)] = {0x10021, 0xFFFFFFF8},
+};
+
+RVPMU_EVENT_CMASK_ATTR(cycles, cycles, 0x01, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(instructions, instructions, 0x02, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(dTLB-load-misses, dTLB_load_miss, 0x10019, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(dTLB-store-misses, dTLB_store_miss, 0x1001B, 0xFFFFFFF8);
+RVPMU_EVENT_CMASK_ATTR(iTLB-load-misses, iTLB_load_miss, 0x10021, 0xFFFFFFF8);
+
+static struct attribute *qemu_virt_event_group[] = {
+ RVPMU_EVENT_ATTR_PTR(cycles),
+ RVPMU_EVENT_ATTR_PTR(instructions),
+ RVPMU_EVENT_ATTR_PTR(dTLB_load_miss),
+ RVPMU_EVENT_ATTR_PTR(dTLB_store_miss),
+ RVPMU_EVENT_ATTR_PTR(iTLB_load_miss),
+ NULL,
+};
+
static struct riscv_vendor_pmu_events pmu_vendor_events_table[] = {
+ RISCV_VENDOR_PMU_EVENTS(QEMU_VIRT_VENDOR_ID, QEMU_VIRT_ARCH_ID, QEMU_VIRT_IMPL_ID,
+ qemu_virt_hw_event_map, qemu_virt_cache_event_map,
+ qemu_virt_event_group)
};
static const struct riscv_pmu_event *current_pmu_hw_event_map;
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH v4 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
In-Reply-To: <20260609073204.1760077-1-amhetre@nvidia.com>
Tegra264 SMMU is affected by an erratum where a TLB entry can survive
an invalidation that races with concurrent traffic targeting the same
entry. The hardware-recommended software workaround is to issue every
CFGI/TLBI command (each followed by CMD_SYNC) twice. The second issue
is guaranteed to evict the entry. ATC_INV is not affected and must
not be doubled.
The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
cannot be detected from hardware registers. Tegra264 boots from device
tree only and has no ACPI/IORT support, so detection is through device
tree only.
Add the ARM_SMMU_OPT_REPEAT_TLBI_CFGI option and set it on instances
matching the existing "nvidia,tegra264-smmu" compatible. Also add a
matching arm_smmu_erratum_repeat_tlbi_cfgi_key static key that DT
probe enables, so the inline classifier compiles down to a single
test+branch on unaffected kernels. Add an
arm_smmu_erratum_cmd_needs_repeating() helper in arm-smmu-v3.h that
gates on the static key first and then range-checks the opcode
(CFGI_STE .. ATC_INV), so subsequent changes wiring the workaround
into the CMDQ submission and iommufd batching paths can share a
single predicate.
No callers consume the option yet. A subsequent change wires the
workaround into the CMDQ issue paths.
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 +++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 24 +++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 76efe479e80f..599c835c50d8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -42,6 +42,8 @@ MODULE_PARM_DESC(disable_msipolling,
static const struct iommu_ops arm_smmu_ops;
static struct iommu_dirty_ops arm_smmu_dirty_ops;
+DEFINE_STATIC_KEY_FALSE(arm_smmu_erratum_repeat_tlbi_cfgi_key);
+
enum arm_smmu_msi_index {
EVTQ_MSI_INDEX,
GERROR_MSI_INDEX,
@@ -5303,8 +5305,11 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
if (of_dma_is_coherent(dev->of_node))
smmu->features |= ARM_SMMU_FEAT_COHERENCY;
- if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu"))
+ if (of_device_is_compatible(dev->of_node, "nvidia,tegra264-smmu")) {
tegra_cmdqv_dt_probe(dev->of_node, smmu);
+ smmu->options |= ARM_SMMU_OPT_REPEAT_TLBI_CFGI;
+ static_branch_enable(&arm_smmu_erratum_repeat_tlbi_cfgi_key);
+ }
return ret;
}
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index c909c9a88538..c6ea3b8dc761 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -11,6 +11,7 @@
#include <linux/bitfield.h>
#include <linux/iommu.h>
#include <linux/iommufd.h>
+#include <linux/jump_label.h>
#include <linux/kernel.h>
#include <linux/mmzone.h>
#include <linux/sizes.h>
@@ -928,6 +929,12 @@ struct arm_smmu_device {
#define ARM_SMMU_OPT_MSIPOLL (1 << 2)
#define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3)
#define ARM_SMMU_OPT_TEGRA241_CMDQV (1 << 4)
+/*
+ * Repeat every {CFGI,TLBI};CMD_SYNC command sequence so that the second
+ * issue executes only after the first issue's CMD_SYNC has completed.
+ * Does not apply to ATC_INV.
+ */
+#define ARM_SMMU_OPT_REPEAT_TLBI_CFGI (1 << 5)
u32 options;
struct arm_smmu_cmdq cmdq;
@@ -1212,6 +1219,23 @@ int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
struct arm_smmu_cmd *cmds, int n,
bool sync);
+DECLARE_STATIC_KEY_FALSE(arm_smmu_erratum_repeat_tlbi_cfgi_key);
+
+static inline bool
+arm_smmu_erratum_cmd_needs_repeating(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmd *cmd)
+{
+ u8 opcode;
+
+ if (!static_branch_unlikely(&arm_smmu_erratum_repeat_tlbi_cfgi_key))
+ return false;
+ if (!(smmu->options & ARM_SMMU_OPT_REPEAT_TLBI_CFGI))
+ return false;
+
+ opcode = FIELD_GET(CMDQ_0_OP, cmd->data[0]);
+ return opcode >= CMDQ_OP_CFGI_STE && opcode < CMDQ_OP_ATC_INV;
+}
+
#ifdef CONFIG_ARM_SMMU_V3_SVA
bool arm_smmu_sva_supported(struct arm_smmu_device *smmu);
void arm_smmu_sva_notifier_synchronize(void);
--
2.50.1
^ permalink raw reply related
* [PATCH v4 1/3] iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
In-Reply-To: <20260609073204.1760077-1-amhetre@nvidia.com>
From: Nicolin Chen <nicolinc@nvidia.com>
arm_smmu_cmdq_batch_add_cmd_p() carries two distinct reasons for
flushing the current batch with a CMD_SYNC before appending the
new command:
- The batch's pre-assigned cmdq does not support the new command.
- The Arm erratum 2812531 workaround (ARM_SMMU_OPT_CMDQ_FORCE_SYNC)
forces a SYNC at one entry before the batch is full.
Lift those checks into a new arm_smmu_cmdq_batch_force_sync() helper
so that adding another force-sync condition becomes a one-line
addition. No functional change.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 23 +++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a10affb483a4..76efe479e80f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -847,16 +847,27 @@ static void arm_smmu_cmdq_batch_init_cmd(struct arm_smmu_device *smmu,
cmds->cmdq = arm_smmu_get_cmdq(smmu, cmd);
}
+static bool arm_smmu_cmdq_batch_force_sync(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmdq_batch *cmds,
+ struct arm_smmu_cmd *cmd)
+{
+ /* The batch's pre-assigned cmdq doesn't support the new command */
+ if (!arm_smmu_cmdq_supports_cmd(cmds->cmdq, cmd))
+ return true;
+
+ /* Arm erratum 2812531 */
+ if (cmds->num == CMDQ_BATCH_ENTRIES - 1 &&
+ (smmu->options & ARM_SMMU_OPT_CMDQ_FORCE_SYNC))
+ return true;
+
+ return false;
+}
+
static void arm_smmu_cmdq_batch_add_cmd_p(struct arm_smmu_device *smmu,
struct arm_smmu_cmdq_batch *cmds,
struct arm_smmu_cmd *cmd)
{
- bool force_sync = (cmds->num == CMDQ_BATCH_ENTRIES - 1) &&
- (smmu->options & ARM_SMMU_OPT_CMDQ_FORCE_SYNC);
- bool unsupported_cmd;
-
- unsupported_cmd = !arm_smmu_cmdq_supports_cmd(cmds->cmdq, cmd);
- if (force_sync || unsupported_cmd) {
+ if (arm_smmu_cmdq_batch_force_sync(smmu, cmds, cmd)) {
arm_smmu_cmdq_issue_cmdlist(smmu, cmds->cmdq, cmds->cmds,
cmds->num, true);
arm_smmu_cmdq_batch_init_cmd(smmu, cmds, cmd);
--
2.50.1
^ permalink raw reply related
* [PATCH v4 3/3] iommu/arm-smmu-v3: Issue CFGI/TLBI twice on Tegra264
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
In-Reply-To: <20260609073204.1760077-1-amhetre@nvidia.com>
Apply the workaround for Tegra264 erratum ARM_SMMU_OPT_REPEAT_TLBI_CFGI
by issuing every CFGI/TLBI cmdlist twice on affected SMMU instances,
with CMD_SYNC after each. The erratum requires this exact sequencing:
TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC
Rename the existing arm_smmu_cmdq_issue_cmdlist() to
__arm_smmu_cmdq_issue_cmdlist() and add a thin wrapper that, on
affected SMMUs and when @sync is true with @n > 0, re-issues the
same cmdlist a second time when arm_smmu_erratum_cmd_needs_repeating()
is true. The @n > 0 gate is needed because arm_smmu_cmdq_batch_add_cmd_p()
can call arm_smmu_cmdq_issue_cmdlist() with @n == 0 and @sync == true
to flush a bare CMD_SYNC when the next command is not supported by
the batch's pre-selected cmdq; the repeat path must not inspect
cmds[0] in that case. The static-key gate inside the predicate means
the wrapper compiles to a single tested branch on unaffected kernels.
For the in-tree batching path, register the new condition with
arm_smmu_cmdq_batch_force_sync() so that a full batch carrying
CFGI/TLBI commands flushes with sync=true.
For the iommufd VSMMU path add an arm_vsmmu_can_batch_cmd() predicate
that splits the iommufd batch at every "needs repeating" transition,
so the wrapper's per-batch decision based on the first command stays
correct even when userspace mixes opcode classes.
Also document the erratum in Documentation/arch/arm64/silicon-errata.rst.
Suggested-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
---
Documentation/arch/arm64/silicon-errata.rst | 2 ++
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 15 +++++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 35 ++++++++++++++++---
3 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 046a7fa47063..96050886a7d6 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -268,6 +268,8 @@ stable kernels.
| | | T241-MPAM-4, | |
| | | T241-MPAM-6 | |
+----------------+-----------------+-----------------+-----------------------------+
+| NVIDIA | T264 SMMU | T264-SMMU-3 | N/A |
++----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+----------------+-----------------+-----------------+-----------------------------+
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
index 1e9f7d2de344..11d22acae613 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
@@ -350,6 +350,18 @@ static int arm_vsmmu_convert_user_cmd(struct arm_vsmmu *vsmmu,
return 0;
}
+static bool arm_vsmmu_can_batch_cmd(struct arm_smmu_device *smmu,
+ struct arm_vsmmu_invalidation_cmd *last,
+ struct arm_vsmmu_invalidation_cmd *next)
+{
+ struct arm_smmu_cmd next_cmd = {
+ .data[0] = le64_to_cpu(next->ucmd.cmd[0]),
+ };
+
+ return arm_smmu_erratum_cmd_needs_repeating(smmu, &last->cmd) ==
+ arm_smmu_erratum_cmd_needs_repeating(smmu, &next_cmd);
+}
+
int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
struct iommu_user_data_array *array)
{
@@ -382,7 +394,8 @@ int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
/* FIXME work in blocks of CMDQ_BATCH_ENTRIES and copy each block? */
cur++;
- if (cur != end && (cur - last) != CMDQ_BATCH_ENTRIES - 1)
+ if (cur != end && (cur - last) != CMDQ_BATCH_ENTRIES - 1 &&
+ arm_vsmmu_can_batch_cmd(smmu, last, cur))
continue;
/* FIXME always uses the main cmdq rather than trying to group by type */
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 599c835c50d8..041e188b3b30 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -700,10 +700,10 @@ static void arm_smmu_cmdq_write_entries(struct arm_smmu_cmdq *cmdq,
* insert their own list of commands then all of the commands from one
* CPU will appear before any of the commands from the other CPU.
*/
-int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
- struct arm_smmu_cmdq *cmdq,
- struct arm_smmu_cmd *cmds, int n,
- bool sync)
+static int __arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmdq *cmdq,
+ struct arm_smmu_cmd *cmds, int n,
+ bool sync)
{
struct arm_smmu_cmd cmd_sync;
u32 prod;
@@ -822,6 +822,28 @@ int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
return ret;
}
+int arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
+ struct arm_smmu_cmdq *cmdq,
+ struct arm_smmu_cmd *cmds, int n,
+ bool sync)
+{
+ int ret = __arm_smmu_cmdq_issue_cmdlist(smmu, cmdq, cmds, n, sync);
+
+ /*
+ * arm_smmu_cmdq_batch_add_cmd_p() can flush its current batch with
+ * sync=true and n=0 (bare SYNC) when the next command is not
+ * supported by the batch's pre-selected cmdq, so the repeat path
+ * must not inspect cmds[0].
+ */
+ if (!n || ret || !sync)
+ return ret;
+
+ if (arm_smmu_erratum_cmd_needs_repeating(smmu, &cmds[0]))
+ ret = __arm_smmu_cmdq_issue_cmdlist(smmu, cmdq, cmds, n, sync);
+
+ return ret;
+}
+
static int arm_smmu_cmdq_issue_cmd_p(struct arm_smmu_device *smmu,
struct arm_smmu_cmd *cmd, bool sync)
{
@@ -862,6 +884,11 @@ static bool arm_smmu_cmdq_batch_force_sync(struct arm_smmu_device *smmu,
(smmu->options & ARM_SMMU_OPT_CMDQ_FORCE_SYNC))
return true;
+ /* See ARM_SMMU_OPT_REPEAT_TLBI_CFGI */
+ if (cmds->num == CMDQ_BATCH_ENTRIES &&
+ arm_smmu_erratum_cmd_needs_repeating(smmu, &cmds->cmds[0]))
+ return true;
+
return false;
}
--
2.50.1
^ permalink raw reply related
* [PATCH v4 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround
From: Ashish Mhetre @ 2026-06-09 7:32 UTC (permalink / raw)
To: will, robin.murphy, joro, jgg, nicolinc
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra, Ashish Mhetre
Nvidia Tegra264 SMMUs are affected by an erratum where a TLB entry can
survive an invalidation that races with concurrent traffic targeting
the same entry. The hardware-recommended software workaround is to
issue every CFGI/TLBI command (each followed by CMD_SYNC) twice.
The second issue must execute only after the first issue's CMD_SYNC
has completed, giving the sequence:
TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC
ATC_INV is not affected and must not be doubled.
The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
cannot be detected from hardware ID. Tegra264 is device-tree-only
(no ACPI/IORT support), so detection is purely by compatible string.
This series is structured as a small refactor + detect + apply
sequence so that each step is reviewable in isolation:
1/3 Pure refactor (no functional change): lift the existing
force-sync conditions out of arm_smmu_cmdq_batch_add_cmd_p()
into a new arm_smmu_cmdq_batch_force_sync() helper, so that
adding another condition (in patch 3) is a one-liner.
Authored by Nicolin Chen.
2/3 Detect the erratum and provide the classifier. Adds the
ARM_SMMU_OPT_REPEAT_TLBI_CFGI per-instance option, a global
arm_smmu_erratum_repeat_tlbi_cfgi_key static key, and the
arm_smmu_erratum_cmd_needs_repeating() predicate. The static
key means the wrapper compiles to a single tested branch on
unaffected kernels.
3/3 Apply the workaround: factor arm_smmu_cmdq_issue_cmdlist()
into a thin wrapper around __arm_smmu_cmdq_issue_cmdlist()
that re-issues the cmdlist a second time when the predicate
fires; register the same condition with the batch helper so
full batches of CFGI/TLBI flush with sync=true; and add
arm_vsmmu_can_batch_cmd() so iommufd does not mix command
classes inside a single batch. Also documents the erratum
in silicon-errata.rst.
The series applies cleanly on linux-next/master (base-commit below).
Changes since v3:
- Drop the cmds->num == 0 early-return so the refactor is
truly "no functional change".
- Rename ARM_SMMU_OPT_TLBI_TWICE -> ARM_SMMU_OPT_REPEAT_TLBI_CFGI
and rephrase its kdoc to be hardware-agnostic.
- Rename arm_smmu_cmd_needs_tlbi_twice() ->
arm_smmu_erratum_cmd_needs_repeating() and drop the kdoc
above it.
- Replace the explicit opcode switch with a single range check
opcode >= CMDQ_OP_CFGI_STE && opcode < CMDQ_OP_ATC_INV.
- Introduce arm_smmu_erratum_repeat_tlbi_cfgi_key static key:
the predicate gates on it first so unaffected kernels pay
only a single static_branch_unlikely() check.
- Drop the verbose Tegra264-specific comments above
arm_vsmmu_can_batch_cmd() and inside the batch helper.
- Document the erratum in
Documentation/arch/arm64/silicon-errata.rst.
- Guard the repeat path in arm_smmu_cmdq_issue_cmdlist() with
an n > 0 check so we never inspect cmds[0] on the bare-SYNC
flush emitted by arm_smmu_cmdq_batch_add_cmd_p() when the
next command is unsupported by the batch's pre-selected
cmdq.
- Drop the carried Reviewed-by tags now that the patch
shape has changed; re-review appreciated.
Changes since v2:
- Split into a 3-patch series (refactor / detect / apply) to keep
each step small and bisectable.
- Move the classifier to arm-smmu-v3.h as static inline so the
iommufd file can share it.
- Add arm_vsmmu_can_batch_cmd() to split iommufd batches at
"needs repeating" transitions so the per-batch decision based
on the first command stays correct under mixed user input.
- Spell out in the commit message why detection is via DT and
not via IIDR/ACPI.
Changes since v1:
- Detect the erratum from the existing "nvidia,tegra264-smmu"
compatible instead of adding a new property.
- Centralise the doubling at the CMDQ submission layer and only
apply it to CFGI/TLBI (not ATC_INV).
- Drop the binding/dtsi patches accordingly.
Ashish Mhetre (2):
iommu/arm-smmu-v3: Detect Tegra264 erratum
iommu/arm-smmu-v3: Issue CFGI/TLBI twice on Tegra264
Nicolin Chen (1):
iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
Documentation/arch/arm64/silicon-errata.rst | 2 +
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 15 ++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 65 +++++++++++++++----
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 24 +++++++
4 files changed, 94 insertions(+), 12 deletions(-)
base-commit: 7da7f07112610a520567421dd2ffcb51beaefbcc
--
2.50.1
^ permalink raw reply
* [PATCH] gpio: zynq: fix runtime PM leak on remove
From: Ruoyu Wang @ 2026-06-09 7:33 UTC (permalink / raw)
To: Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, Linus Walleij,
Bartosz Golaszewski
Cc: Harini Katakam, Soren Brinkmann, linux-gpio, linux-arm-kernel,
linux-kernel, Ruoyu Wang
pm_runtime_get_sync() increments the runtime PM usage counter even when it
returns an error. zynq_gpio_remove() uses it to keep the controller active
while removing the GPIO chip, but never drops the usage counter again.
Balance the get with pm_runtime_put_noidle() after disabling runtime PM.
Fixes: 3242ba117e9b ("gpio: Add driver for Zynq GPIO controller")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
drivers/gpio/gpio-zynq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 571e366624d2a..fafca91128b2e 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -1014,6 +1014,7 @@ static void zynq_gpio_remove(struct platform_device *pdev)
gpiochip_remove(&gpio->chip);
device_set_wakeup_capable(&pdev->dev, 0);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
static struct platform_driver zynq_gpio_driver = {
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox