* [PATCH v4] ASoC: dt-bindings: mtk-btcvsd-snd: Convert to DT Schema
From: Luca Leonardo Scorcia @ 2026-06-15 18:57 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-sound, devicetree, linux-kernel,
linux-arm-kernel
Convert the mtk-btcvsd-snd.txt DT binding to DT Schema format.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
Changes in v4:
- Removed minItems, maxItems properties from reg node
- Removed the reg-names property
- Adjusted the example
Changes in v3 [3]:
Sorry about the spam. A second round of dt_binding_check + dtbs_check
led me to additional improvements:
- Use reg-names in place of a non-informative description property
- Simplify the reg property in the example
Changes in v2 [2]:
- Fixed issues from make dt_binding_check
- Set myself as maintainer for the binding
Initial version [1].
[1] https://lore.kernel.org/20260420204514.1640995-1-l.scorcia@gmail.com/
[2] https://lore.kernel.org/20260421154619.227039-1-l.scorcia@gmail.com/
[3] https://lore.kernel.org/linux-mediatek/20260421193858.347258-1-l.scorcia@gmail.com/
.../sound/mediatek,mtk-btcvsd-snd.yaml | 59 +++++++++++++++++++
.../bindings/sound/mtk-btcvsd-snd.txt | 24 --------
2 files changed, 59 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
new file mode 100644
index 000000000000..1b7451655476
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mtk-btcvsd-snd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek ALSA BT SCO CVSD/MSBC
+
+maintainers:
+ - Luca Leonardo Scorcia <l.scorcia@gmail.com>
+
+properties:
+ compatible:
+ const: mediatek,mtk-btcvsd-snd
+
+ reg:
+ items:
+ - description: PKV region
+ - description: SRAM_BANK2 region
+
+ interrupts:
+ items:
+ - description: BT-SCO interrupt
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the infracfg controller
+
+ mediatek,offset:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Array of register offsets and masks
+ items:
+ - description: infra_misc_offset
+ - description: infra_conn_bt_cvsd_mask
+ - description: cvsd_mcu_read_offset
+ - description: cvsd_mcu_write_offset
+ - description: cvsd_packet_indicator_offset
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - mediatek,infracfg
+ - mediatek,offset
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mtk-btcvsd-snd@18000000 {
+ compatible = "mediatek,mtk-btcvsd-snd";
+ reg = <0x18000000 0x1000>,
+ <0x18080000 0x8000>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
+ mediatek,infracfg = <&infrasys>;
+ mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt b/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
deleted file mode 100644
index 679e44839b48..000000000000
--- a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Mediatek ALSA BT SCO CVSD/MSBC Driver
-
-Required properties:
-- compatible = "mediatek,mtk-btcvsd-snd";
-- reg: register location and size of PKV and SRAM_BANK2
-- interrupts: should contain BTSCO interrupt
-- mediatek,infracfg: the phandles of INFRASYS
-- mediatek,offset: Array contains of register offset and mask
- infra_misc_offset,
- infra_conn_bt_cvsd_mask,
- cvsd_mcu_read_offset,
- cvsd_mcu_write_offset,
- cvsd_packet_indicator_offset
-
-Example:
-
- mtk-btcvsd-snd@18000000 {
- compatible = "mediatek,mtk-btcvsd-snd";
- reg=<0 0x18000000 0 0x1000>,
- <0 0x18080000 0 0x8000>;
- interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
- mediatek,infracfg = <&infrasys>;
- mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
- };
--
2.43.0
^ permalink raw reply related
* [PATCH v1] ARM: mvebu: Fix CPU node reference leak in get_cpu_clk()
From: Yuho Choi @ 2026-06-15 18:59 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Russell King
Cc: linux-arm-kernel, linux-kernel, Yuho Choi
of_get_cpu_node() returns a reference to the CPU device node.
get_cpu_clk() only needs that node for of_clk_get(), but never drops the
reference after the clock lookup.
Drop the CPU node reference before returning the clock, covering both
the successful lookup and the IS_ERR() path.
Fixes: f6cec7cd0777 ("ARM: mvebu: remove device tree parsing for cpu nodes")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
arch/arm/mach-mvebu/platsmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 18384ea6862c..0f14d7376770 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -42,6 +42,7 @@ static struct clk *get_cpu_clk(int cpu)
if (WARN(!np, "missing cpu node\n"))
return NULL;
cpu_clk = of_clk_get(np, 0);
+ of_node_put(np);
if (WARN_ON(IS_ERR(cpu_clk)))
return NULL;
return cpu_clk;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm64: tlb: Flush walk cache when unsharing PMD tables
From: David Hildenbrand (Arm) @ 2026-06-15 19:00 UTC (permalink / raw)
To: Catalin Marinas, Zeng Heng
Cc: will, akpm, npiggin, aneesh.kumar, peterz, linux-kernel,
wangkefeng.wang, linux-arm-kernel, linux-mm, linux-arch,
Paul Walmsley, Palmer Dabbelt, Albert Ou
In-Reply-To: <ag8fHYL-S26uO0yZ@arm.com>
On 5/21/26 17:05, Catalin Marinas wrote:
> + David H.
>
> On Thu, May 21, 2026 at 03:30:11PM +0800, Zeng Heng wrote:
>> From: Zeng Heng <zengheng4@huawei.com>
>>
>> When huge_pmd_unshare() is called to unshare a PMD table, the
>> tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true
>> but the aarch64 tlb_flush() only checked tlb->freed_tables to
>> determine whether to use TLBF_NONE (vae1is, invalidates walk
>> cache) or TLBF_NOWALKCACHE (vale1is, leaf-only).
>>
>> This caused the stale PMD page table entry to remain in the walk cache
>> after unshare, potentially leading to incorrect page table walks.
>>
>> Fix by including unshared_tables in the check, so that when
>> unsharing tables, TLBF_NONE is used and the walk cache is properly
>> invalidated.
>>
>> Here is the detailed distinction between vae1is and vale1is:
>>
>> | Instruction Combination | Actual Invalidation Scope |
>> | ------------------------ | --------------------------------------------------|
>> | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) |
>> | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 |
>> | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) |
>> | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only |
>>
>> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
>
> The fix looks fine but does it need:
I'm late ... just stumbled over this in my inbox while digging though a pile.
>
> Fixes: 8ce720d5bd91 ("mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather")
> Cc: <stable@vger.kernel.org>
Very likely, yes.
>
>> ---
>> arch/arm64/include/asm/tlb.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
>> index 10869d7731b8..751bd57bc3ba 100644
>> --- a/arch/arm64/include/asm/tlb.h
>> +++ b/arch/arm64/include/asm/tlb.h
>> @@ -53,7 +53,8 @@ static inline int tlb_get_level(struct mmu_gather *tlb)
>> static inline void tlb_flush(struct mmu_gather *tlb)
>> {
>> struct vm_area_struct vma = TLB_FLUSH_VMA(tlb->mm, 0);
>> - tlbf_t flags = tlb->freed_tables ? TLBF_NONE : TLBF_NOWALKCACHE;
>> + tlbf_t flags = (tlb->freed_tables || tlb->unshared_tables) ?
>> + TLBF_NONE : TLBF_NOWALKCACHE;
>> unsigned long stride = tlb_get_unmap_size(tlb);
>> int tlb_level = tlb_get_level(tlb);
>>
Right, the old code would have effectively called flush_tlb_range() ->
flush_tlb_mm_range() with freed_tables=true.
I recall that being a tricky bit. The commit documents that as:
(1) tlb_remove_table_sync_one() is a NOP on architectures without
CONFIG_MMU_GATHER_RCU_TABLE_FREE.
Here, the assumption is that the previous TLB flush would send an
IPI to all relevant CPUs. Careful: some architectures like x86 only
send IPIs to all relevant CPUs when tlb->freed_tables is set.
The relevant architectures should be selecting
MMU_GATHER_RCU_TABLE_FREE, but x86 might not do that in stable
kernels and it might have been problematic before this patch.
Also, the arch flushing behavior (independent of IPIs) is different
when tlb->freed_tables is set. Do we have to enlighten them to also
take care of tlb->unshared_tables? So far we didn't care, so
hopefully we are fine. Of course, we could be setting
tlb->freed_tables as well, but that might then unnecessarily flush
too much, because the semantics of tlb->freed_tables are a bit
fuzzy.
Turns out I was thinking too much in terms of optimizing IPIs.
Besides arm64 and x86, powerpc and riscv also rely on "tlb->freed_tables"
in tlb_flush(). But only arm64, x86 and riscv support ARCH_WANT_HUGE_PMD_SHARE.
Which makes me wonder whether we also need:
diff --git a/arch/riscv/include/asm/tlb.h b/arch/riscv/include/asm/tlb.h
index 50b63b5c15bd..17c551322b5d 100644
--- a/arch/riscv/include/asm/tlb.h
+++ b/arch/riscv/include/asm/tlb.h
@@ -16,7 +16,8 @@ static void tlb_flush(struct mmu_gather *tlb);
static inline void tlb_flush(struct mmu_gather *tlb)
{
#ifdef CONFIG_MMU
- if (tlb->fullmm || tlb->need_flush_all || tlb->freed_tables)
+ if (tlb->fullmm || tlb->need_flush_all || tlb->freed_tables ||
+ tlb->unshared_tables)
flush_tlb_mm(tlb->mm);
else
flush_tlb_mm_range(tlb->mm, tlb->start, tlb->end,
CCing riscv maintainers.
--
Cheers,
David
^ permalink raw reply related
* Re: [RFC PATCH] KVM: Ignore MMU notifiers for guest_memfd-only memslots
From: David Hildenbrand @ 2026-06-15 19:07 UTC (permalink / raw)
To: Alexandru Elisei, pbonzini, kvm, linux-kernel, maz, oupton,
suzuki.poulose, kvmarm, linux-arm-kernel, seanjc, mark.rutland
In-Reply-To: <20260615155244.183044-1-alexandru.elisei@arm.com>
On 6/15/26 17:52, Alexandru Elisei wrote:
> For guest_memfd-only memslots (kvm_memslot_is_gmem_only() is true), the
> memory provider for the virtual machine is the guest_memfd file, not the
> userspace mapping. Faults are resolved using the guest_memfd page cache,
> and the permissions for the secondary MMU mapping depends exclusively on
> the memslot (i.e, if the memslot is read-only). How userspace happens to
> have the memory mmaped at fault time, or even if the memory is mapped at
> all into userspace, is not taken into consideration.
>
> guest_memfd memory is not evictable, is not movable and there's no backing
> storage. Once memory is allocated for an offset in guest_memfd file, the
> offset will not change, and that memory is not freed unless userspace
> explicitly punches a hole in the file. As a result, memory reclaim, page
> migration, page aging and dirty page tracking for the userspace mapping
> serve little purpose.
I don't think any of that is relevant for the patch at hand?
The thing is: invalidation (truncation, later migration, for any other reason)
is driven through guest_memfd notifications, not through unrelated page tables.
If we don't lookup pages for the KVM MMU through the page table, then there is
also no need for MMU notifiers. It's all guest_memfd only.
Or am I missing something?
--
Cheers,
David
^ permalink raw reply
* [PATCH v1] bus: mvebu-mbus: Fix OF node reference leaks in DT init
From: Yuho Choi @ 2026-06-15 19:12 UTC (permalink / raw)
To: Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel, linux-kernel, Yuho Choi
mvebu_mbus_dt_init() gets the MBUS node with
of_find_matching_node_and_match() and the controller node with
of_find_node_by_phandle(). Both helpers return nodes with incremented
references, but the function returns without dropping either reference.
Route the error and success paths through common cleanup labels so both
local node references are released once they are no longer needed.
Fixes: 6839cfa82f99 ("bus: mvebu-mbus: Introduce device tree binding")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/bus/mvebu-mbus.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index dd94145c9b22..61301beeecdc 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -1265,23 +1265,27 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
prop = of_get_property(np, "controller", NULL);
if (!prop) {
pr_err("required 'controller' property missing\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto put_np;
}
controller = of_find_node_by_phandle(be32_to_cpup(prop));
if (!controller) {
pr_err("could not find an 'mbus-controller' node\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto put_np;
}
if (of_address_to_resource(controller, 0, &mbuswins_res)) {
pr_err("cannot get MBUS register address\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto put_controller;
}
if (of_address_to_resource(controller, 1, &sdramwins_res)) {
pr_err("cannot get SDRAM register address\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto put_controller;
}
/*
@@ -1312,9 +1316,15 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
resource_size(&mbusbridge_res),
is_coherent);
if (ret)
- return ret;
+ goto put_controller;
/* Setup statically declared windows in the DT */
- return mbus_dt_setup(&mbus_state, np);
+ ret = mbus_dt_setup(&mbus_state, np);
+
+put_controller:
+ of_node_put(controller);
+put_np:
+ of_node_put(np);
+ return ret;
}
#endif
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 3/3] PCI: rockchip: drive at 2.5 GT/s, error other speeds
From: Geraldo Nascimento @ 2026-06-15 19:30 UTC (permalink / raw)
To: Shawn Lin, Dragan Simic
Cc: linux-rockchip, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, linux-pci,
linux-arm-kernel, linux-kernel
In-Reply-To: <4ac5cd7d2271df375ed6307f5c394247721395d9.1781207474.git.geraldogabriel@gmail.com>
Hi,
On Thu, Jun 11, 2026 at 05:04:22PM -0300, Geraldo Nascimento wrote:
> Configure the core to be driven at 2.5 GT/s Link Speed and ignore
> any other speed with a warning. Also drop the 5.0 GT/s Link Speed
> defines from Rockchip PCIe header.
>
> The reason is that Shawn Lin from Rockchip has reiterated that there
> may be danger of "catastrophic failure" in using their PCIe with
> 5.0 GT/s speeds.
>
> While Rockchip has done so informally without issuing a proper errata,
> and the particulars are thus unknown, this may cause data loss or
> worse.
>
> This change is corroborated by RK3399 official datasheet [1], which
> states maximum link speed for this platform is 2.5 GT/s.
>
> [1] https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf
>
> Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
> Link: https://lore.kernel.org/all/ffd05070-9879-4468-94e3-b88968b4c21b@rock-chips.com/
> Cc: stable@vger.kernel.org
> Reported-by: Dragan Simic <dsimic@manjaro.org>
> Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
> Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
> ---
> drivers/pci/controller/pcie-rockchip.c | 16 +++++++++-------
> drivers/pci/controller/pcie-rockchip.h | 3 ---
> 2 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rockchip.c b/drivers/pci/controller/pcie-rockchip.c
> index 0f88da3788054..5a2876d7c8547 100644
> --- a/drivers/pci/controller/pcie-rockchip.c
> +++ b/drivers/pci/controller/pcie-rockchip.c
> @@ -66,8 +66,10 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
> }
>
> rockchip->link_gen = of_pci_get_max_link_speed(node);
> - if (rockchip->link_gen < 0 || rockchip->link_gen > 2)
> - rockchip->link_gen = 2;
> + if (rockchip->link_gen < 0 || rockchip->link_gen >= 2) {
> + rockchip->link_gen = 1;
> + dev_warn(dev, "invalid max-link-speed, limited to 2.5 GT/s\n");
> + }
>
> for (i = 0; i < ROCKCHIP_NUM_PM_RSTS; i++)
> rockchip->pm_rsts[i].id = rockchip_pci_pm_rsts[i];
> @@ -147,12 +149,12 @@ int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> goto err_exit_phy;
> }
>
> + /* 5.0 GT/s may cause catastrophic failure for this core */
> if (rockchip->link_gen == 2)
> - rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2,
Sashiko caught unreachable dead code rightfully here. It looks like I
had got it right in v4 and then the fix regressed.
Will address this for v7 after I get more comments.
Thanks,
Geraldo Nascimento
^ permalink raw reply
* Re: [PATCH v8 09/12] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops
From: Pranjal Shrivastava @ 2026-06-15 19:44 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Nicolin Chen, Daniel Mentz, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <ajBCazla1VoJX9Ms@google.com>
On Mon, Jun 15, 2026 at 06:20:27PM +0000, Mostafa Saleh wrote:
> On Mon, Jun 01, 2026 at 09:59:06PM +0000, Pranjal Shrivastava wrote:
> > Implement pm_runtime and system sleep ops for arm-smmu-v3.
> >
> > The suspend callback configures the SMMU to abort new transactions,
> > disables the main translation unit and then drains the command queue
> > to ensure completion of any in-flight commands. A software gate
> > (STOP_FLAG) and synchronization barriers are used to quiesce the command
> > submission pipeline and ensure state consistency before power-off.
> >
> > To prevent software metadata flags from leaking into physical registers
> > or polluting the tracking pointer, a newly introduced bitmask
> > (CMDQ_PROD_IDX_MASK) is applied to all register writes and tracking
> > updates.
> >
> > The resume callback restores the MSI configuration and performs a full
> > device reset via `arm_smmu_device_reset` to bring the SMMU back to an
> > operational state. The MSIs are cached during the msi_write and are
> > restored during the resume operation by using the helper. The STOP_FLAG
> > is cleared only after the CMDQ is enabled in hardware.
> >
> > Suggested-by: Daniel Mentz <danielmentz@google.com>
> > Signed-off-by: Pranjal Shrivastava <praan@google.com>
> > ---
> >
[...]
> > + /* Clear any flags from the previous life */
> > + atomic_andnot(CMDQ_PROD_STOP_FLAG, &smmu->cmdq.owner_prod);
> > + atomic_andnot(CMDQ_PROD_STOP_FLAG, &smmu->cmdq.q.llq.atomic.prod);
>
> Should not that be done from the suspend call?
I'm not sure if I understand? We're just clearing the flag here?
We set the flag in suspend to close the gate and clear it in resume
to re-open it. Clearing it at the end of suspend would be wrong as it
would allow new submissions while the SMMU is off..
Additionally, I'll remove the redundant operation on owner_prod (since
it's never set in owner_prod) if that's what you're saying?
>
> > +
> > /* Invalidate any cached configuration */
> > arm_smmu_cmdq_issue_cmd_with_sync(smmu, arm_smmu_make_cmd_cfgi_all());
> >
> > @@ -4898,6 +4939,21 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu)
> > if (is_kdump_kernel())
> > enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
> >
> > + /*
> > + * While the SMMU was suspended, concurrent CPU threads may have
> > + * updated in-memory structures (such as STEs, CDs, and PTEs).
> > + * Any invalidations corresponding to those updates were safely
> > + * elided because the command queue was stopped (STOP_FLAG == 1).
> > + *
> > + * Since the reset invalidate-all commands above have fully cleared
> > + * the HW TLBs and config caches, the SMMU will fetch these descriptors
> > + * directly from RAM as soon as translation is enabled.
> > + *
> > + * Add a memory barrier to collect all prior RAM writes to ensure the
> > + * SMMU sees a consistent view of memory before translation is enabled.
> > + */
> > + smp_mb();
>
> Should not that be dma_wmb() as this is syncing with the HW?
>
Right.. as discussed with Daniel on the other thread, the dma_wmb()
inside the issue_cmdlist() already ensures that PTE writes have reached
RAM. I'll update the comments to clarify the barrier design here.
The first CFGI_ALL invalidation we issue on resume uses the CMDQ's
standard submission path already includes the necessary dma_wmb().
This ensures that the hardware sees the correct state before we set
SMMUEN=1. I'll update the comment to clarify that we are relying on
this existing synchronization rather than adding a redundant barrier.
> > +
> > /* Enable the SMMU interface */
> > enables |= CR0_SMMUEN;
> > ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0,
> > @@ -5580,6 +5636,117 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
> > arm_smmu_device_disable(smmu);
> > }
> >
> > +static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
> > +{
> > + struct arm_smmu_device *smmu = dev_get_drvdata(dev);
> > + struct arm_smmu_cmdq *cmdq = &smmu->cmdq;
> > + int timeout = ARM_SMMU_SUSPEND_TIMEOUT_US;
> > + u32 enables, target;
> > + int ret;
> > +
> > + /* Abort all transactions before disable to avoid spurious bypass */
> > + arm_smmu_update_gbpa(smmu, GBPA_ABORT, 0);
> > +
> > + /* Disable the SMMU via CR0.EN and all queues except CMDQ */
> > + enables = CR0_CMDQEN;
> > + ret = arm_smmu_write_reg_sync(smmu, enables, ARM_SMMU_CR0, ARM_SMMU_CR0ACK);
> > + if (ret) {
> > + dev_err(smmu->dev, "failed to disable SMMU\n");
> > + return ret;
> > + }
> > +
> > + /*
> > + * At this point the SMMU is completely disabled and won't access
> > + * any translation/config structures, even speculative accesses
> > + * aren't performed as per the IHI0070 spec (section 6.3.9.6).
> > + */
> > +
> > + /* Mark the CMDQ to stop and get the target index before the stop */
> > + target = atomic_fetch_or_relaxed(CMDQ_PROD_STOP_FLAG, &cmdq->q.llq.atomic.prod);
>
> As Daniel mentioned, I think this shouldn't be relaxed.
>
Ack. I agree, I mis-read the kdoc about this, I'll fix it.
> > + target &= CMDQ_PROD_IDX_MASK;
> > +
> > +
> > + /* Wait for the last committed owner to reach the hardware */
> > + while ((arm_smmu_cmdq_owner_prod_idx(cmdq) != target) && --timeout)
> > + udelay(1);
>
> I think --timeout has an off-by-one.
>
Good catch, I'll fix this!
Thanks,
Praan
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Declare eats_s1chk and eats_trans as host-endian u64
From: Nicolin Chen @ 2026-06-15 19:45 UTC (permalink / raw)
To: Will Deacon
Cc: Robin Murphy, joro, Jason Gunthorpe, Shuai Xue, linux-arm-kernel,
iommu, linux-kernel
arm_smmu_get_ste_update_safe() declares the eats_s1chk and eats_trans
locals as __le64, but initializes them from FIELD_PREP(), which returns a
host-endian value, and passes them through cpu_to_le64() at the use sites.
Sparse reports the following warnings:
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1122:38: sparse: sparse: cast from restricted __le64
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1124:33: sparse: sparse: cast from restricted __le64
Declare both locals as u64 so the type matches FIELD_PREP() and the
existing cpu_to_le64() at the use sites performs the host-to-little-endian
conversion. No functional change.
Fixes: 7cad80048595 ("iommu/arm-smmu-v3: Mark EATS_TRANS safe when computing the update sequence")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/all/202606151017.QU0evpH9-lkp@intel.com/
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 8ce3e801eda3b..4c0f7b17b1f37 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1240,9 +1240,9 @@ VISIBLE_IF_KUNIT
void arm_smmu_get_ste_update_safe(const __le64 *cur, const __le64 *target,
__le64 *safe_bits)
{
- const __le64 eats_s1chk =
+ const u64 eats_s1chk =
FIELD_PREP(STRTAB_STE_1_EATS, STRTAB_STE_1_EATS_S1CHK);
- const __le64 eats_trans =
+ const u64 eats_trans =
FIELD_PREP(STRTAB_STE_1_EATS, STRTAB_STE_1_EATS_TRANS);
/*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/5] arm64: Rename page table BSS section to .bss..pgtbl
From: Frank Li @ 2026-06-15 20:09 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, catalin.marinas,
Ard Biesheuvel, Kevin Brodsky, Mark Brown, Marc Zyngier
In-Reply-To: <20260604151151.150377-8-ardb+git@google.com>
On Thu, Jun 04, 2026 at 05:11:53PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Rename the .pgdir.bss section to .bss..pgtbl so that the compiler will
> notice the leading ".bss" and mark it as NOBITS by default (rather than
> PROGBITS, which would take up space in Image binary, forcing all of the
> preceding BSS to be emitted into the image as well). This supersedes the
> NOLOAD linker directive, which achieves the same thing, and can be
> therefore be dropped.
>
> Also, rename .pgdir to .pgtbl to be more generic, as page tables of
> various levels will reside here.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
I met boot failure for i.MX8QXP by this patch
[ 0.823515] Unable to handle kernel paging request at virtual address ffff00000328f000
[ 0.831116] Mem abort info:
[ 0.833886] ESR = 0x0000000096000147
[ 0.837622] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.842923] SET = 0, FnV = 0
[ 0.845961] EA = 0, S1PTW = 0
[ 0.849088] FSC = 0x07: level 3 translation fault
[ 0.853952] Data abort info:
[ 0.856809] ISV = 0, ISS = 0x00000147, ISS2 = 0x00000000
[ 0.862296] CM = 1, WnR = 1, TnD = 0, TagAccess = 0
[ 0.867330] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.872633] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000008211f000
[ 0.879321] [ffff00000328f000] pgd=0000000000000000, p4d=18000008bffff403, pud=18000008bfffe403, pmd=18000008bffea403, pte=00e800008328ff06
[ 0.891834] Internal error: Oops: 0000000096000147 [#1] SMP
[ 0.897469] Modules linked in:
[ 0.900514] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.1.0-rc1-00016-g63e0b6a5b693 #834 PREEMPT
[ 0.909978] Hardware name: Freescale i.MX8QXP MEK (DT)
[ 0.915104] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.922053] pc : dcache_clean_inval_poc+0x24/0x48
[ 0.926742] lr : kvm_arm_init+0xa78/0x1638
[ 0.930828] sp : ffff80008318bd10
[ 0.934127] x29: ffff80008318bd50 x28: 0000000000000000 x27: ffff00000328f000
[ 0.941251] x26: 0000000000002000 x25: ffff80008219e000 x24: 0000000001002222
[ 0.948374] x23: 0000000000000030 x22: ffff800081e850c0 x21: ffff800082b790d0
[ 0.955498] x20: 0000000000000004 x19: ffff8000830a0000 x18: 0000000000000000
[ 0.962622] x17: ffff800082f938b8 x16: ffff800082b8b4e0 x15: ffff800082b8b4b8
[ 0.969746] x14: ffff80008308f0a0 x13: ffff800082b8b490 x12: ffff800082b8b530
[ 0.976869] x11: ffff800082b8b508 x10: ffff80008308f140 x9 : ffff80008308f118
[ 0.983993] x8 : ffff80008308f0f0 x7 : ffff80008308f0c8 x6 : ffff80008308f078
[ 0.991117] x5 : ffff80008308f050 x4 : ffff800082b8b468 x3 : 000000000000003f
[ 0.998240] x2 : 0000000000000040 x1 : ffff000003291000 x0 : ffff00000328f000
[ 1.005367] Call trace:
[ 1.007800] dcache_clean_inval_poc+0x24/0x48 (P)
[ 1.012490] do_one_initcall+0x80/0x1c8
[ 1.016310] kernel_init_freeable+0x208/0x2f0
[ 1.020654] kernel_init+0x24/0x1e0
[ 1.024131] ret_from_fork+0x10/0x20
[ 1.027700] Code: 9ac32042 d1000443 8a230000 d503201f (d50b7e20)
[ 1.033779] ---[ end trace 0000000000000000 ]---
[ 1.038428] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.046026] SMP: stopping secondary CPUs
[ 1.049943] Kernel Offset: disabled
[ 1.053408] CPU features: 0x00000000,00000008,00040021,0400421b
[ 1.059316] Memory Limit: none
[ 1.062359] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
Any idea?
Frank
> arch/arm64/include/asm/linkage.h | 2 ++
> arch/arm64/include/asm/mmu.h | 2 --
> arch/arm64/kernel/vmlinux.lds.S | 8 ++++----
> arch/arm64/mm/fixmap.c | 6 +++---
> arch/arm64/mm/kasan_init.c | 2 +-
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
> index 40bd17add539..8637f667667c 100644
> --- a/arch/arm64/include/asm/linkage.h
> +++ b/arch/arm64/include/asm/linkage.h
> @@ -43,4 +43,6 @@
> SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_A_ALIGN) \
> bti c ;
>
> +#define __bss_pgtbl __section(".bss..pgtbl") __aligned(PAGE_SIZE)
> +
> #endif
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index fb95754f2876..5e1211c540ab 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -13,8 +13,6 @@
>
> #ifndef __ASSEMBLER__
>
> -#define __pgtbl_bss __section(".pgdir.bss") __aligned(PAGE_SIZE)
> -
> #include <linux/refcount.h>
> #include <asm/cpufeature.h>
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 2b0ebfb30c63..d3ed59abab38 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -352,11 +352,11 @@ SECTIONS
> BSS_SECTION(SBSS_ALIGN, 0, PAGE_SIZE)
> __pi___bss_start = __bss_start;
>
> - /* fixmap BSS starts here - preceding data/BSS is omitted from the linear map */
> - .pgdir.bss (NOLOAD) : ALIGN(PAGE_SIZE) {
> - *(.pgdir.bss)
> + /* page table BSS starts here - preceding data/BSS is omitted from the linear map */
> + .pgtbl : ALIGN(PAGE_SIZE) {
> + *(.bss..pgtbl)
> }
> - ASSERT(ADDR(.pgdir.bss) == __bss_stop, ".pgdir.bss must follow BSS")
> + ASSERT(ADDR(.pgtbl) == __bss_stop, ".pgtbl must follow BSS")
>
> . = ALIGN(PAGE_SIZE);
> __pi_init_pg_dir = .;
> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
> index 1a3bbd67dd76..f66a0016dd02 100644
> --- a/arch/arm64/mm/fixmap.c
> +++ b/arch/arm64/mm/fixmap.c
> @@ -31,9 +31,9 @@ static_assert(NR_BM_PMD_TABLES == 1);
>
> #define BM_PTE_TABLE_IDX(addr) __BM_TABLE_IDX(addr, PMD_SHIFT)
>
> -static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __pgtbl_bss;
> -static pmd_t bm_pmd[PTRS_PER_PMD] __pgtbl_bss __maybe_unused;
> -static pud_t bm_pud[PTRS_PER_PUD] __pgtbl_bss __maybe_unused;
> +static pte_t bm_pte[NR_BM_PTE_TABLES][PTRS_PER_PTE] __bss_pgtbl;
> +static pmd_t bm_pmd[PTRS_PER_PMD] __bss_pgtbl __maybe_unused;
> +static pud_t bm_pud[PTRS_PER_PUD] __bss_pgtbl __maybe_unused;
>
> static inline pte_t *fixmap_pte(unsigned long addr)
> {
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index dbf22cae82ee..3fcad956fdf7 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -214,7 +214,7 @@ asmlinkage void __init kasan_early_init(void)
> * shadow pud_t[]/p4d_t[], which could end up getting corrupted
> * when the linear region is mapped.
> */
> - static pte_t tbl[PTRS_PER_PTE] __pgtbl_bss;
> + static pte_t tbl[PTRS_PER_PTE] __bss_pgtbl;
> pgd_t *pgdp = pgd_offset_k(KASAN_SHADOW_START);
>
> set_pgd(pgdp, __pgd(__pa_symbol(tbl) | PGD_TYPE_TABLE));
> --
> 2.54.0.1032.g2f8565e1d1-goog
>
^ permalink raw reply
* Re: [PATCH v1 4/4] iommu/arm-smmu-v3: Process vIOMMU invalidations in batches
From: Nicolin Chen @ 2026-06-15 20:19 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Kevin Tian, Robin Murphy, Joerg Roedel, Shuah Khan,
Pranjal Shrivastava, Kees Cook, Yi Liu, Eric Auger,
linux-arm-kernel, iommu, linux-kernel, linux-kselftest
In-Reply-To: <20260615134301.GL1962447@nvidia.com>
On Mon, Jun 15, 2026 at 10:43:01AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 12, 2026 at 12:11:10PM -0700, Nicolin Chen wrote:
>
> > VMM would have to know which command failed, to flag it in the CONS
> > register, indicating: a) commands prior to the CONS are issued, and
> > b) command pointed by the CONS is illegal.
>
> It is a VMM bug to send a malformed command into the kernel in the
> first place.
OK. I will follow that.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Vincent Mailhol @ 2026-06-15 20:33 UTC (permalink / raw)
To: Al Viro
Cc: Jens Axboe, Davidlohr Bueso, Christian Brauner, Jan Kara,
linux-kernel, linux-block, linux-efi, linux-fsdevel,
Richard Henderson, Matt Turner, Magnus Lindholm, linux-alpha,
Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui, loongarch,
Thomas Bogendoerfer, linux-mips, James E.J. Bottomley,
Helge Deller, linux-parisc, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-riscv, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
linux-s390, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615170432.GW2636677@ZenIV>
On 15/06/2026 at 19:04, Al Viro wrote:
> On Mon, Jun 15, 2026 at 06:08:56PM +0200, Vincent Mailhol wrote:
>
>> Tested with GRUB, which implements the LoaderDevicePartUUID EFI variable
>> in its bli module [3]. With this, I was able to boot a kernel with a
>> completely empty cmdline and no initrd.
>>
>> [1] The Discoverable Partitions Specification (DPS)
>> Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
>>
>> [2] systemd-gpt-auto-generator
>> Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
>>
>> [3] GRUB -- §16.2 bli
>> Link: https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
>
> So what does that thing, tied to EFI as it is, have to do with architectures where
> * firmware is rather unlike EFI
I made CONFIG_DPS_ROOT_AUTO_DISCOVERY depend on CONFIG_EFI for this reason.
> * firmware wouldn't know what to do with GPT
> * GRUB is *not* ported to, let alone used
> such as, say it, the very first one mentioned at your [1]?
Fair point. I just did:
$ git grep "^config EFI$"
arch/arm/Kconfig:config EFI
arch/arm64/Kconfig:config EFI
arch/loongarch/Kconfig:config EFI
arch/riscv/Kconfig:config EFI
arch/x86/Kconfig:config EFI
Anything not in this list is dead code at the moment.
> Or is that conditional upon "if anyone wants to design replacement firmware
> for those, and if they agree to follow our wishlist"?
No, it was just an oversight from my side. I will just keep arm, arm64,
loongarch, riscv and x86 in my v2.
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
From: Jakub Kicinski @ 2026-06-15 20:56 UTC (permalink / raw)
To: Parvathi Pudi
Cc: andrew+netdev, davem, edumazet, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260611123636.376577-4-parvathi@couthit.com>
On Thu, 11 Jun 2026 18:03:28 +0530 Parvathi Pudi wrote:
> From: Roger Quadros <rogerq@ti.com>
>
> In HSR and PRP modes each outgoing frame must be sent on both PRU slave
> ports.
>
> Previously the driver was writing the frame into each port's transmit queue
> independently after updating the tags resulting in performing two OCMC
> buffer copy operations.
>
> Frame duplicate offloading is implemented with a common shared queue
> between the two ports. The driver writes the frame once into OCMC RAM,
> each port reads from the shared queue and replicates the transmission to
> both PRU ports, synchronising between PRU ports are maintained within
> firmware with appropriate handling.
>
> For HSR the driver inspects the encapsulated ethertype in the HSR tag.
> PTP frames (ETH_P_1588) are sent on the directed port only to avoid double
> duplication and all other HSR frames are duplicated to both ports.
> VLAN-tagged HSR frames are handled by advancing past the 4-byte VLAN header
> before reading the HSR tag.
>
> For PRP the driver checks the 6-byte RCT trailer for the ETH_P_PRP suffix
> to identify redundancy-tagged frames. Frames without an RCT are sent on the
> originating port only.
Warning: drivers/net/ethernet/ti/icssm/icssm_prueth.h:113 struct member 'host_recv_flag' not described in 'prueth_packet_info'
Please note that net-next will be closed for the next two weeks.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v9 4/9] dt-bindings: display: imx: Add i.MX94 DCIF
From: Rob Herring (Arm) @ 2026-06-15 21:04 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Conor Dooley, Simona Vetter, Fabio Estevam, David Airlie,
Luca Ceresoli, linux-arm-kernel, dri-devel, imx, linux-kernel,
Krzysztof Kozlowski, Maxime Ripard, Maarten Lankhorst,
Thomas Zimmermann, Pengutronix Kernel Team, devicetree, Frank Li,
Philipp Zabel, linux-clk, Sascha Hauer, Ying Liu
In-Reply-To: <20260612-dcif-upstreaming-v9-4-8d0ff89aa3c5@oss.nxp.com>
On Fri, 12 Jun 2026 14:58:35 +0300, Laurentiu Palcu wrote:
> DCIF is the i.MX94 Display Controller Interface which is used to
> drive a TFT LCD panel or connects to a display interface depending
> on the chip configuration.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/display/imx/nxp,imx94-dcif.yaml | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: correcting section tags for .init and .exit data/functions
From: Rong Xu @ 2026-06-15 21:26 UTC (permalink / raw)
To: Nathan Chancellor
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Neal Cardwell, Kuniyuki Iwashima, Willem de Bruijn,
David Ahern, Ido Schimmel, Andreas Färber,
Manivannan Sadhasivam, Nick Desaulniers, Bill Wendling,
Justin Stitt, Maciej Żenczykowski, Yue Haibing, Jeff Layton,
Kees Cook, Fernando Fernandez Mancera, Gustavo A. R. Silva,
Sabrina Dubroca, Masahiro Yamada, Nicolas Schier, netdev,
linux-kernel, linux-arm-kernel, linux-actions, llvm,
kernel test robot
In-Reply-To: <20260613170143.GB3152432@ax162>
After studying the warnings further, I believe this is an incorrect fix.
Normally, *_net_ops structures are intended to live in .data (permanent memory),
even though they point to .init.text. Modpost is handling this by using
hardcoded whitelists to allow these specific exceptions. However, this
whitelist is
failing in ThinLTO because ThinLTO renames *_net_ops to *_net_ops.llvm.*.
I am withdrawing this patch and will send a fix to modpost instead.
Thanks,
-Rong
^ permalink raw reply
* Re: [PATCH v8 00/10] clk: realtek: Add RTD1625 clock support
From: Brian Masney @ 2026-06-15 21:28 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou, devicetree, linux-clk, linux-kernel,
linux-arm-kernel, linux-realtek-soc, james.tai, cy.huang,
stanley_chang
In-Reply-To: <20260610080824.255063-1-eleanor.lin@realtek.com>
Hi Yu-Chun,
On Wed, Jun 10, 2026 at 04:08:14PM +0800, Yu-Chun Lin wrote:
> Hello,
>
> This patch series adds clock support for Realtek's RTD1625 platform.
> The series includes:
> 1. Device Tree: Add clock controller nodes.
> 2. Infrastructure: reset controller, basic clocks, PLLs, gate clocks, mux
> clocks, and MMC-tuned PLLs.
> 3. Platform drivers: two clock controller drivers for RTD1625-CRT and
> RTD1625-ISO.
>
> Best regards,
> Yu-Chun Lin
Sashiko has some legitimate feedback about this patch set:
https://sashiko.dev/#/patchset/20260610080824.255063-1-eleanor.lin%40realtek.com
Can you go through that and post a new version? I'll review the next
version manually in more detail.
Brian
^ permalink raw reply
* Re: [PATCH v5 net-next 0/9] net: dsa: netc: add bridge mode support
From: patchwork-bot+netdevbpf @ 2026-06-15 21:50 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, chleroy, andrew, olteanv, linux,
wei.fang, imx, netdev, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20260611021458.2629145-1-wei.fang@oss.nxp.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 11 Jun 2026 10:14:49 +0800 you wrote:
> From: Wei Fang <wei.fang@nxp.com>
>
> This series adds bridge mode support to the NETC DSA switch driver,
> covering both VLAN-aware and VLAN-unaware operation.
>
> The NETC switch manages forwarding through a set of hardware tables
> accessed via NTMP: the FDB table (FDBT), VLAN filter table (VFT), egress
> treatment table (ETT), and egress count table (ECT). The series extends
> the NTMP layer with the operations required for bridging, then builds the
> DSA bridge callbacks on top.
>
> [...]
Here is the summary with links:
- [v5,net-next,1/9] net: enetc: add interfaces to manage dynamic FDB entries
https://git.kernel.org/netdev/net-next/c/ca394837dfdd
- [v5,net-next,2/9] net: enetc: add "Update" and "Delete" operations to VLAN filter table
https://git.kernel.org/netdev/net-next/c/c52b6702a948
- [v5,net-next,3/9] net: enetc: add interfaces to manage egress treatment table
https://git.kernel.org/netdev/net-next/c/3cc291a35939
- [v5,net-next,4/9] net: enetc: add "Update" operation to the egress count table
https://git.kernel.org/netdev/net-next/c/d51f238a154a
- [v5,net-next,5/9] net: dsa: netc: initialize the group bitmap of ETT and ECT
https://git.kernel.org/netdev/net-next/c/1a58ae73dd74
- [v5,net-next,6/9] net: enetc: add helpers to set/clear table bitmap
https://git.kernel.org/netdev/net-next/c/8469b17310d1
- [v5,net-next,7/9] net: dsa: netc: add VLAN filter table and egress treatment management
https://git.kernel.org/netdev/net-next/c/84b4a3b30abd
- [v5,net-next,8/9] net: dsa: netc: add bridge mode support
https://git.kernel.org/netdev/net-next/c/751aa5a5d593
- [v5,net-next,9/9] net: dsa: netc: implement dynamic FDB entry ageing
https://git.kernel.org/netdev/net-next/c/05b5ee610fbb
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 v4 06/31] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Rob Herring (Arm) @ 2026-06-15 22:14 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-doc, Conor Dooley, puranjay, usama.arif, philip.radford,
devicetree, souvik.chakravarty, linux-kernel, jic23, elif.topuz,
lukasz.luba, sudeep.holla, leitao, vincent.guittot, james.quinlan,
kernel-team, linux-arm-kernel, kas, arm-scmi, peng.fan,
linux-fsdevel, michal.simek, brauner, etienne.carriere, d-gole,
Krzysztof Kozlowski, f.fainelli
In-Reply-To: <20260612223802.1337232-7-cristian.marussi@arm.com>
On Fri, 12 Jun 2026 23:37:36 +0100, Cristian Marussi wrote:
> Add new SCMI v4.0 Telemetry protocol bindings definitions.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v3 --> v4
> - changed protocol number to lowercase 1b
> - fixed misplaced block for protocol 0x1b
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> ---
> Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: Fix skb->priority underflow in
From: Joe Damato @ 2026-06-15 22:34 UTC (permalink / raw)
To: Wayen Yan; +Cc: netdev, lorenzo, horms, linux-arm-kernel, linux-mediatek
In-Reply-To: <6a2ff493.5934d26d.389ef4.d16d@mx.google.com>
On Mon, Jun 15, 2026 at 08:48:13PM +0800, Wayen Yan wrote:
> From b894fc031e307f1b6756ea9fcac98e82e23815e1 Mon Sep 17 00:00:00 2001
> From: "Wayen.Yan" <win847@gmail.com>
> Date: Sun, 14 Jun 2026 07:30:54 +0800
> Subject: [PATCH net v2] net: airoha: Fix skb->priority underflow in
> airoha_dev_select_queue()
>
> In airoha_dev_select_queue(), the expression:
>
> queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES;
>
> implicitly converts to unsigned arithmetic: when skb->priority is 0
> (the default for unclassified traffic), (0u - 1u) wraps to UINT_MAX,
> and UINT_MAX % 8 = 7, routing default best-effort packets to the
> highest-priority QoS queue. This causes QoS inversion where the
> majority of traffic on a PON gateway starves actual high-priority
> flows (VoIP, gaming, etc.).
>
> Fix by guarding the subtraction: when priority is 0, map to queue 0
> (lowest priority), otherwise apply the original (priority - 1) % 8
> mapping.
>
> Fixes: 2b288b81560b ("net: airoha: Introduce ndo_select_queue callback")
> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Signed-off-by: Wayen <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hm, I tried to apply this patch to my tree just to see what would happen with
the duplicated SMTP headers and it looks like they just get added to the
commit message.
I think you might need to re-send it (but you'll have to wait 24 hours between
re-sends).
The code looks fine to me, though, so feel free to include my tag:
Reviewed-by: Joe Damato <joe@dama.to>
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix always-true condition in PPE1 queue reservation loop
From: patchwork-bot+netdevbpf @ 2026-06-15 22:50 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca3de.ad59c0a6.147df9.2ac1@mx.google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 13 Jun 2026 08:23:12 +0800 you wrote:
> In airoha_fe_pse_ports_init(), the inner condition for PPE1 queue
> reservation is identical to the for-loop bound, making it always true
> and the else branch dead code:
>
> for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_PPE1]; q++) {
> if (q < pse_port_num_queues[FE_PSE_PORT_PPE1]) /* always true */
> set RSV_PAGES;
> else
> set 0; /* unreachable */
> }
>
> [...]
Here is the summary with links:
- net: airoha: Fix always-true condition in PPE1 queue reservation loop
https://git.kernel.org/netdev/net/c/c66f8511a810
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinephone Pro"
From: Oren Klopfer @ 2026-06-15 22:50 UTC (permalink / raw)
To: oklopfer37
Cc: linux-arm-kernel, linux-rockchip, linux-kernel, Heiko Stuebner,
Peter Robinson, Thorsten Leemhuis, stable
This reverts commit 096bd8c679185f898cae9933c6a68650fa26ea4f.
Just as with the Pinebook Pro, there are multiple chipset variants for the Pinephone Pro, and multiple firmware binaries for different distributions. The change causes issues with some of these combinations, and reverting it resolves the issues. See the Closes below for the full report.
Similarly with the Pinebook Pro adjustment, the original commit only indicates "further description" and not indicative of fixing any existing issues, so reverting should not kick any back up.
Fixes: 096bd8c67918 ("arm64: dts: rockchip: Further describe the WiFi for the Pinephone Pro")
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/r/20260607225901.64019-1-oklopfer37@gmail.com/
Signed-off-by: Oren Klopfer <oklopfer37@gmail.com>
---
.../boot/dts/rockchip/rk3399-pinephone-pro.dts | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
index 8d26bd9b7500..d46cdfe3f784 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
@@ -734,12 +734,6 @@ light_int_l: light-int-l {
};
};
- wifi {
- wifi_host_wake_l: wifi-host-wake-l {
- rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
wireless-bluetooth {
bt_wake_pin: bt-wake-pin {
rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
@@ -766,19 +760,7 @@ &sdio0 {
pinctrl-names = "default";
pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
sd-uhs-sdr104;
- #address-cells = <1>;
- #size-cells = <0>;
status = "okay";
-
- brcmf: wifi@1 {
- compatible = "brcm,bcm4329-fmac";
- reg = <1>;
- interrupt-parent = <&gpio4>;
- interrupts = <RK_PD0 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "host-wake";
- pinctrl-names = "default";
- pinctrl-0 = <&wifi_host_wake_l>;
- };
};
&pwm0 {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] net: airoha: Fix typos in comments and Kconfig
From: patchwork-bot+netdevbpf @ 2026-06-15 22:50 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca74a.c5b1db4e.21a698.01e7@mx.google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 13 Jun 2026 08:41:16 +0800 you wrote:
> Fix several typos found during code review:
> - Kconfig: "Aiorha" -> "Airoha" in NET_AIROHA_FLOW_STATS help text
> - Comment: "CMD1" -> "CDM1" (Central DMA, not Command)
> - Comments: "GMD1/2/3/4" -> "GDM1/2/3/4" (Gigabit DMA, not GMD)
>
> These are pure comment and documentation fixes with no functional impact.
>
> [...]
Here is the summary with links:
- net: airoha: Fix typos in comments and Kconfig
https://git.kernel.org/netdev/net-next/c/a061dfb063fa
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] net: airoha: Fix non-standard return value in airoha_ppe_get_wdma_info()
From: patchwork-bot+netdevbpf @ 2026-06-15 22:50 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ca3d9.ad59c0a6.147df9.2a62@mx.google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 13 Jun 2026 08:22:31 +0800 you wrote:
> airoha_ppe_get_wdma_info() returns -1 when the last path in the
> forwarding path stack is not of type DEV_PATH_MTK_WDMA. This is not
> a standard kernel error code. Replace it with -EINVAL since the
> input path type is invalid from the caller's perspective.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
>
> [...]
Here is the summary with links:
- net: airoha: Fix non-standard return value in airoha_ppe_get_wdma_info()
https://git.kernel.org/netdev/net-next/c/05173fa30add
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2] media: mt2063: correct CONFIG_MEDIA_TUNER_MT2063 macro name in comment
From: Ethan Nelson-Moore @ 2026-06-15 22:53 UTC (permalink / raw)
To: GitAuthor: Ethan Nelson-Moore, linux-media, linux-arm-kernel,
linux-mediatek
Cc: Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno
A comment in drivers/media/tuners/mt2063.h incorrectly refers to
CONFIG_DVB_MT2063 instead of CONFIG_MEDIA_TUNER_MT2063. Correct it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Changes in v2: Use correct media: commit message prefix
drivers/media/tuners/mt2063.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/tuners/mt2063.h b/drivers/media/tuners/mt2063.h
index 30d03cd76061..6c4b6c68ec25 100644
--- a/drivers/media/tuners/mt2063.h
+++ b/drivers/media/tuners/mt2063.h
@@ -24,6 +24,6 @@ static inline struct dvb_frontend *mt2063_attach(struct dvb_frontend *fe,
return NULL;
}
-#endif /* CONFIG_DVB_MT2063 */
+#endif /* IS_REACHABLE(CONFIG_MEDIA_TUNER_MT2063) */
#endif /* __MT2063_H__ */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar @ 2026-06-15 22:52 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Roman Vivchar via B4 Relay, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Lee Jones,
linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale
In-Reply-To: <20260614182214.65d052e4@jic23-huawei>
Hi Jonathan,
On Sunday, June 14th, 2026 at 8:22 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On Tue, 09 Jun 2026 16:31:59 +0300
> Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
...
> > +
> > +#define MTK_PMIC_IIO_CHAN(_name, _chan, _addr) \
> > +{ \
> > + .type = IIO_VOLTAGE, \
> > + .indexed = 1, \
> > + .channel = _chan, \
> > + .address = _addr, \
> > + .datasheet_name = __stringify(_name), \
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> > + BIT(IIO_CHAN_INFO_SCALE), \
> > +}
> > +
> > +static const struct iio_chan_spec mt6323_auxadc_channels[] = {
> > + MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, MT6323_AUXADC_ADC6),
> > + MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, MT6323_AUXADC_ADC11),
> > + MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, MT6323_AUXADC_ADC5),
>
> Reasonable query from Sashiko on why temperature channels are presented as voltages.
> If for some reason that is the right choice, then maybe a comment here.
mt6323 ADC always returns voltage. The thermal driver (which was in the
previous series and will be sent later) is required to map these to the
actual temperature. Ack.
...
> > +/*
> > + * The MediaTek MT6323 (as well as a lot of other PMICs) has the following hierarchy:
> > + * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
> > + *
> > + * Therefore, PWRAP regmap should be obtained using dev->parent->parent.
> > + */
> > +struct mt6323_auxadc {
> > + struct regmap *regmap;
> > + struct mutex lock;
> Locks should always have a comment on what data they are protecting.
> I think this one is about protecting the state of a device during a channel read
> by serializing those reads.
Nuno said kerneldoc looks unnecessary on v1 [1]. How the comment should
look?
...
> > +static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
> > + unsigned long channel)
> > +{
> > + struct regmap *map = auxadc->regmap;
> > + int ret;
> > +
> > + ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
> > + if (ret)
> > + return ret;
> > +
> > + return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
>
> I'm not sure whether the sashiko question on this is valid or not. Make sure to take
> a look.
>
> https://sashiko.dev/#/patchset/20260609-mt6323-adc-v2-0-aa93a22309f9%40protonmail.com
> You may have carefully selected the numbering so the channel numbering matches
> the bits in this register. If so, it is probably worth a comment in the header
> to provide a cross reference. No idea if Sashiko will notice that, but at least
> humans should!
The hardware is pretty weird, but dt-bindings have correct numbers.
I have double checked with the vendor driver and the logic is the same.
'If regmap_set_bits() fails to set MT6323_AUXADC_CON22, does this leave the
AUXADC voltage buffer (VBUF) permanently enabled?' - if this happens,
then there's something really wrong with PWRAP and disabling VBUF may
not be possible. Same about the 'mt6323_auxadc_release' comment.
...
> > + case IIO_CHAN_INFO_RAW:
>
> What Andy suggested here is the preferred path in IIO at least.
> Mainly because it reduced indent without hurting readability.
> Just be careful to define the scope with { }
Ack.
>
>
> > + scoped_guard(mutex, &auxadc->lock) {
> > + ret = mt6323_auxadc_prepare_channel(auxadc);
> > + if (ret)
> > + return ret;
> > +
> > + ret = mt6323_auxadc_request(auxadc, chan->channel);
> > + if (ret)
> > + return ret;
> > +
> > + /* Hardware limitation: the AUXADC needs a delay to become ready. */
> > + fsleep(300);
> > +
> > + ret = mt6323_auxadc_read(auxadc, chan, val);
> > +
> > + if (mt6323_auxadc_release(auxadc, chan->channel))
> > + dev_err(&indio_dev->dev,
> > + "failed to release channel %d\n", chan->channel);
> > +
> > + if (ret)
> > + return ret;
> > + }
> > + return IIO_VAL_INT;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
>
>
After these changes, should I keep or drop Andy's Reviewed-by?
[1]: https://lore.kernel.org/linux-iio/2df4cad5e29fbcb4c5c5f59ea0bf322c7a301bdc.camel@gmail.com/
Best regards,
Roman
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix MODULE_LICENSE to match SPDX GPL-2.0-only identifier
From: patchwork-bot+netdevbpf @ 2026-06-15 23:00 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <6a2ded59.63d39acb.391892.7632@mx.google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 14 Jun 2026 07:52:39 +0800 you wrote:
> Both airoha_eth.c and airoha_npu.c declare SPDX-License-Identifier:
> GPL-2.0-only but use MODULE_LICENSE("GPL"), which the kernel module
> loader interprets as GPL-2.0+ (any GPL version). This mismatch causes
> license compliance tools (FOSSology, ScanCode, etc.) to misidentify
> the effective license as more permissive than intended.
>
> Replace MODULE_LICENSE("GPL") with MODULE_LICENSE("GPL v2") to
> align with the GPL-2.0-only SPDX identifier. Per include/linux/module.h,
> "GPL v2" maps to GPL-2.0-only, matching the source files' declared
> license.
>
> [...]
Here is the summary with links:
- net: airoha: Fix MODULE_LICENSE to match SPDX GPL-2.0-only identifier
https://git.kernel.org/netdev/net-next/c/b0d62ed16424
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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