* Re: [PATCH v2 5/6] mm/page_vma_mapped: use huge_ptep_get() for hugetlb
From: Muchun Song @ 2026-07-02 8:33 UTC (permalink / raw)
To: Dev Jain
Cc: osalvador, akpm, ljs, david, liam, riel, vbabka, harry, jannh,
lance.yang, kas, linux-mm, linux-kernel, rcampbell, apopple, ziy,
matthew.brost, joshua.hahnjy, rakie.kim, byungchul, gourry,
ying.huang, j-nomura, nao.horiguchi, ak, mel, pfalcato, jpoimboe,
dave.hansen, tglx, catalin.marinas, will, linux-arm-kernel,
ryan.roberts, anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-6-dev.jain@arm.com>
> On Jul 2, 2026, at 13:13, Dev Jain <dev.jain@arm.com> wrote:
>
> check_pte() is the final validation step in page_vma_mapped_walk().
> It reads pvmw->pte with ptep_get() to decide whether the entry maps
> the PFN range being walked. For hugetlb VMAs, that pointer refers
> to a hugetlb entry.
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(),
> pte_present() etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Use huge_ptep_get() to dereference a huge pte pointer.
>
> Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dev Jain <dev.jain@arm.com>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
Thanks.
^ permalink raw reply
* Re: [PATCH 5/5] gpio: nomadik: drop "chip registered" log on probe success
From: Théo Lebrun @ 2026-07-02 8:34 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Philipp Zabel, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <CAD++jLmmHXBC9ni0pcVoB2HNK+osBzgirxH7vLHZaANmoe-tpQ@mail.gmail.com>
Hello Linus,
On Thu Jul 2, 2026 at 10:00 AM CEST, Linus Walleij wrote:
> On Wed, Jul 1, 2026 at 6:57 PM Théo Lebrun <theo.lebrun@bootlin.com> wrote:
>
>> Successful driver probing should be silent. Drop unconditional
>> dev_info() call that is done at nmk_gpio_probe() exit.
>>
>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>
> I actually don't generally agree, but you are using this driver more than
> me now so let's go with your minimalist dmesg style for this driver.
I get from where you stand, but the info level is somewhat strong.
Documentation/process/coding-style.rst agrees ("When drivers are
working properly they are quiet").
If you like this log line we can turn it into a lower debug level?
> Reviewed-by: Linus Walleij <linusw@kernel.org>
Thanks for the reviews Linus!
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Alexandre Belloni @ 2026-07-02 8:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Markus Probst, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <887cb4e9-d60d-47b5-9110-e00d18e9e46c@kernel.org>
On 02/07/2026 10:20:20+0200, Krzysztof Kozlowski wrote:
> On 02/07/2026 10:17, Alexandre Belloni wrote:
> > On 02/07/2026 08:09:55+0200, Krzysztof Kozlowski wrote:
> >>>> Then you need proper wakeup-source support
> >>> Wouldn't that break existing devicetrees?
> >>
> >> How?
> >>
> >>>
> >>> The current driver allows to wake up the system, even without
> >>> having wakeup-source set.
> >>
> >> Anyway, wakeup-source is already there in rtc, so this would be done. I
> >> don't get though, why there is no benefit of routing it to interrupt
> >> controller (interrupt controllers do wake up the system). Additionally,
> >> if you do not connect it to any interrupt, then how does it wake up the
> >> system?
> >>
> >
> > Some systems are routing the interrupt output of the RTC directly to the
> > PMIC and the PMIC is the one responsible for waking the rest of the
> > system, including the SoC.
>
> Yeah, then the PMIC has interrupt line to the SoC and the PMIC is the
> wakeup-source, not RTC.
>
This would be case 3 of Documentation/devicetree/bindings/power/wakeup-source.txt
> Best regards,
> Krzysztof
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 01/19] ARM: use CONFIG_AEABI by default everywhere
From: Arnd Bergmann @ 2026-07-02 8:34 UTC (permalink / raw)
To: Nicolas Ferre, Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Aaro Koskinen, A. Sverdlin, Alexandre Belloni,
Alexandre Torgue, Andrew Lunn, Ard Biesheuvel, Claudiu Beznea,
Daniel Mack, Ethan Nelson-Moore, Frank Li, Gregory Clement,
Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
Mike Rapoport, Patrice Chotard, Ralph Siemsen, Robert Jarzmik,
Russell King, Sascha Hauer, Sebastian Hesselbarth, Stefan Agner,
Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy, Will Deacon,
Linus Walleij
In-Reply-To: <d48d79ad-6a30-4a86-8895-17d4e4fa2940@microchip.com>
On Thu, Jul 2, 2026, at 09:42, Nicolas Ferre wrote:
> On 01/07/2026 at 23:23, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> - All machines that used to explicitly enable EABI can drop that line now
>> - Machines that are likely to actually use old distros and had NWFPE
>> enabled in combination with OABI (rpc, footrbridge, netwinder,
>> assabet, neponset) explicitly turn it on now.
>> - Machines that already had both EABI and NWFPE disabled in defconfig
>> (at91_dt, collie, ep93xx, gemini, h3600, imx_v4_v5, integrator, jornada,
>
> For at91_dt, EABI was explicitly enabled (see below)...
Right. I don't know how I got to that list originally, but looking again
now, the only configs that I see using OABI but not NWFPE here are
spear3xx and spear6xx. I've updated the text now, thanks!
Arnd
^ permalink raw reply
* [PATCH] arm64: dts: mediatek: mt8183-kukui: Add supply for SPI NOR flash
From: Chen-Yu Tsai @ 2026-07-02 8:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
The SPI NOR flash is powered from the always on 1.8V power rail through
a load switch that is controlled by the security chip.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b8d261b375d4..ed552f023cb4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -980,6 +980,8 @@ w25q64dw: flash@0 {
compatible = "winbond,w25q64dw", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <25000000>;
+ /* Power actually controlled by security chip */
+ vcc-supply = <&pp1800_alw>;
};
};
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH] arm64: dts: mediatek: mt8188-geralt: Add supply for SPI NOR flash
From: Chen-Yu Tsai @ 2026-07-02 8:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
The SPI NOR flash is powered the "always on" 1.8V LDO regulated power
rail.
Add the supply for the SPI NOR flash.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
index 4cb23595d17b..f382f90c48f5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
@@ -645,6 +645,7 @@ flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <52000000>;
+ vcc-supply = <&pp1800_ldo_z1>;
};
};
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [soc:rfc-arm-deprecation-7.2] BUILD SUCCESS 3be9b90e0ec1b72b270cb6f77e136afed2238891
From: kernel test robot @ 2026-07-02 8:40 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: 3be9b90e0ec1b72b270cb6f77e136afed2238891 ARM: mark mv78xx0 support as deprecated
elapsed time: 728m
configs tested: 196
configs skipped: 158
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-20260702 gcc-8.5.0
arc randconfig-002-20260702 gcc-8.5.0
arm allnoconfig clang-17
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260702 gcc-8.5.0
arm randconfig-002-20260702 gcc-8.5.0
arm randconfig-003-20260702 gcc-8.5.0
arm randconfig-004-20260702 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260702 gcc-15.2.0
arm64 randconfig-002-20260702 gcc-15.2.0
arm64 randconfig-003-20260702 gcc-15.2.0
arm64 randconfig-004-20260702 gcc-15.2.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260702 gcc-15.2.0
csky randconfig-002-20260702 gcc-15.2.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260702 clang-23
hexagon randconfig-002-20260702 clang-23
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260702 clang-22
i386 buildonly-randconfig-002-20260702 clang-22
i386 buildonly-randconfig-003-20260702 clang-22
i386 buildonly-randconfig-004-20260702 clang-22
i386 buildonly-randconfig-005-20260702 clang-22
i386 buildonly-randconfig-006-20260702 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260702 gcc-14
i386 randconfig-002-20260702 gcc-14
i386 randconfig-003-20260702 gcc-14
i386 randconfig-004-20260702 gcc-14
i386 randconfig-005-20260702 gcc-14
i386 randconfig-006-20260702 gcc-14
i386 randconfig-007-20260702 gcc-14
i386 randconfig-011-20260702 clang-22
i386 randconfig-012-20260702 clang-22
i386 randconfig-013-20260702 clang-22
i386 randconfig-014-20260702 clang-22
i386 randconfig-015-20260702 clang-22
i386 randconfig-016-20260702 clang-22
i386 randconfig-017-20260702 clang-22
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch loongson32_defconfig clang-18
loongarch randconfig-001-20260702 clang-23
loongarch randconfig-002-20260702 clang-23
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 ci20_defconfig clang-23
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001-20260702 clang-23
nios2 randconfig-002-20260702 clang-23
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 clang-17
parisc randconfig-001-20260702 clang-17
parisc randconfig-002 clang-17
parisc randconfig-002-20260702 clang-17
parisc64 defconfig clang-23
powerpc adder875_defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc randconfig-001 clang-17
powerpc randconfig-001-20260702 clang-17
powerpc randconfig-002 clang-17
powerpc randconfig-002-20260702 clang-17
powerpc64 randconfig-001 clang-17
powerpc64 randconfig-001-20260702 clang-17
powerpc64 randconfig-002 clang-17
powerpc64 randconfig-002-20260702 clang-17
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-12.5.0
riscv randconfig-001-20260702 gcc-12.5.0
riscv randconfig-002 gcc-12.5.0
riscv randconfig-002-20260702 gcc-12.5.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-12.5.0
s390 randconfig-001-20260702 gcc-12.5.0
s390 randconfig-002 gcc-12.5.0
s390 randconfig-002-20260702 gcc-12.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001 gcc-12.5.0
sh randconfig-001-20260702 gcc-12.5.0
sh randconfig-002 gcc-12.5.0
sh randconfig-002-20260702 gcc-12.5.0
sh se7619_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260702 gcc-16.1.0
sparc randconfig-002-20260702 gcc-16.1.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260702 gcc-16.1.0
sparc64 randconfig-002-20260702 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-20260702 gcc-16.1.0
um randconfig-002-20260702 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-20260702 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260702 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260702 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260702 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260702 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260702 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 clang-22
x86_64 randconfig-001-20260702 clang-22
x86_64 randconfig-002 clang-22
x86_64 randconfig-002-20260702 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260702 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260702 clang-22
x86_64 randconfig-005 clang-22
x86_64 randconfig-005-20260702 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260702 clang-22
x86_64 randconfig-011-20260702 clang-22
x86_64 randconfig-012-20260702 clang-22
x86_64 randconfig-013-20260702 clang-22
x86_64 randconfig-014-20260702 clang-22
x86_64 randconfig-015-20260702 clang-22
x86_64 randconfig-016-20260702 clang-22
x86_64 randconfig-071-20260702 clang-22
x86_64 randconfig-072-20260702 clang-22
x86_64 randconfig-073-20260702 clang-22
x86_64 randconfig-074-20260702 clang-22
x86_64 randconfig-075-20260702 clang-22
x86_64 randconfig-076-20260702 clang-22
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 randconfig-001-20260702 gcc-16.1.0
xtensa randconfig-002-20260702 gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 17/19] ARM: mark Cortex-M3/M4/M7 based boards as deprecated
From: Vladimir Murzin @ 2026-07-02 8:43 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-18-arnd@kernel.org>
On 7/1/26 22:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The Cortex-M3/M4/M7 cores were designed as a replacement for the earlier
> ARM7TDMI and ARM9TDMI microarchitectures used in older microcontrollers.
>
> At the moment, Linux can run these cores either when they are integrated
> into a larger SoC, or as standalone microcontrollers. While there was
> a lot of development work going into Cortex-M support from 2011 to 2016,
> this largely stopped when it became clear that Zephyr and other RTOS
> had taken over that market. To date, the only Cortex-M based based
> microcontroller boards supported upstream are reference implementations.
>
> Schedule these for removal after the next LTS kernel, so if any users
> remain that want to update their kernels, they can stay on that
> version for a few years before having to maintain the platform support
> out of tree.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/Kconfig | 8 ++++++--
> arch/arm/mach-at91/Kconfig | 4 +++-
> arch/arm/mach-imx/Kconfig | 4 +++-
> arch/arm/mach-stm32/Kconfig | 14 ++++++++------
> 4 files changed, 20 insertions(+), 10 deletions(-)
>
[snip]
> config ARCH_MPS2
> - bool "ARM MPS2 platform"
> + bool "ARM MPS2 platform (DEPRECATED)"
> depends on ARM_SINGLE_ARMV7M
> select ARM_AMBA
> select CLKSRC_MPS2
> @@ -493,6 +495,8 @@ config ARCH_MPS2
> Please, note that depends which Application Note is used memory map
> for the platform may vary, so adjustment of RAM base might be needed.
>
> + This platform is scheduled for removal in early 2027
> +
> # Definitions to make life easier
> config ARCH_ACORN
> bool
Acked-by: Vladimir Murzin <vladimir.murzin@arm.com> # MPS2
Thanks
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: Muchun Song @ 2026-07-02 8:47 UTC (permalink / raw)
To: Dev Jain
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable, osalvador, akpm, ljs, david, liam
In-Reply-To: <20260702051341.126509-3-dev.jain@arm.com>
On 2026/7/2 13:13, Dev Jain wrote:
> try_to_unmap_one() handles hugetlb folios when memory failure needs
> to replace a poisoned hugetlb mapping with a hwpoison entry. In that
> case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio
> in pvmw.pte, but the code reads it with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
> etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Just use huge_ptep_get() for dereferencing a huge pte pointer.
>
> Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
> Cc: stable@vger.kernel.org
> Reported-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> include/linux/hugetlb.h | 3 +++
> mm/rmap.c | 16 ++++++++++------
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 2abaf99321e90..fdb7bdf7645c5 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
> {
> }
>
> +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep);
> +
Maybe I didn't express my thoughts clearly in the first version, let me
explain in more detail.
We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like
set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference
in your previous version). Currently, you've added a declaration, but the
function itself doesn't actually exist, which seems quite strange to me.
Muchun,
Thanks.
> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep)
> {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 1c77d5dc06e9f..aa8a254efaecc 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
> /* Unexpected PMD-mapped THP? */
> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>
> - /*
> - * Handle PFN swap PTEs, such as device-exclusive ones, that
> - * actually map pages.
> - */
> - pteval = ptep_get(pvmw.pte);
> + address = pvmw.address;
> + if (folio_test_hugetlb(folio)) {
> + pteval = huge_ptep_get(mm, address, pvmw.pte);
> + } else {
> + /*
> + * Handle PFN swap PTEs, such as device-exclusive ones,
> + * that actually map pages.
> + */
> + pteval = ptep_get(pvmw.pte);
> + }
> if (likely(pte_present(pteval))) {
> pfn = pte_pfn(pteval);
> } else {
> @@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
> }
>
> subpage = folio_page(folio, pfn - folio_pfn(folio));
> - address = pvmw.address;
> anon_exclusive = folio_test_anon(folio) &&
> PageAnonExclusive(subpage);
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
From: Marc Kleine-Budde @ 2026-07-02 8:49 UTC (permalink / raw)
To: Cunhao Lu
Cc: krzk, heiko, linux-can, mailhol, kernel, robh, krzk+dt, conor+dt,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
shawn.lin
In-Reply-To: <tencent_97F21396469202221027FD429A6E69DA6409@qq.com>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
On 02.07.2026 16:17:25, Cunhao Lu wrote:
> > And why is this different from rk3588?
>
> The reason I used rk3588v2 is that this is how the controller identifies
> itself at runtime:
There are 2 silicon revision (v2 and v3) of the rk3568 available on the
market. The v2 has several errata in the CAN-FD core, the v3 has some of
them fixed...
> rockchip_canfd fea60000.can can0: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
> rockchip_canfd fea70000.can can1: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
However, the version register _in_ the CAN-FD was not changed. :/
This is why we have a rockchip,rk3568v2-canfd and a
rockchip,rk3568v3-canfd compatible.
> I also checked Rockchip's vendor kernel 6.1 sources. The RK3588 DTS uses
> the binding name "rockchip,can-2.0" for these controllers, while the
> upstream driver has SoC-specific compatibles for the Rockchip CAN-FD IP.
> That is why I chose the SoC/IP variant name rockchip,rk3588v2-canfd.
>
> If the preferred binding name is rockchip,rk3588-canfd instead, I can
> change the compatible in v2.
Yes, please use rockchip,rk3588-canfd, unless we get information from
rockchips about CAN-FD errata and SoC silicon revisions.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 0/2] fix clock refcount imbalance for all Coresight platform drivers
From: Jie Gan @ 2026-07-02 8:54 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Anshuman Khandual, Yeoreum Yun,
Yuanfang Zhang, Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, linux-stm32, Jie Gan
Found a clock imbalance issue when remove the CTCU module.
coresight_get_enable_clocks() enables the programming clock and the
optional AT clock through devm_clk_get_optional_enabled(), which also
registers a devm action to call clk_disable_unprepare() when the driver
detaches.
After probe, pm_runtime_put() allows the device to suspend and the
runtime suspend callback disables the same clocks. During remove the
device is left runtime suspended, so pm_runtime_disable() freezes it
with the clocks already disabled. The devm cleanup that runs afterwards
calls clk_disable_unprepare() a second time, underflowing the clock
enable refcount.
Resume the device with pm_runtime_get_sync() before tearing it down so
the clocks are enabled again and balance the devm-managed disable. Then
pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device
in a coherent runtime PM state (suspended, usage count balanced) once
the devm action has disabled the clocks.
Calltrace:
[ 194.074015] ------------[ cut here ]------------
[ 194.078779] qdss already disabled
[ 194.082210] WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0x238/0x240, CPU#4: rmmod/508
[ 194.090976] Modules linked in: coresight_ctcu(-) snd_soc_hdmi_codec snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd soundcore 8021q garp mrp phy_qcom_edp stp af_alg llc anx7625 typec pci_pwrctrl_pwrseq hci_uart qcom_iris v4l2_mem2mem btqca btbcm qcom_pon videobuf2_dma_contig rtc_pm8xxx nvmem_qcom_spmi_sdam qcom_spmi_temp_alarm videobuf2_memops qrtr videobuf2_v4l2 bluetooth msm qcom_stats pwrseq_qcom_wcn ubwc_config videodev ocmem ecdh_generic drm_gpuvm videobuf2_common drm_exec gpu_sched qcom_q6v5_pas kpp marvell videocc_sa8775p camcc_sa8775p ecc drm_dp_aux_bus dispcc0_sa8775p spi_geni_qcom i2c_qcom_geni llcc_qcom mc qcom_refgen_regulator phy_qcom_snps_femto_v2 phy_qcom_qmp_usb icc_bwmon phy_qcom_sgmii_eth dwmac_qcom_ethqos qcom_pil_info gpucc_sa8775p qcom_q6v5 stmmac_platform stmmac ufs_qcom qcom_sysmon drm_display_helper qcom_common pcs_xpcs phylink cec qcom_glink_smem qcrypto drm_client_lib mdt_loader dispcc1_sa8775p qmi_helpers phy_qcom_qmp_ufs libdes qcom_ice display_connector phy_qcom_qmp_pcie
[ 194.091130] qcom_wdt qcomtee nvmem_reboot_mode icc_osm_l3 qcom_rng drm_kms_helper cfg80211 rfkill socinfo fuse drm backlight stm_p_basic
[ 194.196124] CPU: 4 UID: 0 PID: 508 Comm: rmmod Not tainted 7.1.0-next-20260623-00008-ga4671328ba36 #831 PREEMPT
[ 194.206566] Hardware name: Qualcomm SA8775P Ride (DT)
[ 194.211771] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 194.218938] pc : clk_core_disable+0x238/0x240
[ 194.223426] lr : clk_core_disable+0x238/0x240
[ 194.227908] sp : ffff8000889fbb40
[ 194.231327] x29: ffff8000889fbb40 x28: ffff0000972eb580 x27: 0000000000000000
[ 194.238662] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 194.245995] x23: ffffd181d3de4620 x22: ffff8000889fbc28 x21: ffff000082382810
[ 194.253322] x20: ffff000082334a00 x19: ffff000082334a00 x18: 0000000000000006
[ 194.260658] x17: ffffd181d293fb18 x16: ffffd181d295c3c8 x15: ffff8000889fb550
[ 194.267991] x14: 0000000000000000 x13: ffffd181d4eea620 x12: 00000000000004cf
[ 194.275346] x11: 0000000000000e6d x10: ffffd181d4f42620 x9 : ffffd181d4eea620
[ 194.282676] x8 : 3fffffffffffefff x7 : ffffd181d4f42620 x6 : bffffffffffff000
[ 194.290007] x5 : ffff000ead974248 x4 : 0000000000000000 x3 : ffff2e8cd9611000
[ 194.297338] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000972eb580
[ 194.304671] Call trace:
[ 194.307199] clk_core_disable+0x238/0x240 (P)
[ 194.311687] clk_disable+0x30/0x4c
[ 194.315192] clk_disable_unprepare+0x18/0x30
[ 194.319596] devm_clk_release+0x24/0x3c
[ 194.323578] dr_node_release+0x1c/0x28
[ 194.327466] release_nodes+0x5c/0x90
[ 194.331147] devres_release_all+0x90/0x104
[ 194.335364] device_unbind_cleanup+0x2c/0x84
[ 194.339762] device_release_driver_internal+0x200/0x23c
[ 194.345153] driver_detach+0x4c/0x94
[ 194.348835] bus_remove_driver+0x6c/0xbc
[ 194.352872] driver_unregister+0x30/0x60
[ 194.356914] platform_driver_unregister+0x14/0x20
[ 194.361753] ctcu_driver_exit+0x18/0xdf8 [coresight_ctcu]
[ 194.367308] __arm64_sys_delete_module+0x1bc/0x298
[ 194.372240] invoke_syscall+0x54/0x10c
[ 194.376114] el0_svc_common.constprop.0+0xc0/0xe0
[ 194.380956] do_el0_svc+0x1c/0x28
[ 194.384374] el0_svc+0x54/0x3a0
[ 194.387626] el0t_64_sync_handler+0xa0/0xe4
[ 194.391951] el0t_64_sync+0x198/0x19c
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v2:
- Balance the runtime PM state in the remove path: after
pm_runtime_get_sync() and pm_runtime_disable(), also call
pm_runtime_set_suspended() and pm_runtime_put_noidle() so the device is
left suspended with a balanced usage count once the devm action has
disabled the clocks.
- Picked up Reviewed-by from Yeoreum Yun on patch 1.
- Link to v1: https://lore.kernel.org/r/20260701-fix-clock-refcount-unbalance-v1-0-321dc63c1f90@oss.qualcomm.com
---
Jie Gan (2):
coresight: Fix clock refcount imbalance on platform remove
coresight: tnoc: Fix clock refcount imbalance on platform remove
drivers/hwtracing/coresight/coresight-catu.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-cpu-debug.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-ctcu-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-etm4x-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-funnel.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-replicator.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-stm.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tmc-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tnoc.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tpiu.c | 8 ++++++++
10 files changed, 80 insertions(+)
---
base-commit: be5c93fa674f0fc3c8f359c2143abce6bbb422e6
change-id: 20260701-fix-clock-refcount-unbalance-e7c467136a86
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 1/2] coresight: Fix clock refcount imbalance on platform remove
From: Jie Gan @ 2026-07-02 8:54 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Anshuman Khandual, Yeoreum Yun,
Yuanfang Zhang, Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, linux-stm32, Jie Gan
In-Reply-To: <20260702-fix-clock-refcount-unbalance-v2-0-2383fbb9952e@oss.qualcomm.com>
coresight_get_enable_clocks() enables the programming clock and the
optional AT clock through devm_clk_get_optional_enabled(), which also
registers a devm action to call clk_disable_unprepare() when the driver
detaches.
After probe, pm_runtime_put() allows the device to suspend and the
runtime suspend callback disables the same clocks. During remove the
device is left runtime suspended, so pm_runtime_disable() freezes it
with the clocks already disabled. The devm cleanup that runs afterwards
calls clk_disable_unprepare() a second time, underflowing the clock
enable refcount.
Resume the device with pm_runtime_get_sync() before tearing it down so
the clocks are enabled again and balance the devm-managed disable. Then
pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device
in a coherent runtime PM state (suspended, usage count balanced) once
the devm action has disabled the clocks.
This affects all CoreSight platform drivers that obtain their clocks
through coresight_get_enable_clocks(): catu, cpu-debug, ctcu, etm4x,
funnel, replicator, stm, tmc and tpiu.
Fixes: 1abc1b212eff ("coresight: Appropriately disable programming clocks")
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-catu.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-cpu-debug.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-ctcu-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-etm4x-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-funnel.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-replicator.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-stm.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tmc-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tpiu.c | 8 ++++++++
9 files changed, 72 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
index ad8dafea7d2f..b72fa7f4bdeb 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -629,42 +629,50 @@ static int catu_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __catu_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void catu_platform_remove(struct platform_device *pdev)
{
struct catu_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__catu_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int catu_runtime_suspend(struct device *dev)
{
struct catu_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->atclk);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int catu_runtime_resume(struct device *dev)
{
struct catu_drvdata *drvdata = dev_get_drvdata(dev);
int ret;
ret = clk_prepare_enable(drvdata->pclk);
if (ret)
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
index 3a806c1d50ea..87b39874461e 100644
--- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -693,42 +693,50 @@ static int debug_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __debug_probe(&pdev->dev, res);
if (ret) {
pm_runtime_put_noidle(&pdev->dev);
pm_runtime_disable(&pdev->dev);
}
return ret;
}
static void debug_platform_remove(struct platform_device *pdev)
{
struct debug_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__debug_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_ACPI
static const struct acpi_device_id debug_platform_ids[] = {
{"ARMHC503", 0, 0, 0}, /* ARM CoreSight Debug */
{},
};
MODULE_DEVICE_TABLE(acpi, debug_platform_ids);
#endif
#ifdef CONFIG_PM
static int debug_runtime_suspend(struct device *dev)
{
struct debug_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c
index 9043cad42f01..e0e33e3ca5bf 100644
--- a/drivers/hwtracing/coresight/coresight-ctcu-core.c
+++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c
@@ -248,42 +248,50 @@ static int ctcu_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = ctcu_probe(pdev);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void ctcu_platform_remove(struct platform_device *pdev)
{
struct ctcu_drvdata *drvdata = platform_get_drvdata(pdev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
ctcu_remove(pdev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int ctcu_runtime_suspend(struct device *dev)
{
struct ctcu_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->apb_clk);
return 0;
}
static int ctcu_runtime_resume(struct device *dev)
{
struct ctcu_drvdata *drvdata = dev_get_drvdata(dev);
return clk_prepare_enable(drvdata->apb_clk);
}
#endif
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 14bb31bd6a0b..a3ae8e1e3a1b 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2399,41 +2399,49 @@ static void etm4_remove_dev(struct etmv4_drvdata *drvdata)
etm_perf_symlink(drvdata->csdev, false);
cscfg_unregister_csdev(drvdata->csdev);
coresight_unregister(drvdata->csdev);
}
}
static void etm4_remove_amba(struct amba_device *adev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(&adev->dev);
if (drvdata)
etm4_remove_dev(drvdata);
}
static void etm4_remove_platform_dev(struct platform_device *pdev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (drvdata)
etm4_remove_dev(drvdata);
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
static const struct amba_id etm4_ids[] = {
CS_AMBA_ID(0x000bb95d), /* Cortex-A53 */
CS_AMBA_ID(0x000bb95e), /* Cortex-A57 */
CS_AMBA_ID(0x000bb95a), /* Cortex-A72 */
CS_AMBA_ID(0x000bb959), /* Cortex-A73 */
CS_AMBA_UCI_ID(0x000bb9da, uci_id_etm4),/* Cortex-A35 */
CS_AMBA_UCI_ID(0x000bbd05, uci_id_etm4),/* Cortex-A55 */
CS_AMBA_UCI_ID(0x000bbd0a, uci_id_etm4),/* Cortex-A75 */
CS_AMBA_UCI_ID(0x000bbd0c, uci_id_etm4),/* Neoverse N1 */
CS_AMBA_UCI_ID(0x000bbd41, uci_id_etm4),/* Cortex-A78 */
CS_AMBA_UCI_ID(0x000f0205, uci_id_etm4),/* Qualcomm Kryo */
CS_AMBA_UCI_ID(0x000f0211, uci_id_etm4),/* Qualcomm Kryo */
CS_AMBA_UCI_ID(0x000bb802, uci_id_etm4),/* Qualcomm Kryo 385 Cortex-A55 */
CS_AMBA_UCI_ID(0x000bb803, uci_id_etm4),/* Qualcomm Kryo 385 Cortex-A75 */
CS_AMBA_UCI_ID(0x000bb805, uci_id_etm4),/* Qualcomm Kryo 4XX Cortex-A55 */
CS_AMBA_UCI_ID(0x000bb804, uci_id_etm4),/* Qualcomm Kryo 4XX Cortex-A76 */
CS_AMBA_UCI_ID(0x000bbd0d, uci_id_etm4),/* Qualcomm Kryo 5XX Cortex-A77 */
CS_AMBA_UCI_ID(0x000cc0af, uci_id_etm4),/* Marvell ThunderX2 */
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 0abc11f0690c..d69cd66e8394 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -316,42 +316,50 @@ static int funnel_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = funnel_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void funnel_platform_remove(struct platform_device *pdev)
{
struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
funnel_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
static const struct of_device_id funnel_match[] = {
{.compatible = "arm,coresight-static-funnel"},
{}
};
MODULE_DEVICE_TABLE(of, funnel_match);
#ifdef CONFIG_ACPI
static const struct acpi_device_id funnel_acpi_ids[] = {
{"ARMHC9FE", 0, 0, 0}, /* ARM Coresight Static Funnel */
{"ARMHC9FF", 0, 0, 0}, /* ARM CoreSight Dynamic Funnel */
{},
};
MODULE_DEVICE_TABLE(acpi, funnel_acpi_ids);
#endif
static struct platform_driver funnel_driver = {
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 2f382de357ee..1df01deb2f69 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -295,42 +295,50 @@ static int replicator_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = replicator_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void replicator_platform_remove(struct platform_device *pdev)
{
struct replicator_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
replicator_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int replicator_runtime_suspend(struct device *dev)
{
struct replicator_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->atclk);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int replicator_runtime_resume(struct device *dev)
{
struct replicator_drvdata *drvdata = dev_get_drvdata(dev);
int ret;
ret = clk_prepare_enable(drvdata->pclk);
if (ret)
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 4e860519a73f..a75b1c56a867 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -1008,42 +1008,50 @@ static int stm_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __stm_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void stm_platform_remove(struct platform_device *pdev)
{
struct stm_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__stm_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_ACPI
static const struct acpi_device_id stm_acpi_ids[] = {
{"ARMHC502", 0, 0, 0}, /* ARM CoreSight STM */
{},
};
MODULE_DEVICE_TABLE(acpi, stm_acpi_ids);
#endif
static struct platform_driver stm_platform_driver = {
.probe = stm_platform_probe,
.remove = stm_platform_remove,
.driver = {
.name = "coresight-stm-platform",
.acpi_match_table = ACPI_PTR(stm_acpi_ids),
.suppress_bind_attrs = true,
.pm = &stm_dev_pm_ops,
},
};
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index bc5a133ada3e..ed40bfea32f9 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -971,42 +971,50 @@ static int tmc_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __tmc_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void tmc_platform_remove(struct platform_device *pdev)
{
struct tmc_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__tmc_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int tmc_runtime_suspend(struct device *dev)
{
struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->atclk);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int tmc_runtime_resume(struct device *dev)
{
struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
int ret;
ret = clk_prepare_enable(drvdata->pclk);
if (ret)
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 7b029d2eb389..775507d0bb36 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -268,42 +268,50 @@ static int tpiu_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __tpiu_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void tpiu_platform_remove(struct platform_device *pdev)
{
struct tpiu_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__tpiu_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_ACPI
static const struct acpi_device_id tpiu_acpi_ids[] = {
{"ARMHC979", 0, 0, 0}, /* ARM CoreSight TPIU */
{}
};
MODULE_DEVICE_TABLE(acpi, tpiu_acpi_ids);
#endif
static struct platform_driver tpiu_platform_driver = {
.probe = tpiu_platform_probe,
.remove = tpiu_platform_remove,
.driver = {
.name = "coresight-tpiu-platform",
.acpi_match_table = ACPI_PTR(tpiu_acpi_ids),
.suppress_bind_attrs = true,
.pm = &tpiu_dev_pm_ops,
},
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/2] coresight: tnoc: Fix clock refcount imbalance on platform remove
From: Jie Gan @ 2026-07-02 8:54 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Anshuman Khandual, Yeoreum Yun,
Yuanfang Zhang, Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, linux-stm32, Jie Gan
In-Reply-To: <20260702-fix-clock-refcount-unbalance-v2-0-2383fbb9952e@oss.qualcomm.com>
coresight_get_enable_clocks() enables the programming clock through
devm_clk_get_optional_enabled(), which also registers a devm action to
call clk_disable_unprepare() when the driver detaches.
After probe, pm_runtime_put() allows the device to suspend and the
runtime suspend callback disables the clock. During remove the device is
left runtime suspended, so pm_runtime_disable() freezes it with the
clock already disabled. The devm cleanup that runs afterwards calls
clk_disable_unprepare() a second time, underflowing the clock enable
refcount.
Resume the device with pm_runtime_get_sync() before tearing it down so
the clock is enabled again and balances the devm-managed disable. Then
pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device
in a coherent runtime PM state (suspended, usage count balanced) once
the devm action has disabled the clock.
Fixes: 1abc1b212eff ("coresight: Appropriately disable programming clocks")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tnoc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tnoc.c b/drivers/hwtracing/coresight/coresight-tnoc.c
index 9e8de4323d28..eddfdcbaa3ec 100644
--- a/drivers/hwtracing/coresight/coresight-tnoc.c
+++ b/drivers/hwtracing/coresight/coresight-tnoc.c
@@ -282,42 +282,50 @@ static int itnoc_probe(struct platform_device *pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int ret;
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = _tnoc_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void itnoc_remove(struct platform_device *pdev)
{
struct trace_noc_drvdata *drvdata = platform_get_drvdata(pdev);
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
coresight_unregister(drvdata->csdev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int itnoc_runtime_suspend(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int itnoc_runtime_resume(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
return clk_prepare_enable(drvdata->pclk);
}
#endif
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Gokul Praveen @ 2026-07-02 8:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar, Gokul Praveen
In-Reply-To: <20260702-vigilant-tody-of-inquire-ffbede@quoll>
Hi Krzysztof,
On 02/07/26 11:53, Krzysztof Kozlowski wrote:
> On Wed, Jul 01, 2026 at 07:54:56PM +0530, Gokul Praveen wrote:
>> Update maxItems value of "clocks" property to 3 as description of
>> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
>> and phy_en_refclk(optional)).
> But what if description is wrong? You need to provide rationale why you
> are doing it and you cannot use existing code alone as that rationale,
> because as you pointed out - existing code is not fully correct.
>
>> Update the maxItems and items value of "clock-names" property with multiple
>> combination of clock-names possible since pll1_refclk and phy_en_refclk are
>> optional clocks.
> Why? You need to describe why you are doing this, not what you are
> doing.
>
Would the below commit description be good enough ? Please feel free to
give any suggestions on this:
''
dt-bindings: phy: cadence-torrent: Update property values to support 3
clocks
Increase the maxItems value of "clocks" property to 3 to support
2 input clocks(refclk,pll1_refclk) and 1 output clock(phy_en_refclk).
For multilink SERDES configurations where the links require 2
different input clock speeds,
2 different input reference clocks and 1 output clock is needed so
as to cater to this requirement.
For eg: Considering the USXGMII+SGMII multilink SERDES
configuration usecase ,
having only 1 input reference clock fails because USXGMII requires
an input clock speed of 156.25 Mhz and
SGMII protocol requires an input clock speed of 100 Mhz.
Since one input reference clock(refclk) alone cannot cater to the 2
different clock speed requirements
of these protocols, the second input reference clock(pll1_refclk)
has to be added.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
''
>> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
>> ---
>> .../bindings/phy/phy-cadence-torrent.yaml | 16 ++++++++++++----
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> index 9af39b33646a..96c664d50629 100644
>> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> @@ -34,7 +34,7 @@ properties:
>>
>> clocks:
>> minItems: 1
>> - maxItems: 2
>> + maxItems: 3
>> description:
>> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
>> pll1_refclk is optional and used for multi-protocol configurations requiring
>> @@ -45,9 +45,17 @@ properties:
>>
>> clock-names:
>> minItems: 1
>> - items:
>> - - const: refclk
>> - - enum: [ pll1_refclk, phy_en_refclk ]
>> + maxItems: 3
> Drop
sure krzysztof.
>> + oneOf:
>> + - items:
>> + - const: refclk
>> + - items:
>> + - const: refclk
>> + - enum: [ pll1_refclk, phy_en_refclk ]
> Drop these, pointless. You were supposed to grow existing syntax.
>
Sure Krzysztof
>> + - items:
>> + - const: refclk
>> + - const: pll1_refclk
> So here is the enum.
>
>> + - const: phy_en_refclk
>>
>> And this stays.
SUre Krzysztof
>>
>> You make changes which do not make the binding better and are not
>> explained in commit msg. Focus on WHY you are doing things and also
>> explain WHY you did such complicated syntax (if you insist on rewriting
>> correct code into something odd we do not expect).
>>
>> Best regards,
>> Krzysztof
Best Regards
Gokul Praveen
>
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v3 2/7] net: wwan: t9xx: Add control plane transaction layer
From: Wu. JackBB (GSM) @ 2026-07-02 8:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <92b1e341-31a1-4f60-80d5-ccf8f742a38a@lunn.ch>
Hi Andrew,
> > mtk_dev_alloc/mtk_dev_free are paired wrappers so the caller
> > doesn't need to know the underlying allocation mechanism.
> > The devm_kfree is still called inside mtk_dev_free.
>
> Two different issues here:
>
> 1) If you don't want to use devm_, don't use devm_ from the
> beginning. A patch should not change how a previous patch works, since
> you are wasting reviewer time reviewing code which you later change.
>
> 2) Do you understand what devm_ actually does? Since you use
> devm_free() i don't think you actually understand what devm_ is all
> about.
Thank you for the explanation. You are right.
we will remove the mtk_dev_alloc/mtk_dev_free wrappers and use
devm_kzalloc directly from the beginning.
We will also remove all unnecessary devm_kfree() calls from probe
error paths and remove paths, keeping them only where resources
are freed and re-allocated at runtime (e.g., CLDMA queue lifecycle
during modem reset cycles).
Thanks.
Jack Wu
^ permalink raw reply
* Re: [PATCH RFC 0/8] clk: sunxi-ng: Add support for Allwinner A733 CCU and PRCM
From: Andre Przywara @ 2026-07-02 8:57 UTC (permalink / raw)
To: Enzo Adriano, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jerome Brunet, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv, netdev
In-Reply-To: <20260701160055.320000-a733-ccu-status-enzo.adriano.code@gmail.com>
Hi Enzo,
On 7/1/26 18:07, Enzo Adriano wrote:
> Hi Junhui,
>
> Thanks for the A733 CCU/PRCM RFC v1. I've been reading through the
> series and the review feedback, including the NSI clock/reset handling,
> the binding naming and ordering comments, the SDM macro cleanup, and the
> question around modeled but otherwise-unused clocks such as the GIC clock.
that's great, but please tell the list, by replying to the respective
patches. There are still a few patches left that haven't been checked
against the manual or otherwise reviewed. I will probably do this at
some point in time, but we could use any help here.
You don't need to be an expert for this: just comparing the numbers in
the struct (register offsets and bit positions) against the manual is
already very helpful, and can be done by most people, just with some
endurance ;-)
Thanks,
Andre
> I do not see a v2 on the list yet, so I wanted to check in: are you still
> planning to take this series forward? No rush at all, and I am happy to
> leave it entirely with you if so.
>
> If you have moved on to other things, I would be glad to help carry the
> series forward and address the review comments, keeping your authorship
> and prior work intact. I have A733 hardware here and can help test the
> changes.
>
> Either way, please let me know what works best for you.
>
> Thanks,
> Enzo
^ permalink raw reply
* Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable
From: Marc Zyngier @ 2026-07-02 8:59 UTC (permalink / raw)
To: Bradley Morgan
Cc: Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, Leonardo Bras,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260701192428.17430-1-include@grrlz.net>
+ Vincent, Leo
On Wed, 01 Jul 2026 20:24:28 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> pKVM keeps its own mapping list for stage 2 operations. Its flush path
> uses that list directly, so it lost the PTE attribute check done by the
> generic stage 2 walker.
>
> Record whether a mapping is cacheable and skip cache maintenance for
> mappings that are not cacheable.
>
> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> Signed-off-by: Bradley Morgan <include@grrlz.net>
> ---
> Changes since V3:
> - addressed some review :)
This isn't a change log. If you want to be taken seriously, I'd
suggest you start by following the process. You are otherwise wasting
people's time. Again.
You also failed to Cc people who have provided feedback on previous
versions. That's not right.
>
> arch/arm64/kvm/pkvm.c | 51 ++++++++++++++++++++++++++++++++++---------
> 1 file changed, 41 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 053e4f733e4b..6d1cad890c7e 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct pkvm_mapping *m)
> return m->gfn * PAGE_SIZE;
> }
>
> +#define PKVM_MAPPING_NR_PAGES_MASK GENMASK_ULL(47, 0)
> +#define PKVM_MAPPING_NC BIT_ULL(48)
> +
> +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
> +{
> + return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> +}
No. You've been pointed to the correct data structure (an anonymous
structure containing bit fields). Please consider taking the review
comments into account.
This would avoid most of the churn in this patch, and make it easy to
backport. Something like the untested hack below.
M.
diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
index 74fedd9c5ff02..cdddc9e3a11f5 100644
--- a/arch/arm64/include/asm/kvm_pkvm.h
+++ b/arch/arm64/include/asm/kvm_pkvm.h
@@ -195,7 +195,10 @@ struct pkvm_mapping {
struct rb_node node;
u64 gfn;
u64 pfn;
- u64 nr_pages;
+ struct {
+ unsigned long nr_pages:48;
+ unsigned int nc:1;
+ };
u64 __subtree_last; /* Internal member for interval tree */
};
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 428723b1b0f5c..5932b93bded58 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -369,7 +369,7 @@ static int __pkvm_pgtable_stage2_unshare(struct kvm_pgtable *pgt, u64 start, u64
for_each_mapping_in_range_safe(pgt, start, end, mapping) {
ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
- mapping->nr_pages);
+ (u64)mapping->nr_pages);
if (WARN_ON(ret))
return ret;
pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
@@ -473,6 +473,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
mapping->gfn = gfn;
mapping->pfn = pfn;
mapping->nr_pages = size / PAGE_SIZE;
+ mapping->nc = !!(prot & (KVM_PGTABLE_PROT_DEVICE | KVM_PGTABLE_PROT_NORMAL_NC));
pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
return ret;
@@ -503,7 +504,7 @@ int pkvm_pgtable_stage2_wrprotect(struct kvm_pgtable *pgt, u64 addr, u64 size)
lockdep_assert_held(&kvm->mmu_lock);
for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
- mapping->nr_pages);
+ (u64)mapping->nr_pages);
if (WARN_ON(ret))
break;
}
@@ -517,10 +518,11 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable *pgt, u64 addr, u64 size)
struct pkvm_mapping *mapping;
lockdep_assert_held(&kvm->mmu_lock);
- for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
- __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
- PAGE_SIZE * mapping->nr_pages);
-
+ for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
+ if (!mapping->nc)
+ __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
+ PAGE_SIZE * mapping->nr_pages);
+ }
return 0;
}
@@ -537,7 +539,7 @@ bool pkvm_pgtable_stage2_test_clear_young(struct kvm_pgtable *pgt, u64 addr, u64
lockdep_assert_held(&kvm->mmu_lock);
for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
- mapping->nr_pages, mkold);
+ (u64)mapping->nr_pages, mkold);
return young;
}
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH] futex: Optimise the size check get_futex_key()
From: Peter Zijlstra @ 2026-07-02 8:59 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: K Prateek Nayak, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Catalin Marinas, Will Deacon,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Darren Hart, Davidlohr Bueso,
André Almeida, linux-arch, linux-kernel, Samuel Holland,
Charlie Jenkins, linux-arm-kernel, linux-riscv, linux-s390,
H. Peter Anvin, Thomas Huth, Sean Christopherson, Jisheng Zhang,
Alexandre Ghiti, Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260701161736.xYYizA0e@linutronix.de>
On Wed, Jul 01, 2026 at 06:17:36PM +0200, Sebastian Andrzej Siewior wrote:
> The futex address must be naturally aligned and this is checked via
> "address % size" where `address' is the supplied address and `size' is
> the expected size of futex. It is guaranteed that `size' is power of two
> but the compiler does not see it and creates here a `div' operation
> (x86, arm, gcc-15).
That's pretty stupid, since size = futex_size() := 1 << (blah); so it
has every opportunity to actually see this. Also, see below, clang does!
> We can take advantage of the pow2 property and rewrite it as
> "address & (size-1)".
>
> As per testing, the command
> |perf bench futex hash -f 1 -b 16384 -t 1 -r 30
>
> improved from
> | [thread 0] futex: 0x5619f931f740 [ 7001583 ops/sec ]
> to
> | [thread 0] futex: 0x55da173e5740 [ 7376137 ops/sec ]
>
> or by 5.3%
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>
> Could someone verify this, please? The 5% look a bit high. This is on
> top of the series (but not worsen by the series).
Bah, I tried to reproduce and couldn't. Then I noticed I did a clang
build and that is in fact clever enough to do this optimization itself.
/me tries again with a GCC build.
pre: [thread 0] futex: 0x561f14430680 [ 9021408 ops/sec ]
post: [thread 0] futex: 0x55feadbbb680 [ 8977527 ops/sec ]
(and this seems to be well inside the error threshold of this test).
So I see the GCC build do the DIV, and no longer with his patch applied,
but for some reason I cannot get the runtime performance to actually
improve much of anything on my system.
^ permalink raw reply
* Re: [PATCH RFC v5 05/12] clk: zte: Add Clock registration infrastructure.
From: Philipp Zabel @ 2026-07-02 9:01 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <84C4450E-7355-48CD-BCBB-CF619C27EBED@gmail.com>
On Di, 2026-06-30 at 11:53 +0300, Stefan Dösinger wrote:
> Hi Philipp,
>
> > Am 30.06.2026 um 11:27 schrieb Philipp Zabel <p.zabel@pengutronix.de>:
> >
> > I think the MFD driver is unnecessary overhead. Can't you just keep the
> > reset controllers as auxdev and use of_platform_populate() to create
> > devices for clock-controller child nodes such as syscon-reboot?
>
> MFD for top and matrix was the suggestion of Conor:
>
> https://lore.kernel.org/linux-arm-kernel/20260618-fantasy-estimate-6c52edbc6890@spud/
>
> To quote:
>
> > I think aux bus makes perfect sense when you have a clock/reset
> > controller, but once you start expanding past that and you have reboot
> > or hwmon or hwspinlock then mfd starts to make sense.
Note how the example Conor gives is introduced with:
> > Because I messed up stuff in the past, reset-mpfs.c has both aux bus
> > and mfd probing in it, [...]
So while, yes, this is possible, I'd like to avoid it if not necessary.
> I can go either way. To me aux vs mfd seems like a distinction without a difference.
I think that's because the main difference doesn't apply here:
MFD comes from aggregate devices where a shared register space
accessible via a physical bus (which we have) can be partitioned out to
child devices. Reset controls are often just individual registers or
even bits scattered around the CRU register space, so we can't make use
of the MFD framework's IO/IRQ resource partitioning infrastructure at
all.
Auxiliary devices were introduced to separate functionality of a single
device into subsystem drivers (which applies here) for devices that are
not just controlled via direct register access, for example via a
firmware interface. That's not the case here, we usually can just share
a regmap.
Either way, I'd prefer the reset driver to not carry more boilerplate
than actual reset code, so if you can either put all of them into a
single auxiliary_driver or into a single platform_driver, I would be
happier.
regards
Philipp
^ permalink raw reply
* [PATCH v5 0/4] gpio: realtek: Add support for Realtek DHC RTD1625
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
This series adds GPIO support for the Realtek DHC RTD1625 SoC.
Unlike the existing driver (gpio-rtd.c) which uses shared bank registers,
the RTD1625 features a per-pin register architecture where each GPIO line
is managed by its own dedicated 32-bit control register. This distinct
hardware design requires a new, separate driver.
Best Regards,
Yu-Chun Lin
---
Changes in v5:
Patch 3 (driver):
- Add comment for @base_offset.
- Rename the local 'gpio_irq_chip' pointer to 'girq' to match common
GPIO IRQ naming.
- Drop the intermediate variable.
v4: https://lore.kernel.org/lkml/20260622092335.1166876-1-eleanor.lin@realtek.com/
v3: https://lore.kernel.org/lkml/20260512033317.1602537-1-eleanor.lin@realtek.com/
v2: https://lore.kernel.org/lkml/20260408025243.1155482-1-eleanor.lin@realtek.com/
v1: https://lore.kernel.org/lkml/20260331113835.3510341-1-eleanor.lin@realtek.com/
Tzuyi Chang (2):
dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
Yu-Chun Lin (2):
gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
arm64: dts: realtek: Add GPIO support for RTD1625
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 ++
arch/arm64/boot/dts/realtek/kent.dtsi | 39 ++
drivers/gpio/Kconfig | 14 +-
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 610 ++++++++++++++++++
5 files changed, 734 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
create mode 100644 drivers/gpio/gpio-rtd1625.c
--
2.43.0
^ permalink raw reply
* [PATCH v5 2/4] gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
Replace "default y" with "default ARCH_REALTEK" to avoid bloating the build
for non-Realtek platforms when COMPILE_TEST is enabled on other platforms.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- None.
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 28cf6d2e83c2..ed2bc3113374 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -646,7 +646,7 @@ config GPIO_ROCKCHIP
config GPIO_RTD
tristate "Realtek DHC GPIO support"
depends on ARCH_REALTEK || COMPILE_TEST
- default y
+ default ARCH_REALTEK
select GPIOLIB_IRQCHIP
help
This option enables support for GPIOs found on Realtek DHC(Digital
--
2.43.0
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Krzysztof Kozlowski
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add the device tree bindings for the Realtek DHC (Digital Home Center)
RTD1625 GPIO controllers.
The RTD1625 GPIO controller features a per-pin register architecture
that differs significantly from previous generations. It utilizes
separate register blocks for GPIO configuration and interrupt control.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- None.
---
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 +++++++++++++++++++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
new file mode 100644
index 000000000000..f13c910b73c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/realtek,rtd1625-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD1625 GPIO controller
+
+maintainers:
+ - Tzuyi Chang <tychang@realtek.com>
+
+description: |
+ GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
+ architecture that differs significantly from earlier RTD series controllers.
+ Each GPIO has dedicated registers for configuration (direction, input/output
+ values, debounce), and interrupt control supporting edge and level detection
+ modes.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1625-iso-gpio
+ - realtek,rtd1625-isom-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Interrupt number of the assert GPIO interrupt, which is
+ triggered when there is a rising edge.
+ - description: Interrupt number of the deassert GPIO interrupt, which is
+ triggered when there is a falling edge.
+ - description: Interrupt number of the level-sensitive GPIO interrupt,
+ triggered by a configured logic level.
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-ranges: true
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-ranges
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ interrupt-parent = <&iso_m_irq_mux>;
+ interrupts = <0>, <1>, <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v5 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Bartosz Golaszewski
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
Add the GPIO node for the Realtek RTD1625 SoC.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- None.
---
arch/arm64/boot/dts/realtek/kent.dtsi | 39 +++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
index 8d4293cd4c03..228b82dfdb7a 100644
--- a/arch/arm64/boot/dts/realtek/kent.dtsi
+++ b/arch/arm64/boot/dts/realtek/kent.dtsi
@@ -151,6 +151,37 @@ uart0: serial@7800 {
status = "disabled";
};
+ gpio: gpio@31000 {
+ compatible = "realtek,rtd1625-iso-gpio";
+ reg = <0x31000 0x398>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 2>,
+ <&ve4_pinctrl 2 0 6>,
+ <&iso_pinctrl 8 0 4>,
+ <&ve4_pinctrl 12 6 2>,
+ <&main2_pinctrl 14 0 2>,
+ <&ve4_pinctrl 16 8 4>,
+ <&main2_pinctrl 20 2 3>,
+ <&ve4_pinctrl 23 12 3>,
+ <&iso_pinctrl 26 4 2>,
+ <&isom_pinctrl 28 2 2>,
+ <&ve4_pinctrl 30 15 6>,
+ <&main2_pinctrl 36 5 6>,
+ <&ve4_pinctrl 42 21 3>,
+ <&iso_pinctrl 45 6 6>,
+ <&ve4_pinctrl 51 24 1>,
+ <&iso_pinctrl 52 12 1>,
+ <&ve4_pinctrl 53 25 11>,
+ <&main2_pinctrl 64 11 28>,
+ <&ve4_pinctrl 92 36 2>,
+ <&iso_pinctrl 94 13 19>,
+ <&iso_pinctrl 128 32 4>,
+ <&ve4_pinctrl 132 38 13>,
+ <&iso_pinctrl 145 36 19>,
+ <&ve4_pinctrl 164 51 2>;
+ #gpio-cells = <2>;
+ };
+
iso_pinctrl: pinctrl@4e000 {
compatible = "realtek,rtd1625-iso-pinctrl";
reg = <0x4e000 0x1a4>;
@@ -161,6 +192,14 @@ main2_pinctrl: pinctrl@4f200 {
reg = <0x4f200 0x50>;
};
+ iso_m_gpio: gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ #gpio-cells = <2>;
+ };
+
isom_pinctrl: pinctrl@146200 {
compatible = "realtek,rtd1625-isom-pinctrl";
reg = <0x146200 0x34>;
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin @ 2026-07-02 9:01 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
In-Reply-To: <20260702090115.2564318-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
which manages pins via shared bank registers, the RTD1625 introduces
a per-pin register architecture. Each GPIO line now has its own
dedicated 32-bit control register to manage configuration independently,
including direction, output value, input value, interrupt enable, and
debounce. Therefore, this distinct hardware design requires a separate
driver.
Additionally, the RTD1625 GPIO controller has a specific hardware quirk:
it fires both 'assert' and 'de-assert' interrupts simultaneously on any
edge toggle. To handle this, we utilize the polarity register to route
the requested edge (rising/falling) to the 'assert' IRQ line. The driver
then filters out the unwanted 'de-assert' interrupt in the IRQ handler
and pre-clears edge interrupts to prevent interrupt storms caused by
unhandled dropped interrupts.
Interrupt support is optional for this device, matching the dt-bindings.
If the interrupts property is not provided, the driver simply skips IRQ
initialization and operates purely as a basic GPIO controller.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v5:
- Add comment for @base_offset.
- Rename the local 'gpio_irq_chip' pointer to 'girq' to match common
GPIO IRQ naming.
- Drop the intermediate variable.
---
drivers/gpio/Kconfig | 12 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 610 ++++++++++++++++++++++++++++++++++++
3 files changed, 623 insertions(+)
create mode 100644 drivers/gpio/gpio-rtd1625.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ed2bc3113374..f03c05288376 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -656,6 +656,18 @@ config GPIO_RTD
Say yes here to support GPIO functionality and GPIO interrupt on
Realtek DHC SoCs.
+config GPIO_RTD1625
+ tristate "Realtek DHC RTD1625 GPIO support"
+ depends on ARCH_REALTEK || COMPILE_TEST
+ default ARCH_REALTEK
+ select GPIOLIB_IRQCHIP
+ help
+ This option enables support for the GPIO controller on Realtek
+ DHC (Digital Home Center) RTD1625 SoC.
+
+ Say yes here to support both basic GPIO line functionality
+ and GPIO interrupt handling capabilities for this platform.
+
config GPIO_SAMA5D2_PIOBU
tristate "SAMA5D2 PIOBU GPIO support"
depends on OF
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4d0e900402fc..fa14581e3995 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
obj-$(CONFIG_GPIO_REG) += gpio-reg.o
obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
+obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
new file mode 100644
index 000000000000..27af1ac65d28
--- /dev/null
+++ b/drivers/gpio/gpio-rtd1625.c
@@ -0,0 +1,610 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek DHC RTD1625 gpio driver
+ *
+ * Copyright (c) 2023-2026 Realtek Semiconductor Corp.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cleanup.h>
+#include <linux/gpio/driver.h>
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define RTD1625_GPIO_DIR BIT(0)
+#define RTD1625_GPIO_OUT BIT(2)
+#define RTD1625_GPIO_IN BIT(4)
+#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
+#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
+#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
+#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
+#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
+#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
+
+#define RTD1625_GPIO_WREN(x) ((x) << 1)
+
+/* Write-enable masks for all GPIO configs and reserved hardware bits */
+#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
+#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
+
+#define RTD1625_GPIO_DEBOUNCE_1US 0
+#define RTD1625_GPIO_DEBOUNCE_10US 1
+#define RTD1625_GPIO_DEBOUNCE_100US 2
+#define RTD1625_GPIO_DEBOUNCE_1MS 3
+#define RTD1625_GPIO_DEBOUNCE_10MS 4
+#define RTD1625_GPIO_DEBOUNCE_20MS 5
+#define RTD1625_GPIO_DEBOUNCE_30MS 6
+#define RTD1625_GPIO_DEBOUNCE_50MS 7
+
+#define GPIO_CONTROL(gpio) ((gpio) * 4)
+
+enum rtd1625_irq_index {
+ RTD1625_IRQ_ASSERT,
+ RTD1625_IRQ_DEASSERT,
+ RTD1625_IRQ_LEVEL,
+ RTD1625_MAX_IRQS
+};
+
+/**
+ * struct rtd1625_gpio_info - Specific GPIO register information
+ * @num_gpios: The number of GPIOs
+ * @irq_type_support: Supported IRQ types
+ * @base_offset: Offset for GPIO controller register
+ * @gpa_offset: Offset for GPIO assert interrupt status registers
+ * @gpda_offset: Offset for GPIO deassert interrupt status registers
+ * @level_offset: Offset of level interrupt status register
+ * @write_en_all: Write-enable mask for all configurable bits
+ */
+struct rtd1625_gpio_info {
+ unsigned int num_gpios;
+ unsigned int irq_type_support;
+ unsigned int base_offset;
+ unsigned int gpa_offset;
+ unsigned int gpda_offset;
+ unsigned int level_offset;
+ unsigned int write_en_all;
+};
+
+struct rtd1625_gpio {
+ struct gpio_chip gpio_chip;
+ const struct rtd1625_gpio_info *info;
+ void __iomem *base;
+ void __iomem *irq_base;
+ unsigned int irqs[RTD1625_MAX_IRQS];
+ raw_spinlock_t lock;
+ unsigned int *save_regs;
+};
+
+static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpa_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpda_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->level_offset + ((offset / 32) * 4);
+}
+
+static int rtd1625_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+ unsigned int debounce)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u8 deb_val;
+ u32 val;
+
+ switch (debounce) {
+ case 1:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1US;
+ break;
+ case 10:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10US;
+ break;
+ case 100:
+ deb_val = RTD1625_GPIO_DEBOUNCE_100US;
+ break;
+ case 1000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1MS;
+ break;
+ case 10000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10MS;
+ break;
+ case 20000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_20MS;
+ break;
+ case 30000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_30MS;
+ break;
+ case 50000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_50MS;
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
+ val = FIELD_PREP(RTD1625_GPIO_DEBOUNCE, deb_val) | RTD1625_GPIO_DEBOUNCE_WREN;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
+{
+ u32 debounce;
+
+ if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE) {
+ debounce = pinconf_to_config_argument(config);
+ return rtd1625_gpio_set_debounce(chip, offset, debounce);
+ }
+
+ return gpiochip_generic_config(chip, offset, config);
+}
+
+static int rtd1625_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_OUT);
+
+ if (value)
+ val |= RTD1625_GPIO_OUT;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return !!(val & RTD1625_GPIO_OUT);
+ else
+ return !!(val & RTD1625_GPIO_IN);
+}
+
+static int rtd1625_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return GPIO_LINE_DIRECTION_OUT;
+
+ return GPIO_LINE_DIRECTION_IN;
+}
+
+static int rtd1625_gpio_set_direction(struct gpio_chip *chip, unsigned int offset, bool out)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_DIR);
+
+ if (out)
+ val |= RTD1625_GPIO_DIR;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ return rtd1625_gpio_set_direction(chip, offset, false);
+}
+
+static int rtd1625_gpio_direction_output(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ rtd1625_gpio_set(chip, offset, value);
+
+ return rtd1625_gpio_set_direction(chip, offset, true);
+}
+
+static void rtd1625_gpio_irq_handle(struct irq_desc *desc)
+{
+ unsigned int (*get_reg_offset)(struct rtd1625_gpio *gpio, unsigned int offset);
+ struct rtd1625_gpio *data = irq_desc_get_handler_data(desc);
+ struct irq_domain *domain = data->gpio_chip.irq.domain;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int irq = irq_desc_get_irq(desc);
+ unsigned long status;
+ unsigned int reg_offset, i, j;
+ irq_hw_number_t hwirq;
+ u32 irq_type;
+
+ if (irq == data->irqs[RTD1625_IRQ_ASSERT])
+ get_reg_offset = &rtd1625_gpio_gpa_offset;
+ else if (irq == data->irqs[RTD1625_IRQ_DEASSERT])
+ get_reg_offset = &rtd1625_gpio_gpda_offset;
+ else if (irq == data->irqs[2])
+ get_reg_offset = &rtd1625_gpio_level_offset;
+ else
+ return;
+
+ chained_irq_enter(chip, desc);
+
+ for (i = 0; i < data->info->num_gpios; i += 32) {
+ reg_offset = get_reg_offset(data, i);
+ status = readl_relaxed(data->irq_base + reg_offset);
+
+ /*
+ * Hardware quirk: The controller fires both "assert" and "de-assert"
+ * interrupts simultaneously on any edge toggle.
+ * We must pre-clear edge interrupts here. If we drop an unwanted
+ * de-assert interrupt below, it will never reach the IRQ core
+ * (generic_handle_domain_irq), meaning ->irq_ack() won't be called.
+ * Failing to clear it here leads to an interrupt storm.
+ */
+ if (irq != data->irqs[RTD1625_IRQ_LEVEL])
+ writel_relaxed(status, data->irq_base + reg_offset);
+
+ for_each_set_bit(j, &status, 32) {
+ hwirq = i + j;
+ irq_type = irq_get_trigger_type(irq_find_mapping(domain, hwirq));
+
+ /*
+ * Filter out the hardware-forced de-assert interrupt unless
+ * the user explicitly requested IRQ_TYPE_EDGE_BOTH.
+ */
+ if (irq == data->irqs[RTD1625_IRQ_DEASSERT] &&
+ irq_type != IRQ_TYPE_EDGE_BOTH)
+ continue;
+
+ generic_handle_domain_irq(domain, hwirq);
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static void rtd1625_gpio_ack_irq(struct irq_data *d)
+{
+ struct rtd1625_gpio *data = irq_data_get_irq_chip_data(d);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+ u32 bit_mask = BIT(hwirq % 32);
+ int reg_offset;
+
+ if (irq_type & IRQ_TYPE_LEVEL_MASK) {
+ reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ writel_relaxed(bit_mask, data->irq_base + reg_offset);
+ }
+}
+
+static void rtd1625_gpio_enable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int gpda_reg_offset = rtd1625_gpio_gpda_offset(data, hwirq);
+ int gpa_reg_offset = rtd1625_gpio_gpa_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + gpa_reg_offset);
+ writel_relaxed(clr_mask, data->irq_base + gpda_reg_offset);
+ val = RTD1625_GPIO_EDGE_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int level_reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + level_reg_offset);
+ val = RTD1625_GPIO_LEVEL_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ gpiochip_enable_irq(gc, hwirq);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_enable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_enable_level_irq(data, hwirq);
+}
+
+static void rtd1625_gpio_disable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_disable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_disable_level_irq(data, hwirq);
+
+ gpiochip_disable_irq(gc, hwirq);
+}
+
+static int rtd1625_gpio_irq_set_level_type(struct irq_data *d, bool level)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK))
+ return -EINVAL;
+
+ if (level)
+ val |= RTD1625_GPIO_LEVEL_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_level_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_edge_type(struct irq_data *d, bool polarity)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_EDGE_BOTH))
+ return -EINVAL;
+
+ if (polarity)
+ val |= RTD1625_GPIO_EDGE_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_edge_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ switch (type & IRQ_TYPE_SENSE_MASK) {
+ case IRQ_TYPE_EDGE_RISING:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_EDGE_FALLING:
+ return rtd1625_gpio_irq_set_edge_type(d, 0);
+
+ case IRQ_TYPE_EDGE_BOTH:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_LEVEL_HIGH:
+ return rtd1625_gpio_irq_set_level_type(d, 0);
+
+ case IRQ_TYPE_LEVEL_LOW:
+ return rtd1625_gpio_irq_set_level_type(d, 1);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static struct irq_chip rtd1625_iso_gpio_irq_chip = {
+ .name = "rtd1625-gpio",
+ .irq_ack = rtd1625_gpio_ack_irq,
+ .irq_mask = rtd1625_gpio_disable_irq,
+ .irq_unmask = rtd1625_gpio_enable_irq,
+ .irq_set_type = rtd1625_gpio_irq_set_type,
+ .flags = IRQCHIP_IMMUTABLE | IRQCHIP_SKIP_SET_WAKE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
+};
+
+static int rtd1625_gpio_setup_irq(struct platform_device *pdev, struct rtd1625_gpio *data)
+{
+ struct gpio_irq_chip *girq;
+ unsigned int num_irqs;
+ int irq;
+
+ /*
+ * Interrupt support is optional. All IRQs must be provided together.
+ * If index 0 is missing, we assume no interrupts are configured in DT
+ * and fall back to basic GPIO operation.
+ */
+ irq = platform_get_irq_optional(pdev, 0);
+ if (irq == -ENXIO)
+ return 0;
+ if (irq < 0)
+ return irq;
+
+ num_irqs = (data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK) ? 3 : 2;
+ data->irqs[RTD1625_IRQ_ASSERT] = irq;
+
+ for (unsigned int i = 1; i < num_irqs; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0)
+ return irq;
+ data->irqs[i] = irq;
+ }
+
+ girq = &data->gpio_chip.irq;
+ girq->handler = handle_bad_irq;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->parent_handler = rtd1625_gpio_irq_handle;
+ girq->parent_handler_data = data;
+ girq->num_parents = num_irqs;
+ girq->parents = data->irqs;
+
+ gpio_irq_chip_set_chip(girq, &rtd1625_iso_gpio_irq_chip);
+
+ return 0;
+}
+
+static int rtd1625_gpio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rtd1625_gpio *data;
+ void __iomem *irq_base;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->info = device_get_match_data(dev);
+ if (!data->info)
+ return -EINVAL;
+
+ raw_spin_lock_init(&data->lock);
+
+ irq_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(irq_base))
+ return PTR_ERR(irq_base);
+
+ data->irq_base = irq_base;
+ data->base = irq_base + data->info->base_offset;
+
+ data->save_regs = devm_kcalloc(dev, data->info->num_gpios, sizeof(*data->save_regs),
+ GFP_KERNEL);
+ if (!data->save_regs)
+ return -ENOMEM;
+
+ data->gpio_chip.label = dev_name(dev);
+ data->gpio_chip.base = -1;
+ data->gpio_chip.ngpio = data->info->num_gpios;
+ data->gpio_chip.request = gpiochip_generic_request;
+ data->gpio_chip.free = gpiochip_generic_free;
+ data->gpio_chip.get_direction = rtd1625_gpio_get_direction;
+ data->gpio_chip.direction_input = rtd1625_gpio_direction_input;
+ data->gpio_chip.direction_output = rtd1625_gpio_direction_output;
+ data->gpio_chip.set = rtd1625_gpio_set;
+ data->gpio_chip.get = rtd1625_gpio_get;
+ data->gpio_chip.set_config = rtd1625_gpio_set_config;
+ data->gpio_chip.parent = dev;
+
+ ret = rtd1625_gpio_setup_irq(pdev, data);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, data);
+
+ return devm_gpiochip_add_data(dev, &data->gpio_chip, data);
+}
+
+static const struct rtd1625_gpio_info rtd1625_iso_gpio_info = {
+ .num_gpios = 166,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH,
+ .base_offset = 0x100,
+ .gpa_offset = 0x000,
+ .gpda_offset = 0x020,
+ .write_en_all = RTD1625_ISO_GPIO_WREN_ALL,
+};
+
+static const struct rtd1625_gpio_info rtd1625_isom_gpio_info = {
+ .num_gpios = 4,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_LOW |
+ IRQ_TYPE_LEVEL_HIGH,
+ .base_offset = 0x20,
+ .gpa_offset = 0x00,
+ .gpda_offset = 0x04,
+ .level_offset = 0x18,
+ .write_en_all = RTD1625_ISOM_GPIO_WREN_ALL,
+};
+
+static int rtd1625_gpio_suspend(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ data->save_regs[i] = readl_relaxed(data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static int rtd1625_gpio_resume(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ writel_relaxed(data->save_regs[i] | info->write_en_all,
+ data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static DEFINE_NOIRQ_DEV_PM_OPS(rtd1625_gpio_pm_ops, rtd1625_gpio_suspend, rtd1625_gpio_resume);
+
+static const struct of_device_id rtd1625_gpio_of_matches[] = {
+ { .compatible = "realtek,rtd1625-iso-gpio", .data = &rtd1625_iso_gpio_info },
+ { .compatible = "realtek,rtd1625-isom-gpio", .data = &rtd1625_isom_gpio_info },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rtd1625_gpio_of_matches);
+
+static struct platform_driver rtd1625_gpio_platform_driver = {
+ .driver = {
+ .name = "gpio-rtd1625",
+ .of_match_table = rtd1625_gpio_of_matches,
+ .pm = pm_sleep_ptr(&rtd1625_gpio_pm_ops),
+ },
+ .probe = rtd1625_gpio_probe,
+};
+module_platform_driver(rtd1625_gpio_platform_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Realtek Semiconductor Corporation");
+MODULE_DESCRIPTION("Realtek DHC SoC RTD1625 gpio driver");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Uladzislau Rezki @ 2026-07-02 9:04 UTC (permalink / raw)
To: Wen Jiang
Cc: Andrew Morton, linux-mm, linux-arm-kernel, catalin.marinas, will,
urezki, baohua, Xueyuan.chen21, dev.jain, rppt, david,
ryan.roberts, anshuman.khandual, ajd, linux-kernel, jiangwen6,
shanghaoqiang
In-Reply-To: <CAHKocdHJ-JB5jjXG3_-syz4P8k1C=jWrGaFxwnTjcinpGyR_BA@mail.gmail.com>
On Thu, Jul 02, 2026 at 02:35:24PM +0800, Wen Jiang wrote:
> On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> >
> > > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > > is physically fully or partially contiguous. Two techniques are used:
> >
> > Thanks.
> >
> > > 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)
> >
> > Nice.
> >
> > > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
> >
> > Indeed.
> >
> > I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> > folks) have time to go through this.
> >
> > Is there any effect on anything other than arm64? I'm wondering how
> > much testing these changes will really get in mm.git and linux-next.
> >
> > How is our selftests coverage of these changes? Is there some existing
> > selftest which will exercise these new features?
> >
>
> Hi Andrew,
>
> I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
> x86_64, comparing base (v7.0.10) against the patched kernel.
>
> All test_vmalloc subtests passed on both platforms. I do not see any
> functional or performance regression. The small differences below look
> like measurement noise.
>
> ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
> 5 runs averaged):
>
I think there are still comments to this series. One from me about
naming and there is one more from Jain here: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
Could you please have a look?
--
Uladzislau Rezki
^ 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