* Re: [PATCH 09/11] regulator: db8500-prcmu: Remove EPOD regulators
From: Mark Brown @ 2026-06-22 17:00 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Vinod Koul, Frank Li, Lee Jones, linux-arm-kernel,
devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-9-eb5e50b1a588@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 160 bytes --]
On Thu, Jun 18, 2026 at 07:00:55AM +0200, Linus Walleij wrote:
> Remove the obsolete DB8500 PRCMU regulator drivers.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Re: Re: [PATCH v2] PCI: host-common: Request bus reassignment when not probe-only
From: Bjorn Helgaas @ 2026-06-22 16:56 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: bjorn@helgaas.com, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, bhelgaas@google.com,
will@kernel.org, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, robh@kernel.org, vidyas@nvidia.com
In-Reply-To: <MN0PR18MB584758C9286C78B6EE947FE7D3182@MN0PR18MB5847.namprd18.prod.outlook.com>
On Fri, Jun 12, 2026 at 04:03:25AM +0000, Ratheesh Kannoth wrote:
> ...
> Kindly advise if there are any outstanding action items required
> from my side. I see that the patch is not available in net-next yet
> or backported to stable versions. I want to ensure I haven't missed
> a step, so please excuse my impatience if it is simply a matter of
> the usual release cycle.
This is queued on pci/controller/host-common and is in pci/next for
v7.2. I will ask Linus to pull that branch sometime this week. This
is separate from net-next, so it won't appear there. Backports to
stable will happen after Linus pulls the branch.
Bjorn
^ permalink raw reply
* Re: [PATCH kvmtool v2 7/7] arm64: Improve KVM_ARM_VCPU_PMU_V3_CTRL diagnostics
From: Oliver Upton @ 2026-06-22 16:55 UTC (permalink / raw)
To: Alexandru Elisei
Cc: will, julien.thierry.kdev, maz, jean-philippe.brucker,
andre.przywara, suzuki.poulose, kvm, linux-arm-kernel, kvmarm
In-Reply-To: <ajj6oGxytFm2NE4T@raptor>
On Mon, Jun 22, 2026 at 10:04:32AM +0100, Alexandru Elisei wrote:
> Hi Oliver,
>
> On Thu, Jun 18, 2026 at 12:06:12PM -0700, Oliver Upton wrote:
> > The whole if (ret) die_perror(...) thing is a bit repetetive IMO. A
> > treewide cleanup replacing this with macros would be nice, then you could
> > stringize the ioctl under the hood.
>
> Thank you for having a look, that's a great idea, it will avoid out of bounds
> array access if KVM gets a new PMU ioctl and the name array is not updated at
> the same time - that's quite possible since ioctl numbers are pulled by running
> update_headers.sh, and the dependency is not obvious.
>
> I think the compilation errors are a bit higher priority than this, and a
> treewide change would more involved, possibly involving a change in behaviour
> (the gic seems to propagate the error instead of calling die_perror(), for
> example), would you mind if for this series I'll only introduce the macro for
> the pmu and convert the rest of the code in a separate series?
Fine by me, thanks Alex :)
Best,
Oliver
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Doug Anderson @ 2026-06-22 16:52 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, James Morse,
Mark Rutland, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <ajk-Vge2qhaY-TwJ@thinkstation>
Hi,
On Mon, Jun 22, 2026 at 6:56 AM Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> The ratio is flat across the whole 1-to-72 sweep, so -- relevant to the
> scalability question -- it's a constant per-syscall tax, not a contention
> effect. The impact tracks syscall/exception density: page_fault1, a more
> realistic workload, stays within ~5%.
FWIW, I'm not sure 5% is truly a "realistic" measure of the overhead
here. While it cannot be denied that pseudo-NMI has some overhead,
every time I've seen someone study it in "real world" scenarios it
ends up being fairly negligible. Not zero, mind you. ...but some
amount below 1%. ...and by this, I mean put real-world workloads on a
system with pseudo NMI enabled and pick your favorite metric. Perhaps
measure the amount of work completed in a given time. I dunno if this
is possible for you to do in this case.
> > The direction of travel is to deprecate SDEI. I wouldn't add more stuff
> > on top of this interface.
>
> I understand FEAT_NMI is the long-term answer, and I'm not arguing against
> deprecating SDEI. My concern is the gap in between. By our estimate it's
> 10+ years before the last non-FEAT_NMI machine retires from the fleet --
> for scale, we're still running Skylake today. So there's roughly a
> decade where a large installed base has neither FEAT_NMI nor affordable
> pseudo-NMI, and no way to reach a DAIF-masked CPU for an all-CPU
> backtrace or to capture a wedged CPU in a crash dump. That's the
> functional gap this series tries to cover.
>
> Given the deprecation direction, I deliberately kept the SDEI footprint as
> small as I could. The series adds no new firmware interface and no vendor
> SMC -- it uses only the standard software-signalled event (event 0) via
> SDEI_EVENT_SIGNAL, which is already present on these systems for
> firmware-first RAS (APEI/GHES). And SDEI is only ever invoked in a "bad
> state": to deliver a backtrace signal to a CPU that a normal IPI can't
> reach, or to stop a CPU that ignored the stop IPIs. Nothing on any hot or
> steady-state path touches it.
>
> If even that minimal use is unacceptable on a deprecated interface, I'd
> rather know now and redirect the effort -- but I'd appreciate a pointer to
> what should cover this gap for existing silicon in the meantime.
FWIW, despite the fact that pseudo-NMI (in my experience) ends up
being mostly negligible, personally I'd be in favor of landing Kiryl's
patches. I dunno how many times I've had the discussion of pseudo-NMI
overhead over the years and it's certainly very easy to show that
there is _some_ overhead and that in pathological cases there is a lot
of overhead. As Kiryl says, the patches don't add a ton of extra
complexity and they even combine some of the stop/crash-stop code,
which is nice. Having them as a stop-gap until true NMI is available
seems nice to me. ...of course, I'm not an ARM maintainer, so it's
obviously not up to me. :-)
-Doug
^ permalink raw reply
* Re: [PATCH 1/6] arm64: mm: remove unreachable invalid range check in kasan_init_shadow()
From: Andrey Ryabinin @ 2026-06-22 16:52 UTC (permalink / raw)
To: Sang-Heon Jeon, Catalin Marinas, Will Deacon
Cc: Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov, kasan-dev,
linux-arm-kernel, Vincenzo Frascino
In-Reply-To: <20260621145919.1453-2-ekffu200098@gmail.com>
Sang-Heon Jeon <ekffu200098@gmail.com> writes:
> kasan_init_shadow() maps each memblock region with for_each_mem_range()
> and breaks the loop when start >= end. for_each_mem_range() never returns
> an invalid range, so start < end always.
>
> Therefore the start >= end check is unreachable, so remove it.
>
> No functional change.
>
> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> ---
> arch/arm64/mm/kasan_init.c | 3 ---
> 1 file changed, 3 deletions(-)
>
Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index 3fcad956fdf7..45fbdce684c8 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -353,9 +353,6 @@ static void __init kasan_init_shadow(void)
> void *start = (void *)__phys_to_virt(pa_start);
> void *end = (void *)__phys_to_virt(pa_end);
>
> - if (start >= end)
> - break;
> -
> kasan_map_populate((unsigned long)kasan_mem_to_shadow(start),
> (unsigned long)kasan_mem_to_shadow(end),
> early_pfn_to_nid(virt_to_pfn(start)));
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 16:51 UTC (permalink / raw)
To: Randy Dunlap
Cc: Peter Zijlstra, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Julia Lawall, Yury Norov, linux-doc,
linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <08b3c961-18bb-43d9-8d7f-8a87bcad0afa@infradead.org>
On Mon, 22 Jun 2026 09:40:45 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> > Did you forget your C 101 class? If you use a function, you gotta
> > include the relevant header.
>
> Also item #1 in Documentation/process/submit-checklist.rst.
What is that? Remove all trace_printk()s before you submit?
Because that is what you should do. But now you also need to remember
to remove the include <linux/trace_printk.h> too. Or, I guess if
someone uses it a lot, they may just keep it in their files without the
trace_printk()s.
-- Steve
^ permalink raw reply
* Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Ard Biesheuvel @ 2026-06-22 16:42 UTC (permalink / raw)
To: Kevin Brodsky, Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, Catalin Marinas, Will Deacon, Fuad Tabba
In-Reply-To: <2deff570-0497-4438-94ba-a9691881a016@arm.com>
Hi Kevin,
On Mon, Jun 22, 2026 at 5:23 PM Kevin Brodsky <kevin.brodsky@arm.com> wrote:
>
> On 19/06/2026 18:39, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Fuad reports that in some cases, the KVM init code may apply relocations
> > to variables that reside in .data, and does so via the linear map. This
> > means that remapping .data read-only beforehand is a bad idea, and
> > results in an early boot crash.
> >
> > These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG or
> > CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted in
> > testing.
> >
> > So move the remap to mark_rodata_ro(), which is a reasonable place to
> > put this, and ensures that it happens much later during the boot. It
> > also means that rodata=off is now taken into account, and so the linear
> > alias will remain writable in that case.
> >
> > Cc: Fuad Tabba <fuad.tabba@linux.dev>
> > Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > arch/arm64/mm/mmu.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 9f354971b7e4..1f7eca86b5c1 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1198,11 +1198,6 @@ static void __init map_mem(void)
> > __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
> > flags);
> > }
> > -
> > - /* Map the kernel data/bss read-only in the linear map */
> > - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> > - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> > - (unsigned long)lm_alias(__bss_stop));
> > }
> >
> > void mark_rodata_ro(void)
> > @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void)
> > update_mapping_prot(__pa_symbol(_text), (unsigned long)_text,
> > (unsigned long)_stext - (unsigned long)_text,
> > PAGE_KERNEL_RO);
> > +
> > + /* Map the kernel data/bss read-only in the linear map */
> > + update_mapping_prot(__pa_symbol(__init_end),
> > + (unsigned long)lm_alias(__init_end),
> > + (unsigned long)__bss_stop - (unsigned long)__init_end,
> > + PAGE_KERNEL_RO);
>
> I was rather confused by this patch until I saw in master:
>
> f102131c842d Revert "arm64: mm: Unmap kernel data/bss entirely from the
> linear map"
> 81479b6888f8 Revert "arm64: mm: Defer remap of linear alias of data/bss"
>
> ... which explains the diff, but it looks like there are multiple issues
> here. Is my understanding correct that these reverts fix kvm_arm_init()
> because it needs to *read* from the linear map, while this new patch
> fixes some KVM configurations that need to *write* to the linear map?
>
Basically, yes.
> If so it might be good to give a recap in the commit message, because
> the reverts are easy to miss.
>
Ok
> It would also be good to explain why we can't do this in
> mark_linear_text_alias_ro() (presumably because this is too early). I do
> agree that honouring rodata=off is a good thing, though.
>
I didn't consider that tbh - I'll check whether that is a more suitable
location. But generally, I think doing it later rather than earlier is
fine because it reduces the likelihood of hidden issues such as the one
being addressed by this patch, and I don't think doing this very early
makes a meaningful difference in terms of robustness.
> BTW, if only kvm_arm_init() needs to read the data/bss via the linear
> map, maybe we can still unmap it later?
>
Yes, it is still my intent to bring back the patches that unmap this alias
entirely, including some additional tweaks for the fixmap PTE level table
that I dropped after an earlier revision. But that will be 7.3 material,
whereas this fixes a regression due to the changes that were pulled for 7.2.
^ permalink raw reply
* Re: [PATCH v2 4/5] dt-bindings: dma: sun50i-a64-dma: Add allwinner,sun60i-a733-dma compatible string
From: Conor Dooley @ 2026-06-22 16:42 UTC (permalink / raw)
To: Frank Li
Cc: Yuanshen Cao, Vinod Koul, Frank Li, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, dmaengine, linux-arm-kernel, linux-sunxi,
linux-kernel, devicetree
In-Reply-To: <ajhjj7FLn136qMmt@SMW015318>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
On Sun, Jun 21, 2026 at 05:19:59PM -0500, Frank Li wrote:
> On Sun, Jun 21, 2026 at 09:40:57PM +0000, Yuanshen Cao wrote:
>
> subject dt-bindings: dmaengine: ....
>
> > Add `allwinner,sun60i-a733-dma` to the list of compatible strings for the
> > `sun50i-a64-dma` dtbinding documentation.
> >
> > While the A733 DMA controller shares many similarities with the sun50i-a64
> > DMA controller, it requires a specific configuration due to differences in:
> > - Interrupt register layout and mapping.
> > - Number of channels per interrupt register.
> > - Support for higher (32G) address widths in LLI parameters.
> >
> > Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> > ---
>
> After fix subject tags,
Do not change this unless you're respinning for another reason. dma v
dmaengine is not worth resubmission, especially since dma is far more
commonly used and is the directory name.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> > Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > index c3e14eb6cfff..1cc3304b7414 100644
> > --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> > @@ -25,6 +25,7 @@ properties:
> > - allwinner,sun50i-a64-dma
> > - allwinner,sun50i-a100-dma
> > - allwinner,sun50i-h6-dma
> > + - allwinner,sun60i-a733-dma
> > - items:
> > - const: allwinner,sun8i-r40-dma
> > - const: allwinner,sun50i-a64-dma
> > @@ -70,6 +71,7 @@ if:
> > - allwinner,sun20i-d1-dma
> > - allwinner,sun50i-a100-dma
> > - allwinner,sun50i-h6-dma
> > + - allwinner,sun60i-a733-dma
> >
> > then:
> > properties:
> >
> > --
> > 2.54.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Randy Dunlap @ 2026-06-22 16:40 UTC (permalink / raw)
To: Peter Zijlstra, Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Julia Lawall, Yury Norov, linux-doc, linux-kbuild, linuxppc-dev,
dri-devel, linux-stm32, linux-arm-kernel, linux-rdma, linux-usb,
linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260622083440.GX49951@noisy.programming.kicks-ass.net>
On 6/22/26 1:34 AM, Peter Zijlstra wrote:
> On Sun, Jun 21, 2026 at 05:34:30AM -0400, Steven Rostedt wrote:
>> There's been complaints about trace_printk() being defined in kernel.h as it
>> can increase the compilation time. As it is only used by some developers for
>> debugging purposes, it should not be in kernel.h causing lots of wasted CPU
>> cycles for those that do not ever care about it.
>>
>> Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
>> use it can set and not have to always remember to add #include <linux/trace_printk.h>
>> to the files they add trace_printk() while debugging. It also means that
>> those that do not have that config set will not have to worry about wasted
>> CPU cycles as it is only include in the CFLAGS when the option is set, and
>> its completely ignored otherwise.
>
> Did you forget your C 101 class? If you use a function, you gotta
> include the relevant header.
Also item #1 in Documentation/process/submit-checklist.rst.
> You don't see userspace saying: 'Hey, you know what, perhaps we should
> add stdio.h to every other header, just in case someone wants to
> printf()' either.
>
> I really don't understand your argument. Yes, maybe someone will forget
> and then either their editor (if they have a halfway modern setup with
> LSP enabled) or their build will complain, but so what? This is all
> trivial stuff, surely we have more pressing matters to concern outselves
> with?
--
~Randy
^ permalink raw reply
* Re: [PATCH net v3] net: airoha: fix BQL underflow in shared QDMA TX ring
From: Simon Horman @ 2026-06-22 16:39 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260620-airoha-bql-fixes-v3-1-76b95374e63e@kernel.org>
On Sat, Jun 20, 2026 at 05:04:51PM +0200, Lorenzo Bianconi wrote:
> When multiple netdevs share a QDMA TX ring and one device is stopped,
> netdev_tx_reset_subqueue() zeroes that device's BQL counters while its
> pending skbs remain in the shared HW TX ring. When NAPI later completes
> those skbs via netdev_tx_completed_queue(), the already-zeroed
> dql->num_queued counter underflows.
>
> Fix the issue:
> - Remove netdev_tx_reset_subqueue() from airoha_dev_stop() so pending
> skbs are completed naturally by NAPI with proper BQL accounting.
> - Rework airoha_qdma_tx_cleanup() to disable TX DMA, flush BQL
> counters, DMA-unmap and free all pending skbs while skb->dev
> references are still valid. Use a per-queue flushing flag checked
> under q->lock in airoha_dev_xmit() to prevent races between teardown
> and transmit. Call airoha_qdma_stop_napi() before
> airoha_qdma_tx_cleanup() at the call sites.
> - Move DMA engine start into probe. Split DMA teardown so TX DMA is
> disabled in airoha_qdma_tx_cleanup() and RX DMA in
> airoha_qdma_cleanup().
> - Remove qdma->users counter since DMA lifetime is now tied to
> probe/cleanup rather than per-netdev open/stop.
>
> Fixes: a9c2ca61fec7 ("net: airoha: Support multiple net_devices for a single FE GDM port")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> Changes in v3:
> - Remove airoha_qdma users counter.
> - Drop DEV_STATE_FLUSH bit and add per-queue flushing bool to avoid any
> race between airoha_qdma_tx_flush() and airoha_dev_xmit().
> - Refactor airoha_qdma_cleanup_tx_queue().
> - Rename airoha_qdma_cleanup_tx_queue() in airoha_qdma_tx_cleanup().
> - Link to v2: https://lore.kernel.org/r/20260619-airoha-bql-fixes-v2-1-4351d6a24484@kernel.org
>
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] pwm: add Axiado AX3000 PWM driver
From: Uwe Kleine-König @ 2026-06-22 16:29 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-pwm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-axiado-ax3000-pwm-v1-2-c9797a909414@axiado.com>
[-- Attachment #1: Type: text/plain, Size: 9646 bytes --]
Hello Petar,
Just a very high-level review:
On Thu, Jun 18, 2026 at 05:26:57AM -0700, Petar Stepanovic wrote:
> The Axiado AX3000 and AX3005 SoCs include PWM controllers that can be
> used to generate configurable PWM output signals.
>
> Add a PWM driver with support for configuring period, duty cycle, and
> enable state through the Linux PWM framework.
>
> Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
> ---
> MAINTAINERS | 1 +
> drivers/pwm/Kconfig | 11 +++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-axiado.c | 193 +++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 206 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 394c4a3527e8..db93fc235c32 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4319,6 +4319,7 @@ M: Prasad Bolisetty <pbolisetty@axiado.com>
> L: linux-pwm@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/pwm/axiado,ax3000-pwm.yaml
> +F: drivers/pwm/pwm-axiado.c
>
> AXIS ARTPEC ARM64 SoC SUPPORT
> M: Jesper Nilsson <jesper.nilsson@axis.com>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 6f3147518376..76f6c04b0e23 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -129,6 +129,17 @@ config PWM_ATMEL_TCB
> To compile this driver as a module, choose M here: the module
> will be called pwm-atmel-tcb.
>
> +config PWM_AXIADO
> + tristate "Axiado PWM support"
> + depends on ARCH_AXIADO || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> + PWM framework driver for the PWM controller found on Axiado
> + AX3000 and AX3005 SoCs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-axiado.
> +
> config PWM_AXI_PWMGEN
> tristate "Analog Devices AXI PWM generator"
> depends on MICROBLAZE || NIOS2 || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_INTEL_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0dc0d2b69025..4466a29e780a 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PWM_ARGON_FAN_HAT) += pwm-argon-fan-hat.o
> obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
> obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM) += pwm-atmel-hlcdc.o
> obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
> +obj-$(CONFIG_PWM_AXIADO) += pwm-axiado.o
> obj-$(CONFIG_PWM_AXI_PWMGEN) += pwm-axi-pwmgen.o
> obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
> obj-$(CONFIG_PWM_BCM_IPROC) += pwm-bcm-iproc.o
> diff --git a/drivers/pwm/pwm-axiado.c b/drivers/pwm/pwm-axiado.c
> new file mode 100644
> index 000000000000..db197886c5c4
> --- /dev/null
> +++ b/drivers/pwm/pwm-axiado.c
> @@ -0,0 +1,193 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2021-2026 Axiado Corporation.
Please add a Limitations paragraph here like the ones found in the newer
driver files. It should answer:
- Is a period completed on configuration change?
- Is a period completed on disable?
- How does the output behave when disabled? (Low? Inactive? Freeze? High-Z?)
Also mention special properties, like being unable to set 0% or 100%
relative duty.
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/math64.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +
> +/* Register offsets */
> +#define AX_PWM_CNTRL_REG 0x0000
> +#define AX_PWM_PERIOD_REG 0x0004
> +#define AX_PWM_HIGH_REG 0x0008
> +
> +/* PWM channels */
> +#define AX_PWM_NUM 1
This is only used once, and having
chip = devm_pwmchip_alloc(dev, 1, sizeof(*axpwm));
below simplifies grepping for channel numbers.
> +
> +/* Period and duty cycle limits */
> +#define AX_PWM_PERIOD_MIN 2
> +#define AX_PWM_PERIOD_MAX 0xfffffffeU
> +#define AX_PWM_DUTY_MIN 1
> +#define AX_PWM_DUTY_MAX 0xfffffffdU
The U suffix is not needed for hex constants (AFAIK).
> +
> +/* Control register bits */
> +#define AX_PWM_CTRL_ENABLE BIT(0)
> +#define AX_PWM_CTRL_DISABLE 0x0
> +
> +struct axiado_pwm_chip {
> + struct clk *clk;
> + void __iomem *base;
> +};
If you use axiado_pwm_ as prefix for structs and functions, please use
AXIADO_PWM_ as prefix for #defines.
> +
> +static int axiado_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + u64 duty_ns, u64 period_ns)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + unsigned long rate;
> + u64 period_cycles, duty_cycles;
> +
> + /*
> + * The hardware does not support a zero period, 0% duty cycle, or
> + * 100% duty cycle. The caller should handle 0% duty cycle by
> + * disabling the PWM.
> + */
> + if (!period_ns || !duty_ns || duty_ns >= period_ns)
> + return -EINVAL;
> +
> + rate = clk_get_rate(axpwm->clk);
> + if (!rate)
> + return -EINVAL;
> +
> + period_cycles = mul_u64_u64_div_u64(period_ns, rate, NSEC_PER_SEC);
> + if (period_cycles < AX_PWM_PERIOD_MIN ||
> + period_cycles > AX_PWM_PERIOD_MAX)
> + return -EINVAL;
> +
> + duty_cycles = mul_u64_u64_div_u64(duty_ns, rate, NSEC_PER_SEC);
> + if (duty_cycles < AX_PWM_DUTY_MIN ||
> + duty_cycles > AX_PWM_DUTY_MAX)
> + return -EINVAL;
> +
> + if (duty_cycles >= period_cycles)
> + return -EINVAL;
> +
> + writel((u32)period_cycles, axpwm->base + AX_PWM_PERIOD_REG);
> + writel((u32)duty_cycles, axpwm->base + AX_PWM_HIGH_REG);
> +
> + return 0;
> +}
> +
> +static int axiado_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + int ret;
> +
> + if (state->polarity != PWM_POLARITY_NORMAL)
> + return -EINVAL;
> +
> + if (!state->enabled || !state->duty_cycle) {
> + if (pwm->state.enabled)
> + writel(AX_PWM_CTRL_DISABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +
> + return 0;
> + }
> +
> + ret = axiado_pwm_config(chip, pwm, state->duty_cycle, state->period);
> + if (ret)
> + return ret;
> +
> + if (!pwm->state.enabled)
Ideally check hardware state and not PWM internal variables.
> + writel(AX_PWM_CTRL_ENABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +
> + return 0;
> +}
> +
> +static int axiado_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> + struct pwm_state *state)
> +{
> + struct axiado_pwm_chip *axpwm = pwmchip_get_drvdata(chip);
> + unsigned long rate;
> + u32 period_cycles;
> + u32 duty_cycles;
> + u32 ctrl;
> +
> + rate = clk_get_rate(axpwm->clk);
> + if (!rate)
> + return -EINVAL;
> +
> + ctrl = readl(axpwm->base + AX_PWM_CNTRL_REG);
> + period_cycles = readl(axpwm->base + AX_PWM_PERIOD_REG);
> + duty_cycles = readl(axpwm->base + AX_PWM_HIGH_REG);
> +
> + state->enabled = !!(ctrl & AX_PWM_CTRL_ENABLE);
> + state->period = mul_u64_u64_div_u64(period_cycles, NSEC_PER_SEC, rate);
> + state->duty_cycle = mul_u64_u64_div_u64(duty_cycles, NSEC_PER_SEC, rate);
> + state->polarity = PWM_POLARITY_NORMAL;
Please test your driver with PWM_DEBUG enabled, the rounding is wrong
here.
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops axiado_pwm_ops = {
> + .get_state = axiado_pwm_get_state,
> + .apply = axiado_pwm_apply,
Please implement the waveform callbacke instead of .get_state() and
.apply()
> +};
> +
> +static void axiado_pwm_disable(void *data)
> +{
> + struct axiado_pwm_chip *axpwm = data;
> +
> + writel(AX_PWM_CTRL_DISABLE, axpwm->base + AX_PWM_CNTRL_REG);
> +}
> +
> +static int axiado_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct axiado_pwm_chip *axpwm;
> + struct pwm_chip *chip;
> + int ret;
> +
> + chip = devm_pwmchip_alloc(dev, AX_PWM_NUM, sizeof(*axpwm));
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + axpwm = pwmchip_get_drvdata(chip);
> +
> + axpwm->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(axpwm->base))
> + return dev_err_probe(dev, PTR_ERR(axpwm->base),
> + "failed to map registers\n");
Start error messages with a capital letter please.
> +
> + ret = devm_add_action_or_reset(dev, axiado_pwm_disable, axpwm);
> + if (ret)
> + return ret;
This isn't supposed to happen. It's the responsibility of the consumer
to disable the PWM before it's freed.
> +
> +
Single empty line only.
> + axpwm->clk = devm_clk_get_enabled(dev, "pwm");
> + if (IS_ERR(axpwm->clk))
> + return dev_err_probe(dev, PTR_ERR(axpwm->clk),
> + "failed to get/enable clock\n");
Please ensure that the clk rate doesn't change while the PWM is enabled.
Then you can cache the clk rate and set chip->atomic.
> +
> + chip->ops = &axiado_pwm_ops;
> +
> + ret = devm_pwmchip_add(dev, chip);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to add PWM chip\n");
> +
> + return 0;
> +}
> +
> +static const struct of_device_id axiado_pwm_match[] = {
> + { .compatible = "axiado,ax3000-pwm" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, axiado_pwm_match);
> +
> +static struct platform_driver axiado_pwm_driver = {
> + .driver = {
> + .name = "axiado-pwm",
> + .of_match_table = axiado_pwm_match,
> + },
> + .probe = axiado_pwm_probe,
> +};
> +
> +module_platform_driver(axiado_pwm_driver);
No empty line between the driver struct and the module_platform helper
please.
> +
> +MODULE_AUTHOR("Axiado Corporation");
> +MODULE_DESCRIPTION("Axiado PWM driver");
> +MODULE_LICENSE("GPL");
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Disable PRI when no priq IRQ is available
From: Breno Leitao @ 2026-06-22 16:17 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: linux-arm-kernel, iommu, linux-kernel, rmikey, rneu, kernel-team,
Breno Leitao
When platform firmware advertises an SMMU as PRI-capable in IDR0.PRI
but does not assign a GSIV for its priq, arm_smmu_setup_unique_irqs()
warns and continues. ARM_SMMU_FEAT_PRI remains set, so the driver
still allocates the PRI queue, programs PRIQ_BASE/PROD/CONS, enables
IRQ_CTRL_PRIQ_IRQEN, and lets IOMMU_DEV_FEAT_IOPF be advertised to
upper layers. Page Request messages from devices land in a queue no
one drains, and SVA binds appear to succeed while silently dropping
every page fault.
Clear ARM_SMMU_FEAT_PRI in the missing-IRQ path so every PRI-gated
site in the driver consistently treats the SMMU as PRI-less, instead of
the half-baked stated.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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 a10affb483a4f..44bafbb38e242 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4659,7 +4659,8 @@ static void arm_smmu_setup_unique_irqs(struct arm_smmu_device *smmu)
dev_warn(smmu->dev,
"failed to enable priq irq\n");
} else {
- dev_warn(smmu->dev, "no priq irq - PRI will be broken\n");
+ dev_warn(smmu->dev, "no priq irq - disabling PRI\n");
+ smmu->features &= ~ARM_SMMU_FEAT_PRI;
}
}
}
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260622-smmu_pri-a33326900c33
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* Re: [PATCH net v2 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Simon Horman @ 2026-06-22 16:16 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <ajk0kS76nahtop8g@lore-desk>
On Mon, Jun 22, 2026 at 03:11:45PM +0200, Lorenzo Bianconi wrote:
> > On Fri, Jun 19, 2026 at 01:37:14PM +0200, Lorenzo Bianconi wrote:
> > > airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> > > index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> > > real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> > > channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> > > 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> > > accesses in the networking stack.
> > > For example, allocating channel 0 then channel 3 results in
> > > real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> > > Fix this by computing real_num_tx_queues based on the highest active
> > > channel index rather than using a simple counter, in both the allocation
> > > and deletion paths.
> > >
> > > Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >
> > Thanks for the update since v1.
> >
> > Reviewed-by: Simon Horman <horms@kernel.org>
>
> Hi Simon,
>
> thx for the review.
>
> >
> > FTR, there is an AI-generated review of this patch on sashiko.dev.
> > I do not think that should impede the progress of this patch but
> > you may want to consider it in the context of follow-up.
>
> Even if it is not introduced by this patch, I do not think what is reported
> by Sashiko is a real issue since airoha_eth driver implements
> ndo_select_queue() callback and the selected queue is always in the range
> [0, AIROHA_NUM_TX_RING[. HTB queues (in the range
> [AIROHA_NUM_TX_RING, AIROHA_NUM_TX_RING + AIROHA_NUM_QOS_CHANNELS[) are just
> 'offloaded' and never used in the TC sw path. Agree?
Thanks Lorenzo,
I've looked over this more closely with the above in mind and I agree.
^ permalink raw reply
* [soc:rfc-arm-deprecation-7.2] BUILD SUCCESS 1a31334b581c956c261b6618f03fa08041c6e95e
From: kernel test robot @ 2026-06-22 16:00 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git rfc-arm-deprecation-7.2
branch HEAD: 1a31334b581c956c261b6618f03fa08041c6e95e ARM: mark mv78xx0 support as deprecated
elapsed time: 740m
configs tested: 179
configs skipped: 137
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260622 gcc-8.5.0
arc randconfig-002-20260622 gcc-8.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260622 gcc-8.5.0
arm randconfig-002-20260622 gcc-8.5.0
arm randconfig-003-20260622 gcc-8.5.0
arm randconfig-004-20260622 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260622 gcc-8.5.0
arm64 randconfig-002-20260622 gcc-8.5.0
arm64 randconfig-003-20260622 gcc-8.5.0
arm64 randconfig-004-20260622 gcc-8.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260622 gcc-8.5.0
csky randconfig-002-20260622 gcc-8.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260622 gcc-8.5.0
hexagon randconfig-002-20260622 gcc-8.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260622 gcc-14
i386 buildonly-randconfig-002-20260622 gcc-14
i386 buildonly-randconfig-003-20260622 gcc-14
i386 buildonly-randconfig-004-20260622 gcc-14
i386 buildonly-randconfig-005-20260622 gcc-14
i386 buildonly-randconfig-006-20260622 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260622 clang-22
i386 randconfig-002-20260622 clang-22
i386 randconfig-003-20260622 clang-22
i386 randconfig-004-20260622 clang-22
i386 randconfig-005-20260622 clang-22
i386 randconfig-006-20260622 clang-22
i386 randconfig-007-20260622 clang-22
i386 randconfig-011-20260622 gcc-14
i386 randconfig-012-20260622 gcc-14
i386 randconfig-013-20260622 gcc-14
i386 randconfig-014-20260622 gcc-14
i386 randconfig-015-20260622 gcc-14
i386 randconfig-016-20260622 gcc-14
i386 randconfig-017-20260622 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260622 gcc-8.5.0
loongarch randconfig-002-20260622 gcc-8.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips qi_lb60_defconfig clang-17
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001-20260622 gcc-8.5.0
nios2 randconfig-002-20260622 gcc-8.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260622 gcc-14.3.0
parisc randconfig-002-20260622 gcc-14.3.0
parisc64 defconfig clang-23
powerpc akebono_defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260622 gcc-14.3.0
powerpc randconfig-002-20260622 gcc-14.3.0
powerpc64 randconfig-001-20260622 gcc-14.3.0
powerpc64 randconfig-002-20260622 gcc-14.3.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-16.1.0
sparc randconfig-001-20260622 gcc-16.1.0
sparc randconfig-002 gcc-16.1.0
sparc randconfig-002-20260622 gcc-16.1.0
sparc sparc32_defconfig gcc-16.1.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-16.1.0
sparc64 randconfig-001-20260622 gcc-16.1.0
sparc64 randconfig-002 gcc-16.1.0
sparc64 randconfig-002-20260622 gcc-16.1.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-16.1.0
um randconfig-001-20260622 gcc-16.1.0
um randconfig-002 gcc-16.1.0
um randconfig-002-20260622 gcc-16.1.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260622 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260622 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260622 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260622 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260622 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260622 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260622 clang-22
x86_64 randconfig-002-20260622 clang-22
x86_64 randconfig-003-20260622 clang-22
x86_64 randconfig-004-20260622 clang-22
x86_64 randconfig-005-20260622 clang-22
x86_64 randconfig-006-20260622 clang-22
x86_64 randconfig-011-20260622 clang-22
x86_64 randconfig-012-20260622 clang-22
x86_64 randconfig-013-20260622 clang-22
x86_64 randconfig-014-20260622 clang-22
x86_64 randconfig-015-20260622 clang-22
x86_64 randconfig-016-20260622 clang-22
x86_64 randconfig-071-20260622 gcc-14
x86_64 randconfig-072-20260622 gcc-14
x86_64 randconfig-073-20260622 gcc-14
x86_64 randconfig-074-20260622 gcc-14
x86_64 randconfig-075-20260622 gcc-14
x86_64 randconfig-076-20260622 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa generic_kc705_defconfig gcc-16.1.0
xtensa randconfig-001 gcc-16.1.0
xtensa randconfig-001-20260622 gcc-16.1.0
xtensa randconfig-002 gcc-16.1.0
xtensa randconfig-002-20260622 gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/8] power: sequencing: pcie-m2: Add PCI ID for NXP 88W9098 and AW693 Bluetooth
From: Manivannan Sadhasivam @ 2026-06-22 15:42 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, bhelgaas, brgl,
imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260618101047.4185497-3-sherry.sun@oss.nxp.com>
On Thu, Jun 18, 2026 at 06:10:41PM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> 88W9098 is a NXP Wi-Fi/BT combo chip with PCI device ID 0x2b43 under
> Marvell Extended vendor ID. AW693 is a NXP Wi-Fi/BT combo chip with
> PCI device ID 0x3003 under NXP/Philips vendor ID.
>
> Add both chips to pwrseq_m2_pci_ids[] so that the pwrseq-pcie-m2 driver
> can create the Bluetooth serdev device when these cards are inserted into
> a PCIe M.2 Key E connector.
>
> Both chips use "nxp,88w8987-bt" as the serdev compatible string, which
> is the entry point for the btnxpuart driver. The driver identifies the
> actual chip variant at runtime via chip ID auto-detection and loads the
> appropriate firmware accordingly.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/power/sequencing/pwrseq-pcie-m2.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
> index 94c3f4b7ee36..9217ffcfa6e5 100644
> --- a/drivers/power/sequencing/pwrseq-pcie-m2.c
> +++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
> @@ -186,6 +186,10 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
> }
>
> static const struct pci_device_id pwrseq_m2_pci_ids[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x2b43),
> + .driver_data = (kernel_ulong_t)"nxp,88w8987-bt" },
> + { PCI_DEVICE(PCI_VENDOR_ID_PHILIPS, 0x3003),
> + .driver_data = (kernel_ulong_t)"nxp,88w8987-bt" },
> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1107),
> .driver_data = (kernel_ulong_t)"qcom,wcn7850-bt" },
> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1103),
> --
> 2.50.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Bradley Morgan @ 2026-06-22 14:49 UTC (permalink / raw)
To: Marc Zyngier, Fuad Tabba
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <86y0g7q6jh.wl-maz@kernel.org>
On June 22, 2026 10:16:18 AM GMT+01:00, Marc Zyngier <maz@kernel.org>
wrote:
>On Mon, 22 Jun 2026 09:32:45 +0100,
>Fuad Tabba <fuad.tabba@linux.dev> wrote:
>>
>> On Sun, 21 Jun 2026 at 22:32, Bradley Morgan <include@grrlz.net> wrote:
>> >
>> > Protected guest faults charge long term pins to the VM's mm. Teardown
>> > can run later from file release, where current->mm may be unrelated.
>> >
>> > Drop the charge from kvm->mm instead.
>> >
>> > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to
>pkvm_pgtable_stage2_destroy()")
>> > Signed-off-by: Bradley Morgan <include@grrlz.net>
>>
>> Reproduced by creating a protected VM, running the vCPU to fault in a
>> page, then forking and having the child close the last fd reference.
>> Without the fix, the parent's VmLck leaks (the reclaim decrements the
>> child's mm, which is freed on exit). With the fix the parent's VmLck
>> returns to zero.
>>
>> One minor observation: account_locked_vm() also passes `current` as
>> the task pointer to __account_locked_vm(), but on the decrement path
>> that is only used in the pr_debug log line, so it is technically wrong
>> but functionally harmless.
I agree with marc here. Maybe awkward.
I tested it on my pixel 7! :)
>I don't think this is wrong. Awkward, maybe. It is just that the
>rlimit check and the accounting may be different contexts, and the
>pr_debug() call covers both inc and dec.
>
>>
>> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
>> Tested-by: Fuad Tabba < fuad.tabba@linux.dev>
Thanks for the review! :)
Cheers!
>Thanks,
>
> M.
>
>
^ permalink raw reply
* Re: [PATCH] pmdomain: bcm: bcm2835-power: Raise ASB poll timeout to 100us
From: Florian Fainelli @ 2026-06-22 15:29 UTC (permalink / raw)
To: Maíra Canal, Ulf Hansson,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Stefan Wahren
Cc: linux-pm, linux-rpi-kernel, linux-arm-kernel, kernel-dev
In-Reply-To: <20260530204636.1115120-1-mcanal@igalia.com>
On 5/30/2026 9:46 PM, Maíra Canal wrote:
> Commit 18605b1b936b ("pmdomain: bcm: bcm2835-power: Increase ASB control
> timeout") raised the ASB handshake polling budget from 1us to 5us.
> Surveying the pmdomain subsystem, 5us is still one of the smallest polling
> budgets by a wide margin. Comparable handshakes in other drivers use:
>
> - 100us : starfive jh71xx-pmu, apple pmgr-pwrstate
> - 1ms : renesas rcar-sysc, rmobile-sysc (power-on)
> - 10ms : renesas rcar-gen4-sysc, sunxi sun55i-pck600
> - 1s : mediatek mtk-pm-domains, mtk-scpsys
>
> Raise the BCM2835 timeout to 100us, matching analogous drivers. 100us is
> still negligible relative to a power-domain transition and gives the V3D
> master ASB substantially more headroom to drain under heavy workloads,
> assuring us that the timeout is enough for any scenario.
>
> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
The response I got from our design team is that turning of the the
"slave" should be immediate as it does not support multiple outstanding
transactions, it's the "master" that might requiring bleeding out
in-flight transactions and for which a longer timeout seems reasonable.
--
Florian
^ permalink raw reply
* Re: [PATCH] mfd: db8500-prcmu: Fold dbx500 header into db8500
From: Brian Masney @ 2026-06-22 15:29 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Ulf Hansson, Michael Turquette, Stephen Boyd,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Lee Jones,
Liam Girdwood, Mark Brown, Zhang Rui, Lukasz Luba,
Wim Van Sebroeck, Guenter Roeck, Jaroslav Kysela, Takashi Iwai,
linux-arm-kernel, linux-clk, linux-pm, linux-watchdog,
linux-sound, kernel test robot
In-Reply-To: <20260619-mfd-prcmu-merge-headers-v1-1-8ea0ee23b4d6@kernel.org>
On Fri, Jun 19, 2026 at 10:27:10PM +0200, Linus Walleij wrote:
> Move the DBx500 PRCMU definitions into the DB8500 PRCMU
> header and delete the wrapper header.
>
> Convert users of simple PRCMU wrappers to call the DB8500 helpers
> directly.
>
> The dbx500-prcmu.h header was the result of an earlier attempt to
> abstract several DBx5x SoC PRCMU units to use the same abstract
> header. They are deleted from the kernel and this is not just
> causing maintenance burden and build errors.
>
> The stub code is using -ENOSYS in a way checkpatch complains about
> so replace these with -EINVAL while we're at it.
>
> Assisted-by: Codex:gpt-5-5
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/
> Signed-off-by: Linus Walleij <linusw@kernel.org>
For clk:
Acked-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias
From: Kevin Brodsky @ 2026-06-22 15:23 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, catalin.marinas, will, Ard Biesheuvel, Fuad Tabba
In-Reply-To: <20260619163940.3185308-2-ardb+git@google.com>
On 19/06/2026 18:39, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Fuad reports that in some cases, the KVM init code may apply relocations
> to variables that reside in .data, and does so via the linear map. This
> means that remapping .data read-only beforehand is a bad idea, and
> results in an early boot crash.
>
> These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG or
> CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted in
> testing.
>
> So move the remap to mark_rodata_ro(), which is a reasonable place to
> put this, and ensures that it happens much later during the boot. It
> also means that rodata=off is now taken into account, and so the linear
> alias will remain writable in that case.
>
> Cc: Fuad Tabba <fuad.tabba@linux.dev>
> Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only in the linear map")
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/mm/mmu.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 9f354971b7e4..1f7eca86b5c1 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1198,11 +1198,6 @@ static void __init map_mem(void)
> __map_memblock(start, end, pgprot_tagged(PAGE_KERNEL),
> flags);
> }
> -
> - /* Map the kernel data/bss read-only in the linear map */
> - __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO, flags);
> - flush_tlb_kernel_range((unsigned long)lm_alias(__init_end),
> - (unsigned long)lm_alias(__bss_stop));
> }
>
> void mark_rodata_ro(void)
> @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void)
> update_mapping_prot(__pa_symbol(_text), (unsigned long)_text,
> (unsigned long)_stext - (unsigned long)_text,
> PAGE_KERNEL_RO);
> +
> + /* Map the kernel data/bss read-only in the linear map */
> + update_mapping_prot(__pa_symbol(__init_end),
> + (unsigned long)lm_alias(__init_end),
> + (unsigned long)__bss_stop - (unsigned long)__init_end,
> + PAGE_KERNEL_RO);
I was rather confused by this patch until I saw in master:
f102131c842d Revert "arm64: mm: Unmap kernel data/bss entirely from the
linear map"
81479b6888f8 Revert "arm64: mm: Defer remap of linear alias of data/bss"
... which explains the diff, but it looks like there are multiple issues
here. Is my understanding correct that these reverts fix kvm_arm_init()
because it needs to *read* from the linear map, while this new patch
fixes some KVM configurations that need to *write* to the linear map?
If so it might be good to give a recap in the commit message, because
the reverts are easy to miss.
It would also be good to explain why we can't do this in
mark_linear_text_alias_ro() (presumably because this is too early). I do
agree that honouring rodata=off is a good thing, though.
BTW, if only kvm_arm_init() needs to read the data/bss via the linear
map, maybe we can still unmap it later?
- Kevin
^ permalink raw reply
* Re: [PATCH v4 2/2] media: i2c: ov5640: Add reset controller support with GPIO fallback
From: Frank Li @ 2026-06-22 15:02 UTC (permalink / raw)
To: Philipp Zabel
Cc: robby.cai, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
sebastian.krzyszkowiak, slongerbeam, sakari.ailus, mchehab,
kieran.bingham, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <7ee62b699c5cabb00cd7706ea42573da81c5bc84.camel@pengutronix.de>
On Mon, Jun 22, 2026 at 11:05:34AM +0200, Philipp Zabel wrote:
> On Fr, 2026-06-19 at 09:18 -0500, Frank Li wrote:
> > On Fri, Jun 19, 2026 at 06:05:32PM +0800, robby.cai@oss.nxp.com wrote:
> > > [You don't often get email from robby.cai@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > From: Robby Cai <robby.cai@nxp.com>
> > >
> > > Add support for the reset controller framework by acquiring the reset
> > > line using devm_reset_control_get_optional_shared_deasserted(). This
> > > allows the driver to handle reset lines provided by a reset controller,
> > > including shared ones, while avoiding unbalanced deassert counts.
> > >
> > > Retain support for legacy reset-gpios as a fallback when no reset
> > > controller is defined. In that case, request the GPIO and keep it in the
> > > deasserted state as the initial configuration.
> > >
> > > This enables the driver to support both reset-controller-backed reset
> > > lines and older GPIO-based descriptions while preserving the existing
> > > power-up sequencing behavior.
> > >
> > > Signed-off-by: Robby Cai <robby.cai@nxp.com>
> > > ---
> > > drivers/media/i2c/ov5640.c | 80 +++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 70 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > > index 85ecc23b3587..5e6db8aacb11 100644
> > > --- a/drivers/media/i2c/ov5640.c
> > > +++ b/drivers/media/i2c/ov5640.c
> > > @@ -17,6 +17,7 @@
> > > #include <linux/module.h>
> > > #include <linux/pm_runtime.h>
> > > #include <linux/regulator/consumer.h>
> > > +#include <linux/reset.h>
> > > #include <linux/slab.h>
> > > #include <linux/types.h>
> > > #include <media/v4l2-async.h>
> > > @@ -442,6 +443,7 @@ struct ov5640_dev {
> > > u32 xclk_freq;
> > >
> > > struct regulator_bulk_data supplies[OV5640_NUM_SUPPLIES];
> > > + struct reset_control *reset;
> > > struct gpio_desc *reset_gpio;
> > > struct gpio_desc *pwdn_gpio;
> > > bool upside_down;
> > > @@ -2431,6 +2433,48 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
> > > return ov5640_set_framefmt(sensor, &sensor->fmt);
> > > }
> > >
> > > +static int ov5640_get_reset(struct device *dev, struct ov5640_dev *sensor)
> > > +{
> > > + /* use deasserted version to avoid unbalanced deassert counts */
> > > + sensor->reset =
> > > + devm_reset_control_get_optional_shared_deasserted(dev, NULL);
> > > + if (IS_ERR(sensor->reset))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset),
> > > + "Failed to get reset\n");
> > > + else if (sensor->reset)
> > > + return 0;
> > > +
> > > + /*
> > > + * fallback to legacy reset-gpios
> > > + * GPIOD_OUT_HIGH ensures deasserted state for ACTIVE_LOW reset
> > > + */
> > > + sensor->reset_gpio = devm_gpiod_get_optional(dev, "reset",
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(sensor->reset_gpio))
> > > + return dev_err_probe(dev, PTR_ERR(sensor->reset_gpio),
> > > + "Failed to get reset gpio");
> >
> > I think needn't fallback here, NO ABI change, just change to use reset-gpio
> > driver.
>
> Please keep the gpiod fallback, the reset-gpio driver may not be
> available on all platforms using ov5640.
Maybe try promote reset-gpio is default build in / as module. Leave such
fallback every where make code complex.
Krysztof:
Any suggestion?
Frank
>
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int ov5640_reset_assert(struct ov5640_dev *sensor)
> > > +{
> > > + if (sensor->reset)
> > > + return reset_control_assert(sensor->reset);
> >
> > needn't check sensor->reset, reset_control_assert() is no ops if NULL.
> >
> > > +
> > > + gpiod_set_value_cansleep(sensor->reset_gpio, 1);
> >
> > Needn't fallback, directly replace.
>
> See above.
>
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH] PCI: cadence: skip the link polling when endpoint not connected
From: Manivannan Sadhasivam @ 2026-06-22 14:52 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, vigneshr, s-vadapalli, lpieralisi, kwilczynski, robh,
bhelgaas, mpillai, unicorn_wang, me, 18255117159,
linux-arm-kernel, linux-kernel, danishanwar
In-Reply-To: <20260605071922.1724499-1-a-garg7@ti.com>
On Fri, Jun 05, 2026 at 12:49:22PM +0530, Aksh Garg wrote:
> cdns_pcie_host_wait_for_link() polls on link-up for 10 retries with a
> delay of 90-100ms each (~1 second). A call to cdns_pcie_host_link_setup()
> during the resume operation blocks the resume operation unnecessarily for
> ~1s even when no endpoint device is connected.
>
> Add skip_link_polling flag to track link state across suspend/resume
> cycles. If link was down before suspend, skip the expensive polling
> in resume since no endpoint was present.
>
Won't you need the delay if a device gets plugged while the host was suspended?
We had this same concern with the DWC drivers and we left the delay as-is as
nothing prevents an user to connect a device when the host was suspended.
- Mani
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
> drivers/pci/controller/cadence/pci-j721e.c | 5 +++++
> drivers/pci/controller/cadence/pcie-cadence-host-hpa.c | 3 +++
> drivers/pci/controller/cadence/pcie-cadence-host.c | 3 +++
> drivers/pci/controller/cadence/pcie-cadence.h | 3 +++
> 4 files changed, 14 insertions(+)
>
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index bfdfe98d5aba..849eb8bb9e45 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -686,6 +686,11 @@ static int j721e_pcie_suspend_noirq(struct device *dev)
> struct j721e_pcie *pcie = dev_get_drvdata(dev);
>
> if (pcie->mode == PCI_MODE_RC) {
> + struct cdns_pcie_rc *rc = cdns_pcie_to_rc(pcie->cdns_pcie);
> +
> + /* If link is down before suspend, skip polling in resume */
> + rc->skip_link_polling = !j721e_pcie_link_up(pcie->cdns_pcie);
> +
> gpiod_set_value_cansleep(pcie->reset_gpio, 0);
> clk_disable_unprepare(pcie->refclk);
> }
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
> index 0f540bed58e8..d78c1282a5ee 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
> @@ -301,6 +301,9 @@ int cdns_pcie_hpa_host_link_setup(struct cdns_pcie_rc *rc)
> return ret;
> }
>
> + if (rc->skip_link_polling)
> + return 0;
> +
> ret = cdns_pcie_host_wait_for_link(pcie, cdns_pcie_hpa_link_up);
> if (ret)
> dev_dbg(dev, "PCIe link never came up\n");
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index 0bc9e6e90e0e..026414c21ee1 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -352,6 +352,9 @@ int cdns_pcie_host_link_setup(struct cdns_pcie_rc *rc)
> return ret;
> }
>
> + if (rc->skip_link_polling)
> + return 0;
> +
> ret = cdns_pcie_host_start_link(rc, cdns_pcie_link_up);
> if (ret)
> dev_dbg(dev, "PCIe link never came up\n");
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> index 574e9cf4d003..01e49ecccc7b 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -117,6 +117,8 @@ struct cdns_pcie {
> * @no_inbound_map: Whether inbound mapping is supported
> * @quirk_broken_aspm_l0s: Disable ASPM L0s support as quirk
> * @quirk_broken_aspm_l1: Disable ASPM L1 support as quirk
> + * @skip_link_polling: Skip link polling in resume if link was down before
> + * suspend, to avoid long delay in resume
> */
> struct cdns_pcie_rc {
> struct cdns_pcie pcie;
> @@ -131,6 +133,7 @@ struct cdns_pcie_rc {
> unsigned int no_inbound_map:1;
> unsigned int quirk_broken_aspm_l0s:1;
> unsigned int quirk_broken_aspm_l1:1;
> + unsigned int skip_link_polling:1;
> };
>
> /**
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Liam R. Howlett @ 2026-06-22 14:50 UTC (permalink / raw)
To: Barry Song
Cc: Matthew Wilcox, Suren Baghdasaryan, Lorenzo Stoakes,
David Hildenbrand (Arm), akpm, linux-mm, vbabka, rppt, mhocko,
jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAGsJ_4ybg5LGYopTUJTh5R2rN6X3uR9xoJSL+RdTYVtm1-xqLg@mail.gmail.com>
On 26/06/22 08:15AM, Barry Song wrote:
> On Mon, Jun 22, 2026 at 4:49 AM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Sat, Jun 20, 2026 at 04:48:57PM -0700, Suren Baghdasaryan wrote:
> > > Just checking in on the followup plans. IIUC the RFC mentioned will
> > > try to implement the solution we discussed at LSFMM: splitting
> > > VM_FAULT_RETRY into two flags - one for retrying under per-VMA locks
> > > and another one to fallback to mmap_lock.
> >
> > I continue to hate this idea. I don't believe that those who were
> > pushing for it have ever tried to understand the whole fault path.
> > It's utterly byzantine.
> >
> > I defy anyone to make sense of this:
> >
> > /*
> > * NOTE! This will make us return with VM_FAULT_RETRY, but with
> > * the fault lock still held. That's how FAULT_FLAG_RETRY_NOWAIT
> > * is supposed to work. We have way too many special cases..
> > */
> > if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
> > return 0;
> >
> > *fpin = maybe_unlock_mmap_for_io(vmf, *fpin);
> > if (vmf->flags & FAULT_FLAG_KILLABLE) {
> > if (__folio_lock_killable(folio)) {
> > /*
> > * We didn't have the right flags to drop the
> > * fault lock, but all fault_handlers only check
> > * for fatal signals if we return VM_FAULT_RETRY,
> > * so we need to drop the fault lock here and
> > * return 0 if we don't have a fpin.
> > */
> > if (*fpin == NULL)
> > release_fault_lock(vmf);
> > return 0;
> > }
> >
> > Wed need to simplify the fault path, not add additional complexity.
> > Josef has said he wouldn't've done the lock dropping had we had per-VMA
> > locks. We should rip it out.
>
> I think you have agreed that, at least for anon vma, we can
> keep the current policy, since anon vma is much more volatile
> than file vma.
I don't think any of the above has to do with anon vmas. Does any anon
vma handling have anything to do with your problem?
This would be needed if anon vmas were being faulted while being
unmapped or merged? Do we really need a fast path for that? Note that
anon vmas cannot be merged if the vma chain... you know what, I wonder
how many people know what I'm talking about here... Let's just say that
they can't be merged if they were around for a fork.
So, then, we're looking at anon vmas taking the mmap lock on:
1. single task anon vmas being expanded and faulted at the same time
2. single task anon vmas being unmapped and faulted at the same time
I think that's it?
But maybe I missed something critical about your use case here?
I don't understand why you are involving anon vmas in this discussion,
so I must have missed something with your IO completion issue. Is there
an anon vma causing your priority inversion?
> Concurrent page faults and VMA modifications can happen more
> often than with file VMAs.
But it's only a problem for anon vmas with per-vma locking if it's the
same vma (or the vma lock sequence counter overflows, but let's say
that's a statistically insignificant non-zero value).
>
> For file vmas, how much code can we actually remove, given that
> the first page fault might already be holding mmap_lock?
How much complexity can we remove and maintain the performance, might be
a better question.
> It could be the case that lock_vma_under_rcu() fails, and then
> on the first page fault we end up holding mmap_lock before
> retrying. So are we also going to rip out the lock release,
> even if it risks holding mmap_lock for a long time?
>
> vma = lock_vma_under_rcu(mm, addr);
> if (!vma)
> goto lock_mmap;
> ...
> lock_mmap:
>
> vma = lock_mm_and_find_vma(mm, addr, regs);
> if (unlikely(!vma)) {
> fault = 0;
> si_code = SEGV_MAPERR;
> goto bad_area;
> }
>
> If we still need to keep the page fault retry code there, it
> doesn't seem like "ripping out" really reduces complexity in
> the page fault code?
This seems unrelated to be above complexity that might be the target of
removal?
Thanks,
Liam
^ permalink raw reply
* [PATCH] net: stmmac: fix missed le32_to_cpu()
From: Ben Dooks @ 2026-06-22 14:37 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), Ben Dooks, Maxime Chevallier, netdev,
linux-stm32, linux-arm-kernel, linux-kernel
The print in ndesc_display_ring() sends the des2 and des3
to the pr_info() without passing them through the relevant
conversion to cpu order.
Fix the (prototype) sparse warnings by using le32_to_cpu():
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 6 (different base types)
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des2
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 7 (different base types)
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des3
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index c4b613564f87..74c9b7b1fe8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -258,7 +258,7 @@ static void ndesc_display_ring(void *head, unsigned int size, bool rx,
pr_info("%03d [%pad]: 0x%x 0x%x 0x%x 0x%x",
i, &dma_addr,
(unsigned int)x, (unsigned int)(x >> 32),
- p->des2, p->des3);
+ le32_to_cpu(p->des2), le32_to_cpu(p->des3));
p++;
}
pr_info("\n");
--
2.37.2.352.g3c44437643
^ permalink raw reply related
* Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Geert Uytterhoeven @ 2026-06-22 14:37 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <8cb1c3cb-3d8f-4e76-99e9-ad78ee149556@mailbox.org>
Hi Marek,
On Mon, 22 Jun 2026 at 15:56, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 6/22/26 12:35 PM, Geert Uytterhoeven wrote:
> > On Sun, 21 Jun 2026 at 04:51, Marek Vasut
> > <marek.vasut+renesas@mailbox.org> wrote:
> >> Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
> >> which already has that soc: label. The soc: label is useful in U-Boot
> >> where it is used in U-Boot extras DT fragments.
> >>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >
> > For the whole series:
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > i.e. will queue in renesas-devel for v7.3, squashed into a single
> > commit. Unfortunately there is no cover letter, so I will have to add
> > all nine Link-tags.
>
> Is that why cover letter helps you ?
Another reason is that my scripting turns cover letters into empty
commits in my local tree, serving as separators between patch series.
> If so, I will start generating ones ?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 5/5] dmaengine: sun6i-dma: Add support for Allwinner A733 DMA controller
From: Frank Li @ 2026-06-22 14:35 UTC (permalink / raw)
To: Yuanshen Cao
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel
In-Reply-To: <20260622-sun60i-a733-dma-v3-5-f697ef296cbc@gmail.com>
On Mon, Jun 22, 2026 at 01:36:27AM +0000, Yuanshen Cao wrote:
> Support Allwinner A733 DMA controller. Define new register offsets,
> bitfield mappings and dma_config required for the A733, which slightly
> differs from the older `sun6i` DMA controllers.
>
> Changes:
> - New register macros for A733 interrupt enable `DMA_IRQ_EN_A733`,
> status `DMA_IRQ_STAT_A733`, and channel count `DMA_IRQ_CHAN_NR_A733`.
> - New `SRC_HIGH_ADDR_32G` and `DST_HIGH_ADDR_32G` macro to handle the
> 32G high-address field in the LLI.
> - Implemented `sun6i_dma_set_addr_a733` and A733-specific interrupt
> register accessors.
> - Added `sun60i_a733_dma_cfg`, which ties all the refactored
> functionality together for this specific hardware.
>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 196a0d73b221..4808015934cc 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -52,6 +52,15 @@
> #define SUNXI_H3_SECURE_REG 0x20
> #define SUNXI_H3_DMA_GATE 0x28
> #define SUNXI_H3_DMA_GATE_ENABLE 0x4
> +
> +/*
> + * sun60i specific registers
> + */
> +#define DMA_IRQ_EN_A733(x) ((x) * 0x40 + 0x134)
> +#define DMA_IRQ_STAT_A733(x) ((x) * 0x40 + 0x138)
> +
> +#define DMA_IRQ_CHAN_NR_A733 1
> +
> /*
> * Channels specific registers
> */
> @@ -100,6 +109,8 @@
> */
> #define SRC_HIGH_ADDR(x) (((x) & 0x3U) << 16)
> #define DST_HIGH_ADDR(x) (((x) & 0x3U) << 18)
> +#define SRC_HIGH_ADDR_32G(x) (((x) & 0x7U) << 11)
> +#define DST_HIGH_ADDR_32G(x) (((x) & 0x7U) << 15)
Because the previous code use this pattern, I provide my reviewed-by tags.
I suggest change to use GEN_MASK and FIELD_PREP macro in future.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> /*
> * Various hardware related defines
> @@ -257,6 +268,23 @@ static inline void sun6i_dma_dump_com_regs(struct sun6i_dma_dev *sdev)
> DMA_STAT, readl(sdev->base + DMA_STAT));
> }
>
> +static inline void sun6i_dma_dump_com_regs_a733(struct sun6i_dma_dev *sdev)
> +{
> + int i;
> +
> + for (i = 0; i < sdev->num_pchans / sdev->cfg->num_channels_per_reg; i++) {
> + dev_dbg(sdev->slave.dev, "Common register:\n"
> + "chan num %d\n"
> + "\tmask(%04x): 0x%08x\n"
> + "\tpend(%04x): 0x%08x\n"
> + "\tstats(%04x): 0x%08x\n",
> + i,
> + DMA_IRQ_EN_A733(i), readl(sdev->base + DMA_IRQ_EN_A733(i)),
> + DMA_IRQ_STAT_A733(i), readl(sdev->base + DMA_IRQ_STAT_A733(i)),
> + DMA_STAT, readl(sdev->base + DMA_STAT));
> + }
> +}
> +
> static inline void sun6i_dma_dump_chan_regs(struct sun6i_dma_dev *sdev,
> struct sun6i_pchan *pchan)
> {
> @@ -360,21 +388,41 @@ static u32 sun6i_read_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg)
> return readl(sdev->base + DMA_IRQ_EN(irq_reg));
> }
>
> +static u32 sun6i_read_irq_en_a733(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_EN_A733(irq_reg));
> +}
> +
> static void sun6i_write_irq_en(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> {
> writel(irq_val, sdev->base + DMA_IRQ_EN(irq_reg));
> }
>
> +static void sun6i_write_irq_en_a733(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 irq_val)
> +{
> + writel(irq_val, sdev->base + DMA_IRQ_EN_A733(irq_reg));
> +}
> +
> static u32 sun6i_read_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg)
> {
> return readl(sdev->base + DMA_IRQ_STAT(irq_reg));
> }
>
> +static u32 sun6i_read_irq_stat_a733(struct sun6i_dma_dev *sdev, u32 irq_reg)
> +{
> + return readl(sdev->base + DMA_IRQ_STAT_A733(irq_reg));
> +}
> +
> static void sun6i_write_irq_stat(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> {
> writel(status, sdev->base + DMA_IRQ_STAT(irq_reg));
> }
>
> +static void sun6i_write_irq_stat_a733(struct sun6i_dma_dev *sdev, u32 irq_reg, u32 status)
> +{
> + writel(status, sdev->base + DMA_IRQ_STAT_A733(irq_reg));
> +}
> +
> static size_t sun6i_get_chan_size(struct sun6i_pchan *pchan)
> {
> struct sun6i_desc *txd = pchan->desc;
> @@ -695,6 +743,17 @@ static void sun6i_dma_set_addr_a100(struct sun6i_dma_dev *sdev,
> DST_HIGH_ADDR(upper_32_bits(dst));
> }
>
> +static void sun6i_dma_set_addr_a733(struct sun6i_dma_dev *sdev,
> + struct sun6i_dma_lli *v_lli,
> + dma_addr_t src, dma_addr_t dst)
> +{
> + v_lli->src = lower_32_bits(src);
> + v_lli->dst = lower_32_bits(dst);
> +
> + v_lli->para |= SRC_HIGH_ADDR_32G(upper_32_bits(src)) |
> + DST_HIGH_ADDR_32G(upper_32_bits(dst));
> +}
> +
> static inline void sun6i_dma_set_addr(struct sun6i_dma_dev *sdev,
> struct sun6i_dma_lli *v_lli,
> dma_addr_t src, dma_addr_t dst)
> @@ -1339,6 +1398,33 @@ static struct sun6i_dma_config sun50i_h6_dma_cfg = {
> SUN6I_DMA_IRQ_A31_COMMON_OPS
> };
>
> +/*
> + * The A733 binding uses the number of dma channels from the
> + * device tree node.
> + */
> +static struct sun6i_dma_config sun60i_a733_dma_cfg = {
> + .clock_autogate_enable = sun6i_enable_clock_autogate_h3,
> + .set_burst_length = sun6i_set_burst_length_h3,
> + .set_drq = sun6i_set_drq_h6,
> + .set_mode = sun6i_set_mode_h6,
> + .set_addr = sun6i_dma_set_addr_a733,
> + .dump_com_regs = sun6i_dma_dump_com_regs_a733,
> + .read_irq_en = sun6i_read_irq_en_a733,
> + .write_irq_en = sun6i_write_irq_en_a733,
> + .read_irq_stat = sun6i_read_irq_stat_a733,
> + .write_irq_stat = sun6i_write_irq_stat_a733,
> + .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .num_channels_per_reg = DMA_IRQ_CHAN_NR_A733,
> + .has_mbus_clk = true,
> +};
> +
> /*
> * The V3s have only 8 physical channels, a maximum DRQ port id of 23,
> * and a total of 24 usable source and destination endpoints.
> @@ -1375,6 +1461,7 @@ static const struct of_device_id sun6i_dma_match[] = {
> { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
> { .compatible = "allwinner,sun50i-a100-dma", .data = &sun50i_a100_dma_cfg },
> { .compatible = "allwinner,sun50i-h6-dma", .data = &sun50i_h6_dma_cfg },
> + { .compatible = "allwinner,sun60i-a733-dma", .data = &sun60i_a733_dma_cfg },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
>
> --
> 2.54.0
>
^ 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