* [PATCH] ARM: configs: sama5: Enable current Microchip KSZ DSA symbols
From: Pengpeng Hou @ 2026-06-24 8:12 UTC (permalink / raw)
To: Russell King; +Cc: Pengpeng Hou, linux-arm-kernel, linux-kernel
The Microchip KSZ DSA family now uses `NET_DSA_MICROCHIP_KSZ_COMMON`
for the common switch provider and `NET_DSA_MICROCHIP_KSZ_SPI` for SPI
attached switches.
The sama5 defconfig still enables the stale `KSZ9477`-specific symbols.
Those symbols no longer select the provider objects, while SAMA5 device
trees still contain Microchip KSZ SPI switch consumers such as
`microchip,ksz9477` and `microchip,ksz8563`.
Enable the current common and SPI provider symbols instead.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/configs/sama5_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -70,7 +70,7 @@ CONFIG_BLK_DEV_SD=y
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_NETDEVICES=y
-CONFIG_NET_DSA_MICROCHIP_KSZ9477=m
-CONFIG_NET_DSA_MICROCHIP_KSZ9477_SPI=m
+CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON=m
+CONFIG_NET_DSA_MICROCHIP_KSZ_SPI=m
# CONFIG_NET_VENDOR_BROADCOM is not set
CONFIG_MACB=y
# CONFIG_NET_VENDOR_CIRRUS is not set
^ permalink raw reply
* [PATCH] dmaengine: mediatek: hsdma: fix runtime PM leak on init failure
From: Myeonghun Pak @ 2026-06-24 8:16 UTC (permalink / raw)
To: Sean Wang, Vinod Koul, Frank Li, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dmaengine, linux-arm-kernel, linux-mediatek, linux-kernel,
Myeonghun Pak, Ijae Kim
mtk_hsdma_hw_init() enables runtime PM and gets a runtime PM reference
before enabling the HSDMA clock. It currently ignores failures from
pm_runtime_get_sync(); if runtime resume fails, the usage count remains
held. If clk_prepare_enable() then fails, runtime PM is left enabled with
the usage count held.
Use pm_runtime_resume_and_get() so resume failures do not leak the usage
count, and unwind runtime PM when clk_prepare_enable() fails.
The probe path also ignores the return value from mtk_hsdma_hw_init(), so a
failed hardware init can continue as a successful probe. Propagate
mtk_hsdma_hw_init() failures from probe, while keeping a separate unwind
label so mtk_hsdma_hw_deinit() is only called after hardware init succeeds.
Fixes: 548c4597e984 ("dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
drivers/dma/mediatek/mtk-hsdma.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/mediatek/mtk-hsdma.c b/drivers/dma/mediatek/mtk-hsdma.c
index a43412ff5e..987e5274fc 100644
--- a/drivers/dma/mediatek/mtk-hsdma.c
+++ b/drivers/dma/mediatek/mtk-hsdma.c
@@ -849,16 +849,25 @@ static int mtk_hsdma_hw_init(struct mtk_hsdma_device *hsdma)
int err;
pm_runtime_enable(hsdma2dev(hsdma));
- pm_runtime_get_sync(hsdma2dev(hsdma));
+ err = pm_runtime_resume_and_get(hsdma2dev(hsdma));
+ if (err < 0)
+ goto err_disable_pm;
err = clk_prepare_enable(hsdma->clk);
if (err)
- return err;
+ goto err_put_pm;
mtk_dma_write(hsdma, MTK_HSDMA_INT_ENABLE, 0);
mtk_dma_write(hsdma, MTK_HSDMA_GLO, MTK_HSDMA_GLO_DEFAULT);
return 0;
+
+err_put_pm:
+ pm_runtime_put_sync(hsdma2dev(hsdma));
+err_disable_pm:
+ pm_runtime_disable(hsdma2dev(hsdma));
+
+ return err;
}
static int mtk_hsdma_hw_deinit(struct mtk_hsdma_device *hsdma)
@@ -983,7 +992,9 @@ static int mtk_hsdma_probe(struct platform_device *pdev)
goto err_unregister;
}
- mtk_hsdma_hw_init(hsdma);
+ err = mtk_hsdma_hw_init(hsdma);
+ if (err)
+ goto err_free;
err = devm_request_irq(&pdev->dev, hsdma->irq,
mtk_hsdma_irq, 0,
@@ -991,7 +1002,7 @@ static int mtk_hsdma_probe(struct platform_device *pdev)
if (err) {
dev_err(&pdev->dev,
"request_irq failed with err %d\n", err);
- goto err_free;
+ goto err_deinit;
}
platform_set_drvdata(pdev, hsdma);
@@ -1000,8 +1011,9 @@ static int mtk_hsdma_probe(struct platform_device *pdev)
return 0;
-err_free:
+err_deinit:
mtk_hsdma_hw_deinit(hsdma);
+err_free:
of_dma_controller_free(pdev->dev.of_node);
err_unregister:
dma_async_device_unregister(dd);
--
2.47.1
^ permalink raw reply related
* [PATCH] ARM: davinci_all_defconfig: Enable current ST7586 DRM symbol
From: Pengpeng Hou @ 2026-06-24 8:20 UTC (permalink / raw)
To: Russell King; +Cc: Pengpeng Hou, linux-arm-kernel, linux-kernel
The ST7586 DRM provider is now built by `CONFIG_DRM_ST7586` under
drivers/gpu/drm/sitronix/.
davinci_all_defconfig still enables the old tinyDRM carrier symbols
`CONFIG_DRM_TINYDRM` and `CONFIG_TINYDRM_ST7586`, which no longer carry
st7586.o. Enable the current provider symbol instead.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/configs/davinci_all_defconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -144,8 +144,7 @@ CONFIG_VIDEO_TVP514X=m
CONFIG_VIDEO_ADV7343=m
CONFIG_DRM=m
CONFIG_DRM_TILCDC=m
CONFIG_DRM_SIMPLE_BRIDGE=m
-CONFIG_DRM_TINYDRM=m
-CONFIG_TINYDRM_ST7586=m
+CONFIG_DRM_ST7586=m
CONFIG_FB=y
CONFIG_FB_DA8XX=y
CONFIG_BACKLIGHT_PWM=m
^ permalink raw reply
* Re: [PATCH v6 3/4] reset: cix: add sky1 audss auxiliary reset driver
From: Philipp Zabel @ 2026-06-24 8:30 UTC (permalink / raw)
To: joakim.zhang, mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt,
gary.yang
Cc: cix-kernel-upstream, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623070805.211019-4-joakim.zhang@cixtech.com>
On Di, 2026-06-23 at 15:08 +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> Add an auxiliary reset controller driver for the AUDSS CRU. Sixteen
> software reset lines for audio subsystem peripherals are controlled
> through one register in the CRU register map.
>
> The driver is created by the AUDSS clock platform driver and registers
> the reset controller on the CRU device node.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> drivers/reset/Kconfig | 14 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-sky1-audss.c | 192 +++++++++++++++++++++++++++++++
> 3 files changed, 207 insertions(+)
> create mode 100644 drivers/reset/reset-sky1-audss.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index d009eb0849a3..f74859b292ae 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -300,6 +300,20 @@ config RESET_SKY1
> help
> This enables the reset controller for Cix Sky1.
>
> +config RESET_SKY1_AUDSS
> + tristate "Cix Sky1 Audio Subsystem reset controller"
> + depends on ARCH_CIX || COMPILE_TEST
> + select AUXILIARY_BUS
> + select REGMAP_MMIO
> + default CLK_SKY1_AUDSS
> + help
> + Support for block-level software reset lines in the Cix Sky1
> + Audio Subsystem (AUDSS) Clock and Reset Unit. Sixteen reset
> + outputs for audio peripherals are controlled through the CRU
> + register map. The driver binds as an auxiliary device from
> + the AUDSS clock driver. Say M or Y here if you want to build
> + this driver.
> +
> config RESET_SOCFPGA
> bool "SoCFPGA Reset Driver" if COMPILE_TEST && (!ARM || !ARCH_INTEL_SOCFPGA)
> default ARM && ARCH_INTEL_SOCFPGA
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 3e52569bd276..e81407ea3e29 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_RESET_RZV2H_USB2PHY) += reset-rzv2h-usb2phy.o
> obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
> obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> obj-$(CONFIG_RESET_SKY1) += reset-sky1.o
> +obj-$(CONFIG_RESET_SKY1_AUDSS) += reset-sky1-audss.o
> obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
> obj-$(CONFIG_RESET_SUNPLUS) += reset-sunplus.o
> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> diff --git a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> new file mode 100644
> index 000000000000..20870f37d7d7
> --- /dev/null
> +++ b/drivers/reset/reset-sky1-audss.c
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Cix Sky1 Audio Subsystem reset controller driver
> + *
> + * Copyright 2026 Cix Technology Group Co., Ltd.
> + */
> +
> +#include <dt-bindings/reset/cix,sky1-audss-cru.h>
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/regmap.h>
> +#include <linux/reset-controller.h>
> +
> +#define SKY1_RESET_SLEEP_MIN_US 50
> +#define SKY1_RESET_SLEEP_MAX_US 100
> +
> +#define AUDSS_SW_RST 0x78
> +
> +struct sky1_audss_reset_map {
> + unsigned int offset;
> + unsigned int mask;
> +};
> +
> +struct sky1_audss_reset {
> + struct reset_controller_dev rcdev;
> + struct regmap *regmap;
> + const struct sky1_audss_reset_map *map;
> +};
> +
> +static const struct sky1_audss_reset_map sky1_audss_reset_map[] = {
> + [AUDSS_I2S0_SW_RST] = { AUDSS_SW_RST, BIT(0) },
> + [AUDSS_I2S1_SW_RST] = { AUDSS_SW_RST, BIT(1) },
> + [AUDSS_I2S2_SW_RST] = { AUDSS_SW_RST, BIT(2) },
> + [AUDSS_I2S3_SW_RST] = { AUDSS_SW_RST, BIT(3) },
> + [AUDSS_I2S4_SW_RST] = { AUDSS_SW_RST, BIT(4) },
> + [AUDSS_I2S5_SW_RST] = { AUDSS_SW_RST, BIT(5) },
> + [AUDSS_I2S6_SW_RST] = { AUDSS_SW_RST, BIT(6) },
> + [AUDSS_I2S7_SW_RST] = { AUDSS_SW_RST, BIT(7) },
> + [AUDSS_I2S8_SW_RST] = { AUDSS_SW_RST, BIT(8) },
> + [AUDSS_I2S9_SW_RST] = { AUDSS_SW_RST, BIT(9) },
> + [AUDSS_WDT_SW_RST] = { AUDSS_SW_RST, BIT(10) },
> + [AUDSS_TIMER_SW_RST] = { AUDSS_SW_RST, BIT(11) },
> + [AUDSS_MB0_SW_RST] = { AUDSS_SW_RST, BIT(12) },
> + [AUDSS_MB1_SW_RST] = { AUDSS_SW_RST, BIT(13) },
> + [AUDSS_HDA_SW_RST] = { AUDSS_SW_RST, BIT(14) },
> + [AUDSS_DMAC_SW_RST] = { AUDSS_SW_RST, BIT(15) },
> +};
> +
> +static struct sky1_audss_reset *to_sky1_audss_reset(struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct sky1_audss_reset, rcdev);
> +}
> +
> +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value = assert ? 0 : signal->mask;
> +
> + return regmap_update_bits(priv->regmap, signal->offset, signal->mask, value);
Why does this propagate the return value ...
> +}
> +
> +static int sky1_audss_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_set(rcdev, id, true);
... only to be ignored? It'd be better to pass it on.
> + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> + return 0;
> +}
> +
> +static int sky1_audss_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_set(rcdev, id, false);
> + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> + return 0;
> +}
> +
> +static int sky1_audss_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_assert(rcdev, id);
> + sky1_audss_reset_deassert(rcdev, id);
> + return 0;
> +}
Will any AUDSS reset consumer use the reset_control_reset() API?
If not, no need to implement this.
> +
> +static int sky1_audss_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value;
> +
> + regmap_read(priv->regmap, signal->offset, &value);
> + return !!(value & signal->mask);
> +}
> +
> +static const struct reset_control_ops sky1_audss_reset_ops = {
> + .reset = sky1_audss_reset,
> + .assert = sky1_audss_reset_assert,
> + .deassert = sky1_audss_reset_deassert,
> + .status = sky1_audss_reset_status,
> +};
> +
> +static const struct regmap_config sky1_audss_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static void sky1_audss_reset_iounmap(void *data)
> +{
> + iounmap(data);
> +}
> +
> +static int sky1_audss_reset_get_regmap(struct sky1_audss_reset *priv)
> +{
> + struct device *dev = priv->rcdev.dev;
> + void __iomem *base;
> + int ret;
> +
> + priv->regmap = dev_get_regmap(dev->parent, NULL);
> + if (priv->regmap)
> + return 0;
> +
> + base = of_iomap(dev->parent->of_node, 0);
> + if (!base)
> + return dev_err_probe(dev, -ENOMEM, "failed to iomap address space\n");
> +
> + ret = devm_add_action_or_reset(dev, sky1_audss_reset_iounmap, base);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register iounmap action\n");
> +
> + priv->regmap = devm_regmap_init_mmio(dev, base, &sky1_audss_regmap_config);
> + if (IS_ERR(priv->regmap))
> + return dev_err_probe(dev, PTR_ERR(priv->regmap),
> + "failed to initialize regmap\n");
Why is there a fallback path? The clock driver creates the regmap
before creating the reset aux device, so dev_get_regmap() can never
fail.
> +
> + return 0;
> +}
> +
> +static int sky1_audss_reset_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + struct sky1_audss_reset *priv;
> + struct device *dev = &adev->dev;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->map = sky1_audss_reset_map;
> + priv->rcdev.owner = THIS_MODULE;
> + priv->rcdev.nr_resets = ARRAY_SIZE(sky1_audss_reset_map);
> + priv->rcdev.ops = &sky1_audss_reset_ops;
> + priv->rcdev.of_node = dev->parent->of_node;
auxiliary_device_create() uses device_set_of_node_from_dev() to inherit
the parent of_node, so you can use dev->of_node here.
> + priv->rcdev.dev = dev;
> + priv->rcdev.of_reset_n_cells = 1;
No need to set of_reset_n_cells.
> +
> + dev_set_drvdata(dev, priv);
This seems unnecessary as well.
> +
> + ret = sky1_audss_reset_get_regmap(priv);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to get regmap\n");
> +
> + return devm_reset_controller_register(dev, &priv->rcdev);
> +}
> +
> +static const struct auxiliary_device_id sky1_audss_reset_ids[] = {
> + { .name = "clk_sky1_audss.reset" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(auxiliary, sky1_audss_reset_ids);
> +
> +static struct auxiliary_driver sky1_audss_reset_driver = {
> + .probe = sky1_audss_reset_probe,
> + .id_table = sky1_audss_reset_ids,
> +};
> +
Drop this empty line.
> +module_auxiliary_driver(sky1_audss_reset_driver);
> +
> +MODULE_AUTHOR("Joakim Zhang <joakim.zhang@cixtech.com>");
> +MODULE_DESCRIPTION("Cix Sky1 Audio Subsystem reset driver");
> +MODULE_LICENSE("GPL");
regards
Philipp
^ permalink raw reply
* [PATCH v1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-24 8:37 UTC (permalink / raw)
To: Nicolas Frattaroli, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai
Cc: Heiko Stuebner, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel
Currently that header is only included via:
<sound/dmaengine_pcm.h> ->
<sound/soc.h> ->
<linux/platform_device.h>
which doesn't look reliable, still more in the presence of the comment:
/* For the current users of sound/soc.h to avoid build issues */
in <sound/soc.h>.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
sound/soc/rockchip/rockchip_sai.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..37e81d56bc16 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -11,6 +11,7 @@
#include <linux/delay.h>
#include <linux/of_device.h>
#include <linux/clk.h>
+#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/reset.h>
base-commit: ef0c9f75a19532d7675384708fc8621e10850104
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Add tracepoint for EVTQ events
From: chenjun (AM) @ 2026-06-24 8:43 UTC (permalink / raw)
To: Robin Murphy, will@kernel.org, joro@8bytes.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: zhangyuwei (G)
In-Reply-To: <59c283b1-0436-4ea1-8feb-996dba617b6d@arm.com>
在 2026/6/23 23:31, Robin Murphy 写道:
> On 13/06/2026 2:00 pm, Chen Jun wrote:
>> Events reported by the SMMU can severely impact accelerator
>> performance. Currently, only events that the SMMU fails to handle are
>> printed to the kernel log, leaving most events invisible to users.
>> To analyze and optimize accelerator performance, complete visibility
>> into all SMMU-reported events is required.
>
> What events, exactly? AFAICS the only events we should expect to handle
> "invisibly", without being some unexpected error condition worth
> screaming about, would be stalls for SVA page faults, and if SVA isn't
> generically accounting page faults itself then I would imagine it
> probably should.
>
> Thanks,
> Robin.
>
AF and WP faults are common occurrences. and they can significantly
impact SMMU performance. If we can determine exactly at which address
and what type of page fault occurred, it would help us avoid SVA page
fault events through other means. Also, I don't see any separate
accounting for page fault events in the SVA flow.
Thanks
Chen Jun
>> Add a tracepoint in the EVTQ interrupt handler to capture every
>> event record reported by the SMMU. This allows users to collect all
>> event information via ftrace/perf for further analysis, complementing
>> the existing event decoder and error dump which only cover a subset
>> of events.
>>
>> Signed-off-by: Chen Jun <chenjun102@huawei.com>
>> ---
>> drivers/iommu/arm/arm-smmu-v3/Makefile | 2 +-
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++
>> drivers/iommu/arm/arm-smmu-v3/trace.c | 9 ++++
>> drivers/iommu/arm/arm-smmu-v3/trace.h | 53 +++++++++++++++++++++
>> 4 files changed, 66 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/iommu/arm/arm-smmu-v3/trace.c
>> create mode 100644 drivers/iommu/arm/arm-smmu-v3/trace.h
>>
>> diff --git a/drivers/iommu/arm/arm-smmu-v3/Makefile b/drivers/iommu/arm/arm-smmu-v3/Makefile
>> index 493a659cc66b..63a8d71bfc93 100644
>> --- a/drivers/iommu/arm/arm-smmu-v3/Makefile
>> +++ b/drivers/iommu/arm/arm-smmu-v3/Makefile
>> @@ -1,6 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0
>> obj-$(CONFIG_ARM_SMMU_V3) += arm_smmu_v3.o
>> -arm_smmu_v3-y := arm-smmu-v3.o
>> +arm_smmu_v3-y := arm-smmu-v3.o trace.o
>> arm_smmu_v3-$(CONFIG_ARM_SMMU_V3_IOMMUFD) += arm-smmu-v3-iommufd.o
>> arm_smmu_v3-$(CONFIG_ARM_SMMU_V3_SVA) += arm-smmu-v3-sva.o
>> arm_smmu_v3-$(CONFIG_TEGRA241_CMDQV) += tegra241-cmdqv.o
>> 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 e8d7dbe495f0..85e6c25b73ed 100644
>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> @@ -34,6 +34,8 @@
>> #include "arm-smmu-v3.h"
>> #include "../../dma-iommu.h"
>>
>> +#include "trace.h"
>> +
>> static bool disable_msipolling;
>> module_param(disable_msipolling, bool, 0444);
>> MODULE_PARM_DESC(disable_msipolling,
>> @@ -2271,6 +2273,7 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
>>
>> do {
>> while (!queue_remove_raw(q, evt)) {
>> + trace_smmu_evtq_event(smmu, evt);
>> arm_smmu_decode_event(smmu, evt, &event);
>> if (arm_smmu_handle_event(smmu, evt, &event))
>> arm_smmu_dump_event(smmu, evt, &event, &rs);
>> diff --git a/drivers/iommu/arm/arm-smmu-v3/trace.c b/drivers/iommu/arm/arm-smmu-v3/trace.c
>> new file mode 100644
>> index 000000000000..77378698b1a3
>> --- /dev/null
>> +++ b/drivers/iommu/arm/arm-smmu-v3/trace.c
>> @@ -0,0 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * ARM SMMUv3 trace support
>> + *
>> + * Copyright (c) 2026 OpenCloudOS / openEuler
>> + */
>> +
>> +#define CREATE_TRACE_POINTS
>> +#include "trace.h"
>> diff --git a/drivers/iommu/arm/arm-smmu-v3/trace.h b/drivers/iommu/arm/arm-smmu-v3/trace.h
>> new file mode 100644
>> index 000000000000..7cec8d41745e
>> --- /dev/null
>> +++ b/drivers/iommu/arm/arm-smmu-v3/trace.h
>> @@ -0,0 +1,53 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * ARM SMMUv3 trace support
>> + *
>> + * Copyright (c) 2026 OpenCloudOS / openEuler
>> + */
>> +
>> +#undef TRACE_SYSTEM
>> +#define TRACE_SYSTEM arm_smmu_v3
>> +
>> +#if !defined(_TRACE_ARM_SMMU_V3_H) || defined(TRACE_HEADER_MULTI_READ)
>> +#define _TRACE_ARM_SMMU_V3_H
>> +
>> +#include <linux/tracepoint.h>
>> +
>> +#include "arm-smmu-v3.h"
>> +
>> +TRACE_EVENT(smmu_evtq_event,
>> +
>> + TP_PROTO(struct arm_smmu_device *smmu, u64 *evt),
>> +
>> + TP_ARGS(smmu, evt),
>> +
>> + TP_STRUCT__entry(
>> + __string(iommu, dev_name(smmu->dev))
>> + __field(u64, evt0)
>> + __field(u64, evt1)
>> + __field(u64, evt2)
>> + __field(u64, evt3)
>> + ),
>> +
>> + TP_fast_assign(
>> + __assign_str(iommu);
>> + __entry->evt0 = evt[0];
>> + __entry->evt1 = evt[1];
>> + __entry->evt2 = evt[2];
>> + __entry->evt3 = evt[3];
>> + ),
>> +
>> + TP_printk("%s evt: 0x%016llx 0x%016llx 0x%016llx 0x%016llx",
>> + __get_str(iommu),
>> + __entry->evt0, __entry->evt1,
>> + __entry->evt2, __entry->evt3)
>> +);
>> +
>> +#endif /* _TRACE_ARM_SMMU_V3_H */
>> +
>> +/* This part must be outside protection */
>> +#undef TRACE_INCLUDE_PATH
>> +#undef TRACE_INCLUDE_FILE
>> +#define TRACE_INCLUDE_PATH ../../drivers/iommu/arm/arm-smmu-v3/
>> +#define TRACE_INCLUDE_FILE trace
>> +#include <trace/define_trace.h>
>
>
>
^ permalink raw reply
* [PATCH 0/7] ARM: rockchip: rv1126: Add support for Alientek ATK-DLRV1126
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
The ATK-DLRV1126 board consists of a CLRV1126F core module and a
DLRV1126 carrier board. The core module contains the Rockchip RV1126
SoC, eMMC and RK809 PMIC. The carrier board provides Gigabit Ethernet,
SD card, AP6212 WiFi and Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and
audio connectors.
This series adds the Alientek vendor prefix and board compatible, updates
the Rockchip DWMAC binding and driver for the RV1126 GMAC reference
output clock, adds missing RV1126 SoC description pieces, and finally
adds the CLRV1126F core module and DLRV1126 carrier board device trees.
The board was tested with Ethernet/NFS boot, eMMC, SD card, SDIO WiFi
enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and RK809
audio card registration.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Yanan He (7):
dt-bindings: vendor-prefixes: add alientek
dt-bindings: arm: rockchip: Add Alientek DLRV1126
dt-bindings: net: rockchip-dwmac: Allow 9 clocks
net: stmmac: dwmac-rk: Enable refout clock for RGMII
ARM: dts: rockchip: Add RV1126 GMAC refout clock
ARM: dts: rockchip: Add RV1126 I2C5
ARM: dts: rockchip: Add Alientek DLRV1126
.../devicetree/bindings/arm/rockchip.yaml | 7 +
.../devicetree/bindings/net/rockchip-dwmac.yaml | 2 +-
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rv1126-alientek-clrv1126f.dtsi | 277 +++++++++++++++++++++
.../boot/dts/rockchip/rv1126-alientek-dlrv1126.dts | 258 +++++++++++++++++++
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 +
arch/arm/boot/dts/rockchip/rv1126.dtsi | 18 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 +-
9 files changed, 577 insertions(+), 4 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260618-rv1126-alientek-dlrv1126-d94abdcf8580
Best regards,
--
Yanan He <grumpycat921013@gmail.com>
^ permalink raw reply
* [PATCH 1/7] dt-bindings: vendor-prefixes: add alientek
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
Add a vendor prefix for Alientek, a board and module vendor used by the
ATK-DLRV1126 board.
Link: https://en.alientek.com
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..a23508a61373 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -88,6 +88,8 @@ patternProperties:
description: ALFA Network Inc.
"^algoltek,.*":
description: AlgolTek, Inc.
+ "^alientek,.*":
+ description: Guangzhou Xingyi Intelligent Technology Co., Ltd.
"^allegro,.*":
description: Allegro DVT
"^allegromicro,.*":
--
2.54.0
^ permalink raw reply related
* [PATCH 2/7] dt-bindings: arm: rockchip: Add Alientek DLRV1126
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
The board consists of a DLRV1126 carrier board and a CLRV1126F core
module based on the Rockchip RV1126 SoC.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde18626d..9058f2a461d5 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -162,6 +162,13 @@ properties:
- const: coolpi,pi-4b
- const: rockchip,rk3588s
+ - description: Alientek CLRV1126F SoM based boards
+ items:
+ - enum:
+ - alientek,dlrv1126
+ - const: alientek,clrv1126f
+ - const: rockchip,rv1126
+
- description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
items:
- const: edgeble,neural-compute-module-2-io # Edgeble Neural Compute Module 2 IO Board
--
2.54.0
^ permalink raw reply related
* [PATCH 3/7] dt-bindings: net: rockchip-dwmac: Allow 9 clocks
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
RV1126 has a separate GMAC Ethernet output clock used as the external
PHY reference clock. This clock is described in addition to the existing
GMAC clocks.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 80c252845349..86a7e83675ae 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -71,7 +71,7 @@ properties:
clocks:
minItems: 4
- maxItems: 8
+ maxItems: 9
clock-names:
contains:
--
2.54.0
^ permalink raw reply related
* [PATCH 4/7] net: stmmac: dwmac-rk: Enable refout clock for RGMII
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
Some Rockchip GMAC integrations use clk_mac_refout as an external PHY
reference clock even when the MAC is configured for RGMII.
RV1126 boards can route CLK_GMAC_ETHERNET_OUT to the external PHY as a
25 MHz reference clock. If the driver does not acquire and enable this
clock in RGMII mode, the common clock framework may disable it as unused
and the PHY can lose its reference clock.
Enable the refout clock handling for RGMII in addition to RMII.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 8d7042e68926..f6fdc0c5b475 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1112,7 +1112,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
bsp_priv->clk_enabled = false;
bsp_priv->num_clks = ARRAY_SIZE(rk_clocks);
- if (phy_iface == PHY_INTERFACE_MODE_RMII)
+ if (phy_iface == PHY_INTERFACE_MODE_RMII ||
+ phy_iface == PHY_INTERFACE_MODE_RGMII)
bsp_priv->num_clks += ARRAY_SIZE(rk_rmii_clocks);
bsp_priv->clks = devm_kcalloc(dev, bsp_priv->num_clks,
@@ -1123,7 +1124,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
for (i = 0; i < ARRAY_SIZE(rk_clocks); i++)
bsp_priv->clks[i].id = rk_clocks[i];
- if (phy_iface == PHY_INTERFACE_MODE_RMII) {
+ if (phy_iface == PHY_INTERFACE_MODE_RMII ||
+ phy_iface == PHY_INTERFACE_MODE_RGMII) {
for (j = 0; j < ARRAY_SIZE(rk_rmii_clocks); j++)
bsp_priv->clks[i++].id = rk_rmii_clocks[j];
}
--
2.54.0
^ permalink raw reply related
* [PATCH 5/7] ARM: dts: rockchip: Add RV1126 GMAC refout clock
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
This clock can be routed to an external Ethernet PHY as its reference
clock. Boards using this clock need the clock to be described so the
dwmac-rk driver can acquire and keep it enabled.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/rv1126.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index d6e8b63daa42..5b1ee06dc035 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -624,10 +624,11 @@ gmac: ethernet@ffc40000 {
rockchip,grf = <&grf>;
clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
<&cru CLK_GMAC_TX_RX>, <&cru CLK_GMAC_REF>,
+ <&cru CLK_GMAC_ETHERNET_OUT>,
<&cru ACLK_GMAC>, <&cru PCLK_GMAC>,
<&cru CLK_GMAC_TX_RX>, <&cru CLK_GMAC_PTPREF>;
clock-names = "stmmaceth", "mac_clk_rx",
- "mac_clk_tx", "clk_mac_ref",
+ "mac_clk_tx", "clk_mac_ref", "clk_mac_refout",
"aclk_mac", "pclk_mac",
"clk_mac_speed", "ptp_ref";
resets = <&cru SRST_GMAC_A>;
--
2.54.0
^ permalink raw reply related
* [PATCH 6/7] ARM: dts: rockchip: Add RV1126 I2C5
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
The controller is present in the SoC and can be used by boards for
external peripherals, such as an RTC on the Alientek DLRV1126 carrier
board.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 ++++++++++
arch/arm/boot/dts/rockchip/rv1126.dtsi | 15 +++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
index 35ef6732281f..1d883b80aed4 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
@@ -123,6 +123,16 @@ i2c3m2_xfer: i2c3m2-xfer {
<1 RK_PD7 3 &pcfg_pull_none>;
};
};
+ i2c5 {
+ /omit-if-no-ref/
+ i2c5m0_xfer: i2c5m0-xfer {
+ rockchip,pins =
+ /* i2c5_scl_m0 */
+ <2 RK_PA5 7 &pcfg_pull_none_drv_level_0_smt>,
+ /* i2c5_sda_m0 */
+ <2 RK_PB3 7 &pcfg_pull_none_drv_level_0_smt>;
+ };
+ };
i2s0 {
i2s0m0_lrck_tx: i2s0m0-lrck-tx {
rockchip,pins =
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index 5b1ee06dc035..483576de841e 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -23,6 +23,7 @@ aliases {
i2c0 = &i2c0;
i2c2 = &i2c2;
i2c3 = &i2c3;
+ i2c5 = &i2c5;
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
@@ -400,6 +401,20 @@ i2c3: i2c@ff520000 {
status = "disabled";
};
+ i2c5: i2c@ff540000 {
+ compatible = "rockchip,rv1126-i2c", "rockchip,rk3399-i2c";
+ reg = <0xff540000 0x1000>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5m0_xfer>;
+ rockchip,grf = <&pmugrf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
pwm8: pwm@ff550000 {
compatible = "rockchip,rv1126-pwm", "rockchip,rk3328-pwm";
reg = <0xff550000 0x10>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Krzysztof Kozlowski @ 2026-06-24 7:17 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <73b2bd81ce70814612e6d3cb689c3296de742aaf.1782224059.git.gregoire.layet@9elements.com>
On Tue, Jun 23, 2026 at 02:25:40PM +0000, Grégoire Layet wrote:
> The ASPEED AST2600 has 2 VUART accessible over PCI.
What does that mean? How UART can be accessible over PCI bus?
> This boolean can be set to specify if the VUART is used over PCI.
>
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> ---
> .../devicetree/bindings/serial/8250.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
> index 3cbd0f532e15..b03797f4674d 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -26,6 +26,14 @@ allOf:
> anyOf:
> - const: aspeed,ast2500-vuart
> - const: aspeed,ast2600-vuart
> + - if:
> + anyOf:
> + - required:
> + - aspeed,vuart-over-pci
> + then:
> + properties:
> + compatible:
> + const: aspeed,ast2600-vuart
> - if:
> properties:
> compatible:
> @@ -312,6 +320,13 @@ properties:
> polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
> applicable to aspeed,ast2500-vuart and aspeed,ast2600-vuart.
>
> + aspeed,vuart-over-pci:
> + type: boolean
> + default: false
There is no such syntax. Please do not introduce own style. Instead,
look at other files how this is done.
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Enable the VUART over the BMC PCI device. Only applicable to
> + aspeed,ast2600-vuart.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Nicolas Frattaroli @ 2026-06-24 8:57 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Uwe Kleine-König (The Capable Hub)
Cc: Heiko Stuebner, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624083708.254517-2-u.kleine-koenig@baylibre.com>
On Wednesday, 24 June 2026 10:37:07 Central European Summer Time Uwe Kleine-König (The Capable Hub) wrote:
> Currently that header is only included via:
>
> <sound/dmaengine_pcm.h> ->
> <sound/soc.h> ->
> <linux/platform_device.h>
>
> which doesn't look reliable, still more in the presence of the comment:
>
> /* For the current users of sound/soc.h to avoid build issues */
>
> in <sound/soc.h>.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> sound/soc/rockchip/rockchip_sai.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
> index a195e96fed0a..37e81d56bc16 100644
> --- a/sound/soc/rockchip/rockchip_sai.c
> +++ b/sound/soc/rockchip/rockchip_sai.c
> @@ -11,6 +11,7 @@
> #include <linux/delay.h>
> #include <linux/of_device.h>
> #include <linux/clk.h>
> +#include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/regmap.h>
> #include <linux/reset.h>
>
> base-commit: ef0c9f75a19532d7675384708fc8621e10850104
>
Makes sense.
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 0/4] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Jinjie Ruan @ 2026-06-24 9:02 UTC (permalink / raw)
To: catalin.marinas, will, tsbogend, pjw, palmer, aou, alex, tglx,
mingo, bp, dave.hansen, hpa, peterz, kees, nathan, linusw,
jpoimboe, lukas.bulwahn, ryan.roberts, ojeda, maz, timothy.hayes,
lpieralisi, thuth, menglong8.dong, oupton, yeoreum.yun,
miko.lenczewski, broonie, kevin.brodsky, james.clark, tabba,
mrigendra.chaubey, arnd, anshuman.khandual, x86, linux-kernel,
linux-arm-kernel, linux-mips, linux-riscv, apatel, mhklinux
In-Reply-To: <20260618092444.1316336-1-ruanjinjie@huawei.com>
Please ignore this patchset, will update in v3.
On 6/18/2026 5:24 PM, Jinjie Ruan wrote:
> Support for parallel secondary CPU bringup is already utilized by x86,
> MIPS, and RISC-V. This patch brings this capability to the arm64
> architecture.
>
> Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST to avoid primary SMT threads
> to boot first constraint.
>
> And Add a 'cpu' parameter to update_cpu_boot_status() to allow updating the
> boot status at a per-CPU granularity during parallel bringup.
>
> Rework the global `secondary_data` accessed during early boot into
> a per-CPU array `cpu_boot_data` to allow secondary CPUs to boot
> in parallel.
>
> And reuse `__cpu_logical_map` array in the early boot code in head.S
> to resolve each secondary CPU's logical ID concurrently.
>
> Changes in v2:
> - Remove RFC.
> - Add Tested-by.
> - Fix AI review issues in [1].
> - Add arch_cpuhp_init_parallel_bringup() to check psci boot.
> - Reuse `__cpu_logical_map` instead of a new aray.
> - Defer rcutree_report_cpu_starting() until after
> check_local_cpu_capabilities() to prevent a potential control CPU
> deadlock if an early capability check fails.
> - Move the assembly in head.S to a macro called `mpidr_to_cpuid`.
> - Add `SECONDARY_DATA_SHIFT` for `lsl` to access `cpu_boot_data`.
> - Add sizeof(struct secondary_data) power of 2 assert check.
> - Expand testing with more data collected from real hardware.
>
> [1] https://sashiko.dev/#/patchset/20260611133809.3854977-1-ruanjinjie%40huawei.com
>
> Jinjie Ruan (4):
> cpu/hotplug: Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST
> arm64: smp: Pass CPU ID to update_cpu_boot_status()
> arm64: smp: Defer RCU reporting until after local CPU capability
> checks
> arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
>
> arch/Kconfig | 4 +++
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/smp.h | 17 ++++++++++---
> arch/arm64/kernel/asm-offsets.c | 4 +++
> arch/arm64/kernel/cpufeature.c | 22 ++++++++--------
> arch/arm64/kernel/head.S | 36 ++++++++++++++++++++++++++
> arch/arm64/kernel/smp.c | 45 ++++++++++++++++++++++++++++-----
> arch/arm64/mm/context.c | 4 +--
> arch/mips/Kconfig | 1 +
> arch/riscv/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> kernel/cpu.c | 6 ++++-
> 12 files changed, 119 insertions(+), 23 deletions(-)
>
^ permalink raw reply
* [PATCH 7/7] ARM: dts: rockchip: Add Alientek DLRV1126
From: Yanan He @ 2026-06-24 9:02 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, heiko, andrew+netdev, davem, edumazet,
kuba, pabeni, david.wu, mcoquelin.stm32, alexandre.torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, grumpycat921013
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-dc42d99f75a7@gmail.com>
The board consists of a CLRV1126F core module and a DLRV1126 carrier
board. The core module contains the RV1126 SoC, eMMC and RK809 PMIC,
while the carrier board provides Ethernet, SD card, AP6212 WiFi and
Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and audio connectors.
The board has been tested with Ethernet/NFS boot, eMMC, SD card, SDIO
WiFi enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and
RK809 audio card registration.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rv1126-alientek-clrv1126f.dtsi | 277 +++++++++++++++++++++
.../boot/dts/rockchip/rv1126-alientek-dlrv1126.dts | 258 +++++++++++++++++++
3 files changed, 536 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/Makefile b/arch/arm/boot/dts/rockchip/Makefile
index d0154fd7ff24..e9f9e0ac3bfd 100644
--- a/arch/arm/boot/dts/rockchip/Makefile
+++ b/arch/arm/boot/dts/rockchip/Makefile
@@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
rv1109-relfor-saib.dtb \
rv1109-sonoff-ihost.dtb \
+ rv1126-alientek-dlrv1126.dtb \
rv1126-edgeble-neu2-io.dtb \
rv1126-sonoff-ihost.dtb \
rk3036-evb.dtb \
diff --git a/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi b/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi
new file mode 100644
index 000000000000..9bee424b1797
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-alientek-clrv1126f.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Yanan He <grumpycat921013@gmail.com>
+ */
+
+#include "rv1126.dtsi"
+
+/ {
+ compatible = "alientek,clrv1126f", "rockchip,rv1126";
+
+ aliases {
+ mmc0 = &emmc;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&emmc {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_rstnout>;
+ rockchip,default-sample-phase = <90>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB1 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ #sound-dai-cells = <0>;
+ clock-output-names = "rk808-clkout1", "rk808-clkout2";
+ clock-names = "mclk";
+ clocks = <&cru MCLK_I2S0_TX_OUT2IO>;
+ assigned-clocks = <&cru MCLK_I2S0_TX_OUT2IO>;
+ assigned-clock-parents = <&cru MCLK_I2S0_TX>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc_buck5>;
+ vcc6-supply = <&vcc_buck5>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+
+ regulators {
+ vdd_npu_vepu: DCDC_REG1 {
+ regulator-name = "vdd_npu_vepu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_arm: DCDC_REG2 {
+ regulator-name = "vdd_arm";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc3v3_sys: DCDC_REG4 {
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc_buck5: DCDC_REG5 {
+ regulator-name = "vcc_buck5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <2200000>;
+ regulator-max-microvolt = <2200000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <2200000>;
+ };
+ };
+
+ vcc_0v8: LDO_REG1 {
+ regulator-name = "vcc_0v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmu: LDO_REG2 {
+ regulator-name = "vcc1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd0v8_pmu: LDO_REG3 {
+ regulator-name = "vcc0v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <800000>;
+ };
+ };
+
+ vcc_1v8: LDO_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_dovdd: LDO_REG5 {
+ regulator-name = "vcc_dovdd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_dvdd: LDO_REG6 {
+ regulator-name = "vcc_dvdd";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_avdd: LDO_REG7 {
+ regulator-name = "vcc_avdd";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG8 {
+ regulator-name = "vccio_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: LDO_REG9 {
+ regulator-name = "vcc3v3_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_5v0: SWITCH_REG1 {
+ regulator-name = "vcc_5v0";
+ };
+
+ vcc_3v3: SWITCH_REG2 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio0-supply = <&vcc3v3_sys>;
+ pmuio1-supply = <&vcc3v3_sys>;
+ vccio1-supply = <&vcc_1v8>;
+ vccio2-supply = <&vccio_sd>;
+ vccio3-supply = <&vcc_1v8>;
+ vccio4-supply = <&vcc_3v3>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_3v3>;
+ vccio7-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts b/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts
new file mode 100644
index 000000000000..c8123a3c4746
--- /dev/null
+++ b/arch/arm/boot/dts/rockchip/rv1126-alientek-dlrv1126.dts
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Yanan He <grumpycat921013@gmail.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include "rv1126-alientek-clrv1126f.dtsi"
+
+/ {
+ model = "Alientek ATK-DLRV1126";
+ compatible = "alientek,dlrv1126", "alientek,clrv1126f", "rockchip,rv1126";
+
+ aliases {
+ ethernet0 = &gmac;
+ mmc1 = &sdio;
+ mmc2 = &sdmmc;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-esc {
+ label = "esc";
+ linux,code = <KEY_ESC>;
+ press-threshold-microvolt = <0>;
+ };
+
+ button-right {
+ label = "right";
+ linux,code = <KEY_RIGHT>;
+ press-threshold-microvolt = <400781>;
+ };
+
+ button-left {
+ label = "left";
+ linux,code = <KEY_LEFT>;
+ press-threshold-microvolt = <801562>;
+ };
+
+ button-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ press-threshold-microvolt = <1198828>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "sys-led";
+ gpios = <&gpio3 RK_PD4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ led-1 {
+ label = "user-led";
+ gpios = <&gpio3 RK_PD6 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ default-state = "on";
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "Analog RK809";
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones",
+ "Microphone", "Mic Jack";
+ simple-audio-card,routing =
+ "Speaker", "SPKO",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR",
+ "MICL", "Mic Jack";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&rk809>;
+ };
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ sdio_pwrseq: pwrseq-sdio {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+ post-power-on-delay-ms = <200>;
+ power-off-delay-us = <20000>;
+ };
+};
+
+&i2c5 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <RK_PD0 IRQ_TYPE_LEVEL_LOW>;
+ clock-output-names = "xin32k";
+ };
+};
+
+&gmac {
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+ assigned-clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
+ <&cru CLK_GMAC_ETHERNET_OUT>;
+ assigned-clock-parents = <&cru CLK_GMAC_SRC_M1>,
+ <&cru RGMII_MODE_CLK>;
+ assigned-clock-rates = <125000000>, <0>, <25000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4
+ &clk_out_ethernetm1_pins>;
+ tx_delay = <0x2a>;
+ rx_delay = <0x1a>;
+ phy-handle = <&phy>;
+ status = "okay";
+};
+
+&mdio {
+ phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ clocks = <&cru CLK_GMAC_ETHERNET_OUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ð_phy_rst>;
+ reset-gpios = <&gpio3 RK_PA0 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ };
+};
+
+&pinctrl {
+ ethernet {
+ eth_phy_rst: eth-phy-rst {
+ rockchip,pins = <3 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ bt {
+ bt_enable: bt-enable {
+ rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_dev: bt-wake-dev {
+ rockchip,pins = <1 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host: bt-wake-host {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&sdio {
+ bus-width = <4>;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <25000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc1_clk &sdmmc1_cmd &sdmmc1_bus4>;
+ rockchip,default-sample-phase = <90>;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_bus4 &sdmmc0_det>;
+ rockchip,default-sample-phase = <90>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_ctsn &uart0_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43430a1-bt";
+ shutdown-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_HIGH>;
+ device-wakeup-gpios = <&gpio1 RK_PD1 GPIO_ACTIVE_HIGH>;
+ clocks = <&rk809 1>;
+ clock-names = "lpo";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA5 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "host-wakeup";
+ max-speed = <115200>;
+ vbat-supply = <&vcc_3v3>;
+ vddio-supply = <&vcc_1v8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_enable>, <&bt_wake_dev>, <&bt_wake_host>;
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&i2s0 {
+ rockchip,trcm-sync-tx-only;
+ rockchip,i2s-rx-route = <3 1 2 0>;
+ rockchip,i2s-tx-route = <0 1 2 3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0m0_sclk_tx>,
+ <&i2s0m0_mclk>,
+ <&i2s0m0_lrck_tx>,
+ <&i2s0m0_sdo0>,
+ <&i2s0m0_sdo1_sdi3>;
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* Re: chipidea: usbmisc_imx: i.MX93 support
From: Xu Yang @ 2026-06-24 9:11 UTC (permalink / raw)
To: Stefan Wahren
Cc: Xu Yang, Frank Li, Jun Li, Alexander Stein, Greg Kroah-Hartman,
Linux ARM, linux-usb@vger.kernel.org
In-Reply-To: <40e4df43-5de8-48fb-9c5d-9ccb437e63b9@gmx.net>
On Wed, Jun 24, 2026 at 08:30:00AM +0200, Stefan Wahren wrote:
> Hi Xu,
>
> Am 24.06.26 um 04:50 schrieb Xu Yang:
> > On Tue, Jun 23, 2026 at 12:23:12PM +0200, Stefan Wahren wrote:
> > > Hi,
> > >
> > > during debugging USB OTG on our custom i.MX93 board, we noticed remarkable
> > > differences between the implementation of the chipidea/usbmisc_imx and the
> > > official NXP i.MX93 Reference Manual [1].
> > >
> > > Is the USB OTG part including PHY of the i.MX93 officially supported in
> > > Linux Mainline?
> > Yes.
> >
> > > According to imx91_93_common.dtsi the USB IP of the i.MX93 should be
> > > identical to i.MX8MM [2]
> > >
> > > usbmisc1: usbmisc@4c100200 {
> > >
> > > compatible = "fsl,imx8mm-usbmisc", "fsl,imx7d-usbmisc",
> > > "fsl,imx6q-usbmisc";
> > >
> > > But looking at the PHY register definition and reset values in the NXP
> > > i.MX93 Reference Manual,
> > >
> > > the registers are comparable to the i.MX95 [3] ones.
> > >
> > > Could you please clarify which source is correct (Mainline DTS vs Reference
> > > Manual)?
> > The Reference Manual is correct.
> >
> > > Looking deeper at chipidea/usbmisc_imx shows the usage of the following
> > > register bits
> > >
> > > #define MX7D_USB_OTG_PHY_CFG2_CHRG_CHRGSEL BIT(0)
> > >
> > > #define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATDETENB0 BIT(1)
> > >
> > > #define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATSRCENB0 BIT(2)
> > >
> > > #define MX7D_USB_OTG_PHY_CFG2_CHRG_DCDENB BIT(3)
> > >
> > > #define MX7D_USB_OTG_PHY_STATUS_LINE_STATE0 BIT(0)
> > >
> > > #define MX7D_USB_OTG_PHY_STATUS_LINE_STATE1 BIT(1)
> > >
> > > #define MX7D_USB_OTG_PHY_STATUS_CHRGDET BIT(29)
> > >
> > > According to NXP i.MX93 & i.MX95 Reference Manual, these are bits reserved.
> > >
> > > Is it correct that the chipidea/usbmisc_imx use these bits on i.MX93?
> > i.MX93 & i.MX95 no longer claims to support Battery charger detection. So these
> > bits are reserved. However, at the IP level, accessing these bits will not produce
> > errors. We will remove .charger_detection hook for the i.MX9 series in the future.
> I think the access to MX6_BM_NON_BURST_SETTING should be addressed, too.
Yes.
> > Do you want to use Battery charger detection on i.MX93?
> No, we don't need this feature in our case. We suspect the cause for our
> issue comes from the hardware design of the board.
What's your issue on i.MX93?
Thanks,
Xu Yang
^ permalink raw reply
* RE: [External Mail] [PATCH v2 1/7] net: wwan: t9xx: Add PCIe core
From: Wu. JackBB (GSM) @ 2026-06-24 9:15 UTC (permalink / raw)
To: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, Wu. JackBB (GSM)
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260610-t9xx_driver_v1-v2-1-c65addf23b3f@compal.com>
Hi Jakub,
Addressing sashiko AI code review comments for this patch, as
requested by you in the patch 3/7 review:
https://patchwork.kernel.org/project/netdevbpf/patch/20260610-t9xx_driver_v1-v2-3-c65addf23b3f@compal.com/#27006088
Q1: Does this code perform an incorrect double byte-swap on big-endian
architectures? The hardware bits are manually swapped using cpu_to_le32()
and cast back to u32. This value is later passed to mtk_pci_write32(),
which utilizes iowrite32(). Since iowrite32() internally handles
host-to-little-endian conversion, swapping the value beforehand will cause
a double swap on big-endian platforms.
This driver targets MediaTek T9xx PCIe WWAN modems, which exist
exclusively on x86 platforms (little-endian). On little-endian,
cpu_to_le32() is a no-op and LE32_TO_U32() is a simple cast, so
no byte-swap occurs. The hardware register layout assumes LE host
ordering. While the pattern is technically incorrect for big-endian,
this hardware is not available on BE platforms and the Kconfig
dependency (depends on PCI) combined with the device's PCIe-only
nature effectively restricts this to x86/ARM64-LE.
Q2: Does this call to ffs() yield the wrong channel index on big-endian
systems? hw_bits has already been endian-swapped in
mtk_pci_ext_h2d_evt_hw_bits(). Using ffs() on an endian-swapped value
produces a completely incorrect bit index.
Same as Q1 — on little-endian platforms, no swap occurs, so ffs()
operates on the correct value. Additionally, all callers of
mtk_pci_send_ext_evt() pass known-valid channel values through the
is_power_of_2(ch) check, and the SET_HW_BITS mapping covers all
valid channels.
Q3: Does clearing the top-level interrupt status at the end of the handler
without a subsequent read loop lead to permanently lost hardware events?
If a new hardware event triggers during the worker's execution, clearing
the write-1-to-clear (W1C) interrupt status after the hardware event
statuses were read at the start will discard the newly asserted events.
No events are lost. mtk_pci_clear_irq() clears the MSI-X interrupt
status register (BIT(irq_id) in REG_MSIX_ISTATUS_HOST_GRP0_0), NOT
the MHCCIF event registers. The MHCCIF events are level-triggered
from the modem's EP2RC registers — the modem sets event bits and
they remain set until the modem clears them or the host acknowledges.
The flow is:
1. Hardware: modem sets EP2RC event bits -> MSI-X interrupt fires
2. ISR: masks MSI-X bit, schedules work
3. Worker: reads EP2RC event status, dispatches callbacks
4. Worker: clears MSI-X status (BIT(irq_id)), unmasks MSI-X
If a new MHCCIF event arrives during step 3, the EP2RC register
gets the new bit set. The MSI-X clear in step 4 only clears the
MSI-X pending bit, not the MHCCIF source. After unmask, the MHCCIF
event source re-asserts the MSI-X interrupt because the EP2RC bits
are still set, triggering a new ISR -> new work -> new read of the
updated EP2RC register.
Q4: Does this code incorrectly attempt to unmap a bitmask instead of a
single BAR index? MTK_REQUESTED_BARS is defined as a bitmask, but
pcim_iounmap_region() expects a specific BAR index. Furthermore, is
this manual unmapping redundant since the memory was mapped with
pcim_iomap_regions() and will automatically be cleaned up by devres?
Valid on both points. Fixed in v3 by removing mtk_pci_bar_exit()
entirely. pcim_iomap_regions() is devres-managed so manual unmap
is redundant.
Q5: Does this logic mistakenly drop hardware interrupts when fewer than 32
MSI-X vectors are allocated? If fewer than 32 vectors are allocated
(for example, irq_cnt = 1), GENMASK(0, 0) evaluates to BIT(0). A
hardware interrupt source like MHCCIF (bit 28) will result in
BIT(28) & BIT(0) == 0. Could this lead to a complete loss of critical
device events?
No issue. This is the MSI-X merged mode design. When fewer vectors
are allocated than interrupt sources, mtk_pci_set_msix_merged()
configures the hardware to merge multiple interrupt sources into
the available vectors. With irq_cnt=1, the hardware maps ALL
interrupt sources to vector 0. The GENMASK filters the irq_state
to only the allocated vector bits, then checks if the current
handler's vector bit is set. This correctly handles both full
allocation (32 vectors, 1:1 mapping) and merged mode (fewer
vectors, N:1 mapping).
Q6: Will this manual pci_disable_device() call trigger an atomic underflow?
Since the device was initialized using pcim_enable_device(), devres will
automatically disable the device during cleanup. Manually calling
pci_disable_device() drops the enable_cnt to zero. When devres executes
its cleanup, it will call pci_disable_device() again, leading to an
underflow and a kernel warning.
Valid. Fixed in v3 by removing pci_disable_device() from both the
probe error path and mtk_pci_remove(). pcim_enable_device() handles
cleanup via devres.
Q7: Does performing a PCIe Link Down Reset (PLDR) before freeing IRQs cause
PCIe Unsupported Request (UR) faults? mtk_pci_pldr() power-cycles the
device and clears its BARs. Directly after this, mtk_pci_free_irq() is
called, which attempts to access the device's MSI-X MMIO table.
No UR faults. mtk_pci_pldr() calls ACPI PXP._OFF then PXP._ON.
The _ON call restores power to the device, bringing the PCIe link
back up with BARs accessible. pci_free_irq_vectors() writes to PCI
config space (MSI-X capability enable bit) which is always
accessible while the device is on the bus. The MSI-X table MMIO
access for masking individual entries goes through the
re-established BAR mapping.
Q8: Will this manual pci_disable_device() call in mtk_pci_remove() trigger
an atomic underflow for the same reason as in mtk_pci_probe()?
Is a call to mtk_pci_dev_exit() missing from the remove path?
Two issues, both valid and fixed in v3:
1. pci_disable_device() underflow: same as Q6, removed.
2. Missing mtk_pci_dev_exit(): added in patch 3/7 v3 (where
mtk_pci_dev_init is introduced).
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* RE: [External Mail] [PATCH v2 4/7] net: wwan: t9xx: Add control port
From: Wu. JackBB (GSM) @ 2026-06-24 9:19 UTC (permalink / raw)
To: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, Wu. JackBB (GSM)
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260610-t9xx_driver_v1-v2-4-c65addf23b3f@compal.com>
Hi Jakub,
Addressing sashiko AI code review comments for this patch, as
requested by you in the patch 3/7 review:
https://patchwork.kernel.org/project/netdevbpf/patch/20260610-t9xx_driver_v1-v2-3-c65addf23b3f@compal.com/#27006088
Q1: Does this unconditionally free the internal port memory? If an internal
user or an active TRB holds a reference to the port during device teardown,
it seems this bypasses kref_put and directly calls the release function.
This could lead to a use-after-free when they attempt to access the port
or drop their reference.
Internal ports are exclusively used by the FSM layer. During
teardown, mtk_fsm_ctrl_ch_stop calls mtk_port_internal_close,
which calls kref_put to release the user's reference before
mtk_port_free_or_backup is reached. By the time
mtk_port_free_or_backup runs, the kref count is 1 (the initial
allocation reference only). Calling mtk_port_release directly at
this point is equivalent to kref_put decrementing from 1 to 0.
Internal ports do not use the stale list backup mechanism, so
bypassing kref_put avoids the unnecessary stale list check in the
kref_put path.
Q2: Is it safe to traverse the port_tbl radix tree without holding
rcu_read_lock or the port_mngr_grp_mtx mutex? Concurrent port deletions
could free radix tree nodes or mtk_port structures during traversal,
potentially leading to a use-after-free when the un-refcounted pointers
are dereferenced.
mtk_port_search_by_name is only called from mtk_port_internal_open,
which is exclusively invoked by the FSM kthread during
mtk_fsm_ctrl_ch_start. Port creation and destruction are also
driven by FSM state transitions on the same kthread. Since the FSM
serializes these operations, no concurrent port removal can occur
while search_by_name is iterating the radix tree.
Q3: If this array allocation fails during teardown, does the function skip
deleting items from the radix tree and freeing the dynamically allocated
mtk_port objects? This appears to bypass the teardown phase entirely and
leak memory.
Valid. Fixed in v3 by replacing kcalloc + radix_tree_gang_lookup
with radix_tree_for_each_slot() and single-entry gang_lookup,
eliminating the allocation in the teardown path.
Q4: Should we increment the port's reference count when assigning it to
trb->priv? If a writer thread is interrupted by a signal while waiting for
hardware completion, it returns and drops the port. If the port is then
closed and freed, the asynchronous callback mtk_port_tx_complete will
dereference the freed port, resulting in a use-after-free.
The TRB lifecycle is protected by kref on the TRB itself (kref_get
before submit, kref_put in both the caller and the completion
callback). When a blocking operation times out, the caller releases
its kref reference, but the TRB remains alive in the transaction
layer until the completion callback fires. The port is not freed at
this point — port destruction goes through kref_put(&port->kref,
mtk_port_release), and the port's reference count is not decremented
until the close path completes. Additionally, TRB_CMD_DISABLE
triggers mtk_ctrl_ch_flush in the transaction layer, which forces
all pending TRBs to complete before the port teardown proceeds.
Q5: Can concurrent packet transmissions on the same port race here? There
does not appear to be any synchronization protecting the read and increment
of port->tx_seq.
tx_seq is a per-port 8-bit sequence number. Each port has a single
writer in practice: external ports are written from user space via
cdev write() (serialized by the file descriptor), and internal
ports are written exclusively by the FSM kthread. Concurrent
transmissions on the same port do not occur in normal operation.
Q6: Does this safely handle fragmented SKBs? Without using pskb_may_pull
or similar, the header might span across multiple DMA fragments. If
skb->data does not contain the entire 16-byte header, this cast could
result in reading out-of-bounds memory.
The RX SKBs are allocated internally by the CLDMA driver using
__dev_alloc_skb with linear buffers. The CCCI header always resides
in the contiguous linear data region. mtk_port_strip_header already
validates skb->len >= sizeof(*ccci_h) before accessing the header.
Since these SKBs are not received from the network stack and are
always linear, pskb_may_pull is not needed here.
Q7: Is there a bounds check to ensure that the packet buffer is large
enough to hold the number of ports specified by msg->port_cnt? If the
modem provides an arbitrarily large count, this loop could read past the
end of the packet data.
The message is already validated by head_pattern, tail_pattern, and
version checks before the loop. The port enumeration protocol
between host and modem guarantees that the buffer contains exactly
port_cnt entries. The modem firmware is a trusted source — this is
a control plane interface, not an untrusted network protocol.
Q8: If a signal is pending, wait_event_interruptible_timeout will return
-ERESTARTSYS immediately. Jumping back to start_wait without returning to
userspace to handle the signal creates an infinite tight loop that will
stall the CPU at 100% until the hardware completes.
This is intentional. Channel enable/disable are control plane
operations that must complete or timeout — aborting mid-operation
due to a signal would leave the channel in an inconsistent state.
The loop does not spin: each iteration sleeps in
wait_event_interruptible_timeout until either the signal re-fires,
the condition is met, or the timeout expires. The timeout
(MTK_DFLT_TRB_TIMEOUT) guarantees bounded execution.
Q9: Is there a race condition between checking PORT_S_OPEN and setting it?
If two threads concurrently open the same port, they might both read the
bit as clear and proceed with initialization. Could test_and_set_bit be
used?
All callers of mtk_port_common_open acquire port_mngr_grp_mtx via
mtk_port_get_locked before calling this function, which serializes
concurrent open attempts on the same port. The test_bit/set_bit
sequence is protected by the mutex.
Q10: If mtk_port_common_open fails, the port reference is dropped via
mtk_port_put_locked, but the pointer itself is not set to NULL before
jumping to out. This causes the function to return an un-refcounted,
invalid port pointer.
Valid. Fixed in v3 by adding port = NULL after mtk_port_put_locked()
in the error path.
Q11: If mtk_cldma_submit_tx fails with a fatal error (like -EINVAL), the
error path breaks out of the switch without unlinking the SKB from
skb_list and without signaling completion. Will the next processing loop
retrieve the exact same failing SKB with skb_peek and infinitely repeat
the failure?
Valid. Fixed in v3 by restoring skb_unlink + trb_complete for
non-EAGAIN errors in the TX path.
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* [PATCH] media: cedrus: fix memory leak in cedrus_init_ctrls()
From: Dawei Feng @ 2026-06-24 8:59 UTC (permalink / raw)
To: mripard
Cc: paulk, mchehab, gregkh, wens, jernej.skrabec, samuel, hverkuil,
linux-media, linux-staging, linux-arm-kernel, linux-sunxi,
linux-kernel, jianhao.xu, zilin, Dawei Feng, stable
In cedrus_init_ctrls(), the V4L2 control handler is initialized before
allocating memory for ctx->ctrls. If this allocation fails, the function
returns -ENOMEM without freeing the previously allocated handler
resources, leading to a memory leak.
Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation
failure path.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.
An x86_64 allyesconfig build showed no new warnings. As we do not have an
Allwinner SoC or board with a Cedrus VPU available to test with, no
runtime testing was able to be performed.
Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver")
Cc: stable@vger.kernel.org
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index bbd186b8035b..96acd52e380c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -285,8 +285,10 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
ctrl_size = sizeof(ctrl) * CEDRUS_CONTROLS_COUNT + 1;
ctx->ctrls = kzalloc(ctrl_size, GFP_KERNEL);
- if (!ctx->ctrls)
+ if (!ctx->ctrls) {
+ v4l2_ctrl_handler_free(hdl);
return -ENOMEM;
+ }
j = 0;
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
--
2.34.1
^ permalink raw reply related
* RE: [PATCH] spi: imx: reconfigure for PIO when DMA cannot be started
From: Carlos Song (OSS) @ 2026-06-24 9:22 UTC (permalink / raw)
To: Javier Fernandez Pastrana, Mark Brown, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Carlos Song,
linux-spi@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
In-Reply-To: <20260623153240.57185-1-javier.pastrana@linutronix.de>
> -----Original Message-----
> From: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
> Sent: Tuesday, June 23, 2026 11:33 PM
> To: Mark Brown <broonie@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha
> Hauer <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Carlos Song
> <carlos.song@nxp.com>; linux-spi@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: javier.pastrana@linutronix.de; stable@vger.kernel.org
> Subject: [PATCH] spi: imx: reconfigure for PIO when DMA cannot be started
>
> [You don't often get email from javier.pastrana@linutronix.de. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
> spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
> spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the
> SDMA watermarks.
>
> If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single()
> returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and falls
> back to PIO. The dynamic-burst DMA path uses its own bounce buffers instead of
> the SPI core's mapping, so xfer->{tx,rx}_sg_mapped are not set and the core's
> DMA->PIO retry is skipped; the driver falls back to PIO internally. But none of the
> DMA-mode configuration is undone, so the PIO transfer runs with CTRL.SMC set,
> the wrong burst length and dynamic_burst cleared, and the transferred data is
> corrupted.
>
> This is easily hit on i.MX8MP boards that describe ECSPI DMA in the device tree
> but run SDMA on ROM firmware (no external sdma-imx7d.bin):
> every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then returns
> shifted TPM2_GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is
> never created.
>
> Mark the controller PIO-only (controller->fallback) and re-run
> spi_imx_setupxfer() before falling back, so the ECSPI is reconfigured exactly like a
> normal PIO transfer.
>
> Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA
> mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
> ---
> drivers/spi/spi-imx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index
> 480d1e8b281f..64c78bd79d7d 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -2153,6 +2153,8 @@ static int spi_imx_transfer_one(struct spi_controller
> *controller,
> ret = spi_imx_dma_transfer(spi_imx, transfer);
> if (transfer->error & SPI_TRANS_FAIL_NO_START) {
> spi_imx->usedma = false;
> + controller->fallback = true;
> + spi_imx_setupxfer(spi, transfer);
Hi, Javier
Thank you very much for fixing this issue!
You can remove this line also: spi_imx->usedma = false;
Because spi_imx_setupxfer() will recheck spi_imx_can_dma() and return false because controller->fallback = true;
How do you think about it?
Carlos Song
> if (spi_imx->target_mode)
> return spi_imx_pio_transfer_target(spi,
> transfer);
> else
> --
> 2.47.3
>
^ permalink raw reply
* RE: [External Mail] [PATCH v2 5/7] net: wwan: t9xx: Add FSM thread
From: Wu. JackBB (GSM) @ 2026-06-24 9:23 UTC (permalink / raw)
To: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, Wu. JackBB (GSM)
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260610-t9xx_driver_v1-v2-5-c65addf23b3f@compal.com>
Hi Jakub,
Addressing sashiko AI code review comments for this patch, as
requested by you in the patch 3/7 review:
https://patchwork.kernel.org/project/netdevbpf/patch/20260610-t9xx_driver_v1-v2-3-c65addf23b3f@compal.com/#27006088
Q1: Will this compile on standard compilers? The container_of macro relies
on offsetof, which requires an integer constant expression. Evaluating
hs_info->id dynamically at runtime will cause a compilation error.
This compiles correctly. The Linux kernel's container_of uses
__builtin_offsetof (GCC extension), which supports variable array
indices. GCC and Clang both generate runtime offset calculation
code for container_of(ptr, type, member[variable_index]). This
pattern is used in multiple places in the kernel.
Q2: Could this result in a NULL pointer dereference? If the device sends
multiple CTRL_MSG_HS2 messages, the second message overwrites the skb
pointer. When the first event is processed, it frees the skb and sets
hs_info->rt_data to NULL, causing a deref on the second event.
This cannot happen in practice. The handshake follows a strict
HS1 -> HS2 -> HS3 sequence. The MHCCIF channel interrupt is masked
in mtk_fsm_hs1_handler() before the FSM event is submitted,
preventing duplicate HS2 notifications. Only one HS2 message is
expected per handshake cycle.
Q3: Can this read past the end of the packet? We pass rtft_entry->data to
the action callback before checking if rtft_entry->data_len fits within
the remaining packet length.
The bounds check at the loop start ensures the rtft_entry struct
header is within bounds. The action functions only read fixed-size
fields (e.g., a single __le32 for packet padding mode). The modem
firmware is a trusted source — the feature query protocol uses
head_pattern/tail_pattern integrity checks, and the message format
is guaranteed by the modem firmware.
Q4: Could this result in unaligned memory accesses on the next loop
iteration? Since data_len is not verified to be a multiple of 4, the
next rtft_entry could be misaligned.
On x86 (the target platform for this PCIe WWAN modem), unaligned
memory access is handled natively without traps. The feature query
entries from the modem firmware are always naturally aligned in
practice (data_len is always a multiple of 4 for the defined
feature types).
Q5: Does this code ensure the packet is long enough before parsing the
feature query? It casts and reads ft_query fields without verifying if
hs_info->rt_data_len is large enough to hold a feature_query structure.
The SKB is received from the CLDMA RX path with validated length.
After skb_pull, the remaining data is the feature query payload.
The head/tail pattern check immediately following this cast
validates the message integrity. A truncated message would fail the
pattern check and take the error path.
Q6: Is there a risk of accessing uninitialized memory here? If the skb is
fragmented, checking skb->len is not sufficient. We should use
pskb_may_pull() before casting and accessing skb->data.
The RX SKBs are allocated internally by the CLDMA driver using
__dev_alloc_skb with linear buffers. The CCCI header and control
message data always reside in the contiguous linear data region.
These SKBs are not received from the network stack and are always
linear, so pskb_may_pull is not needed.
Q7: Does this introduce a leak if the device sends multiple messages
rapidly? Overwriting hs_info->rt_data discards the previous skb pointer
without freeing it.
Same as Q2. The handshake is a strict HS1 -> HS2 -> HS3 sequence
with the MHCCIF channel masked after HS1. Only one HS2 message
arrives per handshake cycle. No overwrite can occur.
Q8: Does this permanently hang the device initialization? The interrupt is
masked and cleared at the beginning. If the device stage is not
DEV_STAGE_IDLE, we return without unmasking.
The early_bootup_handler is registered for the BOOT_FLOW_SYNC
MHCCIF event. The MTK modem firmware sends this event once, only
when the modem reaches IDLE stage. The non-IDLE code path handles
unexpected states defensively — masking prevents spurious interrupts
from an error state. The normal boot flow always reaches IDLE
before sending BOOT_FLOW_SYNC.
Q9: Can concurrent modifications corrupt the list traversal? External
modules can call mtk_fsm_notifier_register() to modify these lists
concurrently with FSM thread iteration.
The notifier registration and unregistration are only called during
driver probe and remove paths, which are serialized by the driver
model. The FSM kthread does not start processing events until probe
completes, so there is no concurrent access to the notifier lists
between registration and traversal.
Q10: These lists are modified without any locking mechanism, meaning
concurrent registrations or iterations could crash the kernel.
Same as Q9. mtk_fsm_notifier_register/unregister are only called
from probe/remove paths, serialized by the driver model.
Q11: Is it safe to guess the caller's context like this? The checks do not
catch contexts where preemption is disabled by a standard spin_lock().
The heuristic is sufficient for all current callers.
mtk_fsm_evt_submit is called from FSM kthread, MHCCIF workqueue
callback, probe/remove paths, and CLDMA workqueue callbacks — all
process context, none holding spinlocks. The in_hardirq/in_softirq/
irqs_disabled checks cover the actual calling contexts.
Q12: Could this lead to a NULL pointer dereference? wake_up_process() is
performed outside the lock. If mtk_fsm_exit() stops the thread and sets
fsm->fsm_handler to NULL concurrently.
This race cannot occur. mtk_fsm_exit() is called during the device
remove sequence, which first submits a FSM_EVT_DEV_RM event. The
FSM kthread processes this event via mtk_fsm_dev_rm_act(), which
sets EVT_TF_GATECLOSED under evtq_lock. Only after the kthread
finishes does mtk_fsm_exit() proceed to call kthread_stop() and
set fsm_handler to NULL. The EVT_TF_GATECLOSED check inside the
spinlock provides ordering guarantee.
Q13: Can this loop endlessly if a signal is continuously delivered? Since
this resets the timer to the full MTK_DFLT_TRB_TIMEOUT every time, a
stream of signals might trap the task in an infinite loop.
This is intentional. Channel enable/disable are control plane
operations that must complete or timeout. Each iteration sleeps in
wait_event_interruptible_timeout — not a busy loop. The timeout
guarantees bounded per-iteration execution. The total wait time may
exceed a single timeout with continuous signals, but the operation
eventually completes or times out.
Q14: Does this code silently ignore interrupt registration failures? The
return value of mtk_pci_register_irq() is not checked, and the cleanup
operations below the return statement are unreachable dead code.
Valid. Fixed in v3 by checking the return value and adding an
err_destroy_wq error label. Also propagated specific error codes
from all error paths.
Q15: Does this leak the head SKB when operating in scatter-gather mode? If
rxq->nr_bds > 0, the frag_list is detached but the head SKB itself is
never freed because dev_kfree_skb_any(req->skb) is inside the else block.
Valid. Fixed in v3 by adding dev_kfree_skb_any(req->skb) after
detaching frag_list in SG mode.
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* Re: [PATCH 0/5] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS
From: Francesco Dolcini @ 2026-06-24 9:24 UTC (permalink / raw)
To: Leonardo Costa
Cc: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, vigneshr, kristo, prabhakar.mahadev-lad.rj, thierry.reding,
sam, leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-1-leoreis.costa@gmail.com>
On Tue, Jun 23, 2026 at 04:57:36PM -0300, Leonardo Costa wrote:
> From: Leonardo Costa <leonardo.costa@toradex.com>
>
> This series adds device tree overlays for Toradex Capacitive
> Touch Display 10.1" LVDS V2 on Verdin AM62.
>
> The display addition covers two interface types:
>
> - Native OLDI (LVDS)
> - DSI-to-LVDS adapter based on the SN65DSI84
>
> The Opto Logic vendor prefix and panel binding for the SCX1001511GGC49 is
> also added.
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
^ permalink raw reply
* RE: [External Mail] [PATCH v2 6/7] net: wwan: t9xx: Add AT & MBIM WWAN ports
From: Wu. JackBB (GSM) @ 2026-06-24 9:24 UTC (permalink / raw)
To: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, Wu. JackBB (GSM)
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260610-t9xx_driver_v1-v2-6-c65addf23b3f@compal.com>
Hi Jakub,
Addressing sashiko AI code review comments for this patch, as
requested by you in the patch 3/7 review:
https://patchwork.kernel.org/project/netdevbpf/patch/20260610-t9xx_driver_v1-v2-3-c65addf23b3f@compal.com/#27006088
Q1: Is this mutex ever acquired? It is initialized during port setup, but
it does not appear to be used to serialize operations in
mtk_port_common_write() or when sending data.
Valid. Fixed in v3 by removing the unused write_lock mutex from
struct mtk_port and its mutex_init call.
Q2: Will concurrent writes safely execute here without holding write_lock?
Could this lack of serialization lead to sequence number corruption?
The WWAN core framework holds port->ops_lock (a mutex) around the
tx/tx_blocking callback invocations, serializing write operations
on the same WWAN port. For internal ports, writes are exclusively
performed by the FSM kthread, which is single-threaded. Concurrent
writes to the same port do not occur, and port->tx_seq is always
modified by a single thread.
Q3: What happens if a blocking write is interrupted by a port teardown?
If PORT_S_WR is cleared, trb->status remains at MTK_DFLT_TRB_STATUS (1).
ret = (!trb->status) ? len : trb->status evaluates to 1, causing an
incorrect byte count to be returned.
This only occurs during port teardown (PORT_S_WR cleared by
mtk_port_common_close or disable). At this point the port is being
shut down and the return value is largely irrelevant — the caller
cannot meaningfully use the port afterward. The submitted data may
or may not have been transmitted by DMA, depending on timing. This
is a teardown-only scenario with no practical impact on data
integrity.
Q4: Is it safe to mutate the flags directly here? This is a non-atomic
read-modify-write on the shared port structure.
The WWAN core holds port->ops_lock (a mutex) around tx/tx_blocking
callbacks, serializing flag modifications. mtk_port_wwan_write()
and mtk_port_wwan_write_blocking() are never called concurrently
for the same port.
Q5: Does this silently drop data on partial writes? If
mtk_port_common_write() returns a positive value (partial success),
consume_skb is called unconditionally and 0 (success) is returned.
This is a design limitation of the WWAN port API: wwan_port_op_tx
returns 0 for success or negative for error — there is no mechanism
to report partial writes back to the WWAN core. The already-submitted
fragments cannot be recalled from the DMA engine. For the AT/MBIM
control ports in this driver, messages are small (typically under
1KB, within a single MTU). The multi-fragment path is rarely
exercised for control plane traffic.
Q6: As with mtk_port_wwan_write(), mutating the shared blocking flag
without atomics could race, and ignoring positive return values could
lead to silent data loss.
Same as Q4 (flags serialized by WWAN core ops_lock) and Q5
(partial write is a WWAN API limitation, rare for control messages).
Q7: Is there a race condition here if wwan_create_port() fails? The return
value is directly assigned to w_port without checking IS_ERR() first.
Could concurrent RX pass the error pointer to wwan_port_rx()?
No race. mtk_port_wwan_enable() is called from the FSM thread
during the handshake sequence, before the port starts receiving
data. The CLDMA RX queue for this port has not been opened at this
point — RX data only arrives after the modem completes its
handshake. The RX path cannot observe the error pointer because no
data arrives until after the port is fully enabled.
Q8: Is the WWAN port exposed to userspace before its state is fully
initialized? wwan_create_port() registers the character device and
triggers a uevent. If userspace opens immediately, PORT_S_ENABLE is
not set yet so open returns -ENODEV.
The window between wwan_create_port() returning and
set_bit(PORT_S_ENABLE) is a few instructions (nanoseconds). If
userspace opens in that window, the open returns -ENODEV and the
application retries. In practice, user space WWAN managers (e.g.,
ModemManager) wait for udev events to settle before opening ports.
Reordering to set PORT_S_ENABLE before wwan_create_port is not
correct either — the port should not be marked enabled before the
WWAN port object exists.
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ 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