* [PATCH 01/11] dt-bindings: power: Convert Ux500 PM domains to schema
From: Linus Walleij @ 2026-06-18 5:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones
Cc: linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine,
Linus Walleij
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-0-eb5e50b1a588@kernel.org>
Convert the legacy Ux500 power domain text binding to YAML.
Move it under bindings/power.
Reference the generic power-domain schema.
Update MAINTAINERS for the new path.
Assisted-by: Codex:gpt-5-5
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
.../devicetree/bindings/arm/ux500/power_domain.txt | 35 ----------------
.../power/stericsson,ux500-pm-domains.yaml | 46 ++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 47 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/ux500/power_domain.txt b/Documentation/devicetree/bindings/arm/ux500/power_domain.txt
deleted file mode 100644
index 5679d1742d3e..000000000000
--- a/Documentation/devicetree/bindings/arm/ux500/power_domain.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-* ST-Ericsson UX500 PM Domains
-
-UX500 supports multiple PM domains which are used to gate power to one or
-more peripherals on the SOC.
-
-The implementation of PM domains for UX500 are based upon the generic PM domain
-and use the corresponding DT bindings.
-
-==PM domain providers==
-
-Required properties:
- - compatible: Must be "stericsson,ux500-pm-domains".
- - #power-domain-cells : Number of cells in a power domain specifier, must be 1.
-
-Example:
- pm_domains: pm_domains0 {
- compatible = "stericsson,ux500-pm-domains";
- #power-domain-cells = <1>;
- };
-
-==PM domain consumers==
-
-Required properties:
- - power-domains: A phandle and PM domain specifier. Below are the list of
- valid specifiers:
-
- Index Specifier
- ----- ---------
- 0 DOMAIN_VAPE
-
-Example:
- sdi0_per1@80126000 {
- compatible = "arm,pl18x", "arm,primecell";
- power-domains = <&pm_domains DOMAIN_VAPE>
- };
diff --git a/Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml b/Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml
new file mode 100644
index 000000000000..72c39c083efb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/stericsson,ux500-pm-domains.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST-Ericsson UX500 power domains
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+ - Ulf Hansson <ulfh@kernel.org>
+
+description:
+ The UX500 power domain controller gates power to one or more peripherals on
+ the SoC. Domain specifiers use one cell containing one of the DOMAIN_*
+ indexes defined in dt-bindings/arm/ux500_pm_domains.h.
+
+allOf:
+ - $ref: power-domain.yaml#
+
+properties:
+ compatible:
+ const: stericsson,ux500-pm-domains
+
+ '#power-domain-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#power-domain-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/arm/ux500_pm_domains.h>
+
+ pm_domains: power-controller {
+ compatible = "stericsson,ux500-pm-domains";
+ #power-domain-cells = <1>;
+ };
+
+ sdi0_per1@80126000 {
+ compatible = "arm,pl18x", "arm,primecell";
+ power-domains = <&pm_domains DOMAIN_VAPE>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c8d4b913f26c..a984c4647cc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3167,6 +3167,7 @@ F: Documentation/devicetree/bindings/arm/ux500.yaml
F: Documentation/devicetree/bindings/arm/ux500/
F: Documentation/devicetree/bindings/gpio/st,nomadik-gpio.yaml
F: Documentation/devicetree/bindings/i2c/st,nomadik-i2c.yaml
+F: Documentation/devicetree/bindings/power/stericsson,ux500-pm-domains.yaml
F: arch/arm/boot/dts/st/ste-*
F: arch/arm/mach-nomadik/
F: arch/arm/mach-ux500/
--
2.54.0
^ permalink raw reply related
* [PATCH 00/11] pmdomain: st: ux500: Implement ux500 power domains
From: Linus Walleij @ 2026-06-18 5:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones
Cc: linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine,
Linus Walleij, Linus Walleij
Today the Ux500 SoC specifically DB8500 is using what is called
"EPOD regulators" (EPOD = Electric POwer Domain) to control its power domains.
This was done like this because at the time, power domains did not exist as a
concept in the Linux kernel.
This patch series completes the ambitious work started in
commit cd931dcfda5e ("ARM: ux500: Initial support for PM domains") which added
a dummy domain driver for Ux500 in the following steps:
- Convert the old Ux500 power domain text DT bindings to YAML schema.
- Extend the bindings with all the 16 power domains actually existing
in the hardware.
- Add these domains to the existing ux500 power domain driver (still as dummy
domains).
- Add the power domains to the DB8500 SoC DTSI file.
- Move code over from the EPOD regulators to the actual power domain driver.
Since the two drivers now control the same hardware, make the drivers
mutually exclusive.
- Modify the MCDE display driver to use the power domain instead of
the EPOS regulators.
- Modify the DMA40 DMA controller to use the power domain instead of
the EPOD regulators.
- Delete the old EPOD regulators.
- Implement regulators activating the VANA and VSMPS2 power domains for the
power domain voltage rails that are routed off-chip as external supplies,
re-using the existing EPOD regulator bindings.
- Delete the references to the unused EPOD regulators from the device tree,
keeping the references to VANA and VSMPS2.
This is a bit of brain transplant on the Ux500, and the series is not very
boot-bisectable.
For simplicity, the series can be merged in separate paths and subsystems as
there are no build-time dependencies, as long as the result ends up in kernel
v7.3. Once the concept and patches are ACKed by the power domain folks, I will
send the patches that can be split out individually to each maintainer and
it can all be merged in parallel.
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Linus Walleij (11):
dt-bindings: power: Convert Ux500 PM domains to schema
dt-bindings: Add the actual power domains on U8500
pmdomain: st: ux500: Implement more power domains
ARM: dts: ux500: Rename power domains node
ARM: dts: ux500: Add power domains
pmdomain: st: ux500: Control DB8500 EPODs
drm/mcde: Use power domain for display power
dmaengine: ste_dma40: Use power domain for LCLA SRAM
regulator: db8500-prcmu: Remove EPOD regulators
regulator: db8500: Add power domain regulators
ARM: dts: ux500: Remove DB8500 EPOD regulators
.../devicetree/bindings/arm/ux500/power_domain.txt | 35 --
.../power/stericsson,ux500-pm-domains.yaml | 46 ++
MAINTAINERS | 1 +
arch/arm/boot/dts/st/ste-dbx5x0.dtsi | 134 ++----
arch/arm/mach-ux500/Kconfig | 2 +-
drivers/dma/ste_dma40.c | 97 ++--
drivers/gpu/drm/mcde/mcde_clk_div.c | 4 +-
drivers/gpu/drm/mcde/mcde_display.c | 11 +-
drivers/gpu/drm/mcde/mcde_drm.h | 2 -
drivers/gpu/drm/mcde/mcde_drv.c | 63 +--
drivers/gpu/drm/mcde/mcde_dsi.c | 1 -
drivers/mfd/db8500-prcmu.c | 239 +---------
drivers/pmdomain/st/ste-ux500-pm-domain.c | 353 ++++++++++++++-
drivers/regulator/Kconfig | 22 +-
drivers/regulator/Makefile | 3 +-
drivers/regulator/db8500-prcmu.c | 501 ---------------------
drivers/regulator/db8500-regulator.c | 221 +++++++++
drivers/regulator/dbx500-prcmu.c | 155 -------
drivers/regulator/dbx500-prcmu.h | 55 ---
include/dt-bindings/arm/ux500_pm_domains.h | 17 +-
include/linux/regulator/db8500-prcmu.h | 38 --
21 files changed, 748 insertions(+), 1252 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260618-ux500-power-domains-v7-1-3c9d095828c2
Best regards,
--
Linus Walleij <linusw@kernel.org>
^ permalink raw reply
* [PATCH 56/78] ASoC: codecs: tas2783: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-18 4:54 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Cheng-Yi Chiang,
Tzung-Bi Shih, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek, bui duc phuc
In-Reply-To: <20260617103235.449609-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/codecs/tas2783-sdw.c | 89 ++++++++++++++++------------------
1 file changed, 43 insertions(+), 46 deletions(-)
diff --git a/sound/soc/codecs/tas2783-sdw.c b/sound/soc/codecs/tas2783-sdw.c
index 7d70e7e3f24f..763663daf3e1 100644
--- a/sound/soc/codecs/tas2783-sdw.c
+++ b/sound/soc/codecs/tas2783-sdw.c
@@ -691,12 +691,12 @@ static s32 tas2783_update_calibdata(struct tas2783_prv *tas_dev)
return 0;
}
- mutex_lock(&tas_dev->calib_lock);
- ret = tas2783_validate_calibdata(tas_dev, tas_dev->cali_data.data,
- tas_dev->cali_data.read_sz);
- if (!ret)
- tas2783_set_calib_params_to_device(tas_dev, tmp_val);
- mutex_unlock(&tas_dev->calib_lock);
+ scoped_guard(mutex, &tas_dev->calib_lock) {
+ ret = tas2783_validate_calibdata(tas_dev, tas_dev->cali_data.data,
+ tas_dev->cali_data.read_sz);
+ if (!ret)
+ tas2783_set_calib_params_to_device(tas_dev, tmp_val);
+ }
return ret;
}
@@ -764,27 +764,27 @@ static void tas2783_fw_ready(const struct firmware *fmw, void *context)
goto out;
}
- mutex_lock(&tas_dev->pde_lock);
- while (offset < (img_sz - FW_FL_HDR)) {
- offset += tas_fw_get_next_file(&buf[offset], file);
- dev_dbg(tas_dev->dev,
- "v=%d, fid=%d, ver=%d, len=%d, daddr=0x%x, fw=%p",
- file->vendor_id, file->file_id,
- file->version, file->length,
- file->dest_addr, file->fw_data);
-
- ret = sdw_nwrite_no_pm(tas_dev->sdw_peripheral,
- file->dest_addr,
- file->length,
- file->fw_data);
- if (ret < 0) {
- dev_err(tas_dev->dev,
- "FW download failed: %d", ret);
- break;
+ scoped_guard(mutex, &tas_dev->pde_lock) {
+ while (offset < (img_sz - FW_FL_HDR)) {
+ offset += tas_fw_get_next_file(&buf[offset], file);
+ dev_dbg(tas_dev->dev,
+ "v=%d, fid=%d, ver=%d, len=%d, daddr=0x%x, fw=%p",
+ file->vendor_id, file->file_id,
+ file->version, file->length,
+ file->dest_addr, file->fw_data);
+
+ ret = sdw_nwrite_no_pm(tas_dev->sdw_peripheral,
+ file->dest_addr,
+ file->length,
+ file->fw_data);
+ if (ret < 0) {
+ dev_err(tas_dev->dev,
+ "FW download failed: %d", ret);
+ break;
+ }
+ cur_file++;
}
- cur_file++;
}
- mutex_unlock(&tas_dev->pde_lock);
if (cur_file == 0) {
dev_err(tas_dev->dev, "fw with no files");
@@ -917,22 +917,22 @@ static s32 tas_sdw_hw_params(struct snd_pcm_substream *substream,
dev_err(tas_dev->dev,
"clear latch failed, err=%d", ret);
- mutex_lock(&tas_dev->pde_lock);
- /*
- * Sometimes, there is error returned during power on.
- * So added retry logic to ensure power on so that
- * port prepare succeeds
- */
- do {
- ret = regmap_write(tas_dev->regmap,
- SDW_SDCA_CTL(1, TAS2783_SDCA_ENT_PDE23,
- TAS2783_SDCA_CTL_REQ_POW_STATE, 0),
- TAS2783_SDCA_POW_STATE_ON);
- if (!ret)
- break;
- usleep_range(2000, 2200);
- } while (retry--);
- mutex_unlock(&tas_dev->pde_lock);
+ scoped_guard(mutex, &tas_dev->pde_lock) {
+ /*
+ * Sometimes, there is error returned during power on.
+ * So added retry logic to ensure power on so that
+ * port prepare succeeds
+ */
+ do {
+ ret = regmap_write(tas_dev->regmap,
+ SDW_SDCA_CTL(1, TAS2783_SDCA_ENT_PDE23,
+ TAS2783_SDCA_CTL_REQ_POW_STATE, 0),
+ TAS2783_SDCA_POW_STATE_ON);
+ if (!ret)
+ break;
+ usleep_range(2000, 2200);
+ } while (retry--);
+ }
if (ret)
return ret;
@@ -965,14 +965,11 @@ static s32 tas_sdw_pcm_hw_free(struct snd_pcm_substream *substream,
sdw_stream_remove_slave(tas_dev->sdw_peripheral, sdw_stream);
- mutex_lock(&tas_dev->pde_lock);
- ret = regmap_write(tas_dev->regmap,
+ guard(mutex)(&tas_dev->pde_lock);
+ return regmap_write(tas_dev->regmap,
SDW_SDCA_CTL(1, TAS2783_SDCA_ENT_PDE23,
TAS2783_SDCA_CTL_REQ_POW_STATE, 0),
TAS2783_SDCA_POW_STATE_OFF);
- mutex_unlock(&tas_dev->pde_lock);
-
- return ret;
}
static const struct snd_soc_dai_ops tas_dai_ops = {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Alexey Kardashevskiy @ 2026-06-18 4:44 UTC (permalink / raw)
To: Jason Gunthorpe, Catalin Marinas
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260609144746.GL2764304@ziepe.ca>
On 10/6/26 00:47, Jason Gunthorpe wrote:
> On Tue, Jun 09, 2026 at 02:43:08PM +0100, Catalin Marinas wrote:
>> On Thu, Jun 04, 2026 at 02:09:39PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>> This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
>>> dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
>>> are handled consistently.
>>>
>>> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
>>> shared/decrypted buffer handling. This series consolidates the
>>> force_dma_unencrypted() checks in the top-level functions and ensures
>>> that the remaining DMA interfaces use DMA attributes to make the correct
>>> decisions.
>>
>> Please check Sashiko's reports, it has some good points:
>>
>> https://sashiko.dev/#/patchset/20260604083959.1265923-1-aneesh.kumar@kernel.org
>>
>> I think the main one is the swiotlb_tbl_map_single() changes which break
>> AMD SME host support. There cc_platform_has(CC_ATTR_MEM_ENCRYPT) is true
>> but force_dma_unencrypted() is false. Normally you'd not end up on this
>> path but you can have swiotlb=force.
>
> IMHO that's an AMD issue, not with the design of this series..
>
> The series is right, a device that is !force_dma_decrypted() must be
> considerd to be a trusted device and we must never place any DMA
> mappings for a trusted device into shared memory.
swiotlb=force forces swiotlb, not decryption.
> That AMD has done somethine insane:
>
> bool force_dma_unencrypted(struct device *dev)
> {
> /*
> * For SEV, all DMA must be to unencrypted addresses.
> */
> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> return true;
>
> /*
> * For SME, all DMA must be to unencrypted addresses if the
> * device does not support DMA to addresses that include the
> * encryption mask.
> */
> if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
> u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
> u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
> dev->bus_dma_limit);
>
> if (dma_dev_mask <= dma_enc_mask)
> return true;
> }
So when I try "mem_encrypt=on iommu=pt swiotlb=force" with this patchset, it fails to boot. But it boots with a hack like this:
===
@@ -39,7 +41,7 @@ bool force_dma_unencrypted(struct device *dev)
return true;
}
- return false;
+ return swiotlb_force_bounce;
}
===
Or we say "mem_encrypt=on iommu=pt swiotlb=force" combo is just weird and we won't be supporting which bit in this? Thanks,
>
> Is an AMD issue. We already have an address mask limit system built
> into the DMA API, arch code should not be co-opting the CC mechanism
> to create a special pool for address limited devices.
>
> The correct thing is to ensure the DMA API is checking any address
> limits on the actual true dma_addr_t, not on an intermediate like a
> phys_addr before it is adjusted with any C bit. Then it is a normal
> low address swiotlb bounce like any other.
>
> I think we can ignore this Sashiko remark, in real systems the use of
> swiotlb for 64 bit devices is very rare. Though it would be good to
> remove this code from AMD...>
> Jason
--
Alexey
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: Frank Li @ 2026-06-18 4:13 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mauro Carvalho Chehab, Michael Riesch, Laurent Pinchart, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, devicetree, linux-arm-kernel
In-Reply-To: <ajMhZP5YHuQdhc5M@kekkonen.localdomain>
On Thu, Jun 18, 2026 at 01:36:20AM +0300, Sakari Ailus wrote:
> Hi Frank,
>
> Thanks for the patch.
Thanks for you quick reply.
>
> On Wed, Jun 17, 2026 at 03:50:12PM -0400, Frank.Li@oss.nxp.com wrote:
> > From: Frank Li <Frank.Li@nxp.com>
> >
> > Many V4L2 subdev drivers implement the same registration and media pad
> > setup logic for simple pipelines consisting of a single sink pad and a
> > single source pad. As a result, the same boilerplate code is duplicated
> > across multiple drivers.
> >
> > Introduce a common helper library for 1-to-1 subdevs to encapsulate the
> > registration, media entity initialization, and cleanup paths. Drivers
> > can embed a struct v4l2_subdev_1to1 instance and use the provided helper
> > APIs instead of open-coding the setup sequence.
>
> I appreciate your efforts in trying to reduce the amount of code drivers
> need simply to get things done but I think there are a few issues with the
> approach taken in this patch:
>
> - The new helpers aren't generic enough, but require two pads; one sink,
> one source.
It can cover many case already, there are many bridge type subdev. after
glace of all code, many CSI2RX is type device. It should one kind important
type/case, like sensors.
And I plan do 1 TO N replicator driver, which duplicate 1 sink pad to N
source pad (with/without register config), plus exist video-mux driver,
It think It can cover more than 80% cases.
> You could provide special helpers for just this case, but
> right now it looks like that if there's something you need that the
> helper assumes you don't, you can't use the helper at all. In other
> words, more modularity would be nice.
We can add it later if need, which easy to replace 1to1 API, like I did
for sensor one.
>
> - The new helper should work with the existing types and not add new types
> (struct v4l2_subdev_1to1).
May be save vep data into v4l2_subdev to avoid parse it every time. and
enhence media_entity_pads_init() to avoid refer caller data.
>
> - There should be a way to provide default V4L2 fwnode endpoint
> configuration as well as to validate the obtained configuration.
Do you means remote_bustype_cap_mask information get from a callback?
>
> I don't have a good proposal to address the above but at least one way I
> can think of making error handling easier would be to use devm_() for
> teardown in more places we to today. That certainly does have its own
> issues though.
I tried it before, media and v4l2's clean up is not revised order of init.
Sorry, I can't find original thread. I remember laurnet pinchart said there
are order problem.
1 v4l2_subdev_init()
2. v4l2_async_subdev_nf_init()
3. v4l2_async_nf_register()
4. media_entity_pads_init()
5 v4l2_async_register_subdev()
v4l2_async_unregister_subdev(sd);
v4l2_subdev_cleanup(sd); // Not sure if it save to move to last step
media_entity_cleanup(&sd->entity);
v4l2_async_nf_unregister(&csi2->notifier);
v4l2_async_nf_cleanup(&csi2->notifier);
Frank
>
> --
> Kind regards,
>
> Sakari Ailus
^ permalink raw reply
* [PATCH v2] nvmem: rockchip-otp: skip zero-byte reads
From: Ruoyu Wang @ 2026-06-18 4:08 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Heiko Stuebner, Jonas Karlman, linux-arm-kernel, linux-rockchip,
linux-kernel, Ruoyu Wang
nvmem_device_read() does not reject a zero-byte read before calling the
provider reg_read callback. rockchip_otp_read() then enables clocks and
dispatches to the SoC-specific callback.
Return 0 from rockchip_otp_read() before enabling clocks when bytes is
zero. This avoids hardware access for empty reads and prevents zero
counts from reaching the internal reg_read callbacks.
Fixes: 8ab099fafbbc ("nvmem: rockchip-otp: Add support for RK3588")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
v2:
- Handle empty reads in rockchip_otp_read() instead of initializing ret in
rk3588_otp_read().
drivers/nvmem/rockchip-otp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/nvmem/rockchip-otp.c b/drivers/nvmem/rockchip-otp.c
index 0ec78b5e19e7d..95685a9fcc77b 100644
--- a/drivers/nvmem/rockchip-otp.c
+++ b/drivers/nvmem/rockchip-otp.c
@@ -272,6 +272,9 @@ static int rockchip_otp_read(void *context, unsigned int offset,
if (!otp->data || !otp->data->reg_read)
return -EINVAL;
+ if (!bytes)
+ return 0;
+
ret = clk_bulk_prepare_enable(otp->data->num_clks, otp->clks);
if (ret < 0) {
dev_err(otp->dev, "failed to prepare/enable clks\n");
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 11/78] ASoC: codecs: cros_ec_codec: Use guard() for mutex locks
From: Tzung-Bi Shih @ 2026-06-18 4:05 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Cheng-Yi Chiang, Guenter Roeck, Benson Leung, David Rhodes,
Richard Fitzgerald, povik+lin, Charles Keepax, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260617103235.449609-12-phucduc.bui@gmail.com>
On Wed, Jun 17, 2026 at 05:31:28PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Clean up the code using guard() for mutex locks.
> Merely code refactoring, and no behavior change.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
^ permalink raw reply
* Re: [PATCH v4] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Frank Li @ 2026-06-18 3:22 UTC (permalink / raw)
To: Hongling Zeng
Cc: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd,
dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719
In-Reply-To: <20260618020609.1155962-1-zenghongling@kylinos.cn>
On Thu, Jun 18, 2026 at 10:06:09AM +0800, Hongling Zeng wrote:
> When terminating DMA transfers, active descriptors are not properly
> reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
> descriptors and their LLI chains to be permanently leaked.
>
> Fix by using vchan_terminate_vdesc() which handles both cyclic and
> non-cyclic descriptors by adding them to desc_terminated queue for
> proper cleanup.
>
> Add pchan->desc != pchan->done check to prevent double-adding completed
> descriptors, which would corrupt the list.
>
> Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> Suggested-by: Frank Li <Frank.li@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> ---
> Change in v2;
> -Add pchan->desc != pchan->done check to prevent race condition
> where completed descriptors could be double-added to desc_completed
> list, causing list corruption
> ---
> Change in v3:
> -Fix by using vchan_terminate_vdesc() as suggested by Frank Li
> ---
> Change in v4:
> -Correct the commit message
> ---
> drivers/dma/sun6i-dma.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 7a79f346250a..134ae840f176 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
>
> spin_lock_irqsave(&vchan->vc.lock, flags);
>
> - if (vchan->cyclic) {
> - vchan->cyclic = false;
> - if (pchan && pchan->desc) {
> - struct virt_dma_desc *vd = &pchan->desc->vd;
> - struct virt_dma_chan *vc = &vchan->vc;
> -
> - list_add_tail(&vd->node, &vc->desc_completed);
> - }
> + if (pchan && pchan->desc && pchan->desc != pchan->done) {
> + struct virt_dma_desc *vd = &pchan->desc->vd;
> +
> + vchan_terminate_vdesc(vd);
> }
>
> + vchan->cyclic = false;
> vchan_get_all_descriptors(&vchan->vc, &head);
>
> if (pchan) {
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 3:21 UTC (permalink / raw)
To: Manivannan Sadhasivam, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Marc Zyngier, Rob Herring,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <lstafqaogzunb2azyqwvtt3swrk42nu3n5zyct2la5fqxomaqg@wyrz3qolhist>
On 6/17/26 12:33 PM, Manivannan Sadhasivam wrote:
Hello Manivannan,
[...]
>> +/* INTC address */
>> +#define AXIINTCADDR 0x0a00
>> +/* GITS GIC ITS translation register */
>> +#define AXIINTCADDR_VAL 0xf1050000
>
> As Marc pointed out, this address should be fetched from DT, not hardcoded in
> the driver.
I will reply to Marc when I have this ready for V2.
>> +
>> +/* INTC control & mask */
>> +#define AXIINTCCONT 0x0a04
>> +#define INTC_EN BIT(31)
>> +#define INTC_MASK GENMASK(11, 2)
>> +
>> /* PCIe Power Management Control */
>> #define PCIEPWRMNGCTRL 0x0070
>> #define APP_CLK_REQ_N BIT(11)
>> @@ -305,6 +319,39 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
>> return rcar;
>> }
>>
>> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>> +{
>> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>> + u32 val;
>> +
>> + /* Make sure MSICAP0 MSIE is configured. */
>> + val = dw_pcie_readl_dbi(dw, MSICAP0);
>> + if (pci_msi_enabled())
>> + val |= MSICAP0_MSIE;
>> + else
>> + val &= ~MSICAP0_MSIE;
>> + dw_pcie_writel_dbi(dw, MSICAP0, val);
>> +
>> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
>
> If MSI is not enabled, then what's the point in clearing these registers (also
> above)? I see it as a redundant code. Is there a necessity to clear them?
AXIINTCCONT INTC_EN should not be set if MSI is disabled, this code
makes sure it is not set, even if it might have been left set e.g. by
prior stage. So no, this is not redundant code, this makes sure the
controller is correctly configured.
^ permalink raw reply
* Re: [PATCH v2 0/3] ASoC: rockchip: Use guard() for spin locks
From: Bui Duc Phuc @ 2026-06-18 3:16 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Heiko Stuebner, Liam Girdwood, Mark Brown, Nicolas Frattaroli,
Jaroslav Kysela, Takashi Iwai, linux-sound, linux-rockchip,
linux-arm-kernel, linux-kernel
In-Reply-To: <mPIrpl-QRw6_Q9DZcTQ5xA@collabora.com>
Hi Nicolas,
Thanks for the feedback.
> FWIW, the SAI patch wasn't sent to the proper maintainer e-mail
> for it which is why I didn't notice this series at all until now,
> and the whole thing is pointless churn that wasn't even tested.
>
> From a cursory glance, whatever LLM was pointed at this and decided
> to make the output my problem also didn't do a good job, the scoped
> indentation of rockchip_sai_runtime_suspend seems pointless because
> it could've been replaced by a pm guard followed by a spinlock guard,
> without an additional level of indentation, and `if (ret == 0) {` is
> not kernel style.
>
> It's not worth the revert but it sucks that I have to now set up a
> new lei search for all the drivers I am supposed to receive mail for
> because vibecoders can't be bothered to run get_maintainers as they
> pad their CV with nonsense like this.
>
> >
> > [1/3] ASoC: rockchip: rockchip_i2s: Use guard() for spin locks
> > https://git.kernel.org/broonie/sound/c/4bda5af16920
> > [2/3] ASoC: rockchip: i2s-tdm: Use guard() for spin locks
> > https://git.kernel.org/broonie/sound/c/ec22437fc41a
> > [3/3] ASoC: rockchip: rockchip_sai: Use guard() for spin locks
> > https://git.kernel.org/broonie/sound/c/f7fe9f707360
> >
Regarding the claim that the Rockchip SAI patch was not sent to the proper
maintainer, I believe there may be a misunderstanding.
Before sending the series, I ran get_maintainer.pl on the patch set and
included all recipients reported by the script, including:
Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
along with the relevant mailing lists.
------------------------------------------
phuc@phuc-desktop:~/work/linux$ ls ../patch/sound/rockchip/clean/
0000-cover-letter.patch
v2-0000-cover-letter.patch
0001-ASoC-rockchip-rockchip_i2s-Use-guard-for-spin-locks.patch
v2-0001-ASoC-rockchip-rockchip_i2s-Use-guard-for-spin-loc.patch
0002-ASoC-rockchip-i2s-tdm-Use-guard-for-spin-locks.patch
v2-0002-ASoC-rockchip-i2s-tdm-Use-guard-for-spin-locks.patch
0003-ASoC-rockchip-rockchip_sai-Use-guard-for-spin-locks.patch
v2-0003-ASoC-rockchip-rockchip_sai-Use-guard-for-spin-loc.patch
phuc@phuc-desktop:~/work/linux$
phuc@phuc-desktop:~/work/linux$
phuc@phuc-desktop:~/work/linux$
phuc@phuc-desktop:~/work/linux$ ./scripts/get_maintainer.pl
../patch/sound/rockchip/clean/000*.patch
./scripts/get_maintainer.pl: file
'../patch/sound/rockchip/clean/0000-cover-letter.patch' doesn't appear
to be a patch. Add -f to options?
Liam Girdwood <lgirdwood@gmail.com> (maintainer:SOUND - SOC LAYER /
DYNAMIC AUDIO POWER MANAGEM...)
Mark Brown <broonie@kernel.org> (maintainer:SOUND - SOC LAYER /
DYNAMIC AUDIO POWER MANAGEM...)
Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND)
Takashi Iwai <tiwai@suse.com> (maintainer:SOUND)
Heiko Stuebner <heiko@sntech.de> (maintainer:ARM/Rockchip SoC support)
Nicolas Frattaroli <frattaroli.nicolas@gmail.com> (maintainer:ROCKCHIP
I2S TDM DRIVER)
linux-sound@vger.kernel.org (open list:SOUND - SOC LAYER / DYNAMIC
AUDIO POWER MANAGEM...)
linux-arm-kernel@lists.infradead.org (moderated list:ARM/Rockchip SoC support)
linux-rockchip@lists.infradead.org (open list:ARM/Rockchip SoC support)
linux-kernel@vger.kernel.org (open list)
SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC) status: Supported
phuc@phuc-desktop:~/work/linux$
phuc@phuc-desktop:~/work/linux$
---------------------------------------------
If there are additional maintainers or mailing lists that should receive these
patches but are not currently reported by get_maintainer.pl, please let me know
so I can include them in future submissions.
I would also appreciate avoiding assumptions that the series was generated
by an LLM. The patches were prepared manually and submitted as part of
my ongoing effort to convert lock/unlock patterns to guard()/scoped_guard()
helpers where appropriate.
The series was build-tested before submission, so I do not believe it
is accurate
to describe it as "wasn't even tested".
Whether a particular conversion is worthwhile is certainly open to
technical discussion,
but I do not think it is reasonable to conclude that a patch was AI-generated
simply based on disagreements about the implementation details.
I understand maintainers have different preferences regarding how aggressively
such conversions should be applied, and I am happy to adjust the approach
based on review feedback.
Best regards,
Phuc
^ permalink raw reply
* [PATCH v4 2/2] Bluetooth: btmtksdio: call cancel_work_sync() out of host lock scope
From: Sergey Senozhatsky @ 2026-06-18 3:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Sean Wang
Cc: Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, Sergey Senozhatsky, stable
In-Reply-To: <20260618031338.1011410-1-senozhatsky@chromium.org>
cancel_work_sync() should be called outside of host lock scope
in order to avoid circular locking scenario:
CPU0 CPU1
close()/reset()
sdio_claim_host()
txrx_work
sdio_claim_host() // sleeps
cancel_work_sync() // sleeps
In addition, when txrx_work() runs concurrently with close()/reset()
it better not to re-enable interrupts by testing for BTMTKSDIO_FUNC_ENABLED
and not BTMTKSDIO_HW_RESET_ACTIVE before C_INT_EN_SET write. However,
btmtksdio_close() clears the BTMTKSDIO_FUNC_ENABLED too late (after
cancel_work_sync() call). Move BTMTKSDIO_FUNC_ENABLED bit-clear earlier
so that txrx_work can see concurrent close().
Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
Cc: stable@vger.kernel.org
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
---
drivers/bluetooth/btmtksdio.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index d8c8d2857527..207d04cc2282 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -625,7 +625,9 @@ static void btmtksdio_txrx_work(struct work_struct *work)
} while (int_status && time_is_after_jiffies(txrx_timeout));
/* Enable interrupt */
- if (bdev->func->irq_handler)
+ if (bdev->func->irq_handler &&
+ test_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state) &&
+ !test_bit(BTMTKSDIO_HW_RESET_ACTIVE, &bdev->tx_state))
sdio_writel(bdev->func, C_INT_EN_SET, MTK_REG_CHLPCR, NULL);
sdio_release_host(bdev->func);
@@ -741,6 +743,8 @@ static int btmtksdio_close(struct hci_dev *hdev)
if (!test_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state))
return 0;
+ clear_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state);
+
sdio_claim_host(bdev->func);
/* Disable interrupt */
@@ -748,11 +752,12 @@ static int btmtksdio_close(struct hci_dev *hdev)
sdio_release_irq(bdev->func);
+ sdio_release_host(bdev->func);
cancel_work_sync(&bdev->txrx_work);
+ sdio_claim_host(bdev->func);
btmtksdio_fw_pmctrl(bdev);
- clear_bit(BTMTKSDIO_FUNC_ENABLED, &bdev->tx_state);
sdio_disable_func(bdev->func);
sdio_release_host(bdev->func);
@@ -1295,7 +1300,10 @@ static void btmtksdio_reset(struct hci_dev *hdev)
sdio_writel(bdev->func, C_INT_EN_CLR, MTK_REG_CHLPCR, NULL);
skb_queue_purge(&bdev->txq);
+
+ sdio_release_host(bdev->func);
cancel_work_sync(&bdev->txrx_work);
+ sdio_claim_host(bdev->func);
gpiod_set_value_cansleep(bdev->reset, 1);
msleep(100);
--
2.54.0.1189.g8c84645362-goog
^ permalink raw reply related
* [PATCH v4 0/2] Bluetooth: btmtksdio: teardown fixes
From: Sergey Senozhatsky @ 2026-06-18 3:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Sean Wang
Cc: Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, Sergey Senozhatsky
This fixes several teardown issues:
INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
__cancel_work_timer+0x3f4/0x460
cancel_work_sync+0x1c/0x2c
btmtksdio_flush+0x2c/0x40
hci_dev_open_sync+0x10c4/0x2190
[..]
close/flush can deadlock when run concurrently with btmtksdio_txrx_work().
In addition btmtksdio_txrx_work() re-enables interrupts regardless of
close/flush being executed on another CPU.
v3 -> v4:
- fix commit message linter warnings/errors (tabs, subject line over 80
chars).
Sergey Senozhatsky (2):
Bluetooth: btmtksdio: test for BUS IO errors in btmtksdio_txrx_work()
Bluetooth: btmtksdio: call cancel_work_sync() out of host lock scope
drivers/bluetooth/btmtksdio.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--
2.54.0.1189.g8c84645362-goog
^ permalink raw reply
* [PATCH v4 1/2] Bluetooth: btmtksdio: test for BUS IO errors in btmtksdio_txrx_work()
From: Sergey Senozhatsky @ 2026-06-18 3:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Sean Wang
Cc: Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, Sergey Senozhatsky, stable
In-Reply-To: <20260618031338.1011410-1-senozhatsky@chromium.org>
btmtksdio_txrx_work() loop termination condition checks for
int_status being non-zero, however, this evaluates to true
even when sdio_readl() encounters BUS I/O error (in which
case int_status is 0xffffffff). Break out of the loop if
sdio_readl() errors out.
Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
Cc: stable@vger.kernel.org
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
---
drivers/bluetooth/btmtksdio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index c6f80c419e90..d8c8d2857527 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -574,7 +574,9 @@ static void btmtksdio_txrx_work(struct work_struct *work)
txrx_timeout = jiffies + 5 * HZ;
do {
- int_status = sdio_readl(bdev->func, MTK_REG_CHISR, NULL);
+ int_status = sdio_readl(bdev->func, MTK_REG_CHISR, &err);
+ if (err < 0 || int_status == 0xffffffff)
+ break;
/* Ack an interrupt as soon as possible before any operation on
* hardware.
--
2.54.0.1189.g8c84645362-goog
^ permalink raw reply related
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 2:38 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdX7XuHQDSsX4P7NZ46_OnCX2o25szuALwSs2z+PHq+JNg@mail.gmail.com>
On 6/17/26 9:09 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -4901,6 +4901,18 @@ static bool __maybe_unused its_enable_rk3568002(void *data)
>> return true;
>> }
>>
>> +static bool __maybe_unused its_enable_renesas_gen4(void *data)
>> +{
>> + if (!of_machine_is_compatible("renesas,r8a779f0") &&
>> + !of_machine_is_compatible("renesas,r8a779g0") &&
>> + !of_machine_is_compatible("renesas,r8a779h0"))
>
> of_machine_compatible_match() with an array of strings might generate
> smaller code (I didn't check if 3 entries is enough to trip the balance).
Let me handle that as part of suggestion from Marc.
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 2:50 UTC (permalink / raw)
To: Marc Zyngier, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <864ij1tyrj.wl-maz@kernel.org>
On 6/17/26 9:24 AM, Marc Zyngier wrote:
Hello Marc,
>> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
>> or APB interface configured to 32 bit, it can therefore access only
>> the first 4 GiB of physical address space. This information comes from
>> R-Car V4H Interface Specification sheet, there is currently no technical
>> update number assigned to this limitation. Further input from hardware
>> engineer indicates that this limitation also applies to R-Car S4 and V4M.
>> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
>> limitation.
My concern is this ^ , I do not have an erratum number, because there
isn't one. I am in touch with the hardware engineer and I did get a
glimpse at internal details of the three SoC, which confirm the
limitations. Is this sufficient ?
>> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
>> common for many ARM GICv3 implementations. Therefore, add an extra
>
> Not quite. It designates GIC600 unambiguously.
What I am trying to communicate is, that the 0x0201743b ID is not ID of
the Renesas GIC implementation, but it is a generic ARM GIC600 ID. That
is why we cannot match the quirk on the ID (it is generic ARM GIC600
ID), and instead we have to match the quirk on the [ ID combined with
of_machine_is_compatible("renesas,...") ].
> It is just that GIC600
> is integrated in zillions of SoCs, most of which don't have this
> problem (the machine I'm typing this from has a GIC600 *and* 96GB of
> RAM).
Right.
Shall I reword this paragraph somehow to make it clearer ?
>> of_machine_is_compatible() check.
>>
>> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
>
> Is this relevant?
I included it for the sake of completeness and to provide all relevant
information, based on previous discussions about similar limitations
that I could find on lore.k.o
[...]
>> +#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
>> + {
>> + .desc = "ITS: Renesas R-Car Gen4 GIC600 32-bit limit",
>> + .iidr = 0x0201743b,
>> + .mask = 0xffffffff,
>> + .init = its_enable_renesas_gen4,
>> + },
>> #endif
>> {
>> }
>
>
> Honestly, that's a bit too much copy-paste for my taste. Just refactor
> the erratum handling to be more generic, something like this:
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8da..380c4758647d2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4894,10 +4894,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4972,14 +4979,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
>
> Then add the two lines you need in a separate patch.
Will do in V2.
> In the future, please provide a cover letter when you have more than a
> single patch (git will happily generate one for you).
OK
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 2:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdU0SJ0q2hcpu+qZCH3eZ5eFDyo8Z964h9DhuSaQ7QdHSg@mail.gmail.com>
On 6/17/26 10:26 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>> +{
>> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>> + u32 val;
>> +
>> + /* Make sure MSICAP0 MSIE is configured. */
>> + val = dw_pcie_readl_dbi(dw, MSICAP0);
>> + if (pci_msi_enabled())
>> + val |= MSICAP0_MSIE;
>> + else
>> + val &= ~MSICAP0_MSIE;
>> + dw_pcie_writel_dbi(dw, MSICAP0, val);
>> +
>> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
>> + /* Clear AXIINTC mapping. */
>> + writel(0, rcar->base + AXIINTCADDR);
>> + writel(0, rcar->base + AXIINTCCONT);
>> + } else {
>> + /* Point AXIINTC to GIC ITS and enable. */
>> + writel(AXIINTCADDR_VAL, rcar->base + AXIINTCADDR);
>> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
>> + }
>> +
>> + /* Configure MSI interrupt signal */
>> + val = readl(rcar->base + PCIEINTSTS0EN);
>> + if (pci_msi_enabled())
>> + val |= MSI_CTRL_INT;
>> + else
>> + val &= ~MSI_CTRL_INT;
>> + writel(val, rcar->base + PCIEINTSTS0EN);
>> +}
>> +
>> static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
>
> FTR, this has a contextual dependency on "[PATCH v2] PCI: rcar-gen4:
> Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes"
> (https://lore.kernel.org/all/20260519195219.189323-1-marek.vasut+renesas@mailbox.org).
It is not an explicit dependency, I only had these patches in my tree
and clearly that was an interaction. I'll rebase this dependency out for V2.
Thanks!
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v6 03/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
From: Alexey Kardashevskiy @ 2026-06-18 2:39 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley, Cheloha, Scott
In-Reply-To: <20260617154101.GE3577091@ziepe.ca>
On 18/6/26 01:41, Jason Gunthorpe wrote:
> On Wed, Jun 17, 2026 at 10:50:39AM +1000, Alexey Kardashevskiy wrote:
>>> @@ -193,16 +193,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
>>> {
>>> bool remap = false, set_uncached = false;
>>> - bool mark_mem_decrypt = true;
>>> + bool mark_mem_decrypt = false;
>>> struct page *page;
>>> void *ret;
>>> + /*
>>> + * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
>>> + * attribute. The direct allocator uses it internally after it has
>>> + * decided that the backing pages must be shared/decrypted, so the
>>> + * rest of the allocation path can consistently select DMA addresses,
>>> + * choose compatible pools and restore encryption on free.
>>
>> Why this limit?
>>
>> Context: I am looking for a memory pool for a few shared pages (to
>> do some guest<->host communication), SWIOTLB seems like the right
>> fit but swiotlb_alloc() is not exported and
>> dma_direct_alloc(DMA_ATTR_CC_SHARED) is not allowed. Thanks,
>
> Then setup your struct device so that the DMA API knows the
> guest<->host channel requires unecrypted and it will work correctly.
>
> I think this is a reasonable API to use for that, and I was just
> advocating that hyperv should be using it too.
>
> But it all relies on a properly setup struct device.
Sounds good but how do I do that in practice? DMA_ATTR_CC_SHARED is not externally available so I'll have to trick the DMA layer into using SWIOTLB (which is still all shared, right?) as I specifically want to skip page conversions. Setting low DMA mask won't guarantee that the DMA layer won't allocate a page outside of SWIOTLB and convert it. Manually do
dev->dma_io_tlb_mem->force_bounce = true;
dev->dma_io_tlb_mem->for_allow = true;
?
Or follow the Aneesh'es genpool approach? Thanks,
>
> Jason
--
Alexey
^ permalink raw reply
* Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates
From: Runyu Xiao @ 2026-06-18 2:34 UTC (permalink / raw)
To: Viresh Kumar, Linus Walleij
Cc: Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
linux-arm-kernel, soc, linux-gpio, linux-rt-devel, linux-kernel,
jianhao.xu, runyu.xiao
Hi,
While auditing GPIO/pinctrl irqchip callbacks, our static analysis tool
flagged the SPEAr PLGPIO irq_enable path, and we manually reviewed it
against the current tree.
The path is:
irq_startup()
-> plgpio_irq_enable()
-> gpiochip_enable_irq()
-> spin_lock_irqsave(&plgpio->lock)
-> plgpio_reg_reset()
-> regmap_update_bits()
On PREEMPT_RT, plgpio->lock is a regular spinlock_t and can become a
sleeping lock. Since irq_enable/irq_disable can be called from IRQ
management paths while the IRQ descriptor raw lock is held, taking that
regular spinlock there looks unsafe.
A minimal Lockdep reproducer preserving this irq_chip::irq_enable carrier
reports:
BUG: sleeping function called from invalid context
irqs_disabled(): 1
plgpio_rt_spin_lock_irqsave
plgpio_irq_enable
request_threaded_irq_probe_path
My first thought was to convert the PLGPIO register lock to
raw_spinlock_t. However, that does not seem sufficient because the IE/EIT
updates go through regmap_update_bits()/regmap_read()/regmap_write(). For
the syscon/MMIO regmap used here, regmap may still take its own regular
fast-IO lock unless the regmap was created with use_raw_spinlock. So a
raw_spinlock_t conversion in the PLGPIO driver alone may just move the
PREEMPT_RT problem one level down into regmap.
The repair I am considering is to keep the gpiolib resource updates in
the fast irq_enable/irq_disable callbacks, but defer the actual PLGPIO
IE/EIT register writes to irq_bus_sync_unlock(), after the IRQ core has
dropped desc->lock. The driver would keep per-line shadow state for:
- IRQ disabled/enabled state
- pending IE update
- edge direction state
- pending EIT update
and then synchronize those shadow updates from irq_bus_sync_unlock()
under a mutex.
In other words, the fast callbacks would only update local shadow state
and call gpiochip_enable_irq()/gpiochip_disable_irq(), while the sleepable
regmap writes would be batched into the irq bus sync phase.
Does that sound like an acceptable direction for SPEAr PLGPIO, or would
you prefer a different fix, such as changing the underlying syscon regmap
locking model or handling only the IE register path?
The draft patch I have locally is roughly:
pinctrl: spear: defer PLGPIO IRQ updates to bus sync
and it changes only drivers/pinctrl/spear/pinctrl-plgpio.c.
Thanks,
Runyu
^ permalink raw reply
* [PATCH v2] nvme-apple: Use acquire/release for queue enabled state
From: Gui-Dong Han @ 2026-06-18 2:15 UTC (permalink / raw)
To: sven, kbusch, linux-nvme
Cc: axboe, hch, sagi, j, neal, asahi, linux-kernel, linux-arm-kernel,
baijiaju1990, Gui-Dong Han
apple_nvme_init_queue() initializes queue state and then marks the queue
enabled. The interrupt and request paths check enabled before using that
queue state.
The old wmb() after WRITE_ONCE(enabled, true) does not publish the
earlier initialization before enabled becomes visible. Use a release store
when enabling the queue and acquire loads when testing it.
Although the shutdown-side enabled accesses are not used for publishing
queue initialization, use helpers for them as well for consistency.
Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver")
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
---
v2:
- Drop the old wmb(), as suggested by Keith Busch.
- Use the queue enabled helpers in apple_nvme_disable(), as suggested by
Keith Busch.
v1:
- Found by auditing READ_ONCE() used for synchronization.
- A similar fix can be found in 8df672bfe3ec.
---
drivers/nvme/host/apple.c | 30 +++++++++++++++++++++++-------
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
index f9327feb87d0..291271c3954b 100644
--- a/drivers/nvme/host/apple.c
+++ b/drivers/nvme/host/apple.c
@@ -151,6 +151,23 @@ struct apple_nvme_queue {
bool enabled;
};
+static inline bool apple_nvme_queue_enabled(struct apple_nvme_queue *q)
+{
+ /* Pair with apple_nvme_enable_queue(). */
+ return smp_load_acquire(&q->enabled);
+}
+
+static inline void apple_nvme_enable_queue(struct apple_nvme_queue *q)
+{
+ /* Publish queue initialization before setting q->enabled. */
+ smp_store_release(&q->enabled, true);
+}
+
+static inline void apple_nvme_disable_queue(struct apple_nvme_queue *q)
+{
+ WRITE_ONCE(q->enabled, false);
+}
+
/*
* The apple_nvme_iod describes the data in an I/O.
*
@@ -677,7 +694,7 @@ static bool apple_nvme_handle_cq(struct apple_nvme_queue *q, bool force)
bool found;
DEFINE_IO_COMP_BATCH(iob);
- if (!READ_ONCE(q->enabled) && !force)
+ if (!apple_nvme_queue_enabled(q) && !force)
return false;
found = apple_nvme_poll_cq(q, &iob);
@@ -780,7 +797,7 @@ static blk_status_t apple_nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
* We should not need to do this, but we're still using this to
* ensure we can drain requests on a dying queue.
*/
- if (unlikely(!READ_ONCE(q->enabled)))
+ if (unlikely(!apple_nvme_queue_enabled(q)))
return BLK_STS_IOERR;
if (!nvme_check_ready(&anv->ctrl, req, true))
@@ -863,7 +880,7 @@ static void apple_nvme_disable(struct apple_nvme *anv, bool shutdown)
nvme_quiesce_io_queues(&anv->ctrl);
if (!dead) {
- if (READ_ONCE(anv->ioq.enabled)) {
+ if (apple_nvme_queue_enabled(&anv->ioq)) {
apple_nvme_remove_sq(anv);
apple_nvme_remove_cq(anv);
}
@@ -887,8 +904,8 @@ static void apple_nvme_disable(struct apple_nvme *anv, bool shutdown)
nvme_disable_ctrl(&anv->ctrl, false);
}
- WRITE_ONCE(anv->ioq.enabled, false);
- WRITE_ONCE(anv->adminq.enabled, false);
+ apple_nvme_disable_queue(&anv->ioq);
+ apple_nvme_disable_queue(&anv->adminq);
mb(); /* ensure that nvme_queue_rq() sees that enabled is cleared */
nvme_quiesce_admin_queue(&anv->ctrl);
@@ -1016,8 +1033,7 @@ static void apple_nvme_init_queue(struct apple_nvme_queue *q)
memset(q->tcbs, 0, anv->hw->max_queue_depth
* sizeof(struct apple_nvmmu_tcb));
memset(q->cqes, 0, depth * sizeof(struct nvme_completion));
- WRITE_ONCE(q->enabled, true);
- wmb(); /* ensure the first interrupt sees the initialization */
+ apple_nvme_enable_queue(q);
}
static void apple_nvme_reset_work(struct work_struct *work)
--
2.34.1
^ permalink raw reply related
* [PATCH v4] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Hongling Zeng @ 2026-06-18 2:06 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng, Frank Li
When terminating DMA transfers, active descriptors are not properly
reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
descriptors and their LLI chains to be permanently leaked.
Fix by using vchan_terminate_vdesc() which handles both cyclic and
non-cyclic descriptors by adding them to desc_terminated queue for
proper cleanup.
Add pchan->desc != pchan->done check to prevent double-adding completed
descriptors, which would corrupt the list.
Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Suggested-by: Frank Li <Frank.li@oss.nxp.com>
---
Change in v2;
-Add pchan->desc != pchan->done check to prevent race condition
where completed descriptors could be double-added to desc_completed
list, causing list corruption
---
Change in v3:
-Fix by using vchan_terminate_vdesc() as suggested by Frank Li
---
Change in v4:
-Correct the commit message
---
drivers/dma/sun6i-dma.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 7a79f346250a..134ae840f176 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
spin_lock_irqsave(&vchan->vc.lock, flags);
- if (vchan->cyclic) {
- vchan->cyclic = false;
- if (pchan && pchan->desc) {
- struct virt_dma_desc *vd = &pchan->desc->vd;
- struct virt_dma_chan *vc = &vchan->vc;
-
- list_add_tail(&vd->node, &vc->desc_completed);
- }
+ if (pchan && pchan->desc && pchan->desc != pchan->done) {
+ struct virt_dma_desc *vd = &pchan->desc->vd;
+
+ vchan_terminate_vdesc(vd);
}
+ vchan->cyclic = false;
vchan_get_all_descriptors(&vchan->vc, &head);
if (pchan) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-18 1:57 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <ajNO3KSZV/elWONW@shlinux89>
On Thu, Jun 18, 2026 at 09:50:20AM +0800, Peng Fan wrote:
>Hi Sebastian,
>
>Thanks for your patch.
>
>On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>>which may timeout and is recognized as an error. This error is siltently
>>dropped and not dropped to the caller.
>>
>>Forward the error to the caller.
>>
>>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>>---
>> drivers/mailbox/imx-mailbox.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>>index 246a9a9e39520..0028073be4a71 100644
>>--- a/drivers/mailbox/imx-mailbox.c
>>+++ b/drivers/mailbox/imx-mailbox.c
>>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
>> u32 val;
>> int ret, count;
>>
>>+ ret = 0;
>> switch (cp->type) {
>> case IMX_MU_TYPE_TX:
>> imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
>> return -EINVAL;
>> }
>>
>>- return 0;
>>+ return ret;
>> }
>
>I just rethink about the logic here and rewrite the logic as below.
>error code is propogated to caller and poll timeout are removed.
>Please see whether it looks good for you or not.
Ignore this. Pushed the button too early
>
>[PATCH] mailbox: imx: make TXDB non-blocking and avoid polling in atomic context
>
>+
> imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx),
> priv->dcfg->xCR[IMX_MU_GCR]);
Oh. there might be issues without waiting here. For example, Linux just writes
the doorbell to notify SCMI processor power up a power domain, but when linux
continues to write registers, the SCMI processor may not fetch the message, then
linux will crash.
Regards
Peng
>- ret = -ETIMEDOUT;
>- count = 0;
>- while (ret && (count < 10)) {
>- ret =
>- readl_poll_timeout(priv->base + priv->dcfg->xCR[IMX_MU_GCR], val,
>- !(val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)),
>- 0, 10000);
>-
>- if (ret) {
>- dev_warn_ratelimited(priv->dev,
>- "channel type: %d timeout, %d times, retry\n",
>- cp->type, ++count);
>- }
>- }
> break;
> default:
> dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
>--
>2.50.1
>
>Thanks,
>Peng
>
>>
>> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>>
>>--
>>2.53.0
>>
>
>
^ permalink raw reply
* Re: [PATCH v7 15/20] perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters
From: wuyifan @ 2026-06-18 1:53 UTC (permalink / raw)
To: Colton Lewis, kvm
Cc: Alexandru Elisei, Paolo Bonzini, Jonathan Corbet, Russell King,
Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Mingwei Zhang, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Mark Rutland, Shuah Khan, Ganapatrao Kulkarni, James Clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest, wangyushan, Zhou Wang, xuwei5,
prime.zeng, fanghao11
In-Reply-To: <20260504211813.1804997-16-coltonlewis@google.com>
Hi Colton,
On 5/5/2026 5:18 AM, Colton Lewis wrote:
> static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> {
> - u64 pmovsr;
> struct perf_sample_data data;
> struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
> struct pt_regs *regs;
> + u64 host_set = kvm_pmu_host_counter_mask(cpu_pmu);
> + u64 pmovsr;
kvm_pmu_host_counter_mask() is called from armv8pmu_handle_irq(). This
interrupt fires in both host and guest contexts.
However, kvm_pmu_host_counter_mask() dereferences
host_data_ptr(nr_event_counters). This indirection requires
kvm_arm_hyp_percpu_base[cpu] to be initialized, which only happens during
KVM hypervisor setup. When the interrupt fires in a guest kernel where
KVM is
compiled but not active, the per-CPU base is NULL and the dereference
faults.
Thanks,
Yifan
^ permalink raw reply
* Re: [PATCH v1] mfd: mt6397-irq: Fix PM notifier use-after-free
From: 최유호 @ 2026-06-18 1:53 UTC (permalink / raw)
To: Lee Jones
Cc: Matthias Brugger, AngeloGioacchino Del Regno, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260617152615.GO10056@google.com>
On Wed, 17 Jun 2026 at 11:26, Lee Jones <lee@kernel.org> wrote:
> [Severity: High]
> Is it safe to explicitly remove the IRQ domain here while the devm-managed
> parent threaded IRQ remains active?
>
> The parent IRQ was requested earlier via devm_request_threaded_irq(). Because
> devres cleanup does not run until the probe function completely fails and
> returns, the parent IRQ remains active and enabled during this window.
>
> If an interrupt triggers during this error path, the active IRQ handler
> mt6397_irq_thread() will execute and call mt6397_irq_handle_reg(). This in
> turn calls irq_find_mapping(), which will dereference the freed irq_domain,
> resulting in a use-after-free.
Thanks for pointing this out. Findings 1 and 3 look like pre-existing
issues. Finding 2, however, appears to be related to the error-path cleanup
I added.
I will rework the patch so the notifier and irq_domain cleanup ordering is
handled consistently.
^ permalink raw reply
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-18 1:50 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <20260617-imx_mbox_rproc-v3-1-77948112defc@linutronix.de>
Hi Sebastian,
Thanks for your patch.
On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>which may timeout and is recognized as an error. This error is siltently
>dropped and not dropped to the caller.
>
>Forward the error to the caller.
>
>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> drivers/mailbox/imx-mailbox.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>index 246a9a9e39520..0028073be4a71 100644
>--- a/drivers/mailbox/imx-mailbox.c
>+++ b/drivers/mailbox/imx-mailbox.c
>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> u32 val;
> int ret, count;
>
>+ ret = 0;
> switch (cp->type) {
> case IMX_MU_TYPE_TX:
> imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> return -EINVAL;
> }
>
>- return 0;
>+ return ret;
> }
I just rethink about the logic here and rewrite the logic as below.
error code is propogated to caller and poll timeout are removed.
Please see whether it looks good for you or not.
[PATCH] mailbox: imx: make TXDB non-blocking and avoid polling in atomic context
The IMX_MU_TYPE_TXDB_V2 path currently writes to the GIR register and
then polls until the bit is cleared using readl_poll_timeout().
Because send_data() is invoked under spin_lock_irqsave() from the mailbox
core, meaning the polling loop can run in atomic context with interrupts
disabled. In the worst case, the current implementation may busy-wait for
up to 100ms, leading to excessive interrupt latency and potential soft
lockup warnings.
Moreover, the TXDB channel implements a doorbell mechanism, where the
sender only needs to trigger the event when the channel is idle. Waiting
for the GIR bit to clear after the write is no good with polling.
Fix this by:
- Checking the GIR bit before issuing the write
- Returning -EBUSY if the channel is still active
- Removing the post-write polling loop
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/mailbox/imx-mailbox.c | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 796ba983db29e..ed53bcffec673 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -241,7 +241,6 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
{
u32 *arg = data;
u32 val;
- int ret, count;
switch (cp->type) {
case IMX_MU_TYPE_TX:
@@ -253,22 +252,14 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
queue_work(system_bh_wq, &cp->txdb_work);
break;
case IMX_MU_TYPE_TXDB_V2:
+ val = readl(priv->base + priv->dcfg->xCR[IMX_MU_GCR]);
+ if (val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)) {
+ dev_info(priv->dev, "channel [%d] type: %d busy\n", cp->idx, cp->type);
+ return -EBUSY;
+ }
+
imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx),
priv->dcfg->xCR[IMX_MU_GCR]);
- ret = -ETIMEDOUT;
- count = 0;
- while (ret && (count < 10)) {
- ret =
- readl_poll_timeout(priv->base + priv->dcfg->xCR[IMX_MU_GCR], val,
- !(val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)),
- 0, 10000);
-
- if (ret) {
- dev_warn_ratelimited(priv->dev,
- "channel type: %d timeout, %d times, retry\n",
- cp->type, ++count);
- }
- }
break;
default:
dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
--
2.50.1
Thanks,
Peng
>
> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>
>--
>2.53.0
>
^ permalink raw reply related
* RE: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-18 1:43 UTC (permalink / raw)
To: Conor Dooley
Cc: 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, 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: <20260617-clinic-blank-61289f8fc1c2@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:56 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: 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 <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> On Wed, Jun 17, 2026 at 02:04:35PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The AUDSS CRU contains an internal clock tree of muxes, dividers and
> > gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider
> > is a child node of the cix,sky1-audss-system-control syscon and
> > accesses registers through the parent MMIO region.
>
> Why can this not just be part of the parent syscon node?
The clock and reset blocks are handled by different subsystems and maintainers (clk vs reset). Putting the clock provider on the parent syscon node would mean a single driver has to register both the reset controller and the clock provider on one device, which doesn't fit well.
Thanks,
Joakim
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox