* [soc:soc/drivers] BUILD SUCCESS c7437fab2f2249c1f12d805770c5ba15cbd0e46a
From: kernel test robot @ 2026-06-16 2:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/drivers
branch HEAD: c7437fab2f2249c1f12d805770c5ba15cbd0e46a Merge tag 'memory-controller-drv-7.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
elapsed time: 844m
configs tested: 229
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260615 gcc-10.5.0
arc randconfig-001-20260616 gcc-9.5.0
arc randconfig-002-20260615 gcc-16.1.0
arc randconfig-002-20260616 gcc-9.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig clang-23
arm defconfig gcc-16.1.0
arm imx_v4_v5_defconfig clang-23
arm randconfig-001-20260615 gcc-12.5.0
arm randconfig-001-20260616 gcc-9.5.0
arm randconfig-002-20260615 gcc-8.5.0
arm randconfig-002-20260616 gcc-9.5.0
arm randconfig-003-20260615 gcc-16.1.0
arm randconfig-003-20260616 gcc-9.5.0
arm randconfig-004-20260615 clang-23
arm randconfig-004-20260616 gcc-9.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260615 clang-23
arm64 randconfig-001-20260616 gcc-13.4.0
arm64 randconfig-002-20260615 gcc-8.5.0
arm64 randconfig-002-20260616 gcc-13.4.0
arm64 randconfig-003-20260615 clang-16
arm64 randconfig-003-20260616 gcc-13.4.0
arm64 randconfig-004-20260615 clang-23
arm64 randconfig-004-20260616 gcc-13.4.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260615 gcc-16.1.0
csky randconfig-001-20260616 gcc-13.4.0
csky randconfig-002-20260615 gcc-10.5.0
csky randconfig-002-20260616 gcc-13.4.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig clang-23
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260616 clang-23
hexagon randconfig-002-20260616 clang-23
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260616 clang-22
i386 buildonly-randconfig-002-20260616 clang-22
i386 buildonly-randconfig-003-20260616 clang-22
i386 buildonly-randconfig-004-20260616 clang-22
i386 buildonly-randconfig-005-20260616 clang-22
i386 buildonly-randconfig-006-20260616 clang-22
i386 defconfig clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260615 gcc-14
i386 randconfig-001-20260616 gcc-14
i386 randconfig-002-20260615 clang-22
i386 randconfig-002-20260616 gcc-14
i386 randconfig-003-20260615 clang-22
i386 randconfig-003-20260616 gcc-14
i386 randconfig-004-20260615 clang-22
i386 randconfig-004-20260616 gcc-14
i386 randconfig-005-20260615 clang-22
i386 randconfig-005-20260616 gcc-14
i386 randconfig-006-20260615 clang-22
i386 randconfig-006-20260616 gcc-14
i386 randconfig-007-20260615 gcc-14
i386 randconfig-007-20260616 gcc-14
i386 randconfig-011-20260616 clang-22
i386 randconfig-012-20260616 clang-22
i386 randconfig-013-20260616 clang-22
i386 randconfig-014-20260616 clang-22
i386 randconfig-015-20260616 clang-22
i386 randconfig-016-20260616 clang-22
i386 randconfig-017-20260616 clang-22
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260616 clang-23
loongarch randconfig-002-20260616 clang-23
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001-20260616 clang-23
nios2 randconfig-002-20260616 clang-23
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260616 gcc-8.5.0
parisc randconfig-002-20260616 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc ep88xc_defconfig gcc-16.1.0
powerpc pmac32_defconfig clang-23
powerpc randconfig-001-20260616 gcc-8.5.0
powerpc randconfig-002-20260616 gcc-8.5.0
powerpc64 randconfig-001-20260616 gcc-8.5.0
powerpc64 randconfig-002-20260616 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260615 clang-19
riscv randconfig-001-20260616 gcc-16.1.0
riscv randconfig-002-20260615 gcc-16.1.0
riscv randconfig-002-20260616 gcc-16.1.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260615 gcc-11.5.0
s390 randconfig-001-20260616 gcc-16.1.0
s390 randconfig-002-20260615 clang-23
s390 randconfig-002-20260616 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001-20260615 gcc-16.1.0
sh randconfig-001-20260616 gcc-16.1.0
sh randconfig-002-20260615 gcc-10.5.0
sh randconfig-002-20260616 gcc-16.1.0
sh sh7785lcr_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260616 gcc-8.5.0
sparc randconfig-002-20260616 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260616 gcc-8.5.0
sparc64 randconfig-002-20260616 gcc-8.5.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260616 gcc-8.5.0
um randconfig-002-20260616 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260616 gcc-14
x86_64 buildonly-randconfig-002-20260616 gcc-14
x86_64 buildonly-randconfig-003-20260616 gcc-14
x86_64 buildonly-randconfig-004-20260616 gcc-14
x86_64 buildonly-randconfig-005-20260616 gcc-14
x86_64 buildonly-randconfig-006-20260616 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260616 clang-22
x86_64 randconfig-002-20260616 clang-22
x86_64 randconfig-003-20260616 clang-22
x86_64 randconfig-004-20260616 clang-22
x86_64 randconfig-005-20260616 clang-22
x86_64 randconfig-006-20260616 clang-22
x86_64 randconfig-011-20260616 clang-22
x86_64 randconfig-012-20260616 clang-22
x86_64 randconfig-013-20260616 clang-22
x86_64 randconfig-014-20260616 clang-22
x86_64 randconfig-015-20260616 clang-22
x86_64 randconfig-016-20260616 clang-22
x86_64 randconfig-071-20260616 gcc-14
x86_64 randconfig-072-20260616 clang-22
x86_64 randconfig-072-20260616 gcc-14
x86_64 randconfig-073-20260616 gcc-14
x86_64 randconfig-074-20260616 gcc-14
x86_64 randconfig-075-20260616 gcc-12
x86_64 randconfig-075-20260616 gcc-14
x86_64 randconfig-076-20260616 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260616 gcc-8.5.0
xtensa randconfig-002-20260616 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 6/6] irqchip/gic-v3-its: some minor cleanups
From: Kemeng Shi @ 2026-06-16 1:50 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87eci888ss.wl-maz@kernel.org>
在 2026/6/15 17:14:27, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:10 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> 1. Remove unneeded NULL check in itt_alloc_pool() as addr will always be
>> NULL when we reach here.
>> 2. Correct indentation in cpumask_pick_least_loaded()
>> 3. Remove unneeded updation of range node when it is to be deleted in
>> alloc_lpi_range().
>> 4. Remove unneeded assignment to baser->psz which is already used
>> as input inits_setup_baser()
>
> Honestly, these changes, aside from (maybe) the last one, are pretty
> pointless. I'm sure there are better things to waste your time on.
>
No insistant on this. I will drop this in next version.
Thanks,
Kemeng> M.
>
^ permalink raw reply
* Re: [PATCH 5/6] irqchip/gic-v3-its: fix typo in comments
From: Kemeng Shi @ 2026-06-16 1:49 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87fr2o89ak.wl-maz@kernel.org>
在 2026/6/15 17:03:47, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:09 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> 1. "If it some" -> "If some"
>> 2. "by table by reading" -> by reading"
>>
>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index becd8dd51720..fc32a1709f76 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -163,7 +163,7 @@ struct event_lpi_map {
>>
>> /*
>> * The ITS view of a device - belongs to an ITS, owns an interrupt
>> - * translation table, and a list of interrupts. If it some of its
>> + * translation table, and a list of interrupts. If some of its
>> * LPIs are injected into a guest (GICv4), the event_map.vm field
>> * indicates which one.
>> */
>> @@ -2501,7 +2501,7 @@ static bool its_parse_indirect_baser(struct its_node *its,
>> if ((esz << ids) > (psz * 2)) {
>> /*
>> * Find out whether hw supports a single or two-level table by
>> - * table by reading bit at offset '62' after writing '1' to it.
>> + * reading bit at offset '62' after writing '1' to it.
>> */
>
> If you are going to fix that comment, fix it for good by replacing the
> reference to a bit number with its actual name, making it valuable for
> everyone.
Will improve with this in next version.
Thanks,
Kemeng>
> M.
>
>> its_write_baser(its, baser, val | GITS_BASER_INDIRECT);
>> indirect = !!(baser->val & GITS_BASER_INDIRECT);
>> --
>> 2.36.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH 2/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Kemeng Shi @ 2026-06-16 1:39 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87ik7k89i5.wl-maz@kernel.org>
在 2026/6/15 16:59:14, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:06 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> Fix collection leak when its_init_domain() failed in its_probe_one().
>>
>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 2b7b546c43c8..df26ddc97ae2 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -3032,6 +3032,12 @@ static int its_alloc_collections(struct its_node *its)
>> return 0;
>> }
>>
>> +static void its_free_collections(struct its_node *its)
>> +{
>> + kfree(its->collections);
>> + its->collections = NULL;
>> +}
>
> Why do we need an extra helper for something that has a single calling
> spot? Why is it important to set collections to NULL, given that we're
> about to free the structure without even looking further?
>
The extra helper is added for symmetry with its_alloc_collections(), keeping
allocation/deallocation logic paired. In this way, we need to only modified
allocation/deallocation function if more member is added for collections.
Setting collections to NULL is a personal habit to quickly catch use-after-free
of collections. Could drop this which is not that import.
Thanks,
Kemeng
> M.
>
^ permalink raw reply
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Kemeng Shi @ 2026-06-16 1:31 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <87jys089sn.wl-maz@kernel.org>
在 2026/6/15 16:52:56, Marc Zyngier 写道:
> On Mon, 15 Jun 2026 04:29:05 +0100,
> Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>>
>> Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor
>
> Typo.
>
>> error handling code to make it a little simpler.
>
> No. Please don't mix fixes and (totally pointless) refactoring.
OK, I will only keep fix in this patch.>
>>
>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------
>> 1 file changed, 9 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 291d7668cc8d..2b7b546c43c8 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits)
>> static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
>> {
>> unsigned long *bitmap = NULL;
>> - int err = 0;
>>
>> do {
>> - err = alloc_lpi_range(nr_irqs, base);
>> + int err = alloc_lpi_range(nr_irqs, base);
>> if (!err)
>> break;
>>
>> @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
>> } while (nr_irqs > 0);
>>
>> if (!nr_irqs)
>> - err = -ENOSPC;
>> -
>> - if (err)
>> - goto out;
>> + goto err_out;
>>
>> bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC);
>> if (!bitmap)
>> - goto out;
>> + goto err_free_lpi;
>>
>> *nr_ids = nr_irqs;
>> -
>> -out:
>> - if (!bitmap)
>> - *base = *nr_ids = 0;
>> -
>> return bitmap;
>> +
>> +err_free_lpi:
>> + free_lpi_range(*base, nr_irqs);
>> +err_out:
>> + *base = *nr_ids = 0;
>> + return NULL;
>> }
>>
>> static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids)
>
> Honestly, I question the validity of handling errors this way. You are
> already unable to allocate a per-device bitmap. And yet you are
> calling free_lpi_range(), which has the interesting property of
> *allocating* memory. Which you don't have. Oh wait...
You are right. I'm considering use xarray to track the lpi range or
modify free_lpi_range to try merge first before memory allocation.
What would you recommend?
Thanks,
Kemeng Shi>
> M.
>
^ permalink raw reply
* [PATCH v2] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Kunihiko Hayashi @ 2026-06-16 1:12 UTC (permalink / raw)
To: Mark Brown, linux-spi
Cc: linux-arm-kernel, linux-kernel, Kunihiko Hayashi, Sangyun Kim,
Kyungwook Boo, stable, Masami Hiramatsu
The driver calls devm_request_irq() before initializing the completion
used by the interrupt handler. Because the interrupt may occur immediately
after devm_request_irq(), the handler may execute before init_completion().
This may result in calling complete() on an uninitialized completion,
causing undefined behavior. This has been observed with KASAN.
Fix this by initializing the completion before registering the IRQ.
Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC")
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Changes in v2:
- Rebase onto latest, no functional changes
drivers/spi/spi-uniphier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index cc20fd11f03f..86fce9a571da 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -656,6 +656,8 @@ static int uniphier_spi_probe(struct platform_device *pdev)
priv->host = host;
priv->is_save_param = false;
+ init_completion(&priv->xfer_done);
+
priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
@@ -679,8 +681,6 @@ static int uniphier_spi_probe(struct platform_device *pdev)
return ret;
}
- init_completion(&priv->xfer_done);
-
clk_rate = clk_get_rate(priv->clk);
host->max_speed_hz = DIV_ROUND_UP(clk_rate, SSI_MIN_CLK_DIVIDER);
--
2.34.1
^ permalink raw reply related
* [PATCH] firmware: imx: scu: manage mailbox channels and global handle
From: Pengpeng Hou @ 2026-06-16 0:59 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
imx, linux-arm-kernel, linux-kernel
Cc: Pengpeng Hou
imx_scu_probe() requests mailbox channels with the non-managed
mbox_request_channel_byname() helper and then publishes sc_ipc through
the global imx_sc_ipc_handle. Later probe failures, including child
population failure, can leave the channels and global handle live after
the probe has failed.
Register devres actions to free each mailbox channel and clear the global
handle. Also depopulate partially created child devices when
devm_of_platform_populate() reports an error.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/firmware/imx/imx-scu.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index 67b267a7408a..203aac421252 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -82,6 +82,17 @@ static int imx_sc_linux_errmap[IMX_SC_ERR_LAST] = {
static struct imx_sc_ipc *imx_sc_ipc_handle;
+static void imx_scu_free_mbox_chan(void *data)
+{
+ mbox_free_channel(data);
+}
+
+static void imx_scu_clear_handle(void *data)
+{
+ if (imx_sc_ipc_handle == data)
+ imx_sc_ipc_handle = NULL;
+}
+
static inline int imx_sc_to_linux_errno(int errno)
{
if (errno >= IMX_SC_ERR_NONE && errno < IMX_SC_ERR_LAST)
@@ -321,6 +332,11 @@ static int imx_scu_probe(struct platform_device *pdev)
dev_dbg(dev, "request mbox chan %s\n", chan_name);
/* chan_name is not used anymore by framework */
kfree(chan_name);
+
+ ret = devm_add_action_or_reset(dev, imx_scu_free_mbox_chan,
+ sc_chan->ch);
+ if (ret)
+ return ret;
}
sc_ipc->dev = dev;
@@ -330,6 +346,9 @@ static int imx_scu_probe(struct platform_device *pdev)
init_completion(&sc_ipc->done);
imx_sc_ipc_handle = sc_ipc;
+ ret = devm_add_action_or_reset(dev, imx_scu_clear_handle, sc_ipc);
+ if (ret)
+ return ret;
ret = imx_scu_soc_init(dev);
if (ret)
@@ -342,7 +361,11 @@ static int imx_scu_probe(struct platform_device *pdev)
dev_info(dev, "NXP i.MX SCU Initialized\n");
- return devm_of_platform_populate(dev);
+ ret = devm_of_platform_populate(dev);
+ if (ret)
+ of_platform_depopulate(dev);
+
+ return ret;
}
static const struct of_device_id imx_scu_match[] = {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v2 2/3] drm/msm/adreno: Add support for A704 GPU
From: Dmitry Baryshkov @ 2026-06-16 0:56 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bibek Kumar Patro,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
linux-arm-kernel, iommu, Aditya Sherawat, Konrad Dybcio
In-Reply-To: <20260615-shikra-gpu-v2-2-2f2d1347c3fb@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 03:02:58AM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very
> minimal changes. The only KMD facing difference is the chipid and the
> zap firmware which is specified via devicetree.
>
> Just add the new chipid to enable support for A704 GPU in Shikra.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RESEND PATCH v1] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Kunihiko Hayashi @ 2026-06-16 0:55 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-arm-kernel, linux-kernel, Sangyun Kim,
Kyungwook Boo, Masami Hiramatsu
In-Reply-To: <dffb3303-6371-4415-ac0e-488c421e2555@sirena.org.uk>
On 2026/06/15 20:45, Mark Brown wrote:
> On Mon, Jun 15, 2026 at 11:34:15AM +0900, Kunihiko Hayashi wrote:
>> The driver calls devm_request_irq() before initializing the completion
>> used by the interrupt handler. Because the interrupt may occur immediately
>> after devm_request_irq(), the handler may execute before init_completion().
>>
>> This may result in calling complete() on an uninitialized completion,
>> causing undefined behavior. This has been observed with KASAN.
>>
>> Fix this by initializing the completion before registering the IRQ.
>
> I thought you were going to rebase this, why resend the same version?
Sorry for confusion.
The patch was rebased due to upstream changes.
I'll resend it as v2 with a change comment.
Thank you,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* [PATCH] soc: apple: sart: require device link for consumers
From: Pengpeng Hou @ 2026-06-16 0:53 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, asahi, linux-arm-kernel,
linux-kernel
Cc: Pengpeng Hou
devm_apple_sart_get() obtains the supplier platform device and attempts
to create a runtime-PM device link to it, but it ignores device_link_add()
failure. A consumer can then continue without the dependency that keeps
the SART supplier ordered and runtime-PM reachable.
Treat a failed device link as an error and drop the supplier device
reference before returning.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/soc/apple/sart.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/apple/sart.c b/drivers/soc/apple/sart.c
index 9eaf3febb382..66b99955b395 100644
--- a/drivers/soc/apple/sart.c
+++ b/drivers/soc/apple/sart.c
@@ -218,6 +218,7 @@ struct apple_sart *devm_apple_sart_get(struct device *dev)
{
struct device_node *sart_node;
struct platform_device *sart_pdev;
+ struct device_link *link;
struct apple_sart *sart;
sart_node = of_parse_phandle(dev->of_node, "apple,sart", 0);
@@ -236,8 +237,12 @@ struct apple_sart *devm_apple_sart_get(struct device *dev)
return ERR_PTR(-EPROBE_DEFER);
}
- device_link_add(dev, &sart_pdev->dev,
- DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
+ link = device_link_add(dev, &sart_pdev->dev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER);
+ if (!link) {
+ put_device(&sart_pdev->dev);
+ return ERR_PTR(-ENODEV);
+ }
put_device(&sart_pdev->dev);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] mmc: sdhci-of-aspeed: depopulate slots before disabling clock
From: Pengpeng Hou @ 2026-06-16 0:49 UTC (permalink / raw)
To: Adrian Hunter, Andrew Jeffery, Ulf Hansson, Joel Stanley,
linux-mmc, linux-aspeed, openbmc, linux-arm-kernel, linux-kernel
Cc: Pengpeng Hou
aspeed_sdc_probe() creates child slot devices one by one after enabling
the controller clock. If a later slot creation fails, the already-created
slot devices remain registered while the parent probe returns an error.
Depopulate any created slot devices on probe failure and during remove,
before disabling the shared controller clock used by the slots.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mmc/host/sdhci-of-aspeed.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
index f5d973783cbe..3e941b176687 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -560,12 +560,14 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
cpdev = of_platform_device_create(child, NULL, &pdev->dev);
if (!cpdev) {
ret = -ENODEV;
- goto err_clk;
+ goto err_depopulate;
}
}
return 0;
+err_depopulate:
+ of_platform_depopulate(&pdev->dev);
err_clk:
clk_disable_unprepare(sdc->clk);
return ret;
@@ -575,6 +577,7 @@ static void aspeed_sdc_remove(struct platform_device *pdev)
{
struct aspeed_sdc *sdc = dev_get_drvdata(&pdev->dev);
+ of_platform_depopulate(&pdev->dev);
clk_disable_unprepare(sdc->clk);
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] firmware: ti_sci: undo list publication on populate failure
From: Pengpeng Hou @ 2026-06-16 0:47 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, linux-arm-kernel,
linux-kernel
Cc: Pengpeng Hou
ti_sci_probe() publishes the controller on the global ti_sci_list before
creating child devices. If of_platform_populate() fails after creating
some children, the probe error path leaves the children around and leaves
the failed controller visible through ti_sci_get_handle().
Depopulate any children created by the failed populate call and remove
the controller from the global list before returning the probe error.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/firmware/ti_sci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index e027a2bd8f26..670ed1fcd8ef 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -4050,6 +4050,10 @@ static int ti_sci_probe(struct platform_device *pdev)
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "platform_populate failed %pe\n", ERR_PTR(ret));
+ of_platform_depopulate(dev);
+ mutex_lock(&ti_sci_list_mutex);
+ list_del(&info->node);
+ mutex_unlock(&ti_sci_list_mutex);
goto out;
}
return 0;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [GIT PULL] arm64 updates for 7.2
From: pr-tracker-bot @ 2026-06-16 0:33 UTC (permalink / raw)
To: Will Deacon
Cc: torvalds, catalin.marinas, linux-arm-kernel, linux-kernel,
kernel-team, maz
In-Reply-To: <ai_PGPYpLyFr2Vyb@willie-the-truck>
The pull request you sent on Mon, 15 Jun 2026 11:08:24 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-upstream
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/80476f22b8b7e193b26f285a7c9f9e4b63abca16
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Dmitry Baryshkov @ 2026-06-16 0:22 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <8518a085-b8b7-4ee6-b08c-8dde3971a6f1@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 06:55:45PM +0530, Bibek Kumar Patro wrote:
>
>
> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
> > On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
> > > On some SoCs the SMMU registers require an active interconnect
> > > bandwidth vote to be accessible. While other clients typically
> > > satisfy this requirement implicitly, certain corner cases (e.g.
> > > during sleep/wakeup transitions) can leave the SMMU without a
> > > vote, causing intermittent register access failures.
> > >
> > > Add support for an optional interconnect path to the arm-smmu
> > > driver and vote for bandwidth while the SMMU is active. The path
> > > is acquired from DT if present and ignored otherwise.
> > >
> > > The bandwidth vote is enabled before accessing SMMU registers
> > > during probe and runtime resume, and released during runtime
> > > suspend and on error paths.
> > >
> > > Generally, from an architectural perspective, GEM_NOC and DDR are
> > > expected to have an active vote whenever the adreno_smmu block is
> > > powered on. In most common use cases, this requirement is implicitly
> > > satisfied because other GPU-related clients (for example, the GMU
> > > device) already hold a GEM_NOC vote when adreno_smmu is enabled.
> > >
> > > However, there are certain corner cases, such as during sleep/wakeup
> > > transitions, where the GEM_NOC vote can be removed before adreno_smmu
> > > is powered down. If adreno_smmu is then accessed while the interconnect
> > > vote is missing, it can lead to the observed failures. Because of the
> > > precise ordering involved, this scenario is difficult to reproduce
> > > consistently.
> > > (also GDSC is involved in adreno usecases can have an independent vote)
> > >
> > > Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> > > ---
> > > drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
> > > drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
> > > 2 files changed, 57 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
> > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > @@ -53,6 +53,11 @@
> > > #define MSI_IOVA_BASE 0x8000000
> > > #define MSI_IOVA_LENGTH 0x100000
> > > +/* Interconnect bandwidth vote values for the SMMU register access path */
> > > +#define ARM_SMMU_ICC_AVG_BW 0
> > > +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
> >
> > totally random numbers, which might be different for non-Qualcomm platform.
> >
> > > +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
> > > +
> > > static int force_stage;
> > > module_param(force_stage, int, S_IRUGO);
> > > MODULE_PARM_DESC(force_stage,
> > > @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
> > > }
> > > }
> > > +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
> > > +{
> > > + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
> >
> > Is there always only one bus / path in question?
> >
>
> <Apologies, missed to respond to this query>
> Yes for TCU, it needs to only have a vote on GEM_NOC interconnect
> while accessing the DDR in downstream path (client->TCU->DDR), which we are
> addressing here.
> Hence it's only one icc path in question here.
Again, you are describing Qualcomm platform, while the code part is
generic.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Dmitry Baryshkov @ 2026-06-16 0:21 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <d25f24ca-5bb3-4276-ac8f-8340e8fb4ce8@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 06:36:51PM +0530, Bibek Kumar Patro wrote:
>
>
> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
> > On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
> > > On some SoCs the SMMU registers require an active interconnect
> > > bandwidth vote to be accessible. While other clients typically
> > > satisfy this requirement implicitly, certain corner cases (e.g.
> > > during sleep/wakeup transitions) can leave the SMMU without a
> > > vote, causing intermittent register access failures.
> > >
> > > Add support for an optional interconnect path to the arm-smmu
> > > driver and vote for bandwidth while the SMMU is active. The path
> > > is acquired from DT if present and ignored otherwise.
> > >
> > > The bandwidth vote is enabled before accessing SMMU registers
> > > during probe and runtime resume, and released during runtime
> > > suspend and on error paths.
> > >
> > > Generally, from an architectural perspective, GEM_NOC and DDR are
> > > expected to have an active vote whenever the adreno_smmu block is
> > > powered on. In most common use cases, this requirement is implicitly
> > > satisfied because other GPU-related clients (for example, the GMU
> > > device) already hold a GEM_NOC vote when adreno_smmu is enabled.
> > >
> > > However, there are certain corner cases, such as during sleep/wakeup
> > > transitions, where the GEM_NOC vote can be removed before adreno_smmu
> > > is powered down. If adreno_smmu is then accessed while the interconnect
> > > vote is missing, it can lead to the observed failures. Because of the
> > > precise ordering involved, this scenario is difficult to reproduce
> > > consistently.
> > > (also GDSC is involved in adreno usecases can have an independent vote)
> > >
> > > Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> > > ---
> > > drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
> > > drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
> > > 2 files changed, 57 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
> > > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> > > @@ -53,6 +53,11 @@
> > > #define MSI_IOVA_BASE 0x8000000
> > > #define MSI_IOVA_LENGTH 0x100000
> > > +/* Interconnect bandwidth vote values for the SMMU register access path */
> > > +#define ARM_SMMU_ICC_AVG_BW 0
> > > +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
> >
> > totally random numbers, which might be different for non-Qualcomm platform.
> >
>
> Ideally, any non-zero value would be enough to keep the path active.
This is true for Qualcomm devices. However, you are adding this to a
generic code.
> Here 1 Would be enough to keep the path active, but might be too small to
> reliably keep the bus active.
> Other is UINT_MAX, which will reliably keep the bus active but might cause a
> power penalty.
>
> #define ARM_SMMU_ICC_PEAK_BW_HIGH UINT_MAX
>
> seems to be suitable here to reliably keep the bus active by BCM
> for both Qualcomm and non-Qualcomm platforms (with some power penalty).
>
> LMK, if you feel otherwise.
Shift it to the qcom instance or provide platform-specific values? (My
preference would be towards the first solution).
>
>
> > > +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
> > > +
> > > static int force_stage;
> > > module_param(force_stage, int, S_IRUGO);
> > > MODULE_PARM_DESC(force_stage,
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6] soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read
From: Andrew Jeffery @ 2026-06-16 0:20 UTC (permalink / raw)
To: Karthikeyan KS
Cc: joel, andrew, Kees Cook, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-hardening
In-Reply-To: <20260612190744.172638-1-karthiproffesional@gmail.com>
On Fri, 2026-06-12 at 19:07 +0000, Karthikeyan KS wrote:
> put_fifo_with_discard() acts as both producer and consumer on the kfifo:
> it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from
> the IRQ handler without synchronizing with snoop_file_read(), which also
> consumes via kfifo_to_user(). On SMP systems this concurrent access can
> leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp
> to (in - out) is ineffective and kfifo_copy_to_user() can attempt a
> copy_to_user() past the kmalloc-2k backing store:
>
> usercopy: Kernel memory exposure attempt detected from SLUB object
> 'kmalloc-2k' (offset 0, size 2049)!
> kernel BUG at mm/usercopy.c!
> Call trace:
> usercopy_abort
> __check_heap_object
> __check_object_size
> kfifo_copy_to_user
> __kfifo_to_user
> snoop_file_read
> vfs_read
>
> Serialize kfifo access with a per-channel spinlock shared between the
> IRQ handler (producer) and the file reader (consumer). Annotate @fifo
> with __guarded_by(&lock) and opt the driver into context analysis so the
> compiler enforces that all fifo access holds the lock.
>
> Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev")
> Signed-off-by: Karthikeyan KS <karthiproffesional@gmail.com>
> ---
> drivers/soc/aspeed/Makefile | 1 +
> drivers/soc/aspeed/aspeed-lpc-snoop.c | 38 ++++++++++++++++++---------
> 2 files changed, 27 insertions(+), 12 deletions(-)
>
> Andrew,
>
> Thanks for the review.
>
> Changes since v5:
> - Annotate @fifo with __guarded_by(&lock) instead of a comment
> - Move kfifo_initialized() check inside scoped_guard(spinlock, &chan->lock)
> in put_fifo_with_discard()
> - Replace spin_lock_init() with scoped_guard(spinlock_init, &channel->lock)
> around kfifo_alloc() in aspeed_lpc_enable_snoop()
> - Enable CONTEXT_ANALYSIS for this driver in drivers/soc/aspeed/Makefile
>
> Dropped Cc: stable — the fix uses cleanup.h/context-analysis idioms absent
> from LTS; I'll send adapted backports to stable@ once this is in mainline.
>
> Tested on ast2600-evb (QEMU):
>
Can you describe the specific steps you used to test this under qemu?
I'm interested in reproducing your efforts here.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
From: patchwork-bot+netdevbpf @ 2026-06-16 0:20 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev, madhur.agrawal, aleksander.lobakin
In-Reply-To: <20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 11 Jun 2026 23:55:50 +0200 you wrote:
> Add the capability to configure GDM3/GDM4 as WAN/LAN on demand when QoS
> offload is created or destroyed.
> Make dev->qdma an RCU pointer so the TX path can safely dereference it
> without holding RTNL.
> Introduce airoha_qdma_start() and airoha_qdma_stop() helpers.
>
>
> [...]
Here is the summary with links:
- [net-next,v5,1/3] net: airoha: use int instead of atomic_t for qdma users counter
https://git.kernel.org/netdev/net-next/c/a459b560e58b
- [net-next,v5,2/3] net: airoha: refactor QDMA start/stop into reusable helpers
(no matching commit)
- [net-next,v5,3/3] net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: dts: qcom: kodiak: Add GEM_NOC interconnect for adreno SMMU
From: Dmitry Baryshkov @ 2026-06-16 0:19 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <26d51cbb-2d87-4564-b3c6-cc61ab900e19@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 08:07:07PM +0530, Bibek Kumar Patro wrote:
>
>
> On 6/8/2026 7:27 PM, Dmitry Baryshkov wrote:
> > On Tue, May 26, 2026 at 08:12:04PM +0530, Bibek Kumar Patro wrote:
> > > On Kodiak platforms, the Adreno SMMU requires a bandwidth vote on
> > > the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers
> > > are accessible. Without this vote, the SMMU may become unreachable,
> > > leading to intermittent probe failures and runtime issues.
> > >
> > > Add the required interconnect to ensure reliable register access.
> >
> > Does it only concern the GPU SMMU? What about the APPS SMMU? Should it
> > be voting on other interconnects too? I guess so, because currently I
> > see that TBUs vote for various interconnects. BTW: should apps_smmu also
> > vote on the power domains?
> >
>
> This race mainly occurs in GPU SMMU, where the GDSC can have an
> independent vote on the Adreno SMMU. However, the GEM_NOC vote may
> already have been removed by the GPU (or any consumer of adreno_smmu,
> e.g gmu), unless it is explicitly voted by the GPU SMMU (which acts as a
> supplier for the GPU). This mismatch can lead to SHUB timeouts or NoC
> errors.
>
> Mostly this race reported in suspend/resume cycle (when gpu/gmu devices
> moves to slumber/suspend state before adreno_smmu powers down
> and the later doesn't have explicit interconnect voting).
>
> In the case of APPS SMMU, such a race is not expected for any known
> use case. APPS SMMU is part of a shared infrastructure block, and its
> power is typically kept enabled as long as attached master devices are
> active. Therefore, explicit power-domain voting from APPS SMMU may not
> be required.
This looks like a good part of the commit message. Please add it where
it belongs.
>
> Thanks,
> Bibek
>
>
> > >
> > > Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > > index fa540d8c2615dc02d941eb16bc7253204c2750bd..eefa4b836a81374ff437ab4bbcbc3fecc1590ab6 100644
> > > --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > > @@ -3386,6 +3386,8 @@ adreno_smmu: iommu@3da0000 {
> > > power-domains = <&gpucc GPU_CC_CX_GDSC>;
> > > dma-coherent;
> > > + interconnects = <&gem_noc MASTER_GPU_TCU QCOM_ICC_TAG_ALWAYS
> > > + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> > > };
> > > gfx_0_tbu: tbu@3dd9000 {
> > >
> > > --
> > > 2.34.1
> > >
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property
From: Dmitry Baryshkov @ 2026-06-16 0:18 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Konrad Dybcio, Will Deacon, Robin Murphy, Joerg Roedel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <a1db573b-bcb4-44a5-89b6-6d1c76f4a18a@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 07:32:45PM +0530, Bibek Kumar Patro wrote:
>
>
> On 6/8/2026 7:19 PM, Dmitry Baryshkov wrote:
> > On Mon, Jun 08, 2026 at 07:14:43PM +0530, Bibek Kumar Patro wrote:
> > >
> > >
> > > On 6/8/2026 3:22 PM, Konrad Dybcio wrote:
> > > > On 5/26/26 4:42 PM, Bibek Kumar Patro wrote:
> > > > > Some SoC implementations require a bandwidth vote on an interconnect
> > > > > path before the SMMU register space is accessible. Add the optional
> > > > > 'interconnects' property to the binding to allow platform DT nodes
> > > > > to describe this path.
> > > > >
> > > > > Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> > > > > ---
> > > > > .../devicetree/bindings/iommu/arm,smmu.yaml | 27 ++++++++++++++++++++++
> > > > > 1 file changed, 27 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > > > > index 06fb5c8e7547cb7a92823adc2772b94f747376a6..3a677ff1a18fcdf5c0ca9ec8a017d41f9eb5ff09 100644
> > > > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > > > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > > > > @@ -243,6 +243,13 @@ properties:
> > > > > minItems: 1
> > > > > maxItems: 3
> > > > > + interconnects:
> > > > > + maxItems: 1
> > > > > + description:
> > > > > + Interconnect path to the SMMU register space. Required on SoCs
> > > > > + where the SMMU registers are only accessible after a bandwidth
> > > > > + vote has been placed on the interconnect fabric.
> > > > > +
> > > > > nvidia,memory-controller:
> > > > > description: |
> > > > > A phandle to the memory controller on NVIDIA Tegra186 and later SoCs.
> > > > > @@ -602,6 +609,26 @@ allOf:
> > > > > clock-names: false
> > > > > clocks: false
> > > > > + - if:
> > > > > + properties:
> > > > > + compatible:
> > > > > + items:
> > > > > + - enum:
> > > > > + - qcom,qcs615-smmu-500
> > > > > + - qcom,qcs8300-smmu-500
> > > > > + - qcom,sa8775p-smmu-500
> > > > > + - qcom,sc7280-smmu-500
> > > >
> > > > This is a list of targets that happen to be supported by QLI.. but should
> > > > this list not contain _all_ Qualcomm SoCs, or at least a much broader range?
> > > >
> > > > Perhaps
> > > >
> > > > if: properties: compatible: contains: qcom,adreno-smmu
> > > >
> > > > ?
> > > >
> > >
> > > As of now platforms where the issues [1] getting reported are added, the
> > > list will grow.
> > > <We still have to evaluate and test on other non-QLI platforms hosted in
> > > upstream [2]>
> >
> > Do you really need to test, which platforms have an interconnect, or can
> > you predict it by checking the SoC documentation? I strongly belive, the
> > latter is the case.
> >
>
> Agree, for interconnect path we can surely predict from the SoC
> documentation,
> But for the corresponding FLAGS/values (MASTER_GPU_TCU, SLAVE_EBI1), it
> would need some testing before finalizing the change on corresponding
> platforms.
I'd assume that corresponding values should already be known. The
platforms are not new.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: aspeed: add BMC-side PCIe BMC device driver
From: Andrew Jeffery @ 2026-06-16 0:16 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel, anirudhsriniv
In-Reply-To: <CAFi2wKanAH+ekKz3eVtdiz=pjEvmKwSh1XhE-Xo7p=CCiSWpEw@mail.gmail.com>
On Fri, 2026-06-12 at 11:21 +0200, Grégoire Layet wrote:
> Hello Andrew,
>
> Anirudh Srinivasan and I have found that IPMI over KCS using the
> PCI worked with the stock ASPEED bmc driver (the bmc driver in the V1)
> but not with the trimmed-down version in the V2. I have apparently removed
> a bit too much from the V2 , but that's not what I want to focus on.
Sure.
>
> This brings back the question of where we should put the registers
> configuration,
> considering that two different functionalities depend on it.
>
> > It is also possible to put the SCU initialisation on the
> > 8250_aspeed_vuart driver
> > directly. This could be activated with a specific flag added to VUART nodes
> > ('pcie2vuart' for example) on the DeviceTree.
The concept sounds reasonable to me. There's probably some bikeshedding
to do on the devicetree property though.
>
> Similarly to this idea, we could include have the necessary configuration in the
> 'kcs_bmc_aspeed' driver. This could be activated using a similar flag
> ,such as 'pci2lpc'
> or 'pci2kcs' directly. However, this would result in a lot of code
> duplication for most
> of the configuration.
Can you outline the duplication you're concerned about? I think it's a
matter of resolving the SCU syscon to its regmap, then performing the
necessary accesses?
>
> The issue for me is that, two drivers configuring the same registers
> is not a good idea.
I think it's not as bad as you make it out to be. The SCU's regmap
protects updates to individual registers under a lock, so concurrent
modification isn't a concern. The hardware design choices make all of
this slightly awkward for any related software design. As an
alternative you could implement a mini subsystem that relevant drivers
could call through to set the bits, but I currently think that's
unnecessary work.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 5/8] net: dsa: mt7530: replace mt7530_read with regmap_read
From: Jakub Kicinski @ 2026-06-16 0:15 UTC (permalink / raw)
To: daniel
Cc: chester.a.unal, andrew, olteanv, davem, edumazet, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260615235649.1060736-1-kuba@kernel.org>
On Mon, 15 Jun 2026 16:56:49 -0700 Jakub Kicinski wrote:
> > static u32
> > -mt7530_read(struct mt7530_priv *priv, u32 reg)
> > +mt7530_mii_poll(struct mt7530_dummy_poll *p)
> > {
> > - int ret;
> > u32 val;
> >
> > - ret = regmap_read(priv->regmap, reg, &val);
> > - if (ret) {
> > - WARN_ON_ONCE(1);
> > - dev_err(priv->dev,
> > - "failed to read mt7530 register\n");
> > - return 0;
> > - }
> > + regmap_read(p->priv->regmap, p->reg, &val);
> >
> > return val;
> > }
>
> [Medium]
> The old wrapper guaranteed val == 0 on failure. The new mt7530_mii_poll()
> declares val without an initializer and ignores the regmap_read() return
> code, so on a failed underlying transfer val is whatever was on the stack.
>
> Looking at drivers/net/dsa/mt7530-mdio.c::mt7530_regmap_read():
>
> ret = bus->write(bus, priv->mdiodev->addr, 0x1f, page);
> if (ret < 0)
> return ret;
>
> lo = bus->read(bus, priv->mdiodev->addr, r);
> hi = bus->read(bus, priv->mdiodev->addr, 0x10);
>
> *val = (hi << 16) | (lo & 0xffff);
This looks legit, AFAICT, sadly.
Maybe just write *val = 0; in mt7530_regmap_read() unconditionally ?
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
From: Jakub Kicinski @ 2026-06-15 23:37 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal,
Alexander Lobakin
In-Reply-To: <20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1@kernel.org>
On Thu, 11 Jun 2026 23:55:50 +0200 Lorenzo Bianconi wrote:
> net: airoha: use int instead of atomic_t for qdma users counter
> net: airoha: refactor QDMA start/stop into reusable helpers
> net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload
only the first patch applies cleanly right now
^ permalink raw reply
* Re: [PATCH net-next v2 8/8] net: dsa: mt7530: implement port_change_conduit op
From: Jakub Kicinski @ 2026-06-15 23:57 UTC (permalink / raw)
To: daniel
Cc: Jakub Kicinski, chester.a.unal, andrew, olteanv, davem, edumazet,
pabeni, matthias.bgg, angelogioacchino.delregno, linux, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <8dd8cfe32bc8e38b92c49e30a6255090fb0998fb.1781312667.git.daniel@makrotopia.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: dsa: mt7530: implement port_change_conduit op
Implements the port_change_conduit operation for the mt7530 driver,
updating the port matrix to forward to a new CPU port. The op is
restricted to MT7531 because MT7530/MT7621 cannot honour per-port CPU
affinity for trapped frames and the MT7988/EN7581/AN7583 switches have
only a single CPU port.
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index c96420c291d5..2f3e734b9f53 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -3206,6 +3206,34 @@ static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
> return 0;
> }
>
> +static int
> +mt753x_port_change_conduit(struct dsa_switch *ds, int port,
> + struct net_device *conduit,
> + struct netlink_ext_ack *extack)
> +{
> + struct dsa_port *new_cpu_dp = conduit->dsa_ptr;
> + struct dsa_port *dp = dsa_to_port(ds, port);
> + struct mt7530_priv *priv = ds->priv;
> +
> + if (priv->id != ID_MT7531)
> + return -EOPNOTSUPP;
[Low]
Should this branch populate the supplied extack with NL_SET_ERR_MSG_MOD()
before returning -EOPNOTSUPP?
Because port_change_conduit is registered in the shared mt7530_switch_ops
table, the DSA core's fallback message in dsa_user_change_conduit() ("Driver
does not support changing DSA conduit") is bypassed; that branch only runs
when ds->ops->port_change_conduit is NULL. Neither dsa_port_change_conduit()
nor __dsa_port_change_conduit() in net/dsa/port.c synthesize an extack on
callback failure either.
The result is that on MT7530, MT7621, MT7988, EN7581 and AN7583, userspace
invoking IFLA_DSA_CONDUIT receives EOPNOTSUPP with an empty extack, with
none of the per-chip context that the commit message itself spells out
(single CPU port; MT7530 MFC CPU_PORT trapping limitation). Would a short
NL_SET_ERR_MSG_MOD() naming the reason be appropriate here?
> +
> + mutex_lock(&priv->reg_mutex);
> +
> + /* dp->cpu_dp still points to the old CPU port */
> + priv->ports[port].pm &= ~PCR_MATRIX(BIT(dp->cpu_dp->index));
> + priv->ports[port].pm |= PCR_MATRIX(BIT(new_cpu_dp->index));
> + if (priv->ports[port].enable)
> + regmap_update_bits(priv->regmap, MT7530_PCR_P(port),
> + PCR_MATRIX_MASK, priv->ports[port].pm);
> +
> + mutex_unlock(&priv->reg_mutex);
> +
> + mt7530_port_fast_age(ds, port);
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH net-next v2 7/8] net: dsa: mt7530: implement port_fast_age
From: Jakub Kicinski @ 2026-06-15 23:56 UTC (permalink / raw)
To: daniel
Cc: Jakub Kicinski, chester.a.unal, andrew, olteanv, davem, edumazet,
pabeni, matthias.bgg, angelogioacchino.delregno, linux, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <e6cdb705f0ec142283071e1966000d3a76f71a16.1781312667.git.daniel@makrotopia.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
Subject: net: dsa: mt7530: implement port_fast_age
This change adds a .port_fast_age operation for the mt7530 DSA driver.
The implementation triggers an ATC flush of all non-static MAC address
entries and polls ATC_BUSY for completion.
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index dcf72ab0cd66..c96420c291d5 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -193,6 +193,21 @@ mt7530_fdb_cmd(struct mt7530_priv *priv, enum mt7530_fdb_cmd cmd, u32 *rsp)
> return 0;
> }
>
> +static void mt7530_port_fast_age(struct dsa_switch *ds, int port)
> +{
> + struct mt7530_priv *priv = ds->priv;
> + struct mt7530_dummy_poll p;
> + u32 val;
> +
> + /* Flush all non-static MAC address entries */
> + val = ATC_BUSY | ATC_MAT_NON_STATIC_MAC | MT7530_FDB_FLUSH;
> + regmap_write(priv->regmap, MT7530_ATC, val);
[High]
Should this transaction be serialised against priv->reg_mutex?
Every other accessor that touches MT7530_ATC wraps the write+poll
sequence in mutex_lock(&priv->reg_mutex)/mutex_unlock(&priv->reg_mutex).
For example mt7530_port_fdb_add(), mt7530_port_fdb_del(),
mt7530_port_fdb_dump(), mt7530_port_mdb_add() and mt7530_port_mdb_del()
all hold reg_mutex around the call to mt7530_fdb_cmd():
mutex_lock(&priv->reg_mutex);
mt7530_fdb_write(priv, vid, port_mask, addr, -1, STATIC_ENT);
ret = mt7530_fdb_cmd(priv, MT7530_FDB_WRITE, NULL);
mutex_unlock(&priv->reg_mutex);
If .port_fast_age runs concurrently with one of those operations, can
the two write-then-busy-poll sequences on the same MT7530_ATC register
overlap?
Could one thread's poll loop observe ATC_BUSY clearing for the other
thread's command, leading mt7530_port_fdb_dump() to read stale ATRD
data, or could one thread's freshly written ATC command be overwritten
by the other before the controller has executed it?
> +
> + INIT_MT7530_DUMMY_POLL(&p, priv, MT7530_ATC);
> + readx_poll_timeout(mt7530_mii_poll, &p, val,
> + !(val & ATC_BUSY), 20, 20000);
> +}
[Medium]
Is there a reason the return value of readx_poll_timeout() is ignored
here?
The structurally identical helper mt7530_fdb_cmd() in the same file
checks the result and emits a diagnostic on timeout:
ret = readx_poll_timeout(mt7530_mii_poll, &p, val,
!(val & ATC_BUSY), 20, 20000);
if (ret < 0) {
dev_err(priv->dev, "reset timeout\n");
return ret;
}
Peer DSA drivers also log on failure (b53_br_fast_age prints "fast
ageing failed"; rtl83xx_port_fast_age prints "failed to fast age on
port %d: %d").
If the ATC engine fails to clear ATC_BUSY within the 20ms timeout,
mt7530_port_fast_age() returns silently and a subsequent
mt7530_fdb_cmd() will write a new command on top of the in-flight
operation. Should this path emit dev_err() on timeout to make a wedged
ATC engine visible to operators?
> +
> static void
> mt7530_fdb_read(struct mt7530_priv *priv, struct mt7530_fdb *fdb)
> {
[ ... ]
[Low]
Is the claim in the commit message accurate?
"This is consistent with what other DSA drivers do (b53, realtek)
and relearning is fast."
Both drivers cited actually implement per-port fast aging.
In b53, b53_br_fast_age() calls b53_fast_age_port() which writes the
target port to B53_FAST_AGE_PORT_CTRL and selects FAST_AGE_PORT mode.
In realtek, rtl83xx_port_fast_age() calls
priv->ops->l2_flush(priv, port, 0), and rtl8366rb_port_fast_age()
flushes only BIT(port) via RTL8366RB_SECURITY_CTRL.
The mt7530 implementation flushes globally and ignores the port
argument entirely, which is the opposite of the cited examples. The
hardware-limitation rationale ("switch does not offer combined
non-static AND per-port match mode") may be valid, but the b53/realtek
comparison appears to be the wrong precedent.
A side effect not mentioned is that an STP transition on one port will
flush dynamic FDB entries on every other port and every other bridge
sharing the switch. Should this divergence from the typical
.port_fast_age contract be called out?
> diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
> index abf19aa69520..decad7a93dbd 100644
> --- a/drivers/net/dsa/mt7530.h
> +++ b/drivers/net/dsa/mt7530.h
> @@ -165,6 +165,7 @@ enum mt753x_to_cpu_fw {
> #define ATC_MAT_MASK GENMASK(11, 8)
> #define ATC_MAT(x) FIELD_PREP(ATC_MAT_MASK, x)
> #define ATC_MAT_MACTAB ATC_MAT(0)
> +#define ATC_MAT_NON_STATIC_MAC ATC_MAT(4)
[Low]
The new ATC_MAT_NON_STATIC_MAC define uses a single tab between the
macro name and its value, while the surrounding ATC_MAT_* macros use
multiple tabs and align the values at the same column. Should this
follow the existing alignment?
>
> enum mt7530_fdb_cmd {
> MT7530_FDB_READ = 0,
^ permalink raw reply
* Re: [PATCH net-next v2 6/8] net: dsa: mt7530: convert to use field accessor macros
From: Jakub Kicinski @ 2026-06-15 23:56 UTC (permalink / raw)
To: daniel
Cc: Jakub Kicinski, chester.a.unal, andrew, olteanv, davem, edumazet,
pabeni, matthias.bgg, angelogioacchino.delregno, linux, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <62e0a7e96bcadba0ec1a0f090c2fd2990c6ae0f1.1781312667.git.daniel@makrotopia.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: dsa: mt7530: convert to use field accessor macros
This patch converts the mt7530 DSA driver to use FIELD_GET and FIELD_PREP
instead of open-coded shift/mask constructs, and replaces a 0x1f literal
in the PHY address helper with (PHY_MAX_ADDR - 1).
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 4168adca949f..dcf72ab0cd66 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
[ ... ]
> @@ -1555,7 +1555,7 @@ mt7530_vlan_cmd(struct mt7530_priv *priv, enum mt7530_vlan_cmd cmd, u16 vid)
> u32 val;
> int ret;
>
> - val = VTCR_BUSY | VTCR_FUNC(cmd) | vid;
> + val = VTCR_BUSY | VTCR_FUNC(cmd) | VTCR_VID(vid);
[Low]
The commit message describes this change as a refactor:
"Use FIELD_GET and FIELD_PREP instead of open-coding register fields."
The mt7530_vlan_cmd() hunk is not quite a pure conversion though. The
previous code OR'd in vid directly:
val = VTCR_BUSY | VTCR_FUNC(cmd) | vid;
while the new code applies a GENMASK(11, 0) truncation through VTCR_VID():
val = VTCR_BUSY | VTCR_FUNC(cmd) | VTCR_VID(vid);
Spec-conformant VIDs always fit in 12 bits, so the runtime result is the
same, but the value is now masked where it previously was not.
A related observation is that the prior VTCR_VID and ATC_HASH macros
referenced an undeclared x:
#define ATC_HASH (((x) & 0xfff) << 16)
#define VTCR_VID ((x) & 0xfff)
so they could not have been used by any caller before this patch. Adding
the (x) parameter and a GENMASK is effectively a fix for those macros.
Would it be worth calling out the VTCR_VID() truncation and the macro
parameter fix in the commit message, or splitting them into a separate
patch so the conversion remains a no-op refactor?
> diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
[ ... ]
> @@ -171,32 +176,29 @@ enum mt7530_fdb_cmd {
>
> /* Registers for table search read address */
> #define MT7530_TSRA1 0x84
[ ... ]
> #define MT7530_ATRD 0x8C
> -#define AGE_TIMER 24
> -#define AGE_TIMER_MASK 0xff
> -#define PORT_MAP 4
> -#define PORT_MAP_MASK 0xff
> -#define ENT_STATUS 2
> -#define ENT_STATUS_MASK 0x3
> +#define AGE_TIMER_RD_MASK GENMASK(31, 24)
> +#define PORT_MAP_MASK GENMASK(11, 4)
> +#define ENT_STATUS_MASK GENMASK(3, 2)
[Low]
The mask formerly named AGE_TIMER_MASK is renamed to AGE_TIMER_RD_MASK,
but the same mask is consumed on both the read and write paths
(mt7530_fdb_read() and mt7530_fdb_write()), so the _RD_ infix reads as
"read-side only".
Its sibling fields in the same MT7530_ATRD register keep plain names
(PORT_MAP_MASK, ENT_STATUS_MASK), and the related ageing counters in
MT7530_AAC use AGE_CNT_MASK / AGE_UNIT_MASK rather than an _RD_
disambiguation.
Was the _RD_ infix intentional, and if so, what does it disambiguate
from?
[ ... ]
> @@ -731,38 +745,48 @@ enum mt7531_xtal_fsel {
> #define MT7531_PHY_PLL_OFF BIT(5)
> #define MT7531_PHY_PLL_BYPASS_MODE BIT(4)
>
> -#define MT753X_CTRL_PHY_ADDR(addr) ((addr + 1) & 0x1f)
> +#define MT753X_CTRL_PHY_ADDR(addr) (((addr) + 1) & (PHY_MAX_ADDR - 1))
[Low]
The replacement evaluates to the same value today, since PHY_MAX_ADDR is
32 in include/linux/phy.h and PHY_MAX_ADDR - 1 is 0x1f, and both forms
ultimately derive from the IEEE 802.3 5-bit MDIO PHY-address field.
The original 0x1f represented the width of the hardware register field,
while PHY_MAX_ADDR - 1 represents the maximum software PHY address minus
one and additionally relies on PHY_MAX_ADDR being a power of two, which
phy.h does not formally guarantee.
Given the rest of the patch introduces explicit GENMASK based field
masks, would something like:
#define MT753X_CTRL_PHY_ADDR_MASK GENMASK(4, 0)
#define MT753X_CTRL_PHY_ADDR(addr) FIELD_PREP(MT753X_CTRL_PHY_ADDR_MASK, (addr) + 1)
be more consistent and make the hardware-field intent clearer?
^ 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