* Re: [PATCH] irqchip/gic-v3-its: Reconfigure ITS from software state on resume
From: Thomas Gleixner @ 2026-07-02 15:13 UTC (permalink / raw)
To: Bjoern Doebel, stable, Marc Zyngier, linux-arm-kernel,
linux-kernel, David Woodhouse, Ali Saidi, David Arinzon,
Zeev Zilberman
Cc: Bjoern Doebel
In-Reply-To: <akZPM6SeJiM8th0N@amazon.de>
On Thu, Jul 02 2026 at 11:57, Bjoern Doebel wrote:
> Hi all,
>
> gentle ping on this one.
Marc?
> Since the original posting I've re-validated the fix against current
> mainline:
>
> - It still applies cleanly to v7.2-rc1 (and to v7.1.0).
>
> - I reproduced the original failure on *stock* v7.2-rc1. On EC2
> Graviton instances, hibernation resume fails 100% of the time: the
> ITS comes back reset, MAPD/MAPTI are never replayed, and the ENA
> NIC silently loses its LPIs:
>
> ena 0000:00:05.0: ... didn't receive a MSI-X interrupt (cmd 3)
> ena 0000:00:05.0: Failed to create IO CQ. error: -62
>
> The instance then has no networking after resume.
>
> - With this patch applied, the same kernel survives hibernate/resume
> cleanly: 9/9 cycles with zero failures, across all three Graviton
> generations (Graviton 2/3/4, i.e. Neoverse N1/V1/V2), networking
> fully restored on every resume.
>
> As described in the previous message, this is the fallout from 713335b6ee29
> ("irqchip/gic-v3-its: Implement .msi_teardown() callback"): device
> teardown no longer happens across a suspend/resume that keeps the MSI
> domain, so the ITS is never reprogrammed and drops interrupts after the
> hardware has been reset.
>
> Could you take a look when you get a chance?
>
> Thanks,
> Bjoern
>
>
>
>
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597
^ permalink raw reply
* Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable
From: Leonardo Bras @ 2026-07-02 15:13 UTC (permalink / raw)
To: Bradley Morgan
Cc: Leonardo Bras, Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, Quentin Perret, Vincent Donnefort, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <6495D546-8FC7-4A31-B18C-88F34E1B64BB@grrlz.net>
On Thu, Jul 02, 2026 at 03:52:14PM +0100, Bradley Morgan wrote:
> On July 2, 2026 12:18:58 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
> wrote:
> >On Thu, Jul 02, 2026 at 09:59:23AM +0100, Marc Zyngier wrote:
> >> + Vincent, Leo
> >>
> >> On Wed, 01 Jul 2026 20:24:28 +0100,
> >> Bradley Morgan <include@grrlz.net> wrote:
> >> >
> >> > pKVM keeps its own mapping list for stage 2 operations. Its flush path
> >> > uses that list directly, so it lost the PTE attribute check done by
> >the
> >> > generic stage 2 walker.
> >> >
> >> > Record whether a mapping is cacheable and skip cache maintenance for
> >> > mappings that are not cacheable.
> >> >
> >> > Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> >> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> >> > ---
> >> > Changes since V3:
> >> > - addressed some review :)
> >>
> >> This isn't a change log. If you want to be taken seriously, I'd
> >> suggest you start by following the process. You are otherwise wasting
> >> people's time. Again.
> >
> >Agree... the process has a reason: the changelog here helps the reviewer
> >having an overview of what actually changed between versions, and that
> >makes reviewing much easier, and costs very little to the contributor.
> >
> >Also, the 1 week waiting time is really important, as mentioned before, as
> >it allows more reviewers and maintainers to give feedback: different
> >people, from different companies and lifestyles have different schedules
> >for dev/rev, but in general it happens weekly. So waiting for a week is
> >really recommended, as it tends to avoid people re-reading 2+ versions of
> >the same patchset, and allows revs time to discuss the suggestions in the
> >same thread.
> >
> >(I know the waiting can be really frustating, and that sending a vN+1 fast
> >seems to show that you are interested in it, but it really does not help)
>
> Well, it's fair, let me give you reasoning on why I do quick Rerolls.
>
> So, if I do something wrong, e.g: checkpatch, I don't want to wait a week,
> because I would get grilled for a said checkpatch failure.
>
Fair, but people would not avoid reviewing your new version due to a
checkpath/etc issue. It's common to just report/ignore that and go on with
the code that matters.
Also, checkpath is a good example of what you can run in your code before
sending, so it does not become a respin.
>
> In this case, I was just excited /shrug.
It's okay. Been there as well :)
> >>
> >> You also failed to Cc people who have provided feedback on previous
> >> versions. That's not right.
> >
> >(Bradley: usually you want as many people as possible to review your
> >stuff,
> >so CC'ing previous reviewers is actually good for you)
>
> Vincent not being CCed was dumb of me, no idea how I didn't get him on get
> maintainers.
>
> For you, I didn't want to annoy you with another patch, since maintainers
> tend to be stressed and annoyed. And I didn't wanna add on to the pain.
>
Don't worry on this. Previous reviewers can just ignore the e-mail if
they don't find it interesting anymore.
> >>
> >> >
> >> > arch/arm64/kvm/pkvm.c | 51
> >++++++++++++++++++++++++++++++++++---------
> >> > 1 file changed, 41 insertions(+), 10 deletions(-)
> >> >
> >> > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> >> > index 053e4f733e4b..6d1cad890c7e 100644
> >> > --- a/arch/arm64/kvm/pkvm.c
> >> > +++ b/arch/arm64/kvm/pkvm.c
> >> > @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct
> >pkvm_mapping *m)
> >> > return m->gfn * PAGE_SIZE;
> >> > }
> >> >
> >> > +#define PKVM_MAPPING_NR_PAGES_MASK GENMASK_ULL(47, 0)
> >> > +#define PKVM_MAPPING_NC BIT_ULL(48)
> >> > +
> >> > +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
> >> > +{
> >> > + return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> >> > +}
> >>
> >> No. You've been pointed to the correct data structure (an anonymous
> >> structure containing bit fields). Please consider taking the review
> >> comments into account.
> >
> >(and if you do not agree with the suggestion, discuss it in the same
> >thread. Although as Marc shows below, it becames much simpler like that)
> >
> >Thanks!
> >Leo
> >
>
> I'll test it. If it's good. I'll do
>
> Suggested-by? Or co-developed by?
I would say none. It's just a change suggestion to your patch, made by a
reviewer.
IIRC 'Suggested-by' is used if someone suggested the idea for the patch,
such as "ah, you should do this thing before", etc. It's both for giving
credit and showing people the idea for that was not yours, for multiple
reasons.
>
> I'll hold the patch on for a week.
>
Good!
If you get too excited, I suggest reading other people's patches. Everybody
makes mistakes, and the solutions / suggestions are really interesting :)
>
> Thanks you lot for taking my bull crap.
>
It's not bad, the process just goes like that for everybody.
It's just slower than people expect :)
We get slightly better over time, but still make mistakes.
(And try our best not to make the same mistakes again :)
Thanks for contributing!
Leo
> >>
> >> This would avoid most of the churn in this patch, and make it easy to
> >> backport. Something like the untested hack below.
> >>
> >> M.
> >>
> >> diff --git a/arch/arm64/include/asm/kvm_pkvm.h
> >b/arch/arm64/include/asm/kvm_pkvm.h
> >> index 74fedd9c5ff02..cdddc9e3a11f5 100644
> >> --- a/arch/arm64/include/asm/kvm_pkvm.h
> >> +++ b/arch/arm64/include/asm/kvm_pkvm.h
> >> @@ -195,7 +195,10 @@ struct pkvm_mapping {
> >> struct rb_node node;
> >> u64 gfn;
> >> u64 pfn;
> >> - u64 nr_pages;
> >> + struct {
> >> + unsigned long nr_pages:48;
> >> + unsigned int nc:1;
> >> + };
> >> u64 __subtree_last; /* Internal member for interval tree */
> >> };
> >>
> >> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> >> index 428723b1b0f5c..5932b93bded58 100644
> >> --- a/arch/arm64/kvm/pkvm.c
> >> +++ b/arch/arm64/kvm/pkvm.c
> >> @@ -369,7 +369,7 @@ static int __pkvm_pgtable_stage2_unshare(struct
> >kvm_pgtable *pgt, u64 start, u64
> >>
> >> for_each_mapping_in_range_safe(pgt, start, end, mapping) {
> >> ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
> >> - mapping->nr_pages);
> >> + (u64)mapping->nr_pages);
> >> if (WARN_ON(ret))
> >> return ret;
> >> pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> >> @@ -473,6 +473,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt,
> >u64 addr, u64 size,
> >> mapping->gfn = gfn;
> >> mapping->pfn = pfn;
> >> mapping->nr_pages = size / PAGE_SIZE;
> >> + mapping->nc = !!(prot & (KVM_PGTABLE_PROT_DEVICE | KVM_PGTABLE_PROT_NORMAL_NC));
> >> pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
> >>
> >> return ret;
> >> @@ -503,7 +504,7 @@ int pkvm_pgtable_stage2_wrprotect(struct kvm_pgtable
> >*pgt, u64 addr, u64 size)
> >> lockdep_assert_held(&kvm->mmu_lock);
> >> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> >> ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
> >> - mapping->nr_pages);
> >> + (u64)mapping->nr_pages);
> >> if (WARN_ON(ret))
> >> break;
> >> }
> >> @@ -517,10 +518,11 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable
> >*pgt, u64 addr, u64 size)
> >> struct pkvm_mapping *mapping;
> >>
> >> lockdep_assert_held(&kvm->mmu_lock);
> >> - for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> >> - __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
> >> - PAGE_SIZE * mapping->nr_pages);
> >> -
> >> + for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> >> + if (!mapping->nc)
> >> + __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
> >> + PAGE_SIZE * mapping->nr_pages);
> >> + }
> >> return 0;
> >> }
> >>
> >> @@ -537,7 +539,7 @@ bool pkvm_pgtable_stage2_test_clear_young(struct
> >kvm_pgtable *pgt, u64 addr, u64
> >> lockdep_assert_held(&kvm->mmu_lock);
> >> for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> >> young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
> >> - mapping->nr_pages, mkold);
> >> + (u64)mapping->nr_pages, mkold);
> >>
> >> return young;
> >> }
> >>
> >> --
> >> Without deviation from the norm, progress is not possible.
> >
>
> Thanks!
^ permalink raw reply
* Re: [PATCH v9 0/9] Add support for MT6392 PMIC
From: Lee Jones @ 2026-07-02 15:14 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Mark Brown,
Linus Walleij, Louis-Alexis Eyraud, Val Packett, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260621081634.467858-1-l.scorcia@gmail.com>
On Sun, 21 Jun 2026, Luca Leonardo Scorcia wrote:
> The MediaTek MT6392 PMIC is usually found on devices powered by
> the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
The MFD pieces look fine to me.
I'm assuming this will go in via MFD.
Just let me know when you have all of the remaining Acks.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-v3: Shrink command/event/PRI queues in kdump kernel
From: Jason Gunthorpe @ 2026-07-02 15:17 UTC (permalink / raw)
To: Kiryl Shutsemau (Meta)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Nicolin Chen,
Kyle McMartin, Breno Leitao, Usama Arif, linux-arm-kernel, iommu,
linux-kernel
In-Reply-To: <20260702112825.781750-1-kas@kernel.org>
On Thu, Jul 02, 2026 at 12:28:25PM +0100, Kiryl Shutsemau (Meta) wrote:
> The command, event and PRI queues are sized from the maxima the hardware
> advertises in IDR1, which can be several megabytes each. On systems with
> many SMMUv3 instances that cost is paid per instance and adds up to tens
> of megabytes of coherent DMA in the capture kernel.
>
> A kdump capture kernel runs from a small crashkernel reservation and only
> has to drive the few devices used to save the dump, so deep queues serve
> no purpose. The queues carry invalidation commands and fault records, not
> DMA data, so dump throughput is unaffected; a shallower queue only bounds
> how many commands may be in flight before a sync, which does not matter for
> the capture kernel's small device count and modest I/O.
>
> Clamp every queue to a single page when is_kdump_kernel() is true. Doing
> it in arm_smmu_init_one_queue() covers the command, event and PRI queues
> in one place. The command queue still holds at least one batch plus a sync
> (256 entries on a 4K-page kernel, well above CMDQ_BATCH_ENTRIES), so
> command batching keeps working.
>
> Suggested-by: Kyle McMartin <jkkm@meta.com>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Reviewed-by: Breno Leitao <leitao@debian.org>
> ---
> v2:
> - Use min() instead of min_t(); both operands are u32 so the cast was
> redundant (Jason Gunthorpe, Breno Leitao).
> - Add Reviewed-by from Breno.
>
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Jason Gunthorpe @ 2026-07-02 15:19 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Alexey Kardashevskiy, Catalin Marinas, iommu, linux-arm-kernel,
linux-kernel, linux-coco, Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5abjcro17x.fsf@kernel.org>
On Wed, Jul 01, 2026 at 08:39:06AM +0530, Aneesh Kumar K.V wrote:
> This is the only code path where we need to special-case host memory
> encryption. For this reason, I have avoided renaming
> io_tlb_mem::cc_shared to io_tlb_mem::unencrypted. I can send a v7 with
> the above and we can review the changes based on that?
I'm OK with this
Jason
^ permalink raw reply
* Re: [PATCH 2/3] arm64: Document missing bitfields in cpu-feature-registers.rst
From: Catalin Marinas @ 2026-07-02 15:19 UTC (permalink / raw)
To: Mark Brown
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, Peter Maydell,
Joey Gouly, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <20260522-arm64-cpu-ftr-regs-v1-2-19775b40faf0@kernel.org>
On Fri, May 22, 2026 at 06:58:38PM +0100, Mark Brown wrote:
> --- a/Documentation/arch/arm64/cpu-feature-registers.rst
> +++ b/Documentation/arch/arm64/cpu-feature-registers.rst
> @@ -113,6 +113,30 @@ infrastructure:
> 4. List of registers with visible features
> -------------------------------------------
>
> + ID_AA6FPFR0_EL1 - Floating Point feature ID register 0
That's missing a '4' in '64'.
> + ID_AA6SMFR0_EL1 - SME feature ID register 0
Same here.
--
Catalin
^ permalink raw reply
* Re: [PATCH 3/3] arm64: Sort registers in cpu-feature-registers.rst
From: Catalin Marinas @ 2026-07-02 15:22 UTC (permalink / raw)
To: Mark Brown
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, Peter Maydell,
Joey Gouly, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <20260522-arm64-cpu-ftr-regs-v1-3-19775b40faf0@kernel.org>
On Fri, May 22, 2026 at 06:58:39PM +0100, Mark Brown wrote:
> - ID_AA64PFR0_EL1 - Processor Feature Register 0
> + ID_AA64ISAR1_EL1 - Instruction set attribute register 1
>
> +------------------------------+---------+---------+
> | Name | bits | visible |
> +------------------------------+---------+---------+
> - | DIT | [51-48] | y |
> + | LS64 | [63-60] | y |
> +------------------------------+---------+---------+
> - | MPAM | [43-40] | n |
> + | I8MM | [55-52] | y |
> +------------------------------+---------+---------+
> - | SVE | [35-32] | y |
> + | DGH | [51-48] | y |
> +------------------------------+---------+---------+
> - | GIC | [27-24] | n |
> + | BF16 | [47-44] | y |
> +------------------------------+---------+---------+
> - | AdvSIMD | [23-20] | y |
> + | SB | [39-36] | y |
> +------------------------------+---------+---------+
> - | FP | [19-16] | y |
> + | FRINTTS | [35-32] | y |
> +------------------------------+---------+---------+
> - | EL3 | [15-12] | n |
> + | GPI | [31-28] | y |
> +------------------------------+---------+---------+
> - | EL2 | [11-8] | n |
> + | GPA | [27-24] | y |
> +------------------------------+---------+---------+
> - | EL1 | [7-4] | n |
> + | LRCPC | [23-20] | y |
> +------------------------------+---------+---------+
> - | EL0 | [3-0] | n |
> + | FCMA | [19-16] | y |
> + +------------------------------+---------+---------+
> + | JSCVT | [15-12] | y |
> + +------------------------------+---------+---------+
> + | API | [11-8] | y |
> + +------------------------------+---------+---------+
> + | APA | [7-4] | y |
> + +------------------------------+---------+---------+
> + | DPB | [3-0] | y |
> +------------------------------+---------+---------+
The patch is fine but I just realised that we are really inconsistent
with the non-visible things. We exposed a few hear, I guess in the early
days, and then we stopped, just adding the occasional visible fields.
Shall we drop the 'visible' column altogether and only document the
visible fields here?
--
Catalin
^ permalink raw reply
* [PATCH v8 17/39] drm/bridge: dw-hdmi-qp: Rate limit i2c read error messages
From: Cristian Ciocaltea @ 2026-07-02 14:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
During EDID reads, repeated i2c errors can flood the kernel log:
[ 25.361716] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 25.363376] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
...
[ 25.368671] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 25.369440] dwhdmiqp-rockchip fde80000.hdmi: failed to get edid
Switch to dev_err_ratelimited() in dw_hdmi_qp_i2c_read() to reduce log
spam while still reporting the condition.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
index cfd1b18c06e6..7475b6b71836 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
@@ -561,7 +561,7 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi,
dev_dbg_ratelimited(hdmi->dev,
"i2c read timed out\n");
else
- dev_err(hdmi->dev, "i2c read timed out\n");
+ dev_err_ratelimited(hdmi->dev, "i2c read timed out\n");
dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
return -EAGAIN;
}
@@ -572,7 +572,7 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi,
dev_dbg_ratelimited(hdmi->dev,
"i2c read error\n");
else
- dev_err(hdmi->dev, "i2c read error\n");
+ dev_err_ratelimited(hdmi->dev, "i2c read error\n");
dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
return -EIO;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5] dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA
From: Vinod Koul @ 2026-07-02 15:25 UTC (permalink / raw)
To: Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd,
Hongling Zeng
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Frank Li, Frank Li
In-Reply-To: <20260701045733.33654-1-zenghongling@kylinos.cn>
On Wed, 01 Jul 2026 12:57:33 +0800, Hongling Zeng wrote:
> When terminating DMA transfers, active descriptors are not properly
> reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
> descriptors and their LLI chains to be permanently leaked.
>
> Fix by using vchan_terminate_vdesc() which handles both cyclic and
> non-cyclic descriptors by adding them to desc_terminated queue for
> proper cleanup.
>
> [...]
Applied, thanks!
[1/1] dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA
commit: ab1150115e68a46b687eb38c1ab92782018c9f2c
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: can: rockchip: add rk3588 CAN-FD compatible
From: Cunhao Lu @ 2026-07-02 15:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, Rob Herring, Krzysztof Kozlowski, kernel,
Conor Dooley, Heiko Stuebner, Dmitry Torokhov, Shengjiu Wang,
Pengpeng Hou, Russell King, Eric Biggers, Mario Limonciello,
Karl Mehltretter, Yixun Lan, Stephen Boyd, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <ec548326-dd8d-4d81-8500-ed4c4c30ddb2@kernel.org>
Hi Krzysztof,
Thanks for pointing this out.
> > Add a dedicated rockchip,rk3588-canfd compatible to describe this
> > variant. Do not use rockchip,rk3568v2-canfd as a fallback, because that
> > would describe a register layout that does not match the hardware.
> >
> > Changes in v2:
>
> Changelog goes to changelog, so ---.
>
> See also submitting patches or just start using b4, which would solve
> also your broken threading problem.
>
I will move it below --- in v3. At the same time, I'll also spend some time
learning how to use b4, and will use b4 to send the next v3 submission.
Best regards,
Cunhao
^ permalink raw reply
* Re: [PATCH v7 0/9] dmaengine: Add new API to combine configuration and descriptor preparation
From: Vinod Koul @ 2026-07-02 15:26 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel, Frank.Li
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260521-dma_prep_config-v7-0-1f73f4899883@nxp.com>
On Thu, 21 May 2026 11:32:46 -0400, Frank.Li@oss.nxp.com wrote:
> Previously, configuration and preparation required two separate calls. This
> works well when configuration is done only once during initialization.
>
> However, in cases where the burst length or source/destination address must
> be adjusted for each transfer, calling two functions is verbose.
>
> if (dmaengine_slave_config(chan, &sconf)) {
> dev_err(dev, "DMA slave config fail\n");
> return -EIO;
> }
>
> [...]
Applied, thanks!
[1/9] dmaengine: Add API to combine configuration and preparation (sg and single)
commit: 796bdb33e86aec8504bf8868e0665f120638ac72
[2/9] dmaengine: Add safe API to combine configuration and preparation
commit: af900b7dc1e1cdac571ac38e7fee80f1a1776a62
[3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code
commit: 9605825841061bbdd2fc2a0218098373c539173e
[4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback
commit: bfb66d8098dbbaaada3ab877eda21cd447115c95
[5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
commit: 1af246e9d222f93aee59f3b47ff3bd59d08725e7
[6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
commit: bd00d2c4a1b2a1e7ad3060d3d606fb4c9db6a064
[7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
commit: a0fba0a49f77effd3962723b1fa14c766fbc0ec4
[8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code
commit: 53191cc449db1cf4f25db275978c61b1c6aaeba9
[9/9] crypto: atmel: Use dmaengine_prep_config_sg() API
commit: c9e9927c6d8346cdf6555a8f97da093980172e4b
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 1/6] arm64: make huge_ptep_get handled unaligned addresses
From: David Hildenbrand (Arm) @ 2026-07-02 15:28 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-2-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> huge_ptep_get() can be handed a virtual address pointing to the middle of
> a contpmd/contpte mapped hugetlb folio (examples of callers are
> pagemap_hugetlb_range, page_mapped_in_vma).
>
> The arm64 helper rewalks the pgtables in find_num_contig to answer whether
> the huge pte we have maps a contpmd or a contpte hugetlb folio, and
> returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the
> contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS
> if the addr is not aligned.
>
> Fix this by aligning the pmdp pointer down to a contpmd base before
> checking equality with the passed huge pte pointer, to correctly answer
> whether the huge pte is the base of a contpmd block.
>
> Fixes: 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 30772a909aea3..8e799c1fe0aa6 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -87,7 +87,7 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
> p4dp = p4d_offset(pgdp, addr);
> pudp = pud_offset(p4dp, addr);
> pmdp = pmd_offset(pudp, addr);
> - if ((pte_t *)pmdp == ptep) {
> + if ((pte_t *)PTR_ALIGN_DOWN(pmdp, sizeof(*pmdp) * CONT_PMDS) == ptep) {
> *pgsize = PMD_SIZE;
> return CONT_PMDS;
> }
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: David Hildenbrand (Arm) @ 2026-07-02 15:30 UTC (permalink / raw)
To: Muchun Song, Dev Jain
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable, osalvador, akpm, ljs, liam
In-Reply-To: <CE6E9F6C-8891-40E3-A5B7-BA475070EACD@linux.dev>
On 7/2/26 11:35, Muchun Song wrote:
>
>
>> On Jul 2, 2026, at 17:08, Dev Jain <dev.jain@arm.com> wrote:
>>
>>
>>
>> On 02/07/26 2:17 pm, Muchun Song wrote:
>>>
>>>
>>>
>>> Maybe I didn't express my thoughts clearly in the first version, let me
>>> explain in more detail.
>>>
>>> We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like
>>> set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference
>>> in your previous version). Currently, you've added a declaration, but the
>>> function itself doesn't actually exist, which seems quite strange to me.
>>
>> https://lore.kernel.org/all/a4fe8ba6-2ecd-4bb9-95a9-27f9f1e87d2e@kernel.org/
>>
>> David suggested this. Honestly I quite like David's suggestion, what do you
>> think?
>
> Thanks for pointing that out, I missed it earlier. That said, looking at
> hugetlb.h, it already contains quite a few no-op stubs. To keep things
> consistent, I'd personally prefer a stub here. Since David suggested this,
> I’d love to hear his thoughts on this as well.
It's the shortest possible way to enforce (through the linker!) that you
function is not called from wrong context.
The only alternative is using a stub with a BUILD_BUG() in it. Which will 4 5 LOC :)
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v8 00/39] Add HDMI 2.0 support to DW HDMI QP TX
From: Cristian Ciocaltea @ 2026-07-02 15:31 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
Dmitry Baryshkov, Diederik de Haas, Maud Spierings
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
Hi,
I've just realized I missed updating the part of the cover letter that
describes the patch structure. Please find the corrected content below.
Regards,
Cristian
On 7/2/26 5:46 PM, Cristian Ciocaltea wrote:
> Enable HDMI 2.0 display modes (e.g. 4K@60Hz) on the Synopsys DW HDMI QP
> TX controller, as found in Rockchip RK3576 & RK3588 SoCs, by adding SCDC
> management for high TMDS clock ratio and scrambling.
Since SCDC state is lost on sink disconnects, the bridge driver needs to
trigger a CRTC reset during connector detection. To support this, the
series first introduces the HDMI version enum and the caps-based HDMI
connector init helper (patches 1-3), then builds the connector and
bridge scrambling infrastructure on top of it - the connector scrambler
support, the scdc-helper additions (connector-prefixed debug macro and
SCDC version helper), and the HDMI scrambling management helpers
including SCDC source-version advertisement (patches 4-8).
It then wires this up through the hdmi-state-helper and bridge connector
layers: fallback TMDS rate validation, hotplug SCDC state sync and the
scrambling requirement (patches 9-11), a bridge cleanup and the new
source-side scrambling bridge ops (patches 12-13), the switch to a
cached-status, atomic-aware .detect_ctx() connector helper (patches
14-15), and finally hooking up the HDMI 2.0 scrambler callbacks (patch
16).
The SCDC scrambling feature itself is implemented in the DW HDMI QP
bridge driver, alongside i2c error-message rate limiting,
.enable_hpd()/.disable_hpd() PHY ops and a dw_hdmi_qp_hpd_notify()
helper (patches 17-20).
Patches 21-28 cover the Rockchip platform driver and HPD handling: minor
cleanups (newlines in dev_err_probe(), consistent local dev variable,
dropping an unnecessary include), deferring HPD IRQ enable until after
connector setup, masking the RK3576 HPD IRQ in io_init, implementing the
.{enable|disable}_hpd() PHY ops, switching HPD reports to
dw_hdmi_qp_hpd_notify() to restrict events to the affected connector,
and dropping the now-unused .setup_hpd() PHY op.
Patches 29-31 convert vc4 HDMI to the common infrastructure as a proof
of reuse: adopting the shared TMDS char rate constants, switching to
drm_hdmi_mode_needs_scrambling(), and replacing the driver-local
scrambling implementation with the common SCDC scrambling helpers.
Patches 32-39 add KUnit tests: HDMI caps-based init coverage and
source-side scrambler validation for the connector, conversion of
hdmi_state_helper to drmm_connector_hdmi_init_with_caps() with
max_tmds_char_rate fallback tests, a new 4K@60Hz 600MHz TMDS EDID,
source-side scrambling decision coverage, and conformity fixes for the
existing 1080p+4K YUV420 200MHz and 4K RGB/YUV 340MHz test EDID blobs.
>
> This has been tested on the following boards:
>
> * Radxa ROCK 5B (RK3588)
> * Radxa ROCK 4D (RK3576)
> * Raspberry Pi 5 Model B Rev 1.1 (BCM2712 D0)
>
> Note that commit d87773de9efe1 ("clocksource/drivers/arm_arch_timer:
> Default to EL2 virtual timer when running VHE"), introduced in v7.2-rc1,
> causes Raspberry Pi 5 to hang during boot. Reverting the commit
> restores normal boot. This issue has already been reported in [1];
> alternatively, the workaround proposed in [2] can be applied.
>
> Regards,
> Cristian
>
> [1] https://lore.kernel.org/all/ea15cce1-b393-43f6-8d58-3d6f90f0c0cd@samsung.com/
> [2] https://lore.kernel.org/all/20260619204832.586079-1-dan@reactivated.net/
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Changes in v8:
> - Added an enum hdmi_version under video/hdmi to describe the HDMI
> specification version a source/sink supports (new patch 1)
> - Introduced HDMI connector capabilities API and reworked the
> infrastructure patches on top of it: drmm_connector_hdmi_init() now
> takes a drm_connector_hdmi_caps struct that carries supported_formats,
> max_bpc, supported_hdmi_ver and max_tmds_char_rate (new patches 2-3)
> - Moved all the new SCDC helpers covering both source and sink to
> display/drm_hdmi_helper.c
> - Renamed drm_scdc_{start,stop}_scrambling() to
> drm_connector_hdmi_{enable,disable}_scrambling() and added a
> connector-state argument so the scrambler_needed flag is checked
> centrally instead of in every driver
> - Renamed drm_scdc_sync_status() to drm_connector_hdmi_sync_scdc(),
> aligned its lifecycle with vc4_hdmi_reset_link(), and removed the
> internal drm_scdc_reset_crtc() helper; it now also gates on CRTC state
> and an in-flight commit (Maxime)
> - Changed the prototype of drm_atomic_helper_connector_hdmi_hotplug() to
> take an acquire context and an int return, instead of adding a new
> _ctx variant (Maxime)
> - Added drm_hdmi_mode_needs_scrambling() to centralise the above-340 MHz
> decision (new patch 7)
> - Made SCDC source version negotiation optional and moved it to a
> dedicated patch "drm/display: hdmi: Advertise SCDC source version when
> scrambling" (new patch 8), backed by a new
> drm_scdc_set_source_version() helper in "drm/display: scdc-helper: Add
> helper to set SCDC version information" (new patch 6)
> - Added a fallback TMDS rate validation patch using the connector-level
> max_tmds_char_rate when the driver provides no .tmds_char_rate_valid()
> hook (new patch 9)
> - Split scrambler_needed flag handling into its own hdmi-state-helper
> dedicate change (new patch 11)
> - VC4:
> * Replaced vc4_hdmi_mode_needs_scrambling() with
> drm_hdmi_mode_needs_scrambling() (new patch 30)
> * Restored drm_dev_{enter,exit}() pairing around the converted
> scrambling paths
> * Removed now unused output_{bpc,color_format} fields from vc4_hdmi as
> part of the SCDC conversion
> - KUnit:
> * Covered the caps-based connector init path: NULL caps, inferred
> max_tmds_char_rate per supported_hdmi_ver, and override validation
> (new patch 32)
> * Switched drm_hdmi_state_helper_test to the caps-based init helper
> and exposed it through
> drm_kunit_helper_connector_hdmi_init_with_caps_edid_funcs() (new
> patch 34)
> * Added max_tmds_char_rate fallback coverage in
> drm_hdmi_state_helper_test (new patch 35)
> - Rebased onto latest drm-misc-next and dropped the already applied
> "drm/fb-helper: Remove unused local variable in hotplug_event()" patch
> - Link to v7: https://patch.msgid.link/20260602-dw-hdmi-qp-scramb-v7-0-445eb54ee1ed@collabora.com
[...]
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: xlnx,axi-dma: Restore xlnx,flush-fsync as u32
From: Vinod Koul @ 2026-07-02 15:31 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, michal.simek,
radhey.shyam.pandey, Suraj Gupta
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260625161016.1249570-1-suraj.gupta2@amd.com>
On Thu, 25 Jun 2026 21:40:16 +0530, Suraj Gupta wrote:
> The DT schema conversion incorrectly changed xlnx,flush-fsync from a u32
> property to a boolean. The original binding documented values 1, 2, and 3
> to select which VDMA channel(s) flush on frame sync.
> Restore the uint32 type with the documented enum values and fix the
> example accordingly.
>
>
> [...]
Applied, thanks!
[1/1] dt-bindings: dma: xlnx,axi-dma: Restore xlnx,flush-fsync as u32
commit: 287bdea77529e6abac5fe15461d93c1acdcb07e9
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: xilinx: Fix "xlnx,irq-delay" type
From: Vinod Koul @ 2026-07-02 15:32 UTC (permalink / raw)
To: Frank Li, Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Shyam Pandey, Abin Joseph, Rob Herring (Arm)
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260612215226.1887726-1-robh@kernel.org>
On Fri, 12 Jun 2026 16:52:25 -0500, Rob Herring (Arm) wrote:
> "xlnx,irq-delay" programs an 8-bit delay field in the DMA control
> register, and the driver stores and reads it as a byte. The binding
> described the property as a uint32 cell, which made the helper type
> check report the driver as wrong.
>
> Document "xlnx,irq-delay" as uint8 so the generated schema reflects
> the hardware field width and the existing driver access.
>
> [...]
Applied, thanks!
[1/1] dt-bindings: dma: xilinx: Fix "xlnx,irq-delay" type
commit: fa9cb11584851414b25fd8bf9f59518424b5917c
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation failure
From: Vinod Koul @ 2026-07-02 15:32 UTC (permalink / raw)
To: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno, Frank Li,
Vladimir Zapolskiy
Cc: Long Cheng, dmaengine, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260701200703.117929-1-vz@kernel.org>
On Wed, 01 Jul 2026 23:07:03 +0300, Vladimir Zapolskiy wrote:
> If dynamic memory allocation in driver's probe function execution fails, it
> should be reported to the driver's framework with -ENOMEM error code.
>
>
Applied, thanks!
[1/1] dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation failure
commit: 467265c750edd7ab43803deeafe7d3120a791d32
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: mediatek,uart-dma: add support for MT8189 SoC
From: Vinod Koul @ 2026-07-02 15:32 UTC (permalink / raw)
To: Sean Wang, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Long Cheng, Louis-Alexis Eyraud
Cc: kernel, dmaengine, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-uart-dma-v1-1-c7106216a40d@collabora.com>
On Wed, 01 Jul 2026 17:47:20 +0200, Louis-Alexis Eyraud wrote:
> Add the compatible string for the APDMA IP found in MT8189 SoC,
> that supports 35-bits addressing as MT6985 SoC.
>
>
Applied, thanks!
[1/1] dt-bindings: dma: mediatek,uart-dma: add support for MT8189 SoC
commit: 0d2b094b1c10be619a63f53a610587bcabbee06b
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: David Hildenbrand (Arm) @ 2026-07-02 15:32 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-3-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> try_to_unmap_one() handles hugetlb folios when memory failure needs
> to replace a poisoned hugetlb mapping with a hwpoison entry. In that
> case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio
> in pvmw.pte, but the code reads it with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
> etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Just use huge_ptep_get() for dereferencing a huge pte pointer.
>
> Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
> Cc: stable@vger.kernel.org
> Reported-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> include/linux/hugetlb.h | 3 +++
> mm/rmap.c | 16 ++++++++++------
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 2abaf99321e90..fdb7bdf7645c5 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
> {
> }
>
> +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep);
Two tabs, or just in a single line.
If others prefer a stub, I don't care. This here is shortest to let the linker
bail out.
> +
> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep)
> {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 1c77d5dc06e9f..aa8a254efaecc 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
> /* Unexpected PMD-mapped THP? */
> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>
> - /*
> - * Handle PFN swap PTEs, such as device-exclusive ones, that
> - * actually map pages.
> - */
That comment now actually belongs above the pte_present() check below.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable
From: Marc Zyngier @ 2026-07-02 15:34 UTC (permalink / raw)
To: Bradley Morgan
Cc: Leonardo Bras, Oliver Upton, Fuad Tabba, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Will Deacon, Quentin Perret, Vincent Donnefort, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <6495D546-8FC7-4A31-B18C-88F34E1B64BB@grrlz.net>
On Thu, 02 Jul 2026 15:52:14 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> I'll test it. If it's good. I'll do
>
> Suggested-by? Or co-developed by?
Sb if you want, definitely not Cdb. More importantly, I expect to you
to follow the process described at [1]. Nothing there is optional.
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 3/6] mm/rmap: use huge_ptep_get() in try_to_migrate_one()
From: David Hildenbrand (Arm) @ 2026-07-02 15:34 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-4-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> try_to_migrate_one() is used by folio migration to replace a present
> mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk()
> returns the pte pointer to the hugetlb folio in pvmw.pte, but the code
> reads the huge pte entry with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
> etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Use huge_ptep_get() to dereference a huge pte pointer.
>
> Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into
> try_to_migrate_one.
>
> Fixes: a98a2f0c8ce1 ("mm/rmap: split migration into its own function")
> Cc: stable@vger.kernel.org
> Acked-by: Muchun Song <muchun.song@linux.dev>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> mm/rmap.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index aa8a254efaecc..abc3a44baaa3d 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2505,11 +2505,16 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
> /* Unexpected PMD-mapped THP? */
> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>
> - /*
> - * Handle PFN swap PTEs, such as device-exclusive ones, that
> - * actually map pages.
> - */
> - pteval = ptep_get(pvmw.pte);
> + address = pvmw.address;
> + if (folio_test_hugetlb(folio)) {
> + pteval = huge_ptep_get(mm, address, pvmw.pte);
> + } else {
> + /*
> + * Handle PFN swap PTEs, such as device-exclusive ones,
> + * that actually map pages.
> + */
Again, the comment is related to the pte_present() handling, so best to move it
down there.
Apart from that LGTM.
--
Cheers,
David
^ permalink raw reply
* [PATCH v8 04/39] drm/connector: Add HDMI 2.0 scrambler infrastructure
From: Cristian Ciocaltea @ 2026-07-02 14:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
Add the connector-level infrastructure to support HDMI 2.0 scrambling:
- A scrambler_supported flag to indicate whether the source supports the
scrambling capability, in which case the newly introduced
.scrambler_{enable|disable}() callbacks in drm_connector_hdmi_funcs
are mandatory
- A scrambler_needed flag to be managed by the hdmi state helpers based
on the negotiated TMDS character rate and the source/sink scrambling
capabilities
- A scrambler_enabled flag to track whether scrambling is currently
active
- A delayed work item (scdc_work) with an associated callback (scdc_cb)
to monitor sink-side scrambling status and retry the setup if the sink
resets it
These are intended to be used by SCDC scrambling helpers to coordinate
scrambling setup and teardown between the source driver and the DRM
core.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/drm_connector.c | 26 ++++++++++++--
include/drm/drm_connector.h | 77 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c7ce6b7bd8b0..deecfc582f09 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -220,6 +220,19 @@ void drm_connector_free_work_fn(struct work_struct *work)
}
}
+static void drm_connector_hdmi_scdc_work(struct work_struct *work)
+{
+ struct drm_connector *connector;
+ struct drm_connector_hdmi *hdmi;
+
+ hdmi = container_of(to_delayed_work(work), struct drm_connector_hdmi,
+ scdc_work);
+ connector = container_of(hdmi, struct drm_connector, hdmi);
+
+ if (hdmi->scdc_cb)
+ hdmi->scdc_cb(connector);
+}
+
static int drm_connector_init_only(struct drm_device *dev,
struct drm_connector *connector,
const struct drm_connector_funcs *funcs,
@@ -285,6 +298,7 @@ static int drm_connector_init_only(struct drm_device *dev,
mutex_init(&connector->edid_override_mutex);
mutex_init(&connector->hdmi.infoframes.lock);
mutex_init(&connector->hdmi_audio.lock);
+ INIT_DELAYED_WORK(&connector->hdmi.scdc_work, drm_connector_hdmi_scdc_work);
connector->edid_blob_ptr = NULL;
connector->epoch_counter = 0;
connector->tile_blob_ptr = NULL;
@@ -624,12 +638,18 @@ int drmm_connector_hdmi_init_with_caps(struct drm_device *dev,
* inferred limit with the actual controller capability. A value of
* zero keeps the default limit inferred from supported_hdmi_ver.
*/
- if (caps->supported_hdmi_ver >= HDMI_VERSION_2_0)
+ if (caps->supported_hdmi_ver >= HDMI_VERSION_2_0) {
+ if (!hdmi_funcs->scrambler_enable ||
+ !hdmi_funcs->scrambler_disable)
+ return -EINVAL;
+
+ connector->hdmi.scrambler_supported = true;
connector->hdmi.max_tmds_char_rate = HDMI_2_0_TMDS_CHAR_RATE_MAX_HZ;
- else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_3)
+ } else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_3) {
connector->hdmi.max_tmds_char_rate = HDMI_1_3_TMDS_CHAR_RATE_MAX_HZ;
- else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_0)
+ } else if (caps->supported_hdmi_ver >= HDMI_VERSION_1_0) {
connector->hdmi.max_tmds_char_rate = HDMI_1_0_TMDS_CHAR_RATE_MAX_HZ;
+ }
if (caps->max_tmds_char_rate) {
if (caps->max_tmds_char_rate > connector->hdmi.max_tmds_char_rate)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 961a729d0869..c70b57963f28 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -28,6 +28,7 @@
#include <linux/ctype.h>
#include <linux/hdmi.h>
#include <linux/notifier.h>
+#include <linux/workqueue.h>
#include <drm/drm_mode_object.h>
#include <drm/drm_util.h>
#include <drm/drm_property.h>
@@ -1131,6 +1132,19 @@ struct drm_connector_hdmi_state {
* @tmds_char_rate: TMDS Character Rate, in Hz.
*/
unsigned long long tmds_char_rate;
+
+ /**
+ * @scrambler_needed: Whether HDMI 2.0 SCDC scrambling is required
+ * for the negotiated mode/bpc/format.
+ *
+ * Computed by drm_atomic_helper_connector_hdmi_check() from
+ * @tmds_char_rate and the source/sink scrambling capabilities.
+ *
+ * Per HDMI 2.0, scrambling is mandatory above 340 MHz TMDS
+ * character rate. Optional scrambling at lower rates is
+ * deliberately not requested by the helper.
+ */
+ bool scrambler_needed;
};
/**
@@ -1439,6 +1453,36 @@ struct drm_connector_hdmi_funcs {
*/
const struct drm_edid *(*read_edid)(struct drm_connector *connector);
+ /**
+ * @scrambler_enable:
+ *
+ * The callback is invoked via @drm_connector_hdmi_enable_scrambling
+ * during commit to setup SCDC scrambling and high TMDS clock ratio on
+ * the source side.
+ *
+ * The @scrambler_enable callback is mandatory if HDMI 2.0 is to be
+ * supported.
+ *
+ * Returns:
+ * 0 on success, a negative error code otherwise
+ */
+ int (*scrambler_enable)(struct drm_connector *connector);
+
+ /**
+ * @scrambler_disable:
+ *
+ * The callback is invoked via @drm_connector_hdmi_disable_scrambling
+ * during commit to tear down SCDC scrambling and high TMDS clock ratio
+ * on the source side.
+ *
+ * The @scrambler_disable callback is mandatory if HDMI 2.0 is to be
+ * supported.
+ *
+ * Returns:
+ * 0 on success, a negative error code otherwise
+ */
+ int (*scrambler_disable)(struct drm_connector *connector);
+
/**
* @avi:
*
@@ -2098,6 +2142,39 @@ struct drm_connector_hdmi {
*/
unsigned long long max_tmds_char_rate;
+ /**
+ * @scrambler_supported: Indicates whether the HDMI controller
+ * (source) supports HDMI 2.0 SCDC scrambling.
+ *
+ * This is set by the HDMI connector init helpers if the provided
+ * capabilities advertise HDMI_VERSION_2_0 support.
+ *
+ * When true, @drm_connector_hdmi_funcs.scrambler_enable and
+ * @drm_connector_hdmi_funcs.scrambler_disable are mandatory.
+ */
+ bool scrambler_supported;
+
+ /**
+ * @scrambler_enabled: Tracks whether HDMI 2.0 scrambler is currently enabled.
+ */
+ bool scrambler_enabled;
+
+ /**
+ * @scdc_work: Work item currently used to monitor sink-side scrambling
+ * status and retry setup if the sink resets it.
+ */
+ struct delayed_work scdc_work;
+
+ /** @scdc_cb: Callback to be invoked as part of @scdc_work.
+ *
+ * Currently used to monitor sink-side scrambling status and retry
+ * setup if the sink resets it.
+ *
+ * This is assigned by the framework when making use of
+ * drm_connector_hdmi_enable_scrambling() helper.
+ */
+ void (*scdc_cb)(struct drm_connector *connector);
+
/**
* @funcs: HDMI connector Control Functions
*/
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: Sort registers in cpu-feature-registers.rst
From: Mark Brown @ 2026-07-02 15:38 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, Peter Maydell,
Joey Gouly, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <akaCJvZkdqigcQUZ@arm.com>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
On Thu, Jul 02, 2026 at 04:22:14PM +0100, Catalin Marinas wrote:
> The patch is fine but I just realised that we are really inconsistent
> with the non-visible things. We exposed a few hear, I guess in the early
> days, and then we stopped, just adding the occasional visible fields.
> Shall we drop the 'visible' column altogether and only document the
> visible fields here?
Yeah, I was struggling to understand the logic and would certainly
prefer to not have to type in every single bitfield in yet another
location. I'll add a patch on top that does as you suggest, see if
anyone objects.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu-v3: Shrink command/event/PRI queues in kdump kernel
From: Kiryl Shutsemau @ 2026-07-02 15:38 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Jason Gunthorpe,
Nicolin Chen, Kyle McMartin, Breno Leitao, Usama Arif,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <akZ-KIVJlmP4LEcQ@google.com>
On Thu, Jul 02, 2026 at 03:05:12PM +0000, Pranjal Shrivastava wrote:
> On Thu, Jul 02, 2026 at 12:28:25PM +0100, Kiryl Shutsemau (Meta) wrote:
> > The command, event and PRI queues are sized from the maxima the hardware
>
> A minor note here is PRI & EVT queues are disabled for the kdump kernel
> (see arm_smmu_device_reset). We could just mention all SMMU queues are
> sized [...] in the commit message.
Fair enough.
Here's updated commit message (I will send v3 in few days, if no new
feedback):
Subject: [PATCH v3] iommu/arm-smmu-v3: Shrink command/event/PRI queues in
kdump kernel
All SMMU queues are sized from the maxima the hardware advertises in IDR1,
which can be several megabytes each, and are allocated at probe. The kdump
kernel already disables the event and PRI queues (arm_smmu_device_reset()
drops CR0_EVTQEN/CR0_PRIQEN) but still allocates them at full size. On
systems with many SMMUv3 instances that cost is paid per instance and adds
up to tens of megabytes of coherent DMA in the capture kernel.
A kdump capture kernel runs from a small crashkernel reservation and only
has to drive the few devices used to save the dump, so deep queues serve
no purpose. The queues are not on the DMA data path, so dump throughput is
unaffected; a shallower command queue only bounds how many commands may be
in flight before a sync, which does not matter for the capture kernel's
small device count and modest I/O.
Clamp every queue to a single page when is_kdump_kernel() is true. Doing
it in arm_smmu_init_one_queue() covers the command, event and PRI queues
in one place. The command queue still holds at least one batch plus a sync
(256 entries on a 4K-page kernel, well above CMDQ_BATCH_ENTRIES), so
command batching keeps working.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v2 4/6] mm/migrate: use huge_ptep_get() in remove_migration_pte()
From: David Hildenbrand (Arm) @ 2026-07-02 15:44 UTC (permalink / raw)
To: Dev Jain, muchun.song, osalvador, akpm, ljs, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-5-dev.jain@arm.com>
On 7/2/26 07:13, Dev Jain wrote:
> remove_migration_pte() converts migration entries back to present PTEs
> after folio migration completes. For hugetlb folios,
> page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in
> pvmw.pte, but the code reads it with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(),
> pte_present() etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
Right, for non-present entries it's even weirder. Fortunately your patch #1 also
handles that.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ 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