* [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-06-18 8:47 UTC (permalink / raw)
To: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki
Cc: baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
This patchset accelerates ioremap, vmalloc, and vmap when the memory
is physically fully or partially contiguous. Two techniques are used:
1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
segments
2. Use batched mappings wherever possible in both vmalloc and ARM64
layers
Besides accelerating the mapping path, this also enables large
mappings (PMD and cont-PTE) for vmap, which are currently not
supported.
Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
CONT-PTE regions instead of just one.
Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
mapping logic between the ioremap and vmalloc/vmap paths, handling both
CONT_PTE and regular PTE mappings. This prepares for the next patch.
Patch 4 extends the page table walk path to support page shifts other
than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
mappings. The function is renamed from vmap_small_pages_range_noflush()
to vmap_pages_range_noflush_walk().
Patches 5-6 add huge vmap support for contiguous pages, including
support for non-compound pages with pfn alignment verification.
On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
the performance CPUfreq policy enabled, benchmark results:
* ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
* vmalloc(1 MB) mapping time (excluding allocation) with
VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
* vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
Changes since v3:
- Squash vmap_pte_range() loop variable fix into patch 4 (patch 3, 4)
- Use shift >= PMD_SHIFT and fix *nr increment in
vmap_pages_pmd_range() (patch 4)
- Pass page_shift directly without capping at PMD_SHIFT (patch 4, 5)
- Add vm_shift() helper and pass pgprot_t to get_vmap_batch_order()
(patch 5)
- Use min(order, __ffs(pfn)) for graceful pfn alignment degradation,
replacing IS_ALIGNED check (patch 5)
- Remove irrelevant ioremap_max_page_shift early-exit (patch 5)
- Add __get_vm_area_node_aligned_caller() wrapper, rename to
vmap_get_aligned_vm_area() (patch 6)
Changes since v2:
- Use __fls instead of fls in arch_vmap_pte_range_map_size (patch 2)
- Add WARN_ON checks in vmap_pages_pmd_range (patch 4)
- Fix flush_cache_vmap to use saved start address instead of the
already-advanced addr (patch 5)
- Rename __vmap_huge() to vmap_batched() (patch 5)
- Add caller parameter and unroll while(1) loop (patch 5)
- Squash patch 7 into patch 5 (stop scanning for compound pages after
encountering small pages)
Changes since v1:
- Fix condition order and use PMD_SIZE instead of CONT_PMD_SIZE in
patch 1 (Dev Jain)
- Squash patch 3+4 and patch 5+7 (Dev Jain)
- Replace "zigzag" with "page table rewalk" in commit messages
(Dev Jain)
- Rename vmap_small_pages_range_noflush() to
vmap_pages_range_noflush_walk() (Dev Jain)
- Extract vmap_set_ptes() as a new patch to consolidate PTE mapping
logic between vmap_pte_range() and vmap_pages_pte_range(), handling
both CONT_PTE and regular mappings (Mike Rapoport)
- Support non-compound pages in get_vmap_batch_order() by falling
back to physical contiguity scanning with pfn alignment check
(Dev Jain, Uladzislau Rezki)
- In get_vmap_batch_order(), filter out orders that the architecture
cannot batch by checking arch_vmap_pte_supported_shift() directly.
This avoids overhead for orders 1-3 on ARM64 CONT_PTE with 4K
pages. (patch 5)
Barry Song (Xiaomi) (5):
arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE
setup
arm64/vmalloc: Allow arch_vmap_pte_range_map_size to batch multiple
CONT_PTE
mm/vmalloc: Extend page table walk to support larger page_shift sizes
and eliminate page table rewalk
mm/vmalloc: map contiguous pages in batches for vmap() if possible
mm/vmalloc: align vm_area so vmap() can batch mappings
Wen Jiang (1):
mm/vmalloc: Extract vmap_set_ptes() to consolidate PTE mapping logic
arch/arm64/include/asm/vmalloc.h | 6 +-
arch/arm64/mm/hugetlbpage.c | 10 ++
mm/vmalloc.c | 247 +++++++++++++++++++++++++------
3 files changed, 213 insertions(+), 50 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: display: vop2: Add missing reset properties
From: Cristian Ciocaltea @ 2026-06-18 8:39 UTC (permalink / raw)
To: Diederik de Haas, Sandy Huang, Heiko Stübner, Andy Yan,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli
Cc: kernel, Andy Yan, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <DJC0L3CRJ0WL.IZEYVLPROMM1@cknow-tech.com>
Hi Diederik,
On 6/18/26 10:58 AM, Diederik de Haas wrote:
> Hi Cristian,
>
> Thanks for this series :-) Just 1 nit (at the end) ...
>
> On Wed Jun 17, 2026 at 8:52 PM CEST, Cristian Ciocaltea wrote:
>> Document the VOP2 resets corresponding to the AXI, AHB and DCLK_VP0..2
>> clocks, which are common to all supported SoCs, plus DCLK_VP3 which is
>> provided only on RK3588.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> .../bindings/display/rockchip/rockchip-vop2.yaml | 42 ++++++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
>> index 93da1fb9adc4..d3bc5380f910 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
[...]
>> @@ -289,6 +321,16 @@ examples:
>> "dclk_vp0",
>> "dclk_vp1",
>> "dclk_vp2";
>> + resets = <&cru SRST_A_VOP>,
>> + <&cru SRST_H_VOP>,
>> + <&cru SRST_VOP0>,
>> + <&cru SRST_VOP1>,
>> + <&cru SRST_VOP2>;
>> + reset-names = "axi",
>> + "ahb",
>> + "dclk_vp0",
>> + "dclk_vp1",
>> + "dclk_vp2";
>> power-domains = <&power RK3568_PD_VO>;
>
> Place reset* props below power-domains (like in patch 9) ?
> So everyone who copies your example has the correct sorting order.
The example doesn't strictly follow that ordering either — see e.g. the iommus
property — so I placed the resets right after the clocks, which keeps the
related properties grouped together.
That said, I don't have a strong preference.
Heiko, is there a convention you'd like the Rockchip bindings to follow here?
Happy to reorder if so.
Regards,
Cristian
>
> Cheers,
> Diederik
>
>> rockchip,grf = <&grf>;
>> iommus = <&vop_mmu>;
>
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-18 8:38 UTC (permalink / raw)
To: Marek Vasut
Cc: Marek Vasut, linux-pci, Yoshihiro Shimoda,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <0935eb67-83d2-49ea-89ab-0d0aa51ead8a@mailbox.org>
On Thu, 18 Jun 2026 03:50:29 +0100,
Marek Vasut <marek.vasut@mailbox.org> wrote:
>
> On 6/17/26 9:24 AM, Marc Zyngier wrote:
>
> Hello Marc,
>
> >> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> >> or APB interface configured to 32 bit, it can therefore access only
> >> the first 4 GiB of physical address space. This information comes from
> >> R-Car V4H Interface Specification sheet, there is currently no technical
> >> update number assigned to this limitation. Further input from hardware
> >> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> >> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> >> limitation.
>
> My concern is this ^ , I do not have an erratum number, because there
> isn't one. I am in touch with the hardware engineer and I did get a
> glimpse at internal details of the three SoC, which confirm the
> limitations. Is this sufficient ?
To be honest, this is between you and the SoC vendor. I'll take
whatever symbol you come up with at face value, and will assume that
the vendor agrees with it. After all, they are on Cc and have their
SoB on the patch.
>
> >> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
> >> common for many ARM GICv3 implementations. Therefore, add an extra
> >
> > Not quite. It designates GIC600 unambiguously.
>
> What I am trying to communicate is, that the 0x0201743b ID is not ID
> of the Renesas GIC implementation, but it is a generic ARM GIC600
> ID. That is why we cannot match the quirk on the ID (it is generic ARM
> GIC600 ID), and instead we have to match the quirk on the [ ID
> combined with of_machine_is_compatible("renesas,...") ].
This is understood, and is no different from the other broken
platforms in the tree.
>
> > It is just that GIC600
> > is integrated in zillions of SoCs, most of which don't have this
> > problem (the machine I'm typing this from has a GIC600 *and* 96GB of
> > RAM).
>
> Right.
>
> Shall I reword this paragraph somehow to make it clearer ?
I'd simply say that the workaround is keyed on the combination of the
GIC implementation and the platform identification in the device tree.
>
> >> of_machine_is_compatible() check.
> >>
> >> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
> >
> > Is this relevant?
>
> I included it for the sake of completeness and to provide all relevant
> information, based on previous discussions about similar limitations
> that I could find on lore.k.o
This information is already contained in the ID you quote (bits
[19:12]), and can be decoded using the public TRM [1].
Thanks,
M.
[1] https://documentation-service.arm.com/static/5e7ddddacbfe76649ba53034
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Aneesh Kumar K.V @ 2026-06-18 8:37 UTC (permalink / raw)
To: Alexey Kardashevskiy, Jason Gunthorpe, Catalin Marinas
Cc: 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: <2ecfa1a8-6202-4319-9692-a6ffeb5a3dbf@amd.com>
Alexey Kardashevskiy <aik@amd.com> writes:
> On 10/6/26 00:47, Jason Gunthorpe wrote:
>> On Tue, Jun 09, 2026 at 02:43:08PM +0100, Catalin Marinas wrote:
>>> On Thu, Jun 04, 2026 at 02:09:39PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>>> This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
>>>> dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
>>>> are handled consistently.
>>>>
>>>> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
>>>> shared/decrypted buffer handling. This series consolidates the
>>>> force_dma_unencrypted() checks in the top-level functions and ensures
>>>> that the remaining DMA interfaces use DMA attributes to make the correct
>>>> decisions.
>>>
>>> Please check Sashiko's reports, it has some good points:
>>>
>>> https://sashiko.dev/#/patchset/20260604083959.1265923-1-aneesh.kumar@kernel.org
>>>
>>> I think the main one is the swiotlb_tbl_map_single() changes which break
>>> AMD SME host support. There cc_platform_has(CC_ATTR_MEM_ENCRYPT) is true
>>> but force_dma_unencrypted() is false. Normally you'd not end up on this
>>> path but you can have swiotlb=force.
>>
>> IMHO that's an AMD issue, not with the design of this series..
>>
>> The series is right, a device that is !force_dma_decrypted() must be
>> considerd to be a trusted device and we must never place any DMA
>> mappings for a trusted device into shared memory.
>
>
> swiotlb=force forces swiotlb, not decryption.
>
>> That AMD has done somethine insane:
>>
>> bool force_dma_unencrypted(struct device *dev)
>> {
>> /*
>> * For SEV, all DMA must be to unencrypted addresses.
>> */
>> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>> return true;
>>
>> /*
>> * For SME, all DMA must be to unencrypted addresses if the
>> * device does not support DMA to addresses that include the
>> * encryption mask.
>> */
>> if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
>> u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
>> u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
>> dev->bus_dma_limit);
>>
>> if (dma_dev_mask <= dma_enc_mask)
>> return true;
>> }
>
>
> So when I try "mem_encrypt=on iommu=pt swiotlb=force" with this patchset, it fails to boot. But it boots with a hack like this:
>
> ===
> @@ -39,7 +41,7 @@ bool force_dma_unencrypted(struct device *dev)
> return true;
> }
>
> - return false;
> + return swiotlb_force_bounce;
> }
> ===
>
> Or we say "mem_encrypt=on iommu=pt swiotlb=force" combo is just weird and we won't be supporting which bit in this? Thanks,
>
Something like?
modified arch/x86/mm/mem_encrypt.c
@@ -34,6 +34,13 @@ bool force_dma_unencrypted(struct device *dev)
u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
dev->bus_dma_limit);
+ /*
+ * With memory encryption enabled, SWIOTLB is marked decrypted.
+ * If SWIOTLB bouncing is forced, treat the device as requiring
+ * decrypted DMA.
+ */
+ if (is_swiotlb_force_bounce(dev))
+ return true;
if (dma_dev_mask <= dma_enc_mask)
return true;
-aneesh
^ permalink raw reply
* Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Philipp Zabel @ 2026-06-18 8:30 UTC (permalink / raw)
To: Joakim Zhang, Conor Dooley
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Gary Yang, cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <SEYPR06MB62262C0F7823337CA9496DE982E32@SEYPR06MB6226.apcprd06.prod.outlook.com>
On Do, 2026-06-18 at 01:43 +0000, Joakim Zhang wrote:
> Hello,
>
>
> > -----Original Message-----
> > From: Conor Dooley <conor@kernel.org>
> > Sent: Wednesday, June 17, 2026 11:56 PM
> > To: Joakim Zhang <joakim.zhang@cixtech.com>
> > Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> > robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> > p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> > upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> > clock controller
> >
> > On Wed, Jun 17, 2026 at 02:04:35PM +0800, joakim.zhang@cixtech.com wrote:
> > > From: Joakim Zhang <joakim.zhang@cixtech.com>
> > >
> > > The AUDSS CRU contains an internal clock tree of muxes, dividers and
> > > gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider
> > > is a child node of the cix,sky1-audss-system-control syscon and
> > > accesses registers through the parent MMIO region.
> >
> > Why can this not just be part of the parent syscon node?
>
> The clock and reset blocks are handled by different subsystems and maintainers (clk vs reset). Putting the clock provider on the parent syscon node would mean a single driver has to register both the reset controller and the clock provider on one device, which doesn't fit well.
There are many examples of clock and reset drivers sharing the same
node, by using platform_driver for one (usually clk) and
auxiliary_driver for the other (usually reset).
regards
Philipp
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Fix VCMDQ indexing in tegra241_vintf0_handle_error
From: lirongqing @ 2026-06-18 7:59 UTC (permalink / raw)
To: Thierry Reding, Krishna Reddy, Will Deacon, Robin Murphy,
Joerg Roedel, Jonathan Hunter, Nicolin Chen, Nate Watterson,
Jason Gunthorpe, linux-tegra, linux-arm-kernel, iommu,
linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
In tegra241_vintf0_handle_error(), the driver loops through the
LVCMDQ_ERR_MAP_64(i) registers to detect and handle error flags for
each virtual command queue (VCMDQ).
However, the code erroneously uses the register-local bit offset
returned by __ffs64(map) directly as the global logical queue index
(lidx) into the vintf->lvcmdqs[] array. When 'i' is greater than 0
(i.e., handling queues 64 and above), this logic incorrectly targets
the queues in the first block (0-63) instead of the intended queues
(i * 64 + bit). This leads to handling errors on the wrong VCMDQ
structures and clearing the wrong hardware error status.
Fix this by properly decoupling the register-local bit offset from the
global array index. Use the local bit offset to clear the local map
snapshot, and use 'i * 64 + bit' to correctly index the global
vintf->lvcmdqs[] array.
Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
index 67be62a..33ec466 100644
--- a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
+++ b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
@@ -317,13 +317,14 @@ static void tegra241_vintf0_handle_error(struct tegra241_vintf *vintf)
u64 map = readq_relaxed(REG_VINTF(vintf, LVCMDQ_ERR_MAP_64(i)));
while (map) {
- unsigned long lidx = __ffs64(map);
+ unsigned long bit = __ffs64(map);
+ unsigned long lidx = i * 64 + bit;
struct tegra241_vcmdq *vcmdq = vintf->lvcmdqs[lidx];
u32 gerror = readl_relaxed(REG_VCMDQ_PAGE0(vcmdq, GERROR));
__arm_smmu_cmdq_skip_err(&vintf->cmdqv->smmu, &vcmdq->cmdq);
writel(gerror, REG_VCMDQ_PAGE0(vcmdq, GERRORN));
- map &= ~BIT_ULL(lidx);
+ map &= ~BIT_ULL(bit);
}
}
}
--
2.9.4
^ permalink raw reply related
* Re: [PATCH 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
From: Fuad Tabba @ 2026-06-18 8:18 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, linux-arm-kernel, kvmarm, linux-kernel,
Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff
In-Reply-To: <86o6h8s2gx.wl-maz@kernel.org>
On Thu, 18 Jun 2026 at 09:00, Marc Zyngier <maz@kernel.org> wrote:
>
> On Sun, 14 Jun 2026 17:33:33 +0100,
> Fuad Tabba <tabba@google.com> wrote:
> >
> > The FPAC syndrome constructed during nested ERET emulation does not set
> > IL. For FPAC (EC=0x1C), IL reflects the instruction length. ERET and
> > its authenticated variants are always A64 32-bit instructions, so IL
> > must be 1.
> >
> > Fixes: 213b3d1ea161 ("KVM: arm64: nv: Handle ERETA[AB] instructions")
> > Signed-off-by: Fuad Tabba <tabba@google.com>
> > ---
> > arch/arm64/kvm/emulate-nested.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index dba7ced74ca5..4b39363cf891 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2777,7 +2777,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
> > */
> > if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
> > esr &= ESR_ELx_ERET_ISS_ERETA;
> > - esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC);
> > + esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC) | ESR_ELx_IL;
>
> In general, I prefer retaining information that is present in the
> source exception, rather than adding arbitrary bits without much
> context, even if we only support AArch64 for NV. In this case, I'd
> rather see this:
>
> esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);
Sounds good to me. I'll rebase on 7.1 and respin.
Cheers,
/fuad
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates
From: Sebastian Andrzej Siewior @ 2026-06-18 8:15 UTC (permalink / raw)
To: Runyu Xiao, Mark Brown
Cc: Viresh Kumar, Linus Walleij, Clark Williams, Steven Rostedt,
linux-arm-kernel, soc, linux-gpio, linux-rt-devel, linux-kernel,
jianhao.xu
In-Reply-To: <20260618023418.213453-1-runyu.xiao@seu.edu.cn>
On 2026-06-18 10:34:18 [+0800], Runyu Xiao wrote:
> Hi,
Hi,
…
> The repair I am considering is to keep the gpiolib resource updates in
> the fast irq_enable/irq_disable callbacks, but defer the actual PLGPIO
> IE/EIT register writes to irq_bus_sync_unlock(), after the IRQ core has
> dropped desc->lock. The driver would keep per-line shadow state for:
>
> - IRQ disabled/enabled state
> - pending IE update
> - edge direction state
> - pending EIT update
>
> and then synchronize those shadow updates from irq_bus_sync_unlock()
> under a mutex.
Not sure how this will look like, but okay. I was looking at making the
a lock a raw_spinlock_t for fast_io. Since it is just a read and write
it shouldn't be a problem. But then there is the regcache and the sync
of many registers might be painful. The actual problem is the type MAPLE
and RBTREE which have an allocation in their write callback. That is a
no but the FLAT ones should work since there is just one alloc during
init. Well, wouldn't it be for the lock that is acquired during the
callback.
I don't think this is required given that it is init time so
holding the lock shouldn't be required. This was introduced in commit
fd4ebc07b4dff ("regmap: Hold the regmap lock when allocating and freeing
the cache"). This change broke gpio-104-idio-16.c, pio-pci-idio-16.c,
pio-pcie-idio-24, gpio-ws16c48.c and pinctrl-apple-gpio.c.
So unless there is something that I miss…
> In other words, the fast callbacks would only update local shadow state
> and call gpiochip_enable_irq()/gpiochip_disable_irq(), while the sleepable
> regmap writes would be batched into the irq bus sync phase.
>
> Does that sound like an acceptable direction for SPEAr PLGPIO, or would
> you prefer a different fix, such as changing the underlying syscon regmap
> locking model or handling only the IE register path?
>
> The draft patch I have locally is roughly:
>
> pinctrl: spear: defer PLGPIO IRQ updates to bus sync
>
> and it changes only drivers/pinctrl/spear/pinctrl-plgpio.c.
>
> Thanks,
> Runyu
Sebastian
^ permalink raw reply
* Re: [PATCH] docs: arm64: Document that text_offset is always 0
From: Rasmus Villemoes @ 2026-06-18 8:02 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Ard Biesheuvel, Will Deacon, Jonathan Corbet, linux-doc,
linux-kernel
In-Reply-To: <20260604140839.1930847-1-linux@rasmusvillemoes.dk>
On Thu, Jun 04 2026, "Rasmus Villemoes" <linux@rasmusvillemoes.dk> wrote:
> When trying to figure out where to place and call an arm64 Image in
> memory, reading booting.rst should provide the answer. However, it
> requires quite some digging to figure out that text_offset is set via
> ".quad 0" in head.S and is thus actually always 0 since v5.10.
>
> Update the documentation and make that explicit. Reword the 2MB
> requirement accordingly, and remove the paragraphs that only apply to
> the ancient versions where text_offset could be non-zero, as they only
> confuse a current reader.
>
ping
^ permalink raw reply
* Re: [PATCH 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
From: Marc Zyngier @ 2026-06-18 7:59 UTC (permalink / raw)
To: Fuad Tabba
Cc: Oliver Upton, linux-arm-kernel, kvmarm, linux-kernel,
Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff
In-Reply-To: <20260614163336.3490925-5-tabba@google.com>
On Sun, 14 Jun 2026 17:33:33 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> The FPAC syndrome constructed during nested ERET emulation does not set
> IL. For FPAC (EC=0x1C), IL reflects the instruction length. ERET and
> its authenticated variants are always A64 32-bit instructions, so IL
> must be 1.
>
> Fixes: 213b3d1ea161 ("KVM: arm64: nv: Handle ERETA[AB] instructions")
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> arch/arm64/kvm/emulate-nested.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index dba7ced74ca5..4b39363cf891 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2777,7 +2777,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
> */
> if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
> esr &= ESR_ELx_ERET_ISS_ERETA;
> - esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC);
> + esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC) | ESR_ELx_IL;
In general, I prefer retaining information that is present in the
source exception, rather than adding arbitrary bits without much
context, even if we only support AArch64 for NV. In this case, I'd
rather see this:
esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: display: vop2: Add missing reset properties
From: Diederik de Haas @ 2026-06-18 7:58 UTC (permalink / raw)
To: Cristian Ciocaltea, Sandy Huang, Heiko Stübner, Andy Yan,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli
Cc: kernel, Andy Yan, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260617-dw-hdmi-qp-yuv-v1-1-a665cfd06d7d@collabora.com>
Hi Cristian,
Thanks for this series :-) Just 1 nit (at the end) ...
On Wed Jun 17, 2026 at 8:52 PM CEST, Cristian Ciocaltea wrote:
> Document the VOP2 resets corresponding to the AXI, AHB and DCLK_VP0..2
> clocks, which are common to all supported SoCs, plus DCLK_VP3 which is
> provided only on RK3588.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> .../bindings/display/rockchip/rockchip-vop2.yaml | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> index 93da1fb9adc4..d3bc5380f910 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> @@ -82,6 +82,20 @@ properties:
> - {}
> - {}
>
> + resets:
> + minItems: 5
> + maxItems: 6
> +
> + reset-names:
> + minItems: 5
> + items:
> + - const: axi
> + - const: ahb
> + - const: dclk_vp0
> + - const: dclk_vp1
> + - const: dclk_vp2
> + - const: dclk_vp3
> +
> rockchip,grf:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> @@ -148,6 +162,12 @@ allOf:
> clock-names:
> maxItems: 5
>
> + resets:
> + maxItems: 5
> +
> + reset-names:
> + maxItems: 5
> +
> interrupts:
> maxItems: 1
>
> @@ -194,6 +214,12 @@ allOf:
> - {}
> - const: pll_hdmiphy0
>
> + resets:
> + maxItems: 5
> +
> + reset-names:
> + maxItems: 5
> +
> interrupts:
> minItems: 4
>
> @@ -246,6 +272,12 @@ allOf:
> - const: pll_hdmiphy0
> - const: pll_hdmiphy1
>
> + resets:
> + minItems: 6
> +
> + reset-names:
> + minItems: 6
> +
> interrupts:
> maxItems: 1
>
> @@ -289,6 +321,16 @@ examples:
> "dclk_vp0",
> "dclk_vp1",
> "dclk_vp2";
> + resets = <&cru SRST_A_VOP>,
> + <&cru SRST_H_VOP>,
> + <&cru SRST_VOP0>,
> + <&cru SRST_VOP1>,
> + <&cru SRST_VOP2>;
> + reset-names = "axi",
> + "ahb",
> + "dclk_vp0",
> + "dclk_vp1",
> + "dclk_vp2";
> power-domains = <&power RK3568_PD_VO>;
Place reset* props below power-domains (like in patch 9) ?
So everyone who copies your example has the correct sorting order.
Cheers,
Diederik
> rockchip,grf = <&grf>;
> iommus = <&vop_mmu>;
^ permalink raw reply
* Re: [PATCHv2] arm64/entry: Fix arm64-specific rseq brokenness
From: Mathias Stearn @ 2026-06-18 7:55 UTC (permalink / raw)
To: Will Deacon
Cc: Jinjie Ruan, Mark Rutland, linux-arm-kernel, Catalin Marinas,
Peter Zijlstra, Thomas Gleixner, ckennelly, dvyukov, linux-kernel,
mathieu.desnoyers
In-Reply-To: <ailagpgcDGVoXgm0@willie-the-truck>
On Wed, Jun 10, 2026 at 2:37 PM Will Deacon <will@kernel.org> wrote:
>
> On Tue, Jun 09, 2026 at 02:04:23PM +0200, Mathias Stearn wrote:
> > Is it possible to get 411c1cf43039 backported to 7.0 or was it omitted
> > intentionally?
>
> You can send a backport to the stable maintainers:
>
> https://docs.kernel.org/process/stable-kernel-rules.html#procedure-for-submitting-patches-to-the-stable-tree
Who was that "you" directed at? I'm not used to the kernel development
process. Is that my responsibility as the bug reporter / interested
party, or something that Mark Rutland, author of the patch, should do?
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add retry mechanism to airoha_qdma_set_trtcm_param()
From: Leto Liu (刘涛) @ 2026-06-18 7:52 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, netdev@vger.kernel.org,
Brown Huang (黃柏翰)
In-Reply-To: <aiqHgJ6FiAMu5gmF@lore-desk>
>I think the issue reported by sashiko in [0] is valid and it needs to be addressed in v2, but since I am not the original author of the patch, I will let Brown or Leto comment on it.
>
>Regards,
>Lorenzo
>
Thanks for the careful review — you are absolutely right.
In the current version, the immediate call to airoha_qdma_get_trtcm_param() can indeed clobber the write command we just issued. That helper programs REG_TRTCM_CFG_PARAM() to start a read transaction, so without first waiting for TRTCM_PARAM_RW_DONE_MASK after the write, we may overwrite the command register before the hardware has latched/finished the write. The added wmb() only enforces the ordering between the DATA and CFG writes, but it does not guarantee the write transaction has completed.
I will address this by restoring the DONE polling after the write, and only then performing the read-back verification (i.e. “write → poll DONE → read-back → compare”, with retries as needed). Also, to avoid clobbering the val argument, the poll will use a separate temporary variable.
I have revised the patch into a v2 version based on this approach, and it is currently under testing and validation. Since this is an intermittent issue, I am running long-duration stability tests. I expect to provide the v2 patch by next Monday.
Best Regards, Leto
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Lorenzo Bianconi @ 2026-06-18 7:42 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166704952.2212140.11002626760717132754@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]
> In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
> using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
>
> Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
> computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
> - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
> - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
> - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
> - channel 3: clears bit 24..31 (channel 3 only) - correct by accident
>
> While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
> mask parameter, the loop still incorrectly clears queues within the
> same channel beyond queue 7.
>
> Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
I guess it is ok now if you respin this patch on top of net branch.
If so, please add my Acked-by.
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..a1eda13400 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2217,7 +2217,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
> struct airoha_gdm_port *port = netdev_priv(dev);
> int i;
>
> - for (i = 0; i < AIROHA_NUM_TX_RING; i++)
> + for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
> airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 2/2] ARM: dts: aspeed: sanmiguel: add current-range property for PDB HSC
From: Mike Hsieh @ 2026-06-18 7:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Potin Lai, Mik Lin, Mike Hsieh, Mike Hsieh
In-Reply-To: <20260618-sanmiguel-dts-config-hsc-lm5066i-v1-0-cccf959c9b78@gmail.com>
Configure the ti,current-range property for the four TI LM5066i
hot-swap controllers on PDB board.
This defines the hardware current limit operating mode (low/high)
for each sensor to match the physical board design.
Specific configurations:
- HSC1 (0x11): low
- HSC2 (0x13): high
- HSC3 (0x15): high
- HSC4 (0x17): low
Signed-off-by: Mike Hsieh <mike.quanta.115@gmail.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index 3faac0925a79..e518e3fc1c97 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -451,6 +451,7 @@ pdb_ti_hsc1: power-monitor@11 {
compatible = "ti,lm5066i";
reg = <0x11>;
shunt-resistor-micro-ohms = <1000>;
+ ti,current-range = "low";
};
pdb_mps_hsc2: power-monitor@12 {
@@ -462,6 +463,7 @@ pdb_ti_hsc2: power-monitor@13 {
compatible = "ti,lm5066i";
reg = <0x13>;
shunt-resistor-micro-ohms = <321>;
+ ti,current-range = "high";
};
pdb_mps_hsc3: power-monitor@14 {
@@ -473,6 +475,7 @@ pdb_ti_hsc3: power-monitor@15 {
compatible = "ti,lm5066i";
reg = <0x15>;
shunt-resistor-micro-ohms = <321>;
+ ti,current-range = "high";
};
pdb_mps_hsc4: power-monitor@16 {
@@ -484,6 +487,7 @@ pdb_ti_hsc4: power-monitor@17 {
compatible = "ti,lm5066i";
reg = <0x17>;
shunt-resistor-micro-ohms = <500>;
+ ti,current-range = "low";
};
pdb_ioexp_20: gpio@20 {
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: aspeed: sanmiguel: fix PDB HSC shunt resistor
From: Mike Hsieh @ 2026-06-18 7:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Potin Lai, Mik Lin, Mike Hsieh, Mike Hsieh
In-Reply-To: <20260618-sanmiguel-dts-config-hsc-lm5066i-v1-0-cccf959c9b78@gmail.com>
Correct the shunt-resistor-micro-ohms values for the four TI LM5066i
hot-swap controllers on the PDB. This ensures accurate current and
power sensor readings from the hardware monitors.
Signed-off-by: Mike Hsieh <mike.quanta.115@gmail.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index d7ed497d7227..3faac0925a79 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -450,7 +450,7 @@ pdb_mps_hsc1: power-monitor@10 {
pdb_ti_hsc1: power-monitor@11 {
compatible = "ti,lm5066i";
reg = <0x11>;
- shunt-resistor-micro-ohms = <763>;
+ shunt-resistor-micro-ohms = <1000>;
};
pdb_mps_hsc2: power-monitor@12 {
@@ -461,7 +461,7 @@ pdb_mps_hsc2: power-monitor@12 {
pdb_ti_hsc2: power-monitor@13 {
compatible = "ti,lm5066i";
reg = <0x13>;
- shunt-resistor-micro-ohms = <294>;
+ shunt-resistor-micro-ohms = <321>;
};
pdb_mps_hsc3: power-monitor@14 {
@@ -472,7 +472,7 @@ pdb_mps_hsc3: power-monitor@14 {
pdb_ti_hsc3: power-monitor@15 {
compatible = "ti,lm5066i";
reg = <0x15>;
- shunt-resistor-micro-ohms = <294>;
+ shunt-resistor-micro-ohms = <321>;
};
pdb_mps_hsc4: power-monitor@16 {
@@ -483,7 +483,7 @@ pdb_mps_hsc4: power-monitor@16 {
pdb_ti_hsc4: power-monitor@17 {
compatible = "ti,lm5066i";
reg = <0x17>;
- shunt-resistor-micro-ohms = <381>;
+ shunt-resistor-micro-ohms = <500>;
};
pdb_ioexp_20: gpio@20 {
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: aspeed: sanmiguel: configure LM5066i HSCs for PDB
From: Mike Hsieh @ 2026-06-18 7:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Potin Lai, Mik Lin, Mike Hsieh, Mike Hsieh
This patch series updates the device tree configurations for
the four TI LM5066i hot-swap controllers (HSCs) on the Power
Distribution Board (PDB) for the sanmiguel platform.
Signed-off-by: Mike Hsieh <mike.quanta.115@gmail.com>
---
Mike Hsieh (2):
ARM: dts: aspeed: sanmiguel: fix PDB HSC shunt resistor
ARM: dts: aspeed: sanmiguel: add current-range property for PDB HSC
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
---
base-commit: 57596c043ad59cf2e53fadebf6d1b418190e3a49
change-id: 20260618-sanmiguel-dts-config-hsc-lm5066i-70f40e1b3c2e
Best regards,
--
Mike Hsieh <mike.quanta.115@gmail.com>
^ permalink raw reply
* Re: Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates
From: Viresh Kumar @ 2026-06-18 7:40 UTC (permalink / raw)
To: Runyu Xiao, Herve Codina
Cc: Viresh Kumar, Linus Walleij, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, linux-arm-kernel, soc, linux-gpio,
linux-rt-devel, linux-kernel, jianhao.xu
In-Reply-To: <20260618023418.213453-1-runyu.xiao@seu.edu.cn>
+ Herve (the last guy to work on this driver).
On 18-06-26, 10:34, Runyu Xiao wrote:
> Hi,
>
> While auditing GPIO/pinctrl irqchip callbacks, our static analysis tool
> flagged the SPEAr PLGPIO irq_enable path, and we manually reviewed it
> against the current tree.
>
> The path is:
>
> irq_startup()
> -> plgpio_irq_enable()
> -> gpiochip_enable_irq()
> -> spin_lock_irqsave(&plgpio->lock)
> -> plgpio_reg_reset()
> -> regmap_update_bits()
>
> On PREEMPT_RT, plgpio->lock is a regular spinlock_t and can become a
> sleeping lock. Since irq_enable/irq_disable can be called from IRQ
> management paths while the IRQ descriptor raw lock is held, taking that
> regular spinlock there looks unsafe.
>
> A minimal Lockdep reproducer preserving this irq_chip::irq_enable carrier
> reports:
>
> BUG: sleeping function called from invalid context
> irqs_disabled(): 1
> plgpio_rt_spin_lock_irqsave
> plgpio_irq_enable
> request_threaded_irq_probe_path
>
> My first thought was to convert the PLGPIO register lock to
> raw_spinlock_t. However, that does not seem sufficient because the IE/EIT
> updates go through regmap_update_bits()/regmap_read()/regmap_write(). For
> the syscon/MMIO regmap used here, regmap may still take its own regular
> fast-IO lock unless the regmap was created with use_raw_spinlock. So a
> raw_spinlock_t conversion in the PLGPIO driver alone may just move the
> PREEMPT_RT problem one level down into regmap.
>
> The repair I am considering is to keep the gpiolib resource updates in
> the fast irq_enable/irq_disable callbacks, but defer the actual PLGPIO
> IE/EIT register writes to irq_bus_sync_unlock(), after the IRQ core has
> dropped desc->lock. The driver would keep per-line shadow state for:
>
> - IRQ disabled/enabled state
> - pending IE update
> - edge direction state
> - pending EIT update
>
> and then synchronize those shadow updates from irq_bus_sync_unlock()
> under a mutex.
>
> In other words, the fast callbacks would only update local shadow state
> and call gpiochip_enable_irq()/gpiochip_disable_irq(), while the sleepable
> regmap writes would be batched into the irq bus sync phase.
>
> Does that sound like an acceptable direction for SPEAr PLGPIO, or would
> you prefer a different fix, such as changing the underlying syscon regmap
> locking model or handling only the IE register path?
>
> The draft patch I have locally is roughly:
>
> pinctrl: spear: defer PLGPIO IRQ updates to bus sync
>
> and it changes only drivers/pinctrl/spear/pinctrl-plgpio.c.
I haven't worked on this for a very long time now (15 yrs). There are some
people who use this hardware, and so it is not removed until now.
Also I am not sure if RT kernel is a valid use case here for this SoC family.
--
viresh
^ permalink raw reply
* Re: [PATCH] net: airoha: Stop TX queues on error path in airoha_dev_open
From: Lorenzo Bianconi @ 2026-06-18 7:33 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Wayen Yan, netdev, horms, pabeni, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260617164448.31e189bc@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
> On Tue, 16 Jun 2026 18:50:39 +0800 Wayen Yan wrote:
> > In airoha_dev_open(), if airoha_set_vip_for_gdm_port() fails after
> > netif_tx_start_all_queues() has been called, the TX queues remain
> > started while the device configuration is incomplete. This leaves
> > the device in an inconsistent state where packets could be
> > transmitted before the VIP/IFC port configuration is complete.
>
> Not sure if this was superseded by another posting but FWIW
> this posting did not apply.
I think we do not need this patch.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 4/4] arm64: tegra: Reorder reg and reg-names to match bindings
From: Manivannan Sadhasivam @ 2026-06-18 7:27 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
Aksh Garg, linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding
In-Reply-To: <20260617-tegra264-pcie-v7-4-eae7ae964629@nvidia.com>
On Wed, Jun 17, 2026 at 06:01:31PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The ECAM region cannot be the first entry in the "reg" property, because
> in that case the unit-address wouldn't match the first entry. The order
> of the nodes can also not be changed to match the ECAM entry because the
> ECAM region is global and outside of any of the control busses.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> Changes in v5:
> - rebase onto v7.1-rc1
>
> Changes in v4:
> - revert ECAM "reg" entry order
>
> Changes in v2:
> - order ECAM "reg" entry before others
> ---
> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 48 ++++++++++++++++----------------
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> index 8f4350c7793b..4c701abd25a8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
> @@ -3513,11 +3513,11 @@ cmdqv4: cmdqv@b200000 {
>
> pci@c000000 {
> compatible = "nvidia,tegra264-pcie";
> - reg = <0xd0 0xb0000000 0x0 0x10000000>,
> - <0x00 0x0c000000 0x0 0x00004000>,
> + reg = <0x00 0x0c000000 0x0 0x00004000>,
> <0x00 0x0c004000 0x0 0x00001000>,
> - <0x00 0x0c005000 0x0 0x00001000>;
> - reg-names = "ecam", "xal", "xtl", "xtl-pri";
> + <0x00 0x0c005000 0x0 0x00001000>,
> + <0xd0 0xb0000000 0x0 0x10000000>;
> + reg-names = "xal", "xtl", "xtl-pri", "ecam";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -3893,12 +3893,12 @@ gpio_uphy: gpio@8300000 {
>
> pci@8400000 {
> compatible = "nvidia,tegra264-pcie";
> - reg = <0xa8 0xb0000000 0x0 0x10000000>,
> - <0x00 0x08400000 0x0 0x00004000>,
> + reg = <0x00 0x08400000 0x0 0x00004000>,
> <0x00 0x08404000 0x0 0x00001000>,
> <0x00 0x08405000 0x0 0x00001000>,
> - <0x00 0x08410000 0x0 0x00010000>;
> - reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
> + <0x00 0x08410000 0x0 0x00010000>,
> + <0xa8 0xb0000000 0x0 0x10000000>;
> + reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -3925,12 +3925,12 @@ pci@8400000 {
>
> pci@8420000 {
> compatible = "nvidia,tegra264-pcie";
> - reg = <0xb0 0xb0000000 0x0 0x10000000>,
> - <0x00 0x08420000 0x0 0x00004000>,
> + reg = <0x00 0x08420000 0x0 0x00004000>,
> <0x00 0x08424000 0x0 0x00001000>,
> <0x00 0x08425000 0x0 0x00001000>,
> - <0x00 0x08430000 0x0 0x00010000>;
> - reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
> + <0x00 0x08430000 0x0 0x00010000>,
> + <0xb0 0xb0000000 0x0 0x10000000>;
> + reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -3957,12 +3957,12 @@ pci@8420000 {
>
> pci@8440000 {
> compatible = "nvidia,tegra264-pcie";
> - reg = <0xb8 0xb0000000 0x0 0x10000000>,
> - <0x00 0x08440000 0x0 0x00004000>,
> + reg = <0x00 0x08440000 0x0 0x00004000>,
> <0x00 0x08444000 0x0 0x00001000>,
> <0x00 0x08445000 0x0 0x00001000>,
> - <0x00 0x08450000 0x0 0x00010000>;
> - reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
> + <0x00 0x08450000 0x0 0x00010000>,
> + <0xb8 0xb0000000 0x0 0x10000000>;
> + reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -3989,12 +3989,12 @@ pci@8440000 {
>
> pci@8460000 {
> compatible = "nvidia,tegra264-pcie";
> - reg = <0xc0 0xb0000000 0x0 0x10000000>,
> - <0x00 0x08460000 0x0 0x00004000>,
> + reg = <0x00 0x08460000 0x0 0x00004000>,
> <0x00 0x08464000 0x0 0x00001000>,
> <0x00 0x08465000 0x0 0x00001000>,
> - <0x00 0x08470000 0x0 0x00010000>;
> - reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
> + <0x00 0x08470000 0x0 0x00010000>,
> + <0xc0 0xb0000000 0x0 0x10000000>;
> + reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> @@ -4021,12 +4021,12 @@ pci@8460000 {
>
> pci@8480000 {
> compatible = "nvidia,tegra264-pcie";
> - reg = <0xc8 0xb0000000 0x0 0x10000000>,
> - <0x00 0x08480000 0x0 0x00004000>,
> + reg = <0x00 0x08480000 0x0 0x00004000>,
> <0x00 0x08484000 0x0 0x00001000>,
> <0x00 0x08485000 0x0 0x00001000>,
> - <0x00 0x08490000 0x0 0x00010000>;
> - reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
> + <0x00 0x08490000 0x0 0x00010000>,
> + <0xc8 0xb0000000 0x0 0x10000000>;
> + reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
>
> --
> 2.54.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v7 3/4] PCI: tegra: Add Tegra264 support
From: Manivannan Sadhasivam @ 2026-06-18 7:26 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
Aksh Garg, linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <20260617-tegra264-pcie-v7-3-eae7ae964629@nvidia.com>
On Wed, Jun 17, 2026 at 06:01:30PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
> driver is very small, with its main purpose being to set up the address
> translation registers and then creating a standard PCI host using ECAM.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v7:
> - select PCI_ECAM to satisfy the build dependency (Jonathan Hunter)
> - remove pre-silicon support patch to avoid extra build dependency
>
> Changes in v6:
> - remove unneeded pm_runtime_disable() call (Sashiko)
> - do not use noirq suspend/resume callbacks (Sashiko)
> - wrap PM ops in pm_ptr() macro (Sashiko)
> - use standard wait times with msleep() (Lukas Wunner)
> - properly check errors for wake IRQs
> - fix build failures /o\
>
> Changes in v5:
> - make PCIE_TEGRA264 symbol tristate
> - drop dependency on PCI_MSI
> - reorganize tegra264_pcie struct
> - use standard wake-gpios property
> - rename tegra264_pcie_bpmp_set_rp_state() to tegra264_pcie_power_off()
> - use dev_err() instead of dev_info() for some error messages
> - add clarifying comment as to why bandwidth requests aren't fatal
> - address some compiler warnings on 32-bit physical address platforms
> - drop needless comments
> - explicitly deinitialize controller on suspend
> - use devm_pm_runtime_active_enabled()
> - rename "free" label to "free_ecam"
> - use dev_err_probe() in more places
> - reselect default pin state during resume, not probe
> - return early on absence of wake GPIO
> - simplify BW value calculation
>
> Changes in v2:
> - specify generations applicable for PCI_TEGRA driver to avoid confusion
> - drop SPDX-FileCopyrightText tag
> - rename link_state to link_up to clarify meaning
> - replace memset() by an empty initializer
> - sanity-check only enable BAR regions
> - bring PCI link out of reset in case firmware didn't
> - use common wait times instead of defining our own
> - use core helpers to parse and print PCI link speed
> - fix multi-line comment
> - use dev_err_probe() more ubiquitously
> - fix probe sequence and error cleanup
> - use DEFINE_NOIRQ_DEV_PM_OPS() to avoid warnings for !PM_SUSPEND
> - reuse more standard registers and remove unused register definitions
> - use %pe and ERR_PTR() to print symbolic errors
> - add signed-off-by from Manikanta as the original author
> - add myself as author after significantly modifying the driver
>
> pcie: remove pre-silicon conditionals
> ---
> drivers/pci/controller/Kconfig | 10 +-
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-tegra264.c | 538 +++++++++++++++++++++++++++++++++
> 3 files changed, 548 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 2247709ef6d6..3045c8aecc7e 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -255,7 +255,15 @@ config PCI_TEGRA
> select IRQ_MSI_LIB
> help
> Say Y here if you want support for the PCIe host controller found
> - on NVIDIA Tegra SoCs.
> + on NVIDIA Tegra SoCs (Tegra20 through Tegra186).
> +
> +config PCIE_TEGRA264
> + tristate "NVIDIA Tegra264 PCIe controller"
> + depends on ARCH_TEGRA || COMPILE_TEST
> + select PCI_ECAM
> + help
> + Say Y here if you want support for the PCIe host controller found
> + on NVIDIA Tegra264 SoCs.
>
> config PCIE_RCAR_HOST
> bool "Renesas R-Car PCIe controller (host mode)"
> diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
> index ac8db283f0fe..d478743b5142 100644
> --- a/drivers/pci/controller/Makefile
> +++ b/drivers/pci/controller/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PCI_HYPERV_INTERFACE) += pci-hyperv-intf.o
> obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
> obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
> +obj-$(CONFIG_PCIE_TEGRA264) += pcie-tegra264.o
> obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
> obj-$(CONFIG_PCIE_RCAR_HOST) += pcie-rcar.o pcie-rcar-host.o
> obj-$(CONFIG_PCIE_RCAR_EP) += pcie-rcar.o pcie-rcar-ep.o
> diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> new file mode 100644
> index 000000000000..e2d295ea4403
> --- /dev/null
> +++ b/drivers/pci/controller/pcie-tegra264.c
> @@ -0,0 +1,538 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * PCIe host controller driver for Tegra264 SoC
> + *
> + * Copyright (c) 2022-2026, NVIDIA CORPORATION. All rights reserved.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/init.h>
> +#include <linux/interconnect.h>
> +#include <linux/interrupt.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci-ecam.h>
> +#include <linux/pci.h>
> +#include <linux/pinctrl/consumer.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/pm_wakeirq.h>
> +
> +#include <soc/tegra/bpmp.h>
> +#include <soc/tegra/bpmp-abi.h>
> +#include <soc/tegra/fuse.h>
> +
> +#include "../pci.h"
> +
> +/* XAL registers */
> +#define XAL_RC_ECAM_BASE_HI 0x00
> +#define XAL_RC_ECAM_BASE_LO 0x04
> +#define XAL_RC_ECAM_BUSMASK 0x08
> +#define XAL_RC_IO_BASE_HI 0x0c
> +#define XAL_RC_IO_BASE_LO 0x10
> +#define XAL_RC_IO_LIMIT_HI 0x14
> +#define XAL_RC_IO_LIMIT_LO 0x18
> +#define XAL_RC_MEM_32BIT_BASE_HI 0x1c
> +#define XAL_RC_MEM_32BIT_BASE_LO 0x20
> +#define XAL_RC_MEM_32BIT_LIMIT_HI 0x24
> +#define XAL_RC_MEM_32BIT_LIMIT_LO 0x28
> +#define XAL_RC_MEM_64BIT_BASE_HI 0x2c
> +#define XAL_RC_MEM_64BIT_BASE_LO 0x30
> +#define XAL_RC_MEM_64BIT_LIMIT_HI 0x34
> +#define XAL_RC_MEM_64BIT_LIMIT_LO 0x38
> +#define XAL_RC_BAR_CNTL_STANDARD 0x40
> +#define XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN BIT(0)
> +#define XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN BIT(1)
> +#define XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN BIT(2)
> +
> +/* XTL registers */
> +#define XTL_RC_PCIE_CFG_LINK_STATUS 0x5a
> +
> +#define XTL_RC_MGMT_PERST_CONTROL 0x218
> +#define XTL_RC_MGMT_PERST_CONTROL_PERST_O_N BIT(0)
> +
> +#define XTL_RC_MGMT_CLOCK_CONTROL 0x47c
> +#define XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT BIT(9)
> +
> +struct tegra264_pcie {
> + struct device *dev;
> +
> + /* I/O memory */
> + void __iomem *xal;
> + void __iomem *xtl;
> + void __iomem *ecam;
> +
> + /* bridge configuration */
> + struct pci_config_window *cfg;
> + struct pci_host_bridge *bridge;
> +
> + /* wake IRQ */
> + struct gpio_desc *wake_gpio;
> + unsigned int wake_irq;
> +
> + /* BPMP and bandwidth management */
> + struct icc_path *icc_path;
> + struct tegra_bpmp *bpmp;
> + u32 ctl_id;
> +
> + bool link_up;
> +};
> +
> +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + int err;
> +
> + pcie->wake_gpio = devm_gpiod_get_optional(dev, "wake", GPIOD_IN);
> + if (IS_ERR(pcie->wake_gpio))
> + return PTR_ERR(pcie->wake_gpio);
> +
> + if (!pcie->wake_gpio)
> + return 0;
> +
> + err = gpiod_to_irq(pcie->wake_gpio);
> + if (err < 0)
> + return dev_err_probe(dev, err, "failed to get wake IRQ\n");
> +
> + pcie->wake_irq = (unsigned int)err;
> +
> + err = devm_device_init_wakeup(dev);
> + if (err < 0)
> + return dev_err_probe(dev, err, "failed to initialize wakeup\n");
> +
> + err = devm_pm_set_wake_irq(dev, pcie->wake_irq);
> + if (err < 0)
> + return dev_err_probe(dev, err, "failed to set wakeup IRQ\n");
> +
I'd really like to get rid of custom WAKE# handling in the controller drivers.
Krishna is trying to add generic WAKE# handling in the PCI core and I'd suggest
you to take a look at the patches:
https://lore.kernel.org/linux-pci/20260511-wakeirq_support-v10-2-c10af9c9eb8c@oss.qualcomm.com/
But this also means that you need to use switch to Root Port binding to move the
Root Port properties out of the controller node. This is something we are
mandating for the new controllers. Not a big change though...
Reference:
Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml#n80
> + return 0;
> +}
> +
> +static void tegra264_pcie_power_off(struct tegra264_pcie *pcie)
> +{
> + struct tegra_bpmp_message msg = {};
> + struct mrq_pcie_request req = {};
> + int err;
> +
> + req.cmd = CMD_PCIE_RP_CONTROLLER_OFF;
> + req.rp_ctrlr_off.rp_controller = pcie->ctl_id;
> +
> + msg.mrq = MRQ_PCIE;
> + msg.tx.data = &req;
> + msg.tx.size = sizeof(req);
> +
> + err = tegra_bpmp_transfer(pcie->bpmp, &msg);
> + if (err)
> + dev_err(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
> + pcie->ctl_id, ERR_PTR(err));
> +
> + if (msg.rx.ret)
> + dev_err(pcie->dev, "failed to turn off PCIe #%u: %d\n",
> + pcie->ctl_id, msg.rx.ret);
> +}
> +
> +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
> +{
> + u32 value, speed, width;
> + int err;
> +
> + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> +
> + value = Mbps_to_icc(width * PCIE_SPEED2MBS_ENC(pcie_link_speed[speed]));
> +
> + /*
> + * We don't want to error out here because a boot-critical device
> + * could be connected to this root port. Failure to set the bandwidth
> + * request may have an adverse impact on performance, but it is not
> + * generally fatal, so we opt to continue regardless so that users
> + * get a chance to fix things.
> + */
> + err = icc_set_bw(pcie->icc_path, value, value);
> + if (err < 0)
> + dev_err(pcie->dev,
> + "failed to request bandwidth (%u MBps): %pe\n",
> + value, ERR_PTR(err));
> +}
> +
> +/*
> + * The various memory regions used by the controller (I/O, memory, ECAM) are
> + * set up during early boot and have hardware-level protections in place. If
> + * the DT ranges don't match what's been setup, the controller won't be able
> + * to write the address endpoints properly, so make sure to validate that DT
> + * and firmware programming agree on these ranges.
> + */
> +static bool tegra264_pcie_check_ranges(struct platform_device *pdev)
> +{
> + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
> + struct device_node *np = pcie->dev->of_node;
> + struct of_pci_range_parser parser;
> + phys_addr_t phys, limit, hi, lo;
> + struct of_pci_range range;
> + struct resource *res;
> + bool status = true;
> + u32 value;
> + int err;
> +
> + err = of_pci_range_parser_init(&parser, np);
> + if (err < 0)
> + return false;
> +
> + for_each_of_pci_range(&parser, &range) {
> + unsigned int addr_hi, addr_lo, limit_hi, limit_lo, enable;
> + unsigned long type = range.flags & IORESOURCE_TYPE_BITS;
> + phys_addr_t start, end, mask;
> + const char *region = NULL;
> +
> + end = range.cpu_addr + range.size - 1;
> + start = range.cpu_addr;
> +
> + switch (type) {
> + case IORESOURCE_IO:
> + addr_hi = XAL_RC_IO_BASE_HI;
> + addr_lo = XAL_RC_IO_BASE_LO;
> + limit_hi = XAL_RC_IO_LIMIT_HI;
> + limit_lo = XAL_RC_IO_LIMIT_LO;
> + enable = XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN;
> + mask = SZ_64K - 1;
> + region = "I/O";
> + break;
> +
> + case IORESOURCE_MEM:
> + if (range.flags & IORESOURCE_PREFETCH) {
> + addr_hi = XAL_RC_MEM_64BIT_BASE_HI;
> + addr_lo = XAL_RC_MEM_64BIT_BASE_LO;
> + limit_hi = XAL_RC_MEM_64BIT_LIMIT_HI;
> + limit_lo = XAL_RC_MEM_64BIT_LIMIT_LO;
> + enable = XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN;
> + region = "prefetchable memory";
> + } else {
> + addr_hi = XAL_RC_MEM_32BIT_BASE_HI;
> + addr_lo = XAL_RC_MEM_32BIT_BASE_LO;
> + limit_hi = XAL_RC_MEM_32BIT_LIMIT_HI;
> + limit_lo = XAL_RC_MEM_32BIT_LIMIT_LO;
> + enable = XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN;
> + region = "memory";
> + }
> +
> + mask = SZ_1M - 1;
> + break;
> + }
> +
> + /* not interested in anything that's not I/O or memory */
> + if (!region)
> + continue;
> +
> + /* don't check regions that haven't been enabled */
> + value = readl(pcie->xal + XAL_RC_BAR_CNTL_STANDARD);
> + if ((value & enable) == 0)
> + continue;
> +
> + hi = readl(pcie->xal + addr_hi);
> + lo = readl(pcie->xal + addr_lo);
> + phys = ((hi << 16) << 16) | lo;
> +
> + hi = readl(pcie->xal + limit_hi);
> + lo = readl(pcie->xal + limit_lo);
> + limit = ((hi << 16) << 16) | lo | mask;
> +
> + if (phys != start || limit != end) {
> + dev_err(pcie->dev,
> + "%s region mismatch: %pap-%pap -> %pap-%pap\n",
> + region, &phys, &limit, &start, &end);
> + status = false;
> + }
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
> + if (!res)
> + return false;
> +
> + hi = readl(pcie->xal + XAL_RC_ECAM_BASE_HI);
> + lo = readl(pcie->xal + XAL_RC_ECAM_BASE_LO);
> + phys = ((hi << 16) << 16) | lo;
> +
> + value = readl(pcie->xal + XAL_RC_ECAM_BUSMASK);
> + limit = phys + ((value + 1) << 20) - 1;
> +
> + if (phys != res->start || limit != res->end) {
> + dev_err(pcie->dev,
> + "ECAM region mismatch: %pap-%pap -> %pap-%pap\n",
> + &phys, &limit, &res->start, &res->end);
> + status = false;
> + }
> +
> + return status;
> +}
> +
> +static bool tegra264_pcie_link_up(struct tegra264_pcie *pcie,
> + enum pci_bus_speed *speed)
> +{
> + u16 value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> +
> + if (value & PCI_EXP_LNKSTA_DLLLA) {
> + if (speed)
> + *speed = pcie_link_speed[FIELD_GET(PCI_EXP_LNKSTA_CLS,
> + value)];
> +
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void tegra264_pcie_init(struct tegra264_pcie *pcie)
> +{
> + enum pci_bus_speed speed;
> + unsigned int i;
> + u32 value;
> +
> + /* bring the endpoint out of reset */
> + value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> + value |= XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
> + writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> +
> + for (i = 0; i < PCIE_LINK_WAIT_MAX_RETRIES; i++) {
> + if (tegra264_pcie_link_up(pcie, NULL))
> + break;
> +
> + msleep(PCIE_LINK_WAIT_SLEEP_MS);
> + }
> +
> + if (tegra264_pcie_link_up(pcie, &speed)) {
> + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> + dev_info(pcie->dev, "PCIe #%u link is up (speed: %s)\n",
> + pcie->ctl_id, pci_speed_string(speed));
> + tegra264_pcie_icc_set(pcie);
> + pcie->link_up = true;
> + } else {
> + dev_info(pcie->dev, "PCIe #%u link is down\n", pcie->ctl_id);
> +
> + value = readl(pcie->xtl + XTL_RC_MGMT_CLOCK_CONTROL);
> +
> + /*
> + * Set link state only when link fails and no hot-plug feature
> + * is present.
> + */
> + if ((value & XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT) == 0) {
> + dev_info(pcie->dev,
> + "PCIe #%u link is down and not hotplug-capable, turning off\n",
> + pcie->ctl_id);
> + tegra264_pcie_power_off(pcie);
> + pcie->link_up = false;
> + } else {
> + pcie->link_up = true;
> + }
> + }
> +}
> +
> +static void tegra264_pcie_deinit(struct tegra264_pcie *pcie)
> +{
> + u32 value;
> +
> + /* take the endpoint into reset */
> + value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> + value &= ~XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
> + writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> +}
> +
> +static int tegra264_pcie_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct pci_host_bridge *bridge;
> + struct tegra264_pcie *pcie;
> + struct resource_entry *bus;
> + struct resource *res;
> + int err;
> +
> + bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct tegra264_pcie));
> + if (!bridge)
> + return dev_err_probe(dev, -ENOMEM,
> + "failed to allocate host bridge\n");
> +
> + pcie = pci_host_bridge_priv(bridge);
> + platform_set_drvdata(pdev, pcie);
> + pcie->bridge = bridge;
> + pcie->dev = dev;
> +
> + err = tegra264_pcie_parse_dt(pcie);
> + if (err < 0)
> + return dev_err_probe(dev, err, "failed to parse device tree\n");
> +
> + pcie->xal = devm_platform_ioremap_resource_byname(pdev, "xal");
> + if (IS_ERR(pcie->xal))
> + return dev_err_probe(dev, PTR_ERR(pcie->xal),
> + "failed to map XAL memory\n");
> +
> + pcie->xtl = devm_platform_ioremap_resource_byname(pdev, "xtl-pri");
> + if (IS_ERR(pcie->xtl))
> + return dev_err_probe(dev, PTR_ERR(pcie->xtl),
> + "failed to map XTL-PRI memory\n");
> +
> + bus = resource_list_first_type(&bridge->windows, IORESOURCE_BUS);
> + if (!bus)
> + return dev_err_probe(dev, -ENODEV,
> + "failed to get bus resources\n");
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
> + if (!res)
> + return dev_err_probe(dev, -ENXIO,
> + "failed to get ECAM resource\n");
> +
> + pcie->icc_path = devm_of_icc_get(dev, "write");
> + if (IS_ERR(pcie->icc_path))
> + return dev_err_probe(dev, PTR_ERR(pcie->icc_path),
> + "failed to get ICC\n");
> +
> + pcie->bpmp = tegra_bpmp_get_with_id(dev, &pcie->ctl_id);
> + if (IS_ERR(pcie->bpmp))
> + return dev_err_probe(dev, PTR_ERR(pcie->bpmp),
> + "failed to get BPMP\n");
> +
> + err = devm_pm_runtime_set_active_enabled(dev);
I belive this has to come after pm_runtime_get_sync() because at this point, the
controller is not enabled.
> + if (err < 0) {
> + dev_err_probe(dev, err, "failed to enable runtime PM\n");
> + goto put_bpmp;
> + }
> +
> + err = pm_runtime_get_sync(dev);
> + if (err < 0) {
> + dev_err_probe(dev, err, "failed to power on device\n");
> + goto put_bpmp;
> + }
> +
> + /* sanity check that programmed ranges match what's in DT */
> + if (!tegra264_pcie_check_ranges(pdev)) {
> + err = -EINVAL;
> + goto put_pm;
> + }
> +
> + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> + if (IS_ERR(pcie->cfg)) {
> + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> + "failed to create ECAM\n");
> + goto put_pm;
> + }
> +
> + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> + bridge->sysdata = pcie->cfg;
> + pcie->ecam = pcie->cfg->win;
> +
> + tegra264_pcie_init(pcie);
> +
> + if (!pcie->link_up)
> + return 0;
So not hotplug support? Also, you do not want the driver to error out? I'm
wondering what's the use then?
> +
> + err = pci_host_probe(bridge);
> + if (err < 0) {
> + dev_err_probe(dev, err, "failed to register host\n");
> + goto free_ecam;
> + }
> +
> + return 0;
> +
> +free_ecam:
Nit: Prefix 'err' for the labels.
> + pci_ecam_free(pcie->cfg);
> +put_pm:
> + pm_runtime_put_sync(dev);
> +put_bpmp:
> + tegra_bpmp_put(pcie->bpmp);
> +
> + return err;
> +}
> +
> +static void tegra264_pcie_remove(struct platform_device *pdev)
> +{
> + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
> +
> + /*
> + * If we undo tegra264_pcie_init() then link goes down and need
> + * controller reset to bring up the link again. Remove intention is
> + * to clean up the root bridge and re-enumerate during bind.
But the controller will be consuming power even if PCIe is not used. Do you
really want that? Can't tegra264_pcie_init() handle the initialization? I'm
wondering how tegra264_pcie_deinit() in tegra264_pcie_suspend() works then.
> + */
> + pci_lock_rescan_remove();
> + pci_stop_root_bus(pcie->bridge->bus);
> + pci_remove_root_bus(pcie->bridge->bus);
> + pci_unlock_rescan_remove();
> +
> + pm_runtime_put_sync(&pdev->dev);
> + tegra_bpmp_put(pcie->bpmp);
> + pci_ecam_free(pcie->cfg);
> +}
> +
> +static int tegra264_pcie_suspend(struct device *dev)
> +{
> + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> + int err;
> +
> + tegra264_pcie_deinit(pcie);
> +
> + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> + err = enable_irq_wake(pcie->wake_irq);
> + if (err < 0)
> + dev_err(dev, "failed to enable wake IRQ: %pe\n",
> + ERR_PTR(err));
> + }
> +
> + return 0;
> +}
> +
> +static int tegra264_pcie_resume(struct device *dev)
> +{
> + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> + int err;
> +
> + err = pinctrl_pm_select_default_state(dev);
> + if (err < 0)
> + dev_err(dev, "failed to configure sideband pins: %pe\n",
> + ERR_PTR(err));
Please remind me if you justified this manual pinctrl handling before.
> +
> + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> + err = disable_irq_wake(pcie->wake_irq);
> + if (err < 0)
> + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> + ERR_PTR(err));
> + }
> +
> + if (pcie->link_up == false)
> + return 0;
How is this possible? If 'pcie->link_up' was 'false' during probe(), then it is
going to stay until tegra264_pcie_init() is called below.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net] net: stmmac: dwmac-spacemit: Fix wrong ctrl register definition
From: Inochi Amaoto @ 2026-06-18 7:12 UTC (permalink / raw)
To: Maxime Chevallier, Inochi Amaoto, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Alexandre Torgue, Yixun Lan, Russell King (Oracle)
Cc: netdev, linux-stm32, linux-arm-kernel, linux-riscv, spacemit,
linux-kernel, Yixun Lan, Longbin Li
In-Reply-To: <9b39829d-92b4-4ffa-be0b-b2b0f857f58e@bootlin.com>
On Thu, Jun 18, 2026 at 09:03:21AM +0200, Maxime Chevallier wrote:
> Hi Inochi,
>
> On 6/18/26 08:41, Inochi Amaoto wrote:
> > There register layout of the phy ctrl register has something wrong,
> > fix it to match the right layout
> >
> > Fixes: 30f0ba420ed3 ("net: stmmac: Add glue layer for Spacemit K3 SoC")
> > Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
> > ---
> > .../net/ethernet/stmicro/stmmac/dwmac-spacemit.c | 13 ++++++++-----
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> > index 223754cc5c79..6feffaa3ef3a 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-spacemit.c
> > @@ -18,10 +18,12 @@
> > #include "stmmac_platform.h"
> >
> > /* ctrl register bits */
> > -#define CTRL_PHY_INTF_RGMII BIT(3)
> > -#define CTRL_PHY_INTF_MII BIT(4)
> > -#define CTRL_WAKE_IRQ_EN BIT(9)
> > -#define CTRL_PHY_IRQ_EN BIT(12)
> > +#define CTRL_PHY_INTF_MODE GENMASK(4, 3)
> > +#define CTRL_PHY_INTF_RMII FIELD_PREP(CTRL_PHY_INTF_MODE, 0)
> > +#define CTRL_PHY_INTF_RGMII FIELD_PREP(CTRL_PHY_INTF_MODE, 1)
> > +#define CTRL_PHY_INTF_MII FIELD_PREP(CTRL_PHY_INTF_MODE, 3)
> > +#define CTRL_PHY_IRQ_EN BIT(9)
> > +#define CTRL_WAKE_IRQ_EN BIT(12)
>
> Looks like you're fixing 2 things there :
>
> -> Wake on Lan probably didn't work before, as the wake irq was apparently wrong.
I guess the vendor firmware and uboot may do something for it,
but the irq is wrong actually.
> -> The MII mode selection apparently also changes, but maybe you don't have a
> MII board around to test this ?
>
Actually, the only board of the K3 is the pico-itx board, and it only has
a RGMII phy. I even doube the spacemit vendor has not tested the MII phy
well....
> Is it possible you address these issues independently (i.e. split this in 2 patches) ?
> That way, if we ever revert one, we won't re-break the other thing that was broken.
>
>
Yes, it is fine for me to split it. I will send it in a few days.
Regards,
Inochi
^ permalink raw reply
* [PATCH V2 3/3] dmaengine: zynqmp_dma: Guard IRQ handler against spurious interrupts
From: Golla Nagendra @ 2026-06-18 7:10 UTC (permalink / raw)
To: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
nagendra.golla, jay.buddhabhatti, harini.katakam, m.tretter,
radhey.shyam.pandey, abin.joseph, kees, sakari.ailus
Cc: git, dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-1-nagendra.golla@amd.com>
Add pm_runtime_get_if_active() check in zynqmp_dma_irq_handler() to
safely handle spurious interrupts that may arrive while the device is
runtime-suspended. Without this guard, a spurious interrupt could cause
the handler to access hardware registers (ISR, IMR) with clocks gated,
potentially leading to a synchronous external abort and kernel crash.
When the device is not runtime-active, pm_runtime_get_if_active()
returns false without incrementing the usage counter, and the handler
returns IRQ_NONE immediately. When the device is active, it increments
the usage counter to prevent a concurrent runtime suspend during
register access, and pm_runtime_put() releases the reference afterward.
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
drivers/dma/xilinx/zynqmp_dma.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index a9dfec3c0ca3..ce9163138be7 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -730,6 +730,9 @@ static irqreturn_t zynqmp_dma_irq_handler(int irq, void *data)
u32 isr, imr, status;
irqreturn_t ret = IRQ_NONE;
+ if (pm_runtime_get_if_active(chan->dev) <= 0)
+ return IRQ_NONE;
+
isr = readl(chan->regs + ZYNQMP_DMA_ISR);
imr = readl(chan->regs + ZYNQMP_DMA_IMR);
status = isr & ~imr;
@@ -756,6 +759,8 @@ static irqreturn_t zynqmp_dma_irq_handler(int irq, void *data)
ret = IRQ_HANDLED;
}
+ pm_runtime_put(chan->dev);
+
return ret;
}
--
2.34.1
^ permalink raw reply related
* [PATCH V2 2/3] dmaengine: zynqmp_dma: Add per-channel reset support
From: Golla Nagendra @ 2026-06-18 7:10 UTC (permalink / raw)
To: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
nagendra.golla, jay.buddhabhatti, harini.katakam, m.tretter,
radhey.shyam.pandey, abin.joseph, kees, sakari.ailus
Cc: git, dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-1-nagendra.golla@amd.com>
Versal Gen 2 and Versal Net SoCs expose a dedicated reset line per
ZDMA channel, replacing the earlier approach where a single reset
was shared across all channels. Add reset handling in the channel
probe path using device_reset_optional() to trigger a reset pulse
on the channel during initialization.
Platforms without per-channel reset continue to work unaffected
since device_reset_optional() returns 0 when no reset is specified.
add pm_runtime_put_noidle() in the probe error path before
pm_runtime_disable() to balance the usage counter incremented by
pm_runtime_resume_and_get(). This is particularly important since
device_reset_optional() can return -EPROBE_DEFER, causing the
kernel to retry probe() and leak one PM usage count per retry
without the put.
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
drivers/dma/xilinx/zynqmp_dma.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
index f6a812e49ddc..a9dfec3c0ca3 100644
--- a/drivers/dma/xilinx/zynqmp_dma.c
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -18,6 +18,7 @@
#include <linux/clk.h>
#include <linux/io-64-nonatomic-lo-hi.h>
#include <linux/pm_runtime.h>
+#include <linux/reset.h>
#include "../dmaengine.h"
@@ -916,6 +917,11 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
if (IS_ERR(chan->regs))
return PTR_ERR(chan->regs);
+ err = device_reset_optional(&pdev->dev);
+ if (err)
+ return dev_err_probe(&pdev->dev, err,
+ "failed to reset channel\n");
+
chan->bus_width = ZYNQMP_DMA_BUS_WIDTH_64;
chan->dst_burst_len = ZYNQMP_DMA_MAX_DST_BURST_LEN;
chan->src_burst_len = ZYNQMP_DMA_MAX_SRC_BURST_LEN;
@@ -1152,6 +1158,7 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
err_disable_pm:
if (!pm_runtime_enabled(zdev->dev))
zynqmp_dma_runtime_suspend(zdev->dev);
+ pm_runtime_put_noidle(zdev->dev);
pm_runtime_disable(zdev->dev);
return ret;
}
--
2.34.1
^ permalink raw reply related
* [PATCH V2 1/3] dt-bindings: dma: xilinx: Add optional resets property for ZDMA
From: Golla Nagendra @ 2026-06-18 7:10 UTC (permalink / raw)
To: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
nagendra.golla, jay.buddhabhatti, harini.katakam, m.tretter,
radhey.shyam.pandey, abin.joseph, kees, sakari.ailus
Cc: git, dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-1-nagendra.golla@amd.com>
From: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Newer SoCs such as Versal Gen2 and Versal‑Net expose a reset line
for ZDMA. Older SoCs do not have this provision. Add an optional
resets property to describe this reset.
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Co-developed-by: Golla Nagendra <nagendra.golla@amd.com>
Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
---
.../devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml
index 2da86037ad79..dff16763e11b 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml
+++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml
@@ -56,6 +56,9 @@ properties:
iommus:
maxItems: 1
+ resets:
+ maxItems: 1
+
power-domains:
maxItems: 1
--
2.34.1
^ permalink raw reply related
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