* [PATCH] fbdev: omapfb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 19:17 UTC (permalink / raw)
To: Helge Deller, Thomas Zimmermann, Kees Cook, Guangshuo Li,
Dan Carpenter, Tomi Valkeinen, linux-fbdev, linux-omap, dri-devel,
linux-kernel
Cc: stable
When platform_device_register() fails in omapfb_probe(), the embedded
struct device in omapdss_device has already been initialized by
device_initialize(), but the failure path only reports the error and
returns without dropping the device reference for the current platform
device:
omapfb_probe()
-> platform_device_register(&omapdss_device)
-> device_initialize(&omapdss_device.dev)
-> setup_pdev_dma_masks(&omapdss_device)
-> platform_device_add(&omapdss_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: f778a12dd3320 ("OMAP: OMAPFB: fix clk_get for RFBI")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/video/fbdev/omap/omapfb_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c
index cafe859d6e5a..0d47a8aec5c5 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -1768,6 +1768,7 @@ static int omapfb_probe(struct platform_device *pdev)
r = platform_device_register(&omapdss_device);
if (r) {
dev_err(&pdev->dev, "can't register omapdss device\n");
+ platform_device_put(&omapdss_device);
return r;
}
--
2.43.0
^ permalink raw reply related
* [PATCH] fbdev: q40fb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 19:13 UTC (permalink / raw)
To: Helge Deller, Guangshuo Li, linux-fbdev, dri-devel, linux-kernel; +Cc: stable
When platform_device_register() fails in q40fb_init(), the embedded
struct device in q40fb_device has already been initialized by
device_initialize(), but the failure path only unregisters the platform
driver and does not drop the device reference for the current platform
device:
q40fb_init()
-> platform_device_register(&q40fb_device)
-> device_initialize(&q40fb_device.dev)
-> setup_pdev_dma_masks(&q40fb_device)
-> platform_device_add(&q40fb_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before unregistering the
platform driver.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/video/fbdev/q40fb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/q40fb.c b/drivers/video/fbdev/q40fb.c
index 1ff8fa176124..0151a41267b3 100644
--- a/drivers/video/fbdev/q40fb.c
+++ b/drivers/video/fbdev/q40fb.c
@@ -141,8 +141,10 @@ static int __init q40fb_init(void)
if (!ret) {
ret = platform_device_register(&q40fb_device);
- if (ret)
+ if (ret) {
+ platform_device_put(&q40fb_device);
platform_driver_unregister(&q40fb_driver);
+ }
}
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH] fbdev: hitfb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 19:10 UTC (permalink / raw)
To: Helge Deller, Guangshuo Li, Andriy Skulysh, Paul Mundt,
linux-fbdev, dri-devel, linux-kernel
Cc: stable
When platform_device_register() fails in hitfb_init(), the embedded
struct device in hitfb_device has already been initialized by
device_initialize(), but the failure path only unregisters the platform
driver and does not drop the device reference for the current platform
device:
hitfb_init()
-> platform_device_register(&hitfb_device)
-> device_initialize(&hitfb_device.dev)
-> setup_pdev_dma_masks(&hitfb_device)
-> platform_device_add(&hitfb_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before unregistering the
platform driver.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: 048839dc548a5 ("video: hitfb suspend/resume and updates.")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/video/fbdev/hitfb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/hitfb.c b/drivers/video/fbdev/hitfb.c
index 97db325df2b4..29708c2d506d 100644
--- a/drivers/video/fbdev/hitfb.c
+++ b/drivers/video/fbdev/hitfb.c
@@ -495,8 +495,10 @@ static int __init hitfb_init(void)
ret = platform_driver_register(&hitfb_driver);
if (!ret) {
ret = platform_device_register(&hitfb_device);
- if (ret)
+ if (ret) {
+ platform_device_put(&hitfb_device);
platform_driver_unregister(&hitfb_driver);
+ }
}
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH] fbdev: dnfb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 19:07 UTC (permalink / raw)
To: Helge Deller, Guangshuo Li, linux-fbdev, dri-devel, linux-kernel; +Cc: stable
When platform_device_register() fails in dnfb_init(), the embedded
struct device in dnfb_device has already been initialized by
device_initialize(), but the failure path only unregisters the platform
driver and does not drop the device reference for the current platform
device:
dnfb_init()
-> platform_device_register(&dnfb_device)
-> device_initialize(&dnfb_device.dev)
-> setup_pdev_dma_masks(&dnfb_device)
-> platform_device_add(&dnfb_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before unregistering the
platform driver.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/video/fbdev/dnfb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/dnfb.c b/drivers/video/fbdev/dnfb.c
index c4d24540d9ef..72a9c47418f8 100644
--- a/drivers/video/fbdev/dnfb.c
+++ b/drivers/video/fbdev/dnfb.c
@@ -296,8 +296,10 @@ static int __init dnfb_init(void)
if (!ret) {
ret = platform_device_register(&dnfb_device);
- if (ret)
+ if (ret) {
+ platform_device_put(&dnfb_device);
platform_driver_unregister(&dnfb_driver);
+ }
}
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: [GIT PULL] fbdev fixes and updates for v7.1-rc1
From: pr-tracker-bot @ 2026-04-15 16:50 UTC (permalink / raw)
To: Helge Deller
Cc: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel,
Thomas Zimmermann
In-Reply-To: <ad5m1zGyRSJFwoC8@carbonx1>
The pull request you sent on Tue, 14 Apr 2026 18:09:59 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/afac4c66d1aa6396ce44d94fe895d7b61e085fd4
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [EXTERNAL] Re: [PATCH 1/8] hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
From: Thomas Zimmermann @ 2026-04-15 13:42 UTC (permalink / raw)
To: Saurabh Singh Sengar, javierm@redhat.com, arnd@arndb.de,
ardb@kernel.org, ilias.apalodimas@linaro.org,
chenhuacai@kernel.org, kernel@xen0n.name,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
airlied@gmail.com, simona@ffwll.ch, KY Srinivasan, Haiyang Zhang,
wei.liu@kernel.org, Dexuan Cui, Long Li, deller@gmx.de
Cc: linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
linux-efi@vger.kernel.org, linux-riscv@lists.infradead.org,
dri-devel@lists.freedesktop.org, linux-hyperv@vger.kernel.org,
linux-fbdev@vger.kernel.org, Michael Kelley, Saurabh Sengar,
stable@vger.kernel.org
In-Reply-To: <KUZP153MB1444885C302B353C02C2FA2FBE242@KUZP153MB1444.APCP153.PROD.OUTLOOK.COM>
Am 13.04.26 um 10:22 schrieb Saurabh Singh Sengar:
[...]
>>
>>> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
>> This fix is independent from the rest of the series. Do you want to merge it or
>> can I take it into DRM trees?
> Please feel free to take it via DRM tree.
Done now. Thanks a lot.
> CC : Wei Liu
>
> - Saurabh
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [patch 33/38] powerpc: Select ARCH_HAS_RANDOM_ENTROPY
From: Christophe Leroy (CS GROUP) @ 2026-04-15 6:47 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Michael Ellerman, linuxppc-dev, Arnd Bergmann, x86, Lu Baolu,
iommu, Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.789114053@kernel.org>
Le 10/04/2026 à 14:21, Thomas Gleixner a écrit :
> The only remaining usage of get_cycles() is to provide random_get_entropy().
>
> Switch powerpc over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
> and providing random_get_entropy() in asm/random.h.
>
> Remove asm/timex.h as it has no functionality anymore.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/random.h | 13 +++++++++++++
> arch/powerpc/include/asm/timex.h | 21 ---------------------
> 3 files changed, 14 insertions(+), 21 deletions(-)
>
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -150,6 +150,7 @@ config PPC
> select ARCH_HAS_PREEMPT_LAZY
> select ARCH_HAS_PTDUMP
> select ARCH_HAS_PTE_SPECIAL
> + select ARCH_HAS_RANDOM_ENTROPY
> select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE && PPC_BOOK3S_64
> select ARCH_HAS_SET_MEMORY
> select ARCH_HAS_STRICT_KERNEL_RWX if (PPC_BOOK3S || PPC_8xx) && !HIBERNATION
> --- /dev/null
> +++ b/arch/powerpc/include/asm/random.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_POWERPC_RANDOM_H
> +#define _ASM_POWERPC_RANDOM_H
> +
> +#include <asm/cputable.h>
> +#include <asm/vdso/timebase.h>
> +
> +static inline unsigned long random_get_entropy(void)
> +{
> + return mftb();
> +}
> +
> +#endif /* _ASM_POWERPC_RANDOM_H */
> --- a/arch/powerpc/include/asm/timex.h
> +++ b/arch/powerpc/include/asm/timex.h
> @@ -1,21 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_POWERPC_TIMEX_H
> -#define _ASM_POWERPC_TIMEX_H
> -
> -#ifdef __KERNEL__
> -
> -/*
> - * PowerPC architecture timex specifications
> - */
> -
> -#include <asm/cputable.h>
> -#include <asm/vdso/timebase.h>
> -
> -ostatic inline cycles_t get_cycles(void)
> -{
> - return mftb();
> -}
> -#define get_cycles get_cycles
> -
> -#endif /* __KERNEL__ */
> -#endif /* _ASM_POWERPC_TIMEX_H */
>
>
^ permalink raw reply
* Re: [patch 07/38] treewide: Consolidate cycles_t
From: Christophe Leroy (CS GROUP) @ 2026-04-15 6:43 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120318.045532623@kernel.org>
Le 10/04/2026 à 14:19, Thomas Gleixner a écrit :
> Most architectures define cycles_t as unsigned long execpt:
>
> - x86 requires it to be 64-bit independent of the 32-bit/64-bit build.
>
> - parisc and mips define it as unsigned int
>
> parisc has no real reason to do so as there are only a few usage sites
> which either expand it to a 64-bit value or utilize only the lower
> 32bits.
>
> mips has no real requirement either.
>
> Move the typedef to types.h and provide a config switch to enforce the
> 64-bit type for x86.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> ---
> arch/Kconfig | 4 ++++
> arch/alpha/include/asm/timex.h | 3 ---
> arch/arm/include/asm/timex.h | 1 -
> arch/loongarch/include/asm/timex.h | 2 --
> arch/m68k/include/asm/timex.h | 2 --
> arch/mips/include/asm/timex.h | 2 --
> arch/nios2/include/asm/timex.h | 2 --
> arch/parisc/include/asm/timex.h | 2 --
> arch/powerpc/include/asm/timex.h | 4 +---
> arch/riscv/include/asm/timex.h | 2 --
> arch/s390/include/asm/timex.h | 2 --
> arch/sparc/include/asm/timex_64.h | 1 -
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/tsc.h | 2 --
> include/asm-generic/timex.h | 1 -
> include/linux/types.h | 6 ++++++
> 16 files changed, 12 insertions(+), 25 deletions(-)
>
> --- a/arch/powerpc/include/asm/timex.h
> +++ b/arch/powerpc/include/asm/timex.h
> @@ -11,9 +11,7 @@
> #include <asm/cputable.h>
> #include <asm/vdso/timebase.h>
>
> -typedef unsigned long cycles_t;
> -
> -static inline cycles_t get_cycles(void)
> +ostatic inline cycles_t get_cycles(void)
What is 'ostatic' ?
> {
> return mftb();
> }
^ permalink raw reply
* Re: [patch 05/38] treewide: Remove CLOCK_TICK_RATE
From: Christophe Leroy (CS GROUP) @ 2026-04-15 6:40 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120317.910770161@kernel.org>
Le 10/04/2026 à 14:18, Thomas Gleixner a écrit :
> This has been scheduled for removal more than a decade ago and the comments
> related to it have been dutifully ignored. The last dependencies are gone.
>
> Remove it along with various now empty asm/timex.h files.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
For powerpc:
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> arch/alpha/include/asm/timex.h | 4 ----
> arch/arc/include/asm/timex.h | 15 ---------------
> arch/arm/mach-omap1/Kconfig | 2 +-
> arch/hexagon/include/asm/timex.h | 3 ---
> arch/m68k/include/asm/timex.h | 15 ---------------
> arch/microblaze/include/asm/timex.h | 13 -------------
> arch/mips/include/asm/timex.h | 8 --------
> arch/openrisc/include/asm/timex.h | 3 ---
> arch/parisc/include/asm/timex.h | 2 --
> arch/powerpc/include/asm/timex.h | 2 --
> arch/s390/include/asm/timex.h | 2 --
> arch/sh/include/asm/timex.h | 24 ------------------------
> arch/sparc/include/asm/timex.h | 2 +-
> arch/sparc/include/asm/timex_32.h | 14 --------------
> arch/sparc/include/asm/timex_64.h | 2 --
> arch/um/include/asm/timex.h | 9 ---------
> arch/x86/include/asm/timex.h | 3 ---
> 17 files changed, 2 insertions(+), 121 deletions(-)
>
> --- a/arch/alpha/include/asm/timex.h
> +++ b/arch/alpha/include/asm/timex.h
> @@ -7,10 +7,6 @@
> #ifndef _ASMALPHA_TIMEX_H
> #define _ASMALPHA_TIMEX_H
>
> -/* With only one or two oddballs, we use the RTC as the ticker, selecting
> - the 32.768kHz reference clock, which nicely divides down to our HZ. */
> -#define CLOCK_TICK_RATE 32768
> -
> /*
> * Standard way to access the cycle counter.
> * Currently only used on SMP for scheduling.
> --- a/arch/arc/include/asm/timex.h
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.synopsys.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cac13d5b928bc4eabd9b708de96fb5935%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639114203455047148%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uCL895qVLUoy3Stzhmgph2DiYmjpd4RPdQIW2dZcJ7w%3D&reserved=0)
> - */
> -
> -#ifndef _ASM_ARC_TIMEX_H
> -#define _ASM_ARC_TIMEX_H
> -
> -#define CLOCK_TICK_RATE 80000000 /* slated to be removed */
> -
> -#include <asm-generic/timex.h>
> -
> -/* XXX: get_cycles() to be implemented with RTSC insn */
> -
> -#endif /* _ASM_ARC_TIMEX_H */
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -74,7 +74,7 @@ config OMAP_32K_TIMER
> currently only available for OMAP16XX, 24XX, 34XX, OMAP4/5 and DRA7XX.
>
> On OMAP2PLUS this value is only used for CONFIG_HZ and
> - CLOCK_TICK_RATE compile time calculation.
> + timer frequency compile time calculation.
> The actual timer selection is done in the board file
> through the (DT_)MACHINE_START structure.
>
> --- a/arch/hexagon/include/asm/timex.h
> +++ b/arch/hexagon/include/asm/timex.h
> @@ -9,9 +9,6 @@
> #include <asm-generic/timex.h>
> #include <asm/hexagon_vm.h>
>
> -/* Using TCX0 as our clock. CLOCK_TICK_RATE scheduled to be removed. */
> -#define CLOCK_TICK_RATE 19200
> -
> #define ARCH_HAS_READ_CURRENT_TIMER
>
> static inline int read_current_timer(unsigned long *timer_val)
> --- a/arch/m68k/include/asm/timex.h
> +++ b/arch/m68k/include/asm/timex.h
> @@ -7,21 +7,6 @@
> #ifndef _ASMm68K_TIMEX_H
> #define _ASMm68K_TIMEX_H
>
> -#ifdef CONFIG_COLDFIRE
> -/*
> - * CLOCK_TICK_RATE should give the underlying frequency of the tick timer
> - * to make ntp work best. For Coldfires, that's the main clock.
> - */
> -#include <asm/coldfire.h>
> -#define CLOCK_TICK_RATE MCF_CLK
> -#else
> -/*
> - * This default CLOCK_TICK_RATE is probably wrong for many 68k boards
> - * Users of those boards will need to check and modify accordingly
> - */
> -#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> -#endif
> -
> typedef unsigned long cycles_t;
>
> static inline cycles_t get_cycles(void)
> --- a/arch/microblaze/include/asm/timex.h
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -/*
> - * Copyright (C) 2006 Atmark Techno, Inc.
> - */
> -
> -#ifndef _ASM_MICROBLAZE_TIMEX_H
> -#define _ASM_MICROBLAZE_TIMEX_H
> -
> -#include <asm-generic/timex.h>
> -
> -#define CLOCK_TICK_RATE 1000 /* Timer input freq. */
> -
> -#endif /* _ASM_TIMEX_H */
> --- a/arch/mips/include/asm/timex.h
> +++ b/arch/mips/include/asm/timex.h
> @@ -19,14 +19,6 @@
> #include <asm/cpu-type.h>
>
> /*
> - * This is the clock rate of the i8253 PIT. A MIPS system may not have
> - * a PIT by the symbol is used all over the kernel including some APIs.
> - * So keeping it defined to the number for the PIT is the only sane thing
> - * for now.
> - */
> -#define CLOCK_TICK_RATE 1193182
> -
> -/*
> * Standard way to access the cycle counter.
> * Currently only used on SMP for scheduling.
> *
> --- a/arch/openrisc/include/asm/timex.h
> +++ b/arch/openrisc/include/asm/timex.h
> @@ -25,9 +25,6 @@ static inline cycles_t get_cycles(void)
> }
> #define get_cycles get_cycles
>
> -/* This isn't really used any more */
> -#define CLOCK_TICK_RATE 1000
> -
> #define ARCH_HAS_READ_CURRENT_TIMER
>
> #endif
> --- a/arch/parisc/include/asm/timex.h
> +++ b/arch/parisc/include/asm/timex.h
> @@ -9,8 +9,6 @@
>
> #include <asm/special_insns.h>
>
> -#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> -
> typedef unsigned long cycles_t;
>
> static inline cycles_t get_cycles(void)
> --- a/arch/powerpc/include/asm/timex.h
> +++ b/arch/powerpc/include/asm/timex.h
> @@ -11,8 +11,6 @@
> #include <asm/cputable.h>
> #include <asm/vdso/timebase.h>
>
> -#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */
> -
> typedef unsigned long cycles_t;
>
> static inline cycles_t get_cycles(void)
> --- a/arch/s390/include/asm/timex.h
> +++ b/arch/s390/include/asm/timex.h
> @@ -177,8 +177,6 @@ static inline void local_tick_enable(uns
> set_clock_comparator(get_lowcore()->clock_comparator);
> }
>
> -#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> -
> typedef unsigned long cycles_t;
>
> static __always_inline unsigned long get_tod_clock(void)
> --- a/arch/sh/include/asm/timex.h
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -/*
> - * linux/include/asm-sh/timex.h
> - *
> - * sh architecture timex specifications
> - */
> -#ifndef __ASM_SH_TIMEX_H
> -#define __ASM_SH_TIMEX_H
> -
> -/*
> - * Only parts using the legacy CPG code for their clock framework
> - * implementation need to define their own Pclk value. If provided, this
> - * can be used for accurately setting CLOCK_TICK_RATE, otherwise we
> - * simply fall back on the i8253 PIT value.
> - */
> -#ifdef CONFIG_SH_PCLK_FREQ
> -#define CLOCK_TICK_RATE (CONFIG_SH_PCLK_FREQ / 4) /* Underlying HZ */
> -#else
> -#define CLOCK_TICK_RATE 1193180
> -#endif
> -
> -#include <asm-generic/timex.h>
> -
> -#endif /* __ASM_SH_TIMEX_H */
> --- a/arch/sparc/include/asm/timex.h
> +++ b/arch/sparc/include/asm/timex.h
> @@ -4,6 +4,6 @@
> #if defined(__sparc__) && defined(__arch64__)
> #include <asm/timex_64.h>
> #else
> -#include <asm/timex_32.h>
> +#include <asm-generic/timex.h>
> #endif
> #endif
> --- a/arch/sparc/include/asm/timex_32.h
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -/*
> - * linux/include/asm/timex.h
> - *
> - * sparc architecture timex specifications
> - */
> -#ifndef _ASMsparc_TIMEX_H
> -#define _ASMsparc_TIMEX_H
> -
> -#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> -
> -#include <asm-generic/timex.h>
> -
> -#endif
> --- a/arch/sparc/include/asm/timex_64.h
> +++ b/arch/sparc/include/asm/timex_64.h
> @@ -9,8 +9,6 @@
>
> #include <asm/timer.h>
>
> -#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> -
> /* Getting on the cycle counter on sparc64. */
> typedef unsigned long cycles_t;
> #define get_cycles() tick_ops->get_tick()
> --- a/arch/um/include/asm/timex.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef __UM_TIMEX_H
> -#define __UM_TIMEX_H
> -
> -#define CLOCK_TICK_RATE (HZ)
> -
> -#include <asm-generic/timex.h>
> -
> -#endif
> --- a/arch/x86/include/asm/timex.h
> +++ b/arch/x86/include/asm/timex.h
> @@ -14,9 +14,6 @@ static inline unsigned long random_get_e
> }
> #define random_get_entropy random_get_entropy
>
> -/* Assume we use the PIT time source for the clock tick */
> -#define CLOCK_TICK_RATE PIT_TICK_RATE
> -
> #define ARCH_HAS_READ_CURRENT_TIMER
>
> #endif /* _ASM_X86_TIMEX_H */
>
>
^ permalink raw reply
* Re: [patch 32/38] powerpc/spufs: Use mftb() directly
From: Christophe Leroy (CS GROUP) @ 2026-04-15 6:38 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Michael Ellerman, linuxppc-dev, Arnd Bergmann, x86, Lu Baolu,
iommu, Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.723429844@kernel.org>
Le 10/04/2026 à 14:21, Thomas Gleixner a écrit :
> There is no reason to indirect via get_cycles(), which is about to be
> removed.
>
> Use mftb() directly.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> arch/powerpc/platforms/cell/spufs/switch.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> --- a/arch/powerpc/platforms/cell/spufs/switch.c
> +++ b/arch/powerpc/platforms/cell/spufs/switch.c
> @@ -34,6 +34,7 @@
> #include <asm/spu_priv1.h>
> #include <asm/spu_csa.h>
> #include <asm/mmu_context.h>
> +#include <asm/time.h>
>
> #include "spufs.h"
>
> @@ -279,7 +280,7 @@ static inline void save_timebase(struct
> * Read PPE Timebase High and Timebase low registers
> * and save in CSA. TBD.
> */
> - csa->suspend_time = get_cycles();
> + csa->suspend_time = mftb();
> }
>
> static inline void remove_other_spu_access(struct spu_state *csa,
> @@ -1261,7 +1262,7 @@ static inline void setup_decr(struct spu
> * in LSCSA.
> */
> if (csa->priv2.mfc_control_RW & MFC_CNTL_DECREMENTER_RUNNING) {
> - cycles_t resume_time = get_cycles();
> + cycles_t resume_time = mftb();
> cycles_t delta_time = resume_time - csa->suspend_time;
>
> csa->lscsa->decr_status.slot[0] = SPU_DECR_STATUS_RUNNING;
>
>
^ permalink raw reply
* [PATCH] staging: sm750fb: rename CamelCase variables to snake_case
From: Robert DeRienzo @ 2026-04-15 3:08 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang
Cc: gregkh, linux-fbdev, linux-staging, linux-kernel, Robert DeRienzo
- pvMem -> p_mem
- pvReg -> p_reg
- powerMode -> power_mode
- setAllEngOff -> set_all_eng_off
- resetMemory -> reset_memory
- sm750_doubleTFT -> sm750_double_tft
- sm750_dualTFT -> sm750_dual_tft
Compile-tested only.
Signed-off-by: Robert DeRienzo <rlderienzo@gmail.com>
---
This is my first contrib, tried something approachable. Feedback
obviously welcome.
drivers/staging/sm750fb/sm750.c | 32 +++++++++++++++---------------
drivers/staging/sm750fb/sm750.h | 14 ++++++-------
drivers/staging/sm750fb/sm750_hw.c | 24 +++++++++++-----------
3 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 62f6e0cdf..399a48df8 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -624,27 +624,27 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_pnc;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
pr_info("use simul primary mode\n");
break;
case sm750_simul_sec:
output->paths = sm750_pnc;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
break;
case sm750_dual_normal:
if (par->index == 0) {
output->paths = sm750_panel;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_secondary;
/* not consider of padding stuffs for o_screen,need fix */
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->pv_mem + crtc->o_screen;
}
break;
case sm750_dual_swap:
@@ -652,7 +652,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_panel;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_primary;
@@ -660,7 +660,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
* need fix
*/
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->pv_mem + crtc->o_screen;
}
break;
default:
@@ -764,14 +764,14 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
* must be set after crtc member initialized
*/
crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
- crtc->cursor.mmio = sm750_dev->pvReg +
+ crtc->cursor.mmio = sm750_dev->pv_reg +
0x800f0 + (int)crtc->channel * 0x140;
pr_info("crtc->cursor.mmio = %p\n", crtc->cursor.mmio);
crtc->cursor.max_h = 64;
crtc->cursor.max_w = 64;
crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
- crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
+ crtc->cursor.vstart = sm750_dev->pv_mem + crtc->cursor.offset;
memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if (!g_hwcursor)
@@ -921,9 +921,9 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
sm750_dev->init_parm.chip_clk = 0;
sm750_dev->init_parm.mem_clk = 0;
sm750_dev->init_parm.master_clk = 0;
- sm750_dev->init_parm.powerMode = 0;
- sm750_dev->init_parm.setAllEngOff = 0;
- sm750_dev->init_parm.resetMemory = 1;
+ sm750_dev->init_parm.power_mode = 0;
+ sm750_dev->init_parm.set_all_eng_off = 0;
+ sm750_dev->init_parm.reset_memory = 1;
/* defaultly turn g_hwcursor on for both view */
g_hwcursor = 3;
@@ -942,9 +942,9 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
} else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
sm750_dev->nocrt = 1;
} else if (!strncmp(opt, "36bit", strlen("36bit"))) {
- sm750_dev->pnltype = sm750_doubleTFT;
+ sm750_dev->pnltype = sm750_double_tft;
} else if (!strncmp(opt, "18bit", strlen("18bit"))) {
- sm750_dev->pnltype = sm750_dualTFT;
+ sm750_dev->pnltype = sm750_dual_tft;
} else if (!strncmp(opt, "24bit", strlen("24bit"))) {
sm750_dev->pnltype = sm750_24TFT;
} else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
@@ -1090,7 +1090,7 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
sm750_dev->mtrr.vram = arch_phys_wc_add(sm750_dev->vidmem_start,
sm750_dev->vidmem_size);
- memset_io(sm750_dev->pvMem, 0, sm750_dev->vidmem_size);
+ memset_io(sm750_dev->pv_mem, 0, sm750_dev->vidmem_size);
pci_set_drvdata(pdev, sm750_dev);
@@ -1121,8 +1121,8 @@ static void lynxfb_pci_remove(struct pci_dev *pdev)
sm750fb_framebuffer_release(sm750_dev);
arch_phys_wc_del(sm750_dev->mtrr.vram);
- iounmap(sm750_dev->pvReg);
- iounmap(sm750_dev->pvMem);
+ iounmap(sm750_dev->pv_reg);
+ iounmap(sm750_dev->pv_mem);
pci_release_region(pdev, 1);
kfree(g_settings);
}
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 67b9bfa23..19dbb9120 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -14,8 +14,8 @@
enum sm750_pnltype {
sm750_24TFT = 0, /* 24bit tft */
- sm750_dualTFT = 2, /* dual 18 bit tft */
- sm750_doubleTFT = 1, /* 36 bit double pixel tft */
+ sm750_dual_tft = 2, /* dual 18 bit tft */
+ sm750_double_tft = 1, /* 36 bit double pixel tft */
};
/* vga channel is not concerned */
@@ -39,13 +39,13 @@ enum sm750_path {
};
struct init_status {
- ushort powerMode;
+ ushort power_mode;
/* below three clocks are in unit of MHZ*/
ushort chip_clk;
ushort mem_clk;
ushort master_clk;
- ushort setAllEngOff;
- ushort resetMemory;
+ ushort set_all_eng_off;
+ ushort reset_memory;
};
struct lynx_accel {
@@ -97,8 +97,8 @@ struct sm750_dev {
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
- void __iomem *pvReg;
- unsigned char __iomem *pvMem;
+ void __iomem *pv_reg;
+ unsigned char __iomem *pv_mem;
/* locks*/
spinlock_t slock;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index f60b152a6..756b9beb2 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -44,19 +44,19 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
/* now map mmio and vidmem */
- sm750_dev->pvReg =
+ sm750_dev->pv_reg =
ioremap(sm750_dev->vidreg_start, sm750_dev->vidreg_size);
- if (!sm750_dev->pvReg) {
+ if (!sm750_dev->pv_reg) {
pr_err("mmio failed\n");
ret = -EFAULT;
goto err_release_region;
}
- pr_info("mmio virtual addr = %p\n", sm750_dev->pvReg);
+ pr_info("mmio virtual addr = %p\n", sm750_dev->pv_reg);
- sm750_dev->accel.dpr_base = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dp_port_base = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->pv_reg + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->pv_reg + DE_PORT_ADDR_TYPE1;
- mmio750 = sm750_dev->pvReg;
+ mmio750 = sm750_dev->pv_reg;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
sm750_dev->vidmem_start = pci_resource_start(pdev, 0);
@@ -71,19 +71,19 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
sm750_dev->vidmem_start, sm750_dev->vidmem_size);
/* reserve the vidmem space of smi adaptor */
- sm750_dev->pvMem =
+ sm750_dev->pv_mem =
ioremap_wc(sm750_dev->vidmem_start, sm750_dev->vidmem_size);
- if (!sm750_dev->pvMem) {
+ if (!sm750_dev->pv_mem) {
pr_err("Map video memory failed\n");
ret = -EFAULT;
goto err_unmap_reg;
}
- pr_info("video memory vaddr = %p\n", sm750_dev->pvMem);
+ pr_info("video memory vaddr = %p\n", sm750_dev->pv_mem);
return 0;
err_unmap_reg:
- iounmap(sm750_dev->pvReg);
+ iounmap(sm750_dev->pv_reg);
err_release_region:
pci_release_region(pdev, 1);
return ret;
@@ -136,10 +136,10 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
switch (sm750_dev->pnltype) {
case sm750_24TFT:
break;
- case sm750_doubleTFT:
+ case sm750_double_tft:
val |= PANEL_DISPLAY_CTRL_DOUBLE_PIXEL;
break;
- case sm750_dualTFT:
+ case sm750_dual_tft:
val |= PANEL_DISPLAY_CTRL_DUAL_DISPLAY;
break;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v8 1/4] dt-bindings: backlight: Add max25014 support
From: Daniel Thompson @ 2026-04-14 16:25 UTC (permalink / raw)
To: maudspierings
Cc: Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li, dri-devel, linux-leds,
devicetree, linux-kernel, linux-fbdev, imx, linux-arm-kernel
In-Reply-To: <20260407-max25014-v8-1-14eac7ed673a@gocontroll.com>
On Tue, Apr 07, 2026 at 04:41:42PM +0200, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings <maudspierings@gocontroll.com>
>
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with integrated boost controller.
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH] backlight: ktd2801: enable BL_CORE_SUSPENDRESUME
From: Daniel Thompson @ 2026-04-14 16:24 UTC (permalink / raw)
To: Duje Mihanović
Cc: Lee Jones, Jingoo Han, Helge Deller, Karel Balej, dri-devel,
linux-fbdev, phone-devel, ~postmarketos/upstreaming, linux-kernel,
Duje Mihanović, stable
In-Reply-To: <20260328-ktd2801-pm-fix-v1-1-007cb103faeb@dujemihanovic.xyz>
On Sat, Mar 28, 2026 at 09:42:16PM +0100, Duje Mihanović wrote:
> From: Duje Mihanović <duje@dujemihanovic.xyz>
>
> Boards using this backlight chip do not power the backlight off on
> suspend. Enable BL_CORE_SUSPENDRESUME so the chip gets powered off by
> the backlight core on suspend.
>
> Tested on samsung,coreprimevelte.
>
> Cc: stable@vger.kernel.org # v6.19
> Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add cgbc backlight driver
From: Daniel Thompson @ 2026-04-14 16:22 UTC (permalink / raw)
To: Thomas Richard
Cc: Lee Jones, Jingoo Han, Helge Deller, Thomas Petazzoni, dri-devel,
linux-fbdev, linux-kernel
In-Reply-To: <20260327-backlight-cgbc-remove-x86-dependency-v1-2-4851c9e95371@bootlin.com>
On Fri, Mar 27, 2026 at 08:39:33PM +0100, Thomas Richard wrote:
> Add missing backlight driver in CONGATEC BOARD CONTROLLER entry.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH 1/2] backlight: cgbc: Remove redundant X86 dependency
From: Daniel Thompson @ 2026-04-14 16:21 UTC (permalink / raw)
To: Thomas Richard
Cc: Lee Jones, Jingoo Han, Helge Deller, Thomas Petazzoni, dri-devel,
linux-fbdev, linux-kernel
In-Reply-To: <20260327-backlight-cgbc-remove-x86-dependency-v1-1-4851c9e95371@bootlin.com>
On Fri, Mar 27, 2026 at 08:39:32PM +0100, Thomas Richard wrote:
> The backlight driver depends on the MFD cgbc-core driver, which already
> depends on X86. The explicit X86 dependency for the backlight driver is
> redundant and can be safely removed.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* [GIT PULL] fbdev fixes and updates for v7.1-rc1
From: Helge Deller @ 2026-04-14 16:09 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel; +Cc: Thomas Zimmermann
Hi Linus,
please pull fixes and updates for fbdev for kernel 7.1-rc1.
A major refactorization regarding console font handling and the usual
smaller fixes and cleanups.
Thanks!
Helge
----------------------------------------------------------------
The following changes since commit 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681:
Linux 7.0-rc3 (2026-03-08 16:56:54 -0700)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-7.1-rc1
for you to fetch changes up to a31e4518bec70333a0a98f2946a12b53b45fe5b9:
fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO (2026-04-10 16:54:38 +0200)
----------------------------------------------------------------
fbdev fixes & cleanups for 7.1-rc1:
A major refactorization by Thomas Zimmermann from SUSE regarding handling of
console font data, addition of helpers for console font rotation and split into
individual components for glyphs, fonts and the overall fbcon state.
And there is the round of usual code cleanups and fixes:
Cleanups:
- atyfb: Remove unused fb_list [Geert Uytterhoeven]
- goldfishfb, wmt_ge_rops: use devm_platform_ioremap_resource() [Amin GATTOUT]
- matroxfb: Mark variable with __maybe_unused [Andy Shevchenko]
- omapfb: Add missing error check for clk_get() [Chen Ni]
- tdfxfb: Make the VGA register initialisation a bit more obvious [Daniel Palmer]
- macfb: Replace deprecated strcpy with strscpy [Thorsten Blum]
Fixes:
- tdfxfb, udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO [Greg Kroah-Hartman]
- omap2: fix inconsistent lock returns in omapfb_mmap [Hongling Zeng]
- viafb: check ioremap return value in viafb_lcd_get_mobile_state [Wang Jun]
----------------------------------------------------------------
Amin GATTOUT (2):
fbdev: goldfishfb: use devm_platform_ioremap_resource()
fbdev: wmt_ge_rops: use devm_platform_ioremap_resource()
Andy Shevchenko (1):
fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build break
Chen Ni (1):
fbdev: omapfb: Add missing error check for clk_get()
Daniel Palmer (1):
fbdev: tdfxfb: Make the VGA register initialisation a bit more obvious
Geert Uytterhoeven (1):
fbdev: atyfb: Remove unused fb_list
Greg Kroah-Hartman (2):
fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO
fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO
Hongling Zeng (1):
fbdev: omap2: fix inconsistent lock returns in omapfb_mmap
Thomas Zimmermann (28):
fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info
fbdev: defio: Keep module reference from VMAs
fbdev: defio: Move variable state into struct fb_deferred_io_state
fbdev: defio: Move pageref array to struct fb_deferred_io_state
fbdev: Declare src parameter of fb_pad_ helpers as constant
vt: Remove trailing whitespaces
vt: Store font in struct vc_font
vt: Calculate font-buffer size with vc_font_size()
lib/fonts: Remove trailing whitespaces
lib/fonts: Remove FNTCHARCNT()
lib/fonts: Store font data as font_data_t; update consoles
lib/fonts: Read font size with font_data_size()
lib/fonts: Manage font-data lifetime with font_data_get/_put()
lib/fonts: Compare font data for equality with font_data_is_equal()
lib/fonts: Create font_data_t from struct console_font with font_data_import()
lib/fonts: Store font data for user space with font_data_export()
lib/fonts: Remove internal symbols and macros from public header file
fbcon: Avoid OOB font access if console rotation fails
vt: Implement helpers for struct vc_font in source file
lib/fonts: Provide helpers for calculating glyph pitch and size
lib/fonts: Clean up Makefile
lib/fonts: Implement glyph rotation
lib/fonts: Refactor glyph-pattern helpers
lib/fonts: Refactor glyph-rotation helpers
lib/fonts: Implement font rotation
fbcon: Fill cursor mask in helper function
fbcon: Put font-rotation state into separate struct
MAINTAINERS: Add dedicated entry for fbcon
Thorsten Blum (1):
fbdev: macfb: Replace deprecated strcpy with strscpy
Wang Jun (1):
fbdev: viafb: check ioremap return value in viafb_lcd_get_mobile_state
robgithub (1):
fbdev: update help text for CONFIG_FB_NVIDIA
MAINTAINERS | 23 +++
drivers/tty/vt/vt.c | 34 +++
drivers/video/console/newport_con.c | 61 ++----
drivers/video/fbdev/Kconfig | 10 +-
drivers/video/fbdev/aty/atyfb_base.c | 4 -
drivers/video/fbdev/core/bitblit.c | 46 +----
drivers/video/fbdev/core/fb_defio.c | 266 +++++++++++++++++-------
drivers/video/fbdev/core/fbcon.c | 242 +++++++++-------------
drivers/video/fbdev/core/fbcon.h | 18 +-
drivers/video/fbdev/core/fbcon_ccw.c | 70 ++-----
drivers/video/fbdev/core/fbcon_cw.c | 70 ++-----
drivers/video/fbdev/core/fbcon_rotate.c | 88 +++-----
drivers/video/fbdev/core/fbcon_rotate.h | 71 -------
drivers/video/fbdev/core/fbcon_ud.c | 67 ++----
drivers/video/fbdev/core/fbmem.c | 6 +-
drivers/video/fbdev/goldfishfb.c | 14 +-
drivers/video/fbdev/macfb.c | 38 ++--
drivers/video/fbdev/matrox/g450_pll.c | 2 +-
drivers/video/fbdev/omap/hwa742.c | 4 +
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +-
drivers/video/fbdev/tdfxfb.c | 112 +++++-----
drivers/video/fbdev/udlfb.c | 3 +
drivers/video/fbdev/via/lcd.c | 3 +
drivers/video/fbdev/wmt_ge_rops.c | 18 +-
include/linux/console_struct.h | 33 ++-
include/linux/fb.h | 19 +-
include/linux/font.h | 166 +++++++++++----
lib/fonts/Makefile | 36 ++--
lib/fonts/font.h | 38 ++++
lib/fonts/font_10x18.c | 2 +-
lib/fonts/font_6x10.c | 3 +-
lib/fonts/font_6x11.c | 2 +-
lib/fonts/font_6x8.c | 3 +-
lib/fonts/font_7x14.c | 2 +-
lib/fonts/font_8x16.c | 3 +-
lib/fonts/font_8x8.c | 2 +-
lib/fonts/font_acorn_8x8.c | 4 +-
lib/fonts/font_mini_4x6.c | 10 +-
lib/fonts/font_pearl_8x8.c | 2 +-
lib/fonts/font_rotate.c | 275 +++++++++++++++++++++++++
lib/fonts/font_sun12x22.c | 3 +-
lib/fonts/font_sun8x16.c | 3 +-
lib/fonts/font_ter10x18.c | 4 +-
lib/fonts/font_ter16x32.c | 4 +-
lib/fonts/fonts.c | 232 ++++++++++++++++++++-
45 files changed, 1328 insertions(+), 790 deletions(-)
create mode 100644 lib/fonts/font.h
create mode 100644 lib/fonts/font_rotate.c
^ permalink raw reply
* Re: [patch 31/38] parisc: Select ARCH_HAS_RANDOM_ENTROPY
From: Helge Deller @ 2026-04-14 12:41 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: linux-parisc, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.658485572@kernel.org>
On 4/10/26 14:21, Thomas Gleixner wrote:
> The only remaining non-architecture usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch parisc over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
> and providing random_get_entropy() in asm/random.h.
>
> Add 'asm/timex.h' includes to the relevant files, so the global include can
> be removed once all architectures are converted over.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-parisc@vger.kernel.org
> ---
> arch/parisc/Kconfig | 1 +
> arch/parisc/include/asm/random.h | 12 ++++++++++++
> arch/parisc/include/asm/timex.h | 6 ------
> arch/parisc/kernel/processor.c | 1 +
> arch/parisc/kernel/time.c | 1 +
> 5 files changed, 15 insertions(+), 6 deletions(-)
I tested this series on parisc.
Works as expected.
Tested-by: Helge Deller <deller@gmx.de>
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix coding style issue in fbtft-bus.c
From: kernel test robot @ 2026-04-14 11:43 UTC (permalink / raw)
To: Baker, andy, gregkh
Cc: oe-kbuild-all, dri-devel, linux-fbdev, linux-staging,
linux-kernel, Baker
In-Reply-To: <20260412173317.3329-1-mzndmzn@gmail.com>
Hi Baker,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/Baker/staging-fbtft-fix-coding-style-issue-in-fbtft-bus-c/20260414-101811
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260412173317.3329-1-mzndmzn%40gmail.com
patch subject: [PATCH] staging: fbtft: fix coding style issue in fbtft-bus.c
config: arm-randconfig-r072-20260414 (https://download.01.org/0day-ci/archive/20260414/202604141939.LhzKrfey-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 13.4.0
smatch: v0.5.0-9007-gcf3ea02b
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260414/202604141939.LhzKrfey-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604141939.LhzKrfey-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro "define_fbtft_write_reg" requires 4 arguments, but only 3 given
65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
| ^
drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" defined here
14 | #define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
|
>> drivers/staging/fbtft/fbtft-bus.c:65:23: error: expected ';' before 'void'
65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
| ^
| ;
drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro "define_fbtft_write_reg" requires 4 arguments, but only 3 given
67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
| ^
drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" defined here
14 | #define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
|
drivers/staging/fbtft/fbtft-bus.c:67:23: error: expected ';' before 'void'
67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
| ^
| ;
68 |
69 | void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
| ~~~~
vim +/define_fbtft_write_reg +65 drivers/staging/fbtft/fbtft-bus.c
64
> 65 define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
66 define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
67 define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
68
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: John Hubbard @ 2026-04-13 22:50 UTC (permalink / raw)
To: Joel Fernandes, Danilo Krummrich
Cc: Eliot Courtney, linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Bjorn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Vivi Rodrigo, Tvrtko Ursulin, Rui Huang, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, Alexey Ivanov,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <56526b93-72a3-4b07-9aa7-7822bd561cd5@nvidia.com>
On 4/13/26 3:27 PM, Joel Fernandes wrote:
>
>
> On 4/13/2026 4:10 PM, Joel Fernandes wrote:
>> Hi Danilo,
>>
>> On 4/9/2026 7:00 AM, Danilo Krummrich wrote:
>>> On Thu Apr 9, 2026 at 12:33 PM CEST, Joel Fernandes wrote:
>>>> Since it is 3 against 1 here, I rest my case :-).
>>>
>>> That's not how I'd view it. :)
>>>
>>> Anyways, in case I'm included in "3", that's not my position. My point was to
>>> ensure we keep discussing advantages and disadvantages on their merits, as I
>>> think you both have good points.
>>
>> Heh, yes I actually *did not* include you in the 3 since you sounded to be open
>> to both. ;-)
>>
>>>
>>>> I am still in disagreement since I do not see much benefit (that is why I said
>>>> pointless above).
>>>
>>> That is fair -- in this case please explain why the advantages pointed out by
>>> others are not worth it, propose something that picks up the best of both
>>> worlds, etc.
>>>
>>> You can also turn it around and ask people whether they can tweak their counter
>>> proposal to get rid of specific parts you dislike for a reason.
>>>
>>> IOW, keep the ball rolling, so we can come up with the best possible solution.
>>
>> Good advice, thanks! I will try to come up with something that is acceptable to
>> everyone and we can further debate pros/cons on v11.
>>
>> There are some merits on the alternative proposal from Eliot/Alex that I'd like
>> to explore while seeing if I can keep some of the merits in mine as well.
> I think I found a nice approach. IMO the MMU version dispatch does not belong in
> Vmm/BarUser layers. Those are version-independent code. However I agree that
> doing version dispatch at every low-level page table operation is a bit heavy on
> matches (if we put the MMIO overhead counter-argument aside).
>
> So how about the following approach?
>
> PtWalk, PtMap and everything below it are monomorphized. Vmm and BarUser are
> not. Version dispatch is handled on PtWalk and PtMap entry points.
Conceptually it sounds pretty good.
>
> I think it makes it cleaner and splits the code up better too and the
> organizations makes sense because the version differences are related to page
> tables, not to generic concepts like Vmm and Bar.
>
> Thoughts? Here is a preview:
> https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=pt-traits-v2&id=ff22ba64f729f9f73258777231763a7b9804123b
>
Probably impractical to review that here, so let's do the review in
a v11 posting, I think.
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Joel Fernandes @ 2026-04-13 22:27 UTC (permalink / raw)
To: Danilo Krummrich
Cc: John Hubbard, Eliot Courtney, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Dave Airlie,
Daniel Almeida, Koen Koning, dri-devel, rust-for-linux,
Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Vivi Rodrigo, Tvrtko Ursulin, Rui Huang, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, Alexey Ivanov,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <acd38f51-3acc-4dbf-9929-50187dccec82@nvidia.com>
On 4/13/2026 4:10 PM, Joel Fernandes wrote:
> Hi Danilo,
>
> On 4/9/2026 7:00 AM, Danilo Krummrich wrote:
>> On Thu Apr 9, 2026 at 12:33 PM CEST, Joel Fernandes wrote:
>>> Since it is 3 against 1 here, I rest my case :-).
>>
>> That's not how I'd view it. :)
>>
>> Anyways, in case I'm included in "3", that's not my position. My point was to
>> ensure we keep discussing advantages and disadvantages on their merits, as I
>> think you both have good points.
>
> Heh, yes I actually *did not* include you in the 3 since you sounded to be open
> to both. ;-)
>
>>
>>> I am still in disagreement since I do not see much benefit (that is why I said
>>> pointless above).
>>
>> That is fair -- in this case please explain why the advantages pointed out by
>> others are not worth it, propose something that picks up the best of both
>> worlds, etc.
>>
>> You can also turn it around and ask people whether they can tweak their counter
>> proposal to get rid of specific parts you dislike for a reason.
>>
>> IOW, keep the ball rolling, so we can come up with the best possible solution.
>
> Good advice, thanks! I will try to come up with something that is acceptable to
> everyone and we can further debate pros/cons on v11.
>
> There are some merits on the alternative proposal from Eliot/Alex that I'd like
> to explore while seeing if I can keep some of the merits in mine as well.
I think I found a nice approach. IMO the MMU version dispatch does not belong in
Vmm/BarUser layers. Those are version-independent code. However I agree that
doing version dispatch at every low-level page table operation is a bit heavy on
matches (if we put the MMIO overhead counter-argument aside).
So how about the following approach?
PtWalk, PtMap and everything below it are monomorphized. Vmm and BarUser are
not. Version dispatch is handled on PtWalk and PtMap entry points.
I think it makes it cleaner and splits the code up better too and the
organizations makes sense because the version differences are related to page
tables, not to generic concepts like Vmm and Bar.
Thoughts? Here is a preview:
https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=pt-traits-v2&id=ff22ba64f729f9f73258777231763a7b9804123b
thanks,
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Joel Fernandes @ 2026-04-13 20:25 UTC (permalink / raw)
To: Gary Guo, Alexandre Courbot, Eliot Courtney, Danilo Krummrich
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi, joel,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DHOKN9XVOTIB.1A4JY7CDJFWPS@garyguo.net>
On 4/9/2026 7:02 AM, Gary Guo wrote:
> On Wed Apr 8, 2026 at 9:19 PM BST, Joel Fernandes wrote:
>> Hi Alex, Eliot, Danilo,
>>
>> Thanks for taking a look. Let me respond to the specific points below.
>>
>> On Wed, 08 Apr 2026, Alexandre Courbot wrote:
>>> After a quick look I'd say that having a trait here would actually be
>>> *good* for correctness and maintainability.
>>>
>>> The current design implies that every operation on a page table (most
>>> likely using the walker) goes through a branching point. Just looking at
>>> `PtWalk::read_pte_at_level`, there are already at least 6
>>> `if version == 2 { } else { }` branches that all resolve to the same
>>> result. Include walking down the PDEs and you have at least a dozen of
>>> these just to resolve a virtual address. I know CPUs are fast, but this
>>> is still wasted cycles for no good reason.
>>
>> I did some measurements and there is no notieceable difference in both
>> approaches. I ran perf and loaded nova with self-tests running. The extra
>> potential branching is lost in the noise. In both cases, loading nova and
>> running the self-tests has ~119.7M branch instructions on my Ampere. The total
>> instruction count is also identical (~615M).
>>
>> I measured like this:
>> perf stat -e
>> branches,branch-misses,cache-references,cache-misses,instructions,cycles --
>> modprobe nova_core
>>
>> So I think the branching argument is not a strong one. I also did more
>> measurements and the dominant time taken is MMIO. During the map prep and
>> execute, page table walks are done. A TLB flush alone costs ~1.4 microseconds.
>> And PRAMIN BAR0 writes to write the PTE is also about 1 microsecond. Considering
>> this, I don't think the extra branching argument holds (even without branch
>> prediction and speculation).
>>
>> Also some branches cannot be eliminated even with parameterization:
>>
>> if level == self.mmu_version.dual_pde_level() {
>> // 128-bit dual PDE read
>> } else {
>> // Regular 64-bit PDE read
>> }
>>
>> This isn't really a version branch -- it's a structural branch that
>> distinguishes between 64-bit PDE and 128-bit dual PDE entries. Any MMU
>> version with a dual PDE level would need this same distinction.
>>
>> I also did code-generation size analysis (see diff of code used below):
>>
>> Code generation analysis:
>>
>> Module .ko size: Before: 511,792 bytes After: 524,464 bytes (+2.5%)
>> .text section: Before: 112,620 bytes After: 116,628 bytes (+4,008 bytes)
>>
>> The +4K .text growth is the monomorphization cost: every generic function
>> is compiled twice (once for MmuV2, once for MmuV3).
>>
>>> If you use a trait here, and make `PtWalk` generic against it, you can
>>> optimize this away. We had a similar situation when we introduced Turing
>>> support and the v2 ucode header, and tried both approaches: the
>>> trait-based one was slightly shorter, and arguably more readable.
>>
>> Actually I was the one who suggested traits for Falcon ucode descriptor if you
>> see this thread [1]. So basically you and Eliot are telling me to do what I
>> suggested in [1]. :-) However, I disagree that it is the right choice for this code.
>>
>> [1] https://lore.kernel.org/all/20251117231028.GA1095236@joelbox2/
>>
>> I think the two cases are quite different in complexity:
>>
>> The falcon ucode descriptor is essentially a set of flat field accessors
>> and a few params (imem_sec_load_params, dmem_load_params).
>> The trait has ~10 simple getter methods. There's no multi-level hierarchy,
>> no walker, and no generic propagation.
>>
>> The MMU page table case is structurally different. Making PtWalk generic
>> over an Mmu trait would require:
>>
>> - PtWalk<M: Mmu> (the walker)
>> - Plus all the associated types: M::Pte, M::Pde, M::DualPde each
>> needing their own trait bounds
>>
>> And we would also need:
>> - Vmm<M: Mmu> (which creates PtWalk)
>> - BarUser<M: Mmu> (which creates Vmm)
>>
>> I am also against making Vmm an enum as Eliot suggested:
>> enum Vmm {
>> V2(VmmInner<MmuV2>),
>> V3(VmmInner<MmuV3>),
>> }
>>
>> That moves the version complexity up to the reader. Code complexity IMO should
>> decrease as we go up abstractions, making it easier for users (Vmm/Bar).
>>
>> If you look at the the changes in vmm.rs to handle version dispatch there [2]:
>> Added: +109
>> Removed: -28
>>
>> [2]
>> https://github.com/Edgeworth/linux/commit/3627af550b61256184d589e7ec666c1108971f0e
>>
>> The main benefit of my approach is version-specific dispatch complexity is
>> completely isolated inside MmuVersion thus making the code outside of
>> pagetable.rs much more readable, without having to parametrize anything, and
>> without code size increase. I think that is worth considering.
>>
>>> But the main argument to use a trait here IMO is that it enables
>>> associated types and constants. That's particularly critical since some
>>> equivalent fields have different lengths between v2 and v3. An
>>> associated `Bounded` type for these would force the caller to validate
>>> the length of these fields before calling a non-fallible operation,
>>> which is exactly the level of caution that we want when dealing with
>>> page tables.
>>
>> I think Bounded validation is orthogonal to the dispatch model.
>> We can add Bounded to the current design without restructuring
>> into traits. For example:
>>
>> // In ver2::Pte
>> pub fn new_vram(pfn: Bounded<Pfn, 25>, writable: bool) -> Self { ... }
>>
>> // In ver3::Pte
>> pub fn new_vram(pfn: Bounded<Pfn, 40>, writable: bool) -> Self { ... }
>>
>> The unified Pte enum wrapper already dispatches to the correct
>> version-specific constructor, which would enforce the correct Bounded
>> constraint for that version.
>>
>>> In order to fully benefit from it, we will need the bitfield macro from
>>> the `kernel` crate so the PDE/PTE fields can be `Bounded`, I will try to
>>> make it available quickly in a patch that you can depend on.
>>
>> That would be great, and I'd be happy to integrate Bounded validation once
>> the macro is available. I just don't think we need to restructure the
>> dispatch model in order to benefit from it.
>>
>>> But long story short, and although I need to dive deeper into the code,
>>> this looks like a good candidate for using a trait and associated types.
>>
>> The walker code (walk.rs) is already version-agnostic and reads cleanly.
>> The version dispatch is encapsulated behind method calls, not exposed as
>> inline if/else blocks.
>>
>> Generic propagation (or version-specific dispatch at higher levels) adds more
>> complexity at higher layers.
>>
>> Enclosed below [3] is the diff I used for my testing with the data, I don't
>> really see a net readability win there (IMO, it is a net-loss in readability).
>>
>> [3]
>> https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=trait-pt-dispatch&id=5eb0e98af11ba608ff4d0f7a06065ee863f5066a
>
> IMO this diff is quite has got me quite in favour of trait approach.
>
> I wanted about to purpose something similar (or maybe I had already?) trait
> approach some versions ago but didn't due to the eventual need of `match` like
> dispatch (like you had with `vmm_dispatch`), but your code made that looks not
> as bad as I thought it would be.
>
That's the drawback right, now vmm_dispatch has to deal with version difference
where as before, the lower layers would. Maybe we can keep the vmm layer the way
it is now, but do the dispatch itself at the lower layers, while still using
traits like in the diff. I'll try that as well. :)
thanks,
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Joel Fernandes @ 2026-04-13 20:10 UTC (permalink / raw)
To: Danilo Krummrich
Cc: John Hubbard, Eliot Courtney, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Dave Airlie,
Daniel Almeida, Koen Koning, dri-devel, rust-for-linux,
Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Vivi Rodrigo, Tvrtko Ursulin, Rui Huang, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, Alexey Ivanov,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DHOKLTRRIX2Z.1YA9X0D0X21K@kernel.org>
Hi Danilo,
On 4/9/2026 7:00 AM, Danilo Krummrich wrote:
> On Thu Apr 9, 2026 at 12:33 PM CEST, Joel Fernandes wrote:
>> Since it is 3 against 1 here, I rest my case :-).
>
> That's not how I'd view it. :)
>
> Anyways, in case I'm included in "3", that's not my position. My point was to
> ensure we keep discussing advantages and disadvantages on their merits, as I
> think you both have good points.
Heh, yes I actually *did not* include you in the 3 since you sounded to be open
to both. ;-)
>
>> I am still in disagreement since I do not see much benefit (that is why I said
>> pointless above).
>
> That is fair -- in this case please explain why the advantages pointed out by
> others are not worth it, propose something that picks up the best of both
> worlds, etc.
>
> You can also turn it around and ask people whether they can tweak their counter
> proposal to get rid of specific parts you dislike for a reason.
>
> IOW, keep the ball rolling, so we can come up with the best possible solution.
Good advice, thanks! I will try to come up with something that is acceptable to
everyone and we can further debate pros/cons on v11.
There are some merits on the alternative proposal from Eliot/Alex that I'd like
to explore while seeing if I can keep some of the merits in mine as well.
thanks,
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH v10 12/21] gpu: nova-core: mm: Add unified page table entry wrapper enums
From: Joel Fernandes @ 2026-04-13 20:04 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Eliot Courtney, Danilo Krummrich, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Bjorn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Dave Airlie,
Daniel Almeida, Koen Koning, dri-devel, rust-for-linux,
Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi, joel,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DHOKJ3MJNO5P.SXKOAYKX13JL@nvidia.com>
Hi Alex,
On 4/9/2026 6:56 AM, Alexandre Courbot wrote:
> On Thu Apr 9, 2026 at 5:19 AM JST, Joel Fernandes wrote:
>> Hi Alex, Eliot, Danilo,
>>
>> Thanks for taking a look. Let me respond to the specific points below.
>>
>> On Wed, 08 Apr 2026, Alexandre Courbot wrote:
>>> After a quick look I'd say that having a trait here would actually be
>>> *good* for correctness and maintainability.
>>>
>>> The current design implies that every operation on a page table (most
>>> likely using the walker) goes through a branching point. Just looking at
>>> `PtWalk::read_pte_at_level`, there are already at least 6
>>> `if version == 2 { } else { }` branches that all resolve to the same
>>> result. Include walking down the PDEs and you have at least a dozen of
>>> these just to resolve a virtual address. I know CPUs are fast, but this
>>> is still wasted cycles for no good reason.
>>
>> I did some measurements and there is no notieceable difference in both
>> approaches. I ran perf and loaded nova with self-tests running. The extra
>> potential branching is lost in the noise. In both cases, loading nova and
>> running the self-tests has ~119.7M branch instructions on my Ampere. The total
>> instruction count is also identical (~615M).
>
> That's expected - as I said, CPUs are fast - and that's also not my
> point. My issue is that we are doing countless tests that all resolve to
> the code path, a code path that is already known during probe time.
> That's a huge code smell.
>
> When we create the GPU, we know whether we will be using v2 or v3 page
> tables. That we need to test that again 12 times per address resolution
> is a design issue, irrespective of performance. There are 24 version
> match sites in patch 12 alone.
>
> And that's precisely a good justification for using monomorphization. v2
> and v3 are technically two different page table implementations (they
> even have their own distinct module in your series), we just use
> generics to factorize the (source) code a bit.
To repeat my point though, the extra tests don't complicate the code or change
performance. The bottleneck is here is MMIO, not CPU cycles (and arguably
testing shows no change in CPU cycles either). So I tend to prefer cleaner code
(which in my view is the few matches in pagetable.rs versus templatizing lots of
code). I do see your point of view though and I Ok with (trying out) the
alternative as well, and it seems to be what mostly everyone wants. It is a
little more boiler plate in higher layers which are not exposed to version
matching, but not the end of the world :).
>> I measured like this:
>> perf stat -e
>> branches,branch-misses,cache-references,cache-misses,instructions,cycles --
>> modprobe nova_core
>>
>> So I think the branching argument is not a strong one. I also did more
>> measurements and the dominant time taken is MMIO. During the map prep and
>> execute, page table walks are done. A TLB flush alone costs ~1.4 microseconds.
>> And PRAMIN BAR0 writes to write the PTE is also about 1 microsecond. Considering
>> this, I don't think the extra branching argument holds (even without branch
>> prediction and speculation).
>>
>> Also some branches cannot be eliminated even with parameterization:
>>
>> if level == self.mmu_version.dual_pde_level() {
>> // 128-bit dual PDE read
>> } else {
>> // Regular 64-bit PDE read
>> }
>>
>> This isn't really a version branch -- it's a structural branch that
>> distinguishes between 64-bit PDE and 128-bit dual PDE entries. Any MMU
>> version with a dual PDE level would need this same distinction.
>
> The dual PDE level should be an associated constant - you still need to
> do the test, but note that you would also do it if there was only a
> single page table version. It's orthogonal to whether we use a trait or
> not here.
Sure, fair enough.
>
>>
>> I also did code-generation size analysis (see diff of code used below):
>>
>> Code generation analysis:
>>
>> Module .ko size: Before: 511,792 bytes After: 524,464 bytes (+2.5%)
>> .text section: Before: 112,620 bytes After: 116,628 bytes (+4,008 bytes)
>>
>> The +4K .text growth is the monomorphization cost: every generic function
>> is compiled twice (once for MmuV2, once for MmuV3).
>
> I would say this is working as intended then.
2.5% is not much for 1 feature but overtime IMO it can add up and become
significant, I think we should keep an eye on size.
>>> If you use a trait here, and make `PtWalk` generic against it, you can
>>> optimize this away. We had a similar situation when we introduced Turing
>>> support and the v2 ucode header, and tried both approaches: the
>>> trait-based one was slightly shorter, and arguably more readable.
>>
>> Actually I was the one who suggested traits for Falcon ucode descriptor if you
>> see this thread [1]. So basically you and Eliot are telling me to do what I
>> suggested in [1]. :-) However, I disagree that it is the right choice for this code.
>>
>> [1] https://lore.kernel.org/all/20251117231028.GA1095236@joelbox2/
>>
>> I think the two cases are quite different in complexity:
>
> Exactly. The complexity is different (this one involves multiple traits
> and associated types) but the pattern is the same - and that's a pattern
> traits are designed to address. If we were supposed to stop applying it
> when things go beyond a certain level of complexity, the conceptors of
> Rust would not have bothered addings things like associated types.
>
> These traits are nothing new, they simply formalize a reality that
> already exists in your code, which is that each version of the page
> table needs to implement a given set of methods. It's already there with
> the version doing dispatches, only it is not articulated clearly to the
> reader. So in that respect, having traits make the code *more* readable
> imho.
Makes the lower layers more readable and the higher layers more complex. Me, I'd
have preferred to keep the version matching stuff to the lower layers /
centralized. Maybe there is still a way to do that, while still using traits.
>>
>> The falcon ucode descriptor is essentially a set of flat field accessors
>> and a few params (imem_sec_load_params, dmem_load_params).
>> The trait has ~10 simple getter methods. There's no multi-level hierarchy,
>> no walker, and no generic propagation.
>>
>> The MMU page table case is structurally different. Making PtWalk generic
>> over an Mmu trait would require:
>>
>> - PtWalk<M: Mmu> (the walker)
>> - Plus all the associated types: M::Pte, M::Pde, M::DualPde each
>> needing their own trait bounds
>>
>> And we would also need:
>> - Vmm<M: Mmu> (which creates PtWalk)
>> - BarUser<M: Mmu> (which creates Vmm)
>>
>> I am also against making Vmm an enum as Eliot suggested:
>> enum Vmm {
>> V2(VmmInner<MmuV2>),
>> V3(VmmInner<MmuV3>),
>> }
>>
>> That moves the version complexity up to the reader. Code complexity IMO should
>> decrease as we go up abstractions, making it easier for users (Vmm/Bar).
>>
>> If you look at the the changes in vmm.rs to handle version dispatch there [2]:
>> Added: +109
>> Removed: -28
>>
>> [2]
>> https://github.com/Edgeworth/linux/commit/3627af550b61256184d589e7ec666c1108971f0e
>>
>> The main benefit of my approach is version-specific dispatch complexity is
>> completely isolated inside MmuVersion thus making the code outside of
>> pagetable.rs much more readable, without having to parametrize anything, and
>> without code size increase. I think that is worth considering.
>>
>>> But the main argument to use a trait here IMO is that it enables
>>> associated types and constants. That's particularly critical since some
>>> equivalent fields have different lengths between v2 and v3. An
>>> associated `Bounded` type for these would force the caller to validate
>>> the length of these fields before calling a non-fallible operation,
>>> which is exactly the level of caution that we want when dealing with
>>> page tables.
>>
>> I think Bounded validation is orthogonal to the dispatch model.
>> We can add Bounded to the current design without restructuring
>> into traits. For example:
>>
>> // In ver2::Pte
>> pub fn new_vram(pfn: Bounded<Pfn, 25>, writable: bool) -> Self { ... }
>>
>> // In ver3::Pte
>> pub fn new_vram(pfn: Bounded<Pfn, 40>, writable: bool) -> Self { ... }
>>
>> The unified Pte enum wrapper already dispatches to the correct
>> version-specific constructor, which would enforce the correct Bounded
>> constraint for that version.
>
> But then what type does the `new_vram` dispatch method take? Generic
> code lets us expose the expected `Bounded` type to the caller, which can
> do the proper validation. This is a small example, but I expect this
> pattern to come up in other parts of the code as well.
Maybe I didn't follow your point, but the caller would do a version match and
pass the correct bounded number of bits, but granted that's uglier if/once we
switched to bounded types here.
>>
>>> In order to fully benefit from it, we will need the bitfield macro from
>>> the `kernel` crate so the PDE/PTE fields can be `Bounded`, I will try to
>>> make it available quickly in a patch that you can depend on.
>>
>> That would be great, and I'd be happy to integrate Bounded validation once
>> the macro is available. I just don't think we need to restructure the
>> dispatch model in order to benefit from it.
>
> I'll finish the series and hopefully send it a bit later today. That's
> another significant rework for the series (sorry about that) but it
> should be worth the effort for the added correctness.
Sure!
thanks,
--
Joel Fernandes
^ permalink raw reply
* Re: [patch 15/38] ptp: ptp_vmclock: Replace get_cycles() usage
From: Arnd Bergmann @ 2026-04-13 19:30 UTC (permalink / raw)
To: David Woodhouse, Thomas Gleixner, LKML
Cc: x86, Baolu Lu, iommu, Michael Grzeschik, Netdev, linux-wireless,
Herbert Xu, linux-crypto, Vlastimil Babka (SUSE), linux-mm,
Bernie Thompson, linux-fbdev, Theodore Ts'o, linux-ext4,
Andrew Morton, Uladzislau Rezki (Sony), Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A . Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc@vger.kernel.org, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S . Miller,
sparclinux
In-Reply-To: <7a48b636cb3146f4f7134c6d4fe42070ac2edb43.camel@infradead.org>
On Mon, Apr 13, 2026, at 17:33, David Woodhouse wrote:
> On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
>
> ... depend on TSC_RELIABLE¹, since if the guest doesn't believe that it
> is, then the guest shouldn't be trying to use it as the basis for
> precise timing.
>
> ¹ (Or... one of the other zoo of TSC flags for the gradually reducing
> brokenness over the years...)
It looks like this is sufficiently handled in the caller:
static int vmclock_get_crosststamp(struct vmclock_state *st,
struct ptp_system_timestamp *sts,
struct system_counterval_t *system_counter,
struct timespec64 *tspec)
{
....
#ifdef CONFIG_X86
/*
* We'd expect the hypervisor to know this and to report the clock
* status as VMCLOCK_STATUS_UNRELIABLE. But be paranoid.
*/
if (check_tsc_unstable())
return -EINVAL;
#endif
With 486 and ELAN out of the way, Winchip6 seems to be the only
one without X86_FEATURE_TSC, so I think the next logical step would
be to turn off Winchip6 as well and remove all X86_FEATURE_TSC
and CONFIG_X86_TSC checks.
Arnd
^ permalink raw reply
* Re: [patch 15/38] ptp: ptp_vmclock: Replace get_cycles() usage
From: David Woodhouse @ 2026-04-13 15:33 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120318.592237447@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
> get_cycles() is not really well defined and similar to other usaage of the
> underlying hardware CPU counters the PTP vmclock should use an explicit
> interface as well.
>
> Implement ptp_vmclock_read_cpu_counter() in arm64 and x86 and simplify the
> Kconfig selection while at it.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Although I might follow up with a change to make this...
> +static inline u64 ptp_vmclock_read_cpu_counter(void)
> +{
> + return cpu_feature_enabled(X86_FEATURE_TSC) ? rdtsc() : 0;
> +}
> +
... depend on TSC_RELIABLE¹, since if the guest doesn't believe that it
is, then the guest shouldn't be trying to use it as the basis for
precise timing.
¹ (Or... one of the other zoo of TSC flags for the gradually reducing
brokenness over the years...)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ 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