* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Geert Uytterhoeven @ 2026-01-07 10:36 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Helge Deller, Greg Kroah-Hartman, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-fbdev, dri-devel, linux-kernel,
linux-sh, linux-m68k
In-Reply-To: <dda4052e-b843-43fa-850c-a1bb20e4a8e3@kernel.org>
Hi Vincent,
On Tue, 6 Jan 2026 at 21:10, Vincent Mailhol <mailhol@kernel.org> wrote:
> On 06/01/2026 at 12:48, Geert Uytterhoeven wrote:
> > Thanks for your patch, which is now commit bd710b3da7308cb1
> > ("video/logo: move logo selection logic to Kconfig") in fbdev/for-next.
> >
> > On Thu, 1 Jan 2026 at 16:26, Vincent Mailhol <mailhol@kernel.org> wrote:
> >> Now that the path to the logo file can be directly entered in Kbuild,
> >> there is no more need to handle all the logo file selection in the
> >> Makefile and the C files.
> >
> > This may do the wrong thing when booting a multi-platform kernel.
> >
> >>
> >> The only exception is the logo_spe_clut224 which is only used by the
> >> Cell processor (found for example in the Playstation 3) [1]. This
> >> extra logo uses its own different image which shows up on a separate
> >> line just below the normal logo. Because the extra logo uses a
> >> different image, it can not be factorized under the custom logo logic.
> >>
> >> Move all the logo file selection logic to Kbuild (except from the
> >> logo_spe_clut224.ppm), this done, clean-up the C code to only leave
> >> one entry for each logo type (monochrome, 16-colors and 224-colors).
> >>
> >> [1] Cell SPE logos
> >> Link: https://lore.kernel.org/all/20070710122702.765654000@pademelon.sonytel.be/
> >>
> >> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> >
> >> --- a/drivers/video/logo/Kconfig
> >> +++ b/drivers/video/logo/Kconfig
> >
> >> @@ -61,6 +63,12 @@ config LOGO_LINUX_CLUT224
> >> config LOGO_LINUX_CLUT224_FILE
> >> string "224-color logo .ppm file"
> >> depends on LOGO_LINUX_CLUT224
> >> + default "drivers/video/logo/logo_dec_clut224.ppm" if MACH_DECSTATION || ALPHA
> >> + default "drivers/video/logo/logo_mac_clut224.ppm" if MAC
> >
> > E.g. an m68k multi-platform kernel including Mac support will scare
> > non-Mac users into thinking their machine was assimilated by the
> > Apple Empire...
> >
> >> + default "drivers/video/logo/logo_parisc_clut224.ppm" if PARISC
> >> + default "drivers/video/logo/logo_sgi_clut224.ppm" if SGI_IP22 || SGI_IP27 || SGI_IP32
> >> + default "drivers/video/logo/logo_sun_clut224.ppm" if SPARC
> >> + default "drivers/video/logo/logo_superh_clut224.ppm" if SUPERH
> >> default "drivers/video/logo/logo_linux_clut224.ppm"
> >> help
> >> Takes a path to a 224-color logo in the portable pixmap file
> >
> >> --- a/drivers/video/logo/logo.c
> >> +++ b/drivers/video/logo/logo.c
> >> @@ -48,59 +48,21 @@ const struct linux_logo * __ref fb_find_logo(int depth)
> >> if (nologo || logos_freed)
> >> return NULL;
> >>
> >> - if (depth >= 1) {
> >> #ifdef CONFIG_LOGO_LINUX_MONO
> >> - /* Generic Linux logo */
> >> + if (depth >= 1)
> >> logo = &logo_linux_mono;
> >> #endif
> >> -#ifdef CONFIG_LOGO_SUPERH_MONO
> >> - /* SuperH Linux logo */
> >> - logo = &logo_superh_mono;
> >> -#endif
> >> - }
> >>
> >> - if (depth >= 4) {
> >> #ifdef CONFIG_LOGO_LINUX_VGA16
> >> - /* Generic Linux logo */
> >> + if (depth >= 4)
> >> logo = &logo_linux_vga16;
> >> #endif
> >> -#ifdef CONFIG_LOGO_SUPERH_VGA16
> >> - /* SuperH Linux logo */
> >> - logo = &logo_superh_vga16;
> >> -#endif
> >> - }
> >>
> >> - if (depth >= 8) {
> >> #ifdef CONFIG_LOGO_LINUX_CLUT224
> >> - /* Generic Linux logo */
> >> + if (depth >= 8)
> >> logo = &logo_linux_clut224;
> >> #endif
> >> -#ifdef CONFIG_LOGO_DEC_CLUT224
> >> - /* DEC Linux logo on MIPS/MIPS64 or ALPHA */
> >> - logo = &logo_dec_clut224;
> >> -#endif
> >> -#ifdef CONFIG_LOGO_MAC_CLUT224
> >> - /* Macintosh Linux logo on m68k */
> >> - if (MACH_IS_MAC)
> >
> > MACH_IS_MAC can be a runtime check.
>
> OK. I missed this.
>
> I think there are two options to fix this:
>
> 1. Keep CONFIG_LOGO_MAC_CLUT224 untouched
> 2. Remove logo_mac_clut224.ppm
>
> The first option is less controversial but I would like to ask you what
> you think about removing the logo_mac_clut224 file.
>
> Here, we are speaking of the Macintosh 68k which ended sales in 1995,
> right? So the user base should be rather small, I guess.
Yes, the user base is small.
BTW, the only reason you don't have this issue with MACH_DECSTATION and
the various SGI_IP* options is that MIPS does not support multi-platform
kernels.
> And people who still want the custom MAC logo would still be able to add
>
> CONFIG_LOGO_MAC_CLUT224="path/to/logo_mac_clut224.ppm"
LOGO_LINUX_CLUT224_FILE ;-)
> to their config to restore the old behaviour anyway.
>
> My choice would go more toward the removal option but what do you think?
I am not too attached to keeping the dynamic behavior for the Mac logo,
I just wanted to point out the impact.
I expect most people who care about logos (in products) just have their
own custom out-of-tree code. As fb_find_logo() and the underlying
infrastructure still exists, I don't expect them to have too much
trouble forward porting that to newer kernels.
What do other people think?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/3] staging: rtl8723bs: remove unnecessary parentheses and true comparisons
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
In-Reply-To: <20260107094714.300380-1-lorenzosimonelli02@gmail.com>
Clean up unnecessary double parentheses and explicit comparisons to
true in rtw_mlme.c. This improves readability and adheres to the
Linux kernel coding style
Signed-off-by: Lorenzo Simonelli <lorenzosimonelli02@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index ff4e668f1..d9e6778e1 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -468,11 +468,11 @@ static void update_current_network(struct adapter *adapter, struct wlan_bssid_ex
&pmlmepriv->cur_network.network,
&pmlmepriv->cur_network.network,
&pmlmepriv->cur_network.network);
-
- if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) && (is_same_network(&pmlmepriv->cur_network.network, pnetwork, 0))) {
+ if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) &&
+ (is_same_network(&pmlmepriv->cur_network.network, pnetwork, 0))) {
update_network(&pmlmepriv->cur_network.network, pnetwork, adapter, true);
rtw_update_protection(adapter, (pmlmepriv->cur_network.network.ies) + sizeof(struct ndis_802_11_fix_ie),
- pmlmepriv->cur_network.network.ie_length);
+ pmlmepriv->cur_network.network.ie_length);
}
}
@@ -710,7 +710,7 @@ void rtw_surveydone_event_callback(struct adapter *adapter, u8 *pbuf)
rtw_set_signal_stat_timer(&adapter->recvpriv);
if (pmlmepriv->to_join) {
- if ((check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)) {
+ if (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE)) {
if (check_fwstate(pmlmepriv, _FW_LINKED) == false) {
set_fwstate(pmlmepriv, _FW_UNDER_LINKING);
@@ -1386,8 +1386,8 @@ void rtw_stassoc_event_callback(struct adapter *adapter, u8 *pbuf)
spin_lock_bh(&pmlmepriv->lock);
- if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
- (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)) {
+ if (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) ||
+ check_fwstate(pmlmepriv, WIFI_ADHOC_STATE)) {
if (adapter->stapriv.asoc_sta_count == 2) {
spin_lock_bh(&pmlmepriv->scanned_queue.lock);
ptarget_wlan = rtw_find_network(&pmlmepriv->scanned_queue, cur_network->network.mac_address);
--
2.52.0
^ permalink raw reply related
* [PATCH 2/3] staging: rtl8723bs: remove trailing whitespace
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
In-Reply-To: <20260107094714.300380-1-lorenzosimonelli02@gmail.com>
Remove a trailing whitespace found by checkpatch.pl in rtw_mlme.c
at line 2021.
Signed-off-by: Lorenzo Simonelli <lorenzosimonelli02@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index 98704179a..ff4e668f1 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -2018,7 +2018,7 @@ int rtw_restruct_wmm_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie, uint in_
return ielength;
}
-/* Ported from 8185: IsInPreAuthKeyList().
+/* Ported from 8185: IsInPreAuthKeyList().
* (Renamed from SecIsInPreAuthKeyList(), 2006-10-13.)
* Added by Annie, 2006-05-07.
*
--
2.52.0
^ permalink raw reply related
* [PATCH 1/3] staging: sm750fb: fix static const char array warning
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
In-Reply-To: <20260107094714.300380-1-lorenzosimonelli02@gmail.com>
Fix the checkpatch.pl warning: "static const char * array should
probably be static const char * const" by adding the missing
const modifier.
Signed-off-by: Lorenzo Simonelli <lorenzosimonelli02@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index fecd7457e..15b5de33b 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -33,7 +33,7 @@
static int g_hwcursor = 1;
static int g_noaccel;
static int g_nomtrr;
-static const char *g_fbmode[] = {NULL, NULL};
+static const char * const g_fbmode[] = {NULL, NULL};
static const char *g_def_fbmode = "1024x768-32@60";
static char *g_settings;
static int g_dualview;
--
2.52.0
^ permalink raw reply related
* [PATCH 0/3] staging: style cleanups for sm750fb and rtl8723bs
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
This patch series performs various style cleanups in the staging
directory to resolve warnings reported by checkpatch.pl.
The changes include:
- Fixing 'static const char * const' declarations in sm750fb.
- Removing trailing whitespace in rtw_mlme.c.
- Simplifying boolean expressions by removing unnecessary parentheses
and explicit comparisons to 'true'.
All patches have been checked with checkpatch.pl and the modified
files have been verified to compile correctly.
Lorenzo Simonelli (3):
staging: sm750fb: fix static const char array warning
staging: rtl8723bs: remove trailing whitespace
staging: rtl8723bs: remove unnecessary parentheses and true comparisons
drivers/staging/rtl8723bs/core/rtw_mlme.c | 14 +++++++-------
drivers/staging/sm750fb/sm750.c | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v4 4/4] fbdev: sh_mobile_lcdc: Make FB_DEVICE dependency optional
From: Thomas Zimmermann @ 2026-01-07 7:33 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-5-chintanlike@gmail.com>
Am 07.01.26 um 05:42 schrieb Chintan Patel:
> The sh_mobile_lcdc driver exposes overlay configuration via sysfs, but the
> core driver does not require CONFIG_FB_DEVICE.
>
> Make overlay sysfs optional so that the driver can build and operate
> even when FB_DEVICE is disabled. The kernel naturally ignores the
> missing attribute group, preserving buildability and type safety.
>
> Suggested-by: Helge Deller <deller@gmx.de>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> index dd950e4ab5ce..5f3a0cd27db3 100644
> --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> @@ -1343,14 +1343,17 @@ static DEVICE_ATTR_RW(overlay_mode);
> static DEVICE_ATTR_RW(overlay_position);
> static DEVICE_ATTR_RW(overlay_rop3);
>
> -static struct attribute *overlay_sysfs_attrs[] = {
> +static struct attribute *overlay_sysfs_attrs[] __maybe_unused = {
> &dev_attr_overlay_alpha.attr,
> &dev_attr_overlay_mode.attr,
> &dev_attr_overlay_position.attr,
> &dev_attr_overlay_rop3.attr,
> NULL,
> };
> +
> +#ifdef CONFIG_FB_DEVICE
> ATTRIBUTE_GROUPS(overlay_sysfs);
> +#endif
>
> static const struct fb_fix_screeninfo sh_mobile_lcdc_overlay_fix = {
> .id = "SH Mobile LCDC",
--
--
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 v4 3/4] fbdev: omapfb: Make FB_DEVICE dependency optional
From: Thomas Zimmermann @ 2026-01-07 7:33 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-4-chintanlike@gmail.com>
Am 07.01.26 um 05:42 schrieb Chintan Patel:
> omapfb provides several sysfs interfaces for framebuffer configuration
> and debugging, but these are not required for the core driver.
>
> Remove the hard dependency on CONFIG_FB_DEVICE and make sysfs support
> optional by using dev_of_fbinfo() to obtain the backing device at runtime.
> When FB_DEVICE is disabled, sysfs operations are skipped while the code
> still builds and is type-checked.
>
> Suggested-by: Helge Deller <deller@gmx.de>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
> .../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 ++++++++++++++----
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
> index f4cdf999a080..2d20e79adefc 100644
> --- a/drivers/video/fbdev/omap2/omapfb/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
> @@ -5,7 +5,6 @@ config OMAP2_VRFB
> menuconfig FB_OMAP2
> tristate "OMAP2+ frame buffer support"
> depends on FB
> - depends on FB_DEVICE
> depends on DRM_OMAP = n
> depends on GPIOLIB
> select FB_OMAP2_DSS
> @@ -13,6 +12,8 @@ menuconfig FB_OMAP2
> select FB_IOMEM_HELPERS
> help
> Frame buffer driver for OMAP2+ based boards.
> + FB_DEVICE is not required, but if enabled, provides sysfs interface
> + for framebuffer configuration and debugging.
>
> if FB_OMAP2
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
> index 831b2c2fbdf9..38a635d38d58 100644
> --- a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
> +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
> @@ -558,10 +558,15 @@ int omapfb_create_sysfs(struct omapfb2_device *fbdev)
>
> DBG("create sysfs for fbs\n");
> for (i = 0; i < fbdev->num_fbs; i++) {
> + struct device *dev;
> int t;
> +
> + dev = dev_of_fbinfo(fbdev->fbs[i]);
> + if (!dev)
> + continue;
> +
> for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++) {
> - r = device_create_file(fbdev->fbs[i]->dev,
> - &omapfb_attrs[t]);
> + r = device_create_file(dev, &omapfb_attrs[t]);
>
> if (r) {
> dev_err(fbdev->dev, "failed to create sysfs "
> @@ -580,9 +585,14 @@ void omapfb_remove_sysfs(struct omapfb2_device *fbdev)
>
> DBG("remove sysfs for fbs\n");
> for (i = 0; i < fbdev->num_fbs; i++) {
> + struct device *dev;
> +
> + dev = dev_of_fbinfo(fbdev->fbs[i]);
> + if (!dev)
> + continue;
> +
> for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++)
> - device_remove_file(fbdev->fbs[i]->dev,
> - &omapfb_attrs[t]);
> + device_remove_file(dev, &omapfb_attrs[t]);
> }
> }
>
--
--
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 v4 2/4] staging: fbtft: Make FB_DEVICE dependency optional
From: Thomas Zimmermann @ 2026-01-07 7:33 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-3-chintanlike@gmail.com>
Am 07.01.26 um 05:42 schrieb Chintan Patel:
> fbtft provides sysfs interfaces for debugging and gamma configuration,
> but these are not required for the core driver.
>
> Drop the hard dependency on CONFIG_FB_DEVICE and make sysfs support
> optional by using dev_of_fbinfo() at runtime. When FB_DEVICE is disabled,
> sysfs operations are skipped while the code remains buildable and
> type-checked.
>
> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
> Suggested-by: Helge Deller <deller@gmx.de>
> Reviewed-by: Helge Deller <deller@gmx.de>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/staging/fbtft/Kconfig | 5 ++++-
> drivers/staging/fbtft/fbtft-sysfs.c | 20 ++++++++++++++++----
> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
> index c2655768209a..578412a2f379 100644
> --- a/drivers/staging/fbtft/Kconfig
> +++ b/drivers/staging/fbtft/Kconfig
> @@ -2,11 +2,14 @@
> menuconfig FB_TFT
> tristate "Support for small TFT LCD display modules"
> depends on FB && SPI
> - depends on FB_DEVICE
> depends on BACKLIGHT_CLASS_DEVICE
> depends on GPIOLIB || COMPILE_TEST
> select FB_BACKLIGHT
> select FB_SYSMEM_HELPERS_DEFERRED
> + help
> + Support for small TFT LCD display modules over SPI bus. FB_DEVICE
> + is not required, but if enabled, provides sysfs interface for debugging
> + and gamma curve configuration.
>
> if FB_TFT
>
> diff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/staging/fbtft/fbtft-sysfs.c
> index e45c90a03a90..d05599d80011 100644
> --- a/drivers/staging/fbtft/fbtft-sysfs.c
> +++ b/drivers/staging/fbtft/fbtft-sysfs.c
> @@ -203,14 +203,26 @@ static struct device_attribute debug_device_attr =
>
> void fbtft_sysfs_init(struct fbtft_par *par)
> {
> - device_create_file(par->info->dev, &debug_device_attr);
> + struct device *dev;
> +
> + dev = dev_of_fbinfo(par->info);
> + if (!dev)
> + return;
> +
> + device_create_file(dev, &debug_device_attr);
> if (par->gamma.curves && par->fbtftops.set_gamma)
> - device_create_file(par->info->dev, &gamma_device_attrs[0]);
> + device_create_file(dev, &gamma_device_attrs[0]);
> }
>
> void fbtft_sysfs_exit(struct fbtft_par *par)
> {
> - device_remove_file(par->info->dev, &debug_device_attr);
> + struct device *dev;
> +
> + dev = dev_of_fbinfo(par->info);
> + if (!dev)
> + return;
> +
> + device_remove_file(dev, &debug_device_attr);
> if (par->gamma.curves && par->fbtftops.set_gamma)
> - device_remove_file(par->info->dev, &gamma_device_attrs[0]);
> + device_remove_file(dev, &gamma_device_attrs[0]);
> }
--
--
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 v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Thomas Zimmermann @ 2026-01-07 7:32 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-2-chintanlike@gmail.com>
Am 07.01.26 um 05:42 schrieb Chintan Patel:
> Add dev_of_fbinfo() to return the framebuffer struct device when
> CONFIG_FB_DEVICE is enabled, or NULL otherwise.
>
> This allows fbdev drivers to use sysfs interfaces via runtime checks
> instead of CONFIG_FB_DEVICE ifdefs, keeping the code clean while
> remaining fully buildable.
>
> Suggested-by: Helge Deller <deller@gmx.de>
> Reviewed-by: Helge Deller <deller@gmx.de>
> Reviewed-by: Andy Shevchenko <andy@kernel.org>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> include/linux/fb.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 05cc251035da..dad3fb61a06a 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -628,6 +628,15 @@ static inline void unlock_fb_info(struct fb_info *info)
> mutex_unlock(&info->lock);
> }
>
> +static inline struct device *dev_of_fbinfo(const struct fb_info *info)
> +{
> +#ifdef CONFIG_FB_DEVICE
> + return info->dev;
> +#else
> + return NULL;
> +#endif
> +}
> +
> static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
> u8 *src, u32 s_pitch, u32 height)
> {
--
--
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
* [PATCH v4 4/4] fbdev: sh_mobile_lcdc: Make FB_DEVICE dependency optional
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
The sh_mobile_lcdc driver exposes overlay configuration via sysfs, but the
core driver does not require CONFIG_FB_DEVICE.
Make overlay sysfs optional so that the driver can build and operate
even when FB_DEVICE is disabled. The kernel naturally ignores the
missing attribute group, preserving buildability and type safety.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index dd950e4ab5ce..5f3a0cd27db3 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1343,14 +1343,17 @@ static DEVICE_ATTR_RW(overlay_mode);
static DEVICE_ATTR_RW(overlay_position);
static DEVICE_ATTR_RW(overlay_rop3);
-static struct attribute *overlay_sysfs_attrs[] = {
+static struct attribute *overlay_sysfs_attrs[] __maybe_unused = {
&dev_attr_overlay_alpha.attr,
&dev_attr_overlay_mode.attr,
&dev_attr_overlay_position.attr,
&dev_attr_overlay_rop3.attr,
NULL,
};
+
+#ifdef CONFIG_FB_DEVICE
ATTRIBUTE_GROUPS(overlay_sysfs);
+#endif
static const struct fb_fix_screeninfo sh_mobile_lcdc_overlay_fix = {
.id = "SH Mobile LCDC",
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/4] fbdev: omapfb: Make FB_DEVICE dependency optional
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
omapfb provides several sysfs interfaces for framebuffer configuration
and debugging, but these are not required for the core driver.
Remove the hard dependency on CONFIG_FB_DEVICE and make sysfs support
optional by using dev_of_fbinfo() to obtain the backing device at runtime.
When FB_DEVICE is disabled, sysfs operations are skipped while the code
still builds and is type-checked.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 ++++++++++++++----
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
index f4cdf999a080..2d20e79adefc 100644
--- a/drivers/video/fbdev/omap2/omapfb/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
@@ -5,7 +5,6 @@ config OMAP2_VRFB
menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
- depends on FB_DEVICE
depends on DRM_OMAP = n
depends on GPIOLIB
select FB_OMAP2_DSS
@@ -13,6 +12,8 @@ menuconfig FB_OMAP2
select FB_IOMEM_HELPERS
help
Frame buffer driver for OMAP2+ based boards.
+ FB_DEVICE is not required, but if enabled, provides sysfs interface
+ for framebuffer configuration and debugging.
if FB_OMAP2
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
index 831b2c2fbdf9..38a635d38d58 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
@@ -558,10 +558,15 @@ int omapfb_create_sysfs(struct omapfb2_device *fbdev)
DBG("create sysfs for fbs\n");
for (i = 0; i < fbdev->num_fbs; i++) {
+ struct device *dev;
int t;
+
+ dev = dev_of_fbinfo(fbdev->fbs[i]);
+ if (!dev)
+ continue;
+
for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++) {
- r = device_create_file(fbdev->fbs[i]->dev,
- &omapfb_attrs[t]);
+ r = device_create_file(dev, &omapfb_attrs[t]);
if (r) {
dev_err(fbdev->dev, "failed to create sysfs "
@@ -580,9 +585,14 @@ void omapfb_remove_sysfs(struct omapfb2_device *fbdev)
DBG("remove sysfs for fbs\n");
for (i = 0; i < fbdev->num_fbs; i++) {
+ struct device *dev;
+
+ dev = dev_of_fbinfo(fbdev->fbs[i]);
+ if (!dev)
+ continue;
+
for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++)
- device_remove_file(fbdev->fbs[i]->dev,
- &omapfb_attrs[t]);
+ device_remove_file(dev, &omapfb_attrs[t]);
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/4] staging: fbtft: Make FB_DEVICE dependency optional
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
fbtft provides sysfs interfaces for debugging and gamma configuration,
but these are not required for the core driver.
Drop the hard dependency on CONFIG_FB_DEVICE and make sysfs support
optional by using dev_of_fbinfo() at runtime. When FB_DEVICE is disabled,
sysfs operations are skipped while the code remains buildable and
type-checked.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Helge Deller <deller@gmx.de>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
drivers/staging/fbtft/Kconfig | 5 ++++-
drivers/staging/fbtft/fbtft-sysfs.c | 20 ++++++++++++++++----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
index c2655768209a..578412a2f379 100644
--- a/drivers/staging/fbtft/Kconfig
+++ b/drivers/staging/fbtft/Kconfig
@@ -2,11 +2,14 @@
menuconfig FB_TFT
tristate "Support for small TFT LCD display modules"
depends on FB && SPI
- depends on FB_DEVICE
depends on BACKLIGHT_CLASS_DEVICE
depends on GPIOLIB || COMPILE_TEST
select FB_BACKLIGHT
select FB_SYSMEM_HELPERS_DEFERRED
+ help
+ Support for small TFT LCD display modules over SPI bus. FB_DEVICE
+ is not required, but if enabled, provides sysfs interface for debugging
+ and gamma curve configuration.
if FB_TFT
diff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/staging/fbtft/fbtft-sysfs.c
index e45c90a03a90..d05599d80011 100644
--- a/drivers/staging/fbtft/fbtft-sysfs.c
+++ b/drivers/staging/fbtft/fbtft-sysfs.c
@@ -203,14 +203,26 @@ static struct device_attribute debug_device_attr =
void fbtft_sysfs_init(struct fbtft_par *par)
{
- device_create_file(par->info->dev, &debug_device_attr);
+ struct device *dev;
+
+ dev = dev_of_fbinfo(par->info);
+ if (!dev)
+ return;
+
+ device_create_file(dev, &debug_device_attr);
if (par->gamma.curves && par->fbtftops.set_gamma)
- device_create_file(par->info->dev, &gamma_device_attrs[0]);
+ device_create_file(dev, &gamma_device_attrs[0]);
}
void fbtft_sysfs_exit(struct fbtft_par *par)
{
- device_remove_file(par->info->dev, &debug_device_attr);
+ struct device *dev;
+
+ dev = dev_of_fbinfo(par->info);
+ if (!dev)
+ return;
+
+ device_remove_file(dev, &debug_device_attr);
if (par->gamma.curves && par->fbtftops.set_gamma)
- device_remove_file(par->info->dev, &gamma_device_attrs[0]);
+ device_remove_file(dev, &gamma_device_attrs[0]);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
Add dev_of_fbinfo() to return the framebuffer struct device when
CONFIG_FB_DEVICE is enabled, or NULL otherwise.
This allows fbdev drivers to use sysfs interfaces via runtime checks
instead of CONFIG_FB_DEVICE ifdefs, keeping the code clean while
remaining fully buildable.
Suggested-by: Helge Deller <deller@gmx.de>
Reviewed-by: Helge Deller <deller@gmx.de>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
include/linux/fb.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 05cc251035da..dad3fb61a06a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -628,6 +628,15 @@ static inline void unlock_fb_info(struct fb_info *info)
mutex_unlock(&info->lock);
}
+static inline struct device *dev_of_fbinfo(const struct fb_info *info)
+{
+#ifdef CONFIG_FB_DEVICE
+ return info->dev;
+#else
+ return NULL;
+#endif
+}
+
static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
u8 *src, u32 s_pitch, u32 height)
{
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/4] fbdev: Make CONFIG_FB_DEVICE optional for drivers
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
This series makes CONFIG_FB_DEVICE optional for fbdev drivers that use
it only for sysfs interfaces, addressing Thomas Zimmermann’s TODO to
remove hard FB_DEVICE dependencies.
The series introduces a small helper, dev_of_fbinfo(), which returns
NULL when CONFIG_FB_DEVICE=n. This allows sysfs code paths to be skipped
via runtime checks, avoids #ifdef CONFIG_FB_DEVICE clutter, and keeps
full compile-time syntax checking.
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
Changes in v4:
- PTR_IF() was removed and overlay sysfs is now optional via __maybe_unused
and #ifdef CONFIG_FB_DEVICE (suggested by Helge Deller)
- Decouple variable definition and assignment in
omapfb_remove/create_sysfs (suggested by Andy Shevchenko)
- Added Reviewed-by tags:
- fb: Add dev_of_fbinfo(): Helge Deller, Andy Shevchenko
- staging: fbtft: Helge Deller
Changes in v3:
- Use PTR_IF() to conditionally include overlay_sysfs_group in
overlay_sysfs_groups(suggested by Andy Shevchenko)
- Decouple variable definition and assignment in
fbtft_sysfs_init/exit(suggested by Andy Shevchenko)
Changes in v2:
- Add dev_of_fbinfo() helper (suggested by Helge Deller)
- Replace #ifdef CONFIG_FB_DEVICE blocks with runtime NULL checks
- Switch to fb_dbg() / fb_info() logging (suggested by Thomas Zimmermann)
---
Chintan Patel (4):
fb: Add dev_of_fbinfo() helper for optional sysfs support
staging: fbtft: Make FB_DEVICE dependency optional
fbdev: omapfb: Make FB_DEVICE dependency optional
fbdev: sh_mobile_lcdc: Make FB_DEVICE dependency optional
drivers/staging/fbtft/Kconfig | 5 ++++-
drivers/staging/fbtft/fbtft-sysfs.c | 20 +++++++++++++++----
drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 +++++++++++++----
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 ++++-
include/linux/fb.h | 9 +++++++++
6 files changed, 49 insertions(+), 11 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Finn Thain @ 2026-01-06 22:16 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Geert Uytterhoeven, Helge Deller, Greg Kroah-Hartman,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
linux-fbdev, dri-devel, linux-kernel, linux-sh, linux-m68k
In-Reply-To: <dda4052e-b843-43fa-850c-a1bb20e4a8e3@kernel.org>
On Tue, 6 Jan 2026, Vincent Mailhol wrote:
> >
> > MACH_IS_MAC can be a runtime check.
>
> OK. I missed this.
>
You can use "qemu-system-m68k -M q800 ..." to run the code you're
interested in.
$ qemu-system-m68k -M q800 -g 800x600x16
qemu-system-m68k: unknown display mode: width 800, height 600, depth 16
Available modes:
640x480x1
640x480x2
640x480x4
640x480x8
640x480x24
800x600x1
800x600x2
800x600x4
800x600x8
800x600x24
1152x870x1
1152x870x2
1152x870x4
1152x870x8
^ permalink raw reply
* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Vincent Mailhol @ 2026-01-06 20:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Helge Deller, Greg Kroah-Hartman, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-fbdev, dri-devel, linux-kernel,
linux-sh, linux-m68k
In-Reply-To: <CAMuHMdVy48F5HAfqfJgbY83KDAztb9YWTqm8mT1ntTfj0311oA@mail.gmail.com>
On 06/01/2026 at 12:48, Geert Uytterhoeven wrote:
> Hi Vincent,
>
> CC linux-m68k
>
> Thanks for your patch, which is now commit bd710b3da7308cb1
> ("video/logo: move logo selection logic to Kconfig") in fbdev/for-next.
>
> On Thu, 1 Jan 2026 at 16:26, Vincent Mailhol <mailhol@kernel.org> wrote:
>> Now that the path to the logo file can be directly entered in Kbuild,
>> there is no more need to handle all the logo file selection in the
>> Makefile and the C files.
>
> This may do the wrong thing when booting a multi-platform kernel.
>
>>
>> The only exception is the logo_spe_clut224 which is only used by the
>> Cell processor (found for example in the Playstation 3) [1]. This
>> extra logo uses its own different image which shows up on a separate
>> line just below the normal logo. Because the extra logo uses a
>> different image, it can not be factorized under the custom logo logic.
>>
>> Move all the logo file selection logic to Kbuild (except from the
>> logo_spe_clut224.ppm), this done, clean-up the C code to only leave
>> one entry for each logo type (monochrome, 16-colors and 224-colors).
>>
>> [1] Cell SPE logos
>> Link: https://lore.kernel.org/all/20070710122702.765654000@pademelon.sonytel.be/
>>
>> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
>
>> --- a/drivers/video/logo/Kconfig
>> +++ b/drivers/video/logo/Kconfig
>
>> @@ -61,6 +63,12 @@ config LOGO_LINUX_CLUT224
>> config LOGO_LINUX_CLUT224_FILE
>> string "224-color logo .ppm file"
>> depends on LOGO_LINUX_CLUT224
>> + default "drivers/video/logo/logo_dec_clut224.ppm" if MACH_DECSTATION || ALPHA
>> + default "drivers/video/logo/logo_mac_clut224.ppm" if MAC
>
> E.g. an m68k multi-platform kernel including Mac support will scare
> non-Mac users into thinking their machine was assimilated by the
> Apple Empire...
>
>> + default "drivers/video/logo/logo_parisc_clut224.ppm" if PARISC
>> + default "drivers/video/logo/logo_sgi_clut224.ppm" if SGI_IP22 || SGI_IP27 || SGI_IP32
>> + default "drivers/video/logo/logo_sun_clut224.ppm" if SPARC
>> + default "drivers/video/logo/logo_superh_clut224.ppm" if SUPERH
>> default "drivers/video/logo/logo_linux_clut224.ppm"
>> help
>> Takes a path to a 224-color logo in the portable pixmap file
>
>> --- a/drivers/video/logo/logo.c
>> +++ b/drivers/video/logo/logo.c
>> @@ -48,59 +48,21 @@ const struct linux_logo * __ref fb_find_logo(int depth)
>> if (nologo || logos_freed)
>> return NULL;
>>
>> - if (depth >= 1) {
>> #ifdef CONFIG_LOGO_LINUX_MONO
>> - /* Generic Linux logo */
>> + if (depth >= 1)
>> logo = &logo_linux_mono;
>> #endif
>> -#ifdef CONFIG_LOGO_SUPERH_MONO
>> - /* SuperH Linux logo */
>> - logo = &logo_superh_mono;
>> -#endif
>> - }
>>
>> - if (depth >= 4) {
>> #ifdef CONFIG_LOGO_LINUX_VGA16
>> - /* Generic Linux logo */
>> + if (depth >= 4)
>> logo = &logo_linux_vga16;
>> #endif
>> -#ifdef CONFIG_LOGO_SUPERH_VGA16
>> - /* SuperH Linux logo */
>> - logo = &logo_superh_vga16;
>> -#endif
>> - }
>>
>> - if (depth >= 8) {
>> #ifdef CONFIG_LOGO_LINUX_CLUT224
>> - /* Generic Linux logo */
>> + if (depth >= 8)
>> logo = &logo_linux_clut224;
>> #endif
>> -#ifdef CONFIG_LOGO_DEC_CLUT224
>> - /* DEC Linux logo on MIPS/MIPS64 or ALPHA */
>> - logo = &logo_dec_clut224;
>> -#endif
>> -#ifdef CONFIG_LOGO_MAC_CLUT224
>> - /* Macintosh Linux logo on m68k */
>> - if (MACH_IS_MAC)
>
> MACH_IS_MAC can be a runtime check.
OK. I missed this.
I think there are two options to fix this:
1. Keep CONFIG_LOGO_MAC_CLUT224 untouched
2. Remove logo_mac_clut224.ppm
The first option is less controversial but I would like to ask you what
you think about removing the logo_mac_clut224 file.
Here, we are speaking of the Macintosh 68k which ended sales in 1995,
right? So the user base should be rather small, I guess.
And people who still want the custom MAC logo would still be able to add
CONFIG_LOGO_MAC_CLUT224="path/to/logo_mac_clut224.ppm"
to their config to restore the old behaviour anyway.
My choice would go more toward the removal option but what do you think?
>> - logo = &logo_mac_clut224;
>> -#endif
>> -#ifdef CONFIG_LOGO_PARISC_CLUT224
>> - /* PA-RISC Linux logo */
>> - logo = &logo_parisc_clut224;
>> -#endif
>> -#ifdef CONFIG_LOGO_SGI_CLUT224
>> - /* SGI Linux logo on MIPS/MIPS64 */
>> - logo = &logo_sgi_clut224;
>> -#endif
>> -#ifdef CONFIG_LOGO_SUN_CLUT224
>> - /* Sun Linux logo */
>> - logo = &logo_sun_clut224;
>> -#endif
>> -#ifdef CONFIG_LOGO_SUPERH_CLUT224
>> - /* SuperH Linux logo */
>> - logo = &logo_superh_clut224;
>> -#endif
>> - }
>> +
>> return logo;
>> }
>> EXPORT_SYMBOL_GPL(fb_find_logo);
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Daniel Palmer @ 2026-01-06 12:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vincent Mailhol, Helge Deller, Greg Kroah-Hartman, Yoshinori Sato,
Rich Felker, John Paul Adrian Glaubitz, linux-fbdev, dri-devel,
linux-kernel, linux-sh, linux-m68k
In-Reply-To: <CAMuHMdVy48F5HAfqfJgbY83KDAztb9YWTqm8mT1ntTfj0311oA@mail.gmail.com>
On Tue, 6 Jan 2026 at 20:54, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> E.g. an m68k multi-platform kernel including Mac support will scare
> non-Mac users into thinking their machine was assimilated by the
> Apple Empire...
>
This is actually how I tell if my Amiga or Mac is currently connected
to my monitor... Amiga has the normal tux, Mac has the tux inside of a
monitor.
^ permalink raw reply
* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Geert Uytterhoeven @ 2026-01-06 11:48 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Helge Deller, Greg Kroah-Hartman, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-fbdev, dri-devel, linux-kernel,
linux-sh, linux-m68k
In-Reply-To: <20260101-custom-logo-v2-6-8eec06dfbf85@kernel.org>
Hi Vincent,
CC linux-m68k
Thanks for your patch, which is now commit bd710b3da7308cb1
("video/logo: move logo selection logic to Kconfig") in fbdev/for-next.
On Thu, 1 Jan 2026 at 16:26, Vincent Mailhol <mailhol@kernel.org> wrote:
> Now that the path to the logo file can be directly entered in Kbuild,
> there is no more need to handle all the logo file selection in the
> Makefile and the C files.
This may do the wrong thing when booting a multi-platform kernel.
>
> The only exception is the logo_spe_clut224 which is only used by the
> Cell processor (found for example in the Playstation 3) [1]. This
> extra logo uses its own different image which shows up on a separate
> line just below the normal logo. Because the extra logo uses a
> different image, it can not be factorized under the custom logo logic.
>
> Move all the logo file selection logic to Kbuild (except from the
> logo_spe_clut224.ppm), this done, clean-up the C code to only leave
> one entry for each logo type (monochrome, 16-colors and 224-colors).
>
> [1] Cell SPE logos
> Link: https://lore.kernel.org/all/20070710122702.765654000@pademelon.sonytel.be/
>
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> --- a/drivers/video/logo/Kconfig
> +++ b/drivers/video/logo/Kconfig
> @@ -61,6 +63,12 @@ config LOGO_LINUX_CLUT224
> config LOGO_LINUX_CLUT224_FILE
> string "224-color logo .ppm file"
> depends on LOGO_LINUX_CLUT224
> + default "drivers/video/logo/logo_dec_clut224.ppm" if MACH_DECSTATION || ALPHA
> + default "drivers/video/logo/logo_mac_clut224.ppm" if MAC
E.g. an m68k multi-platform kernel including Mac support will scare
non-Mac users into thinking their machine was assimilated by the
Apple Empire...
> + default "drivers/video/logo/logo_parisc_clut224.ppm" if PARISC
> + default "drivers/video/logo/logo_sgi_clut224.ppm" if SGI_IP22 || SGI_IP27 || SGI_IP32
> + default "drivers/video/logo/logo_sun_clut224.ppm" if SPARC
> + default "drivers/video/logo/logo_superh_clut224.ppm" if SUPERH
> default "drivers/video/logo/logo_linux_clut224.ppm"
> help
> Takes a path to a 224-color logo in the portable pixmap file
> --- a/drivers/video/logo/logo.c
> +++ b/drivers/video/logo/logo.c
> @@ -48,59 +48,21 @@ const struct linux_logo * __ref fb_find_logo(int depth)
> if (nologo || logos_freed)
> return NULL;
>
> - if (depth >= 1) {
> #ifdef CONFIG_LOGO_LINUX_MONO
> - /* Generic Linux logo */
> + if (depth >= 1)
> logo = &logo_linux_mono;
> #endif
> -#ifdef CONFIG_LOGO_SUPERH_MONO
> - /* SuperH Linux logo */
> - logo = &logo_superh_mono;
> -#endif
> - }
>
> - if (depth >= 4) {
> #ifdef CONFIG_LOGO_LINUX_VGA16
> - /* Generic Linux logo */
> + if (depth >= 4)
> logo = &logo_linux_vga16;
> #endif
> -#ifdef CONFIG_LOGO_SUPERH_VGA16
> - /* SuperH Linux logo */
> - logo = &logo_superh_vga16;
> -#endif
> - }
>
> - if (depth >= 8) {
> #ifdef CONFIG_LOGO_LINUX_CLUT224
> - /* Generic Linux logo */
> + if (depth >= 8)
> logo = &logo_linux_clut224;
> #endif
> -#ifdef CONFIG_LOGO_DEC_CLUT224
> - /* DEC Linux logo on MIPS/MIPS64 or ALPHA */
> - logo = &logo_dec_clut224;
> -#endif
> -#ifdef CONFIG_LOGO_MAC_CLUT224
> - /* Macintosh Linux logo on m68k */
> - if (MACH_IS_MAC)
MACH_IS_MAC can be a runtime check.
> - logo = &logo_mac_clut224;
> -#endif
> -#ifdef CONFIG_LOGO_PARISC_CLUT224
> - /* PA-RISC Linux logo */
> - logo = &logo_parisc_clut224;
> -#endif
> -#ifdef CONFIG_LOGO_SGI_CLUT224
> - /* SGI Linux logo on MIPS/MIPS64 */
> - logo = &logo_sgi_clut224;
> -#endif
> -#ifdef CONFIG_LOGO_SUN_CLUT224
> - /* Sun Linux logo */
> - logo = &logo_sun_clut224;
> -#endif
> -#ifdef CONFIG_LOGO_SUPERH_CLUT224
> - /* SuperH Linux logo */
> - logo = &logo_superh_clut224;
> -#endif
> - }
> +
> return logo;
> }
> EXPORT_SYMBOL_GPL(fb_find_logo);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] fbdev: bitblit: bound-check glyph index in bit_putcs*
From: Thorsten Leemhuis @ 2026-01-06 9:04 UTC (permalink / raw)
To: Barry K. Nathan, Vitaly Chikunov, Junjie Cao, Thomas Zimmermann,
Greg Kroah-Hartman
Cc: Peilin Ye, Daniel Vetter, Shigeru Yoshida, Simona Vetter,
Helge Deller, Zsolt Kajtar, Albin Babu Varghese, linux-fbdev,
dri-devel, linux-kernel, stable, regressions, Ben Hutchings
In-Reply-To: <ccbbf777-cf4e-4c66-856e-282dd9d61970@pobox.com>
[Top posting to make this easy processable]
TWIMC, Ben (now CCed) meanwhile reported the problem as well:
https://lore.kernel.org/all/c5a27a57597c78553bf121d09a1b45ed86dc02a8.camel@decadent.org.uk/
There he wrote
"""
This can be fixed by backporting the following commits from 5.11:
7a089ec7d77f console: Delete unused con_font_copy() callback implementations
259a252c1f4e console: Delete dummy con_font_set() and con_font_default()
callback implementations
4ee573086bd8 Fonts: Add charcount field to font_desc
4497364e5f61 parisc/sticore: Avoid hard-coding built-in font charcount
a1ac250a82a5 fbcon: Avoid using FNTCHARCNT() and hard-coded built-in
font charcount
These all apply without fuzz and builds cleanly for x86_64 and parisc64.
"""
Ciao, Thorsten
On 12/27/25 03:04, Barry K. Nathan wrote:
> On 12/26/25 4:21 AM, Vitaly Chikunov wrote:
>> Dear linux-fbdev, stable,
>>
>> On Fri, Dec 26, 2025 at 01:29:13AM +0300, Vitaly Chikunov wrote:
>>>
>>> On Mon, Oct 20, 2025 at 09:47:01PM +0800, Junjie Cao wrote:
>>>> bit_putcs_aligned()/unaligned() derived the glyph pointer from the
>>>> character value masked by 0xff/0x1ff, which may exceed the actual
>>>> font's
>>>> glyph count and read past the end of the built-in font array.
>>>> Clamp the index to the actual glyph count before computing the address.
>>>>
>>>> This fixes a global out-of-bounds read reported by syzbot.
>>>>
>>>> Reported-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>>>> Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
>>>> Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>>>> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
>>>
>>> This commit is applied to v5.10.247 and causes a regression: when
>>> switching VT with ctrl-alt-f2 the screen is blank or completely filled
>>> with angle characters, then new text is not appearing (or not visible).
>>>
>>> This commit is found with git bisect from v5.10.246 to v5.10.247:
>>>
>>> 0998a6cb232674408a03e8561dc15aa266b2f53b is the first bad commit
>>> commit 0998a6cb232674408a03e8561dc15aa266b2f53b
>>> Author: Junjie Cao <junjie.cao@intel.com>
>>> AuthorDate: 2025-10-20 21:47:01 +0800
>>> Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> CommitDate: 2025-12-07 06:08:07 +0900
>>>
>>> fbdev: bitblit: bound-check glyph index in bit_putcs*
>>>
>>> commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream.
>>>
>>> bit_putcs_aligned()/unaligned() derived the glyph pointer from
>>> the
>>> character value masked by 0xff/0x1ff, which may exceed the
>>> actual font's
>>> glyph count and read past the end of the built-in font array.
>>> Clamp the index to the actual glyph count before computing the
>>> address.
>>>
>>> This fixes a global out-of-bounds read reported by syzbot.
>>>
>>> Reported-by:
>>> syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>>> Closes: https://syzkaller.appspot.com/bug?
>>> extid=793cf822d213be1a74f2
>>> Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>>> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
>>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>
>>> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>
>>> The minimal reproducer in cli, after kernel is booted:
>>>
>>> date >/dev/tty2; chvt 2
>>>
>>> and the date does not appear.
>>>
>>> Thanks,
>>>
>>> #regzbot introduced: 0998a6cb232674408a03e8561dc15aa266b2f53b
>>>
>>>> ---
>>>> v1: https://lore.kernel.org/linux-fbdev/5d237d1a-a528-4205-
>>>> a4d8-71709134f1e1@suse.de/
>>>> v1 -> v2:
>>>> - Fix indentation and add blank line after declarations with
>>>> the .pl helper
>>>> - No functional changes
>>>>
>>>> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
>>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/
>>>> fbdev/core/bitblit.c
>>>> index 9d2e59796c3e..085ffb44c51a 100644
>>>> --- a/drivers/video/fbdev/core/bitblit.c
>>>> +++ b/drivers/video/fbdev/core/bitblit.c
>>>> @@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct
>>>> vc_data *vc, struct fb_info *info,
>>>> struct fb_image *image, u8 *buf, u8 *dst)
>>>> {
>>>> u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
>>>> + unsigned int charcnt = vc->vc_font.charcount;
>>
>> Perhaps, vc->vc_font.charcount (which is relied upon in the following
>> comparison) is not always set correctly in v5.10.247. At least two
>> commits that set vc_font.charcount are missing from v5.10.247:
>>
>> a1ac250a82a5 ("fbcon: Avoid using FNTCHARCNT() and hard-coded
>> built-in font charcount")
>> a5a923038d70 ("fbdev: fbcon: Properly revert changes when
>> vc_resize() failed")
>>
>> Thanks,
>
> I was just about to report this.
>
> I found two ways to fix this bug. One is to revert this patch; the other
> is to apply the following 3 patches, which are already present in 5.11
> and later:
>
> 7a089ec7d77fe7d50f6bb7b178fa25eec9fd822b
> console: Delete unused con_font_copy() callback implementations
>
> 4ee573086bd88ff3060dda07873bf755d332e9ba
> Fonts: Add charcount field to font_desc
>
> a1ac250a82a5e97db71f14101ff7468291a6aaef
> fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font
> charcount
>
> (Oh, by the way, this same regression also affects 5.4.302, and the same
> 3 patches fix the regression on 5.4 as well, once you manually fix merge
> conflicts. Maybe it would be better to backport other additional commits
> instead of fixing the merge conflicts manually, but since 5.4 is now EOL
> I didn't dig that deep.)
>
> Once these 3 patches are applied, I wonder if a5a923038d70 now becomes
> necessary for 5.10.y. For what it's worth, it applies fine and the
> resulting kernel seems to run OK in brief testing.
>
^ permalink raw reply
* Re: [PATCH v3 4/4] fbdev: sh_mobile_lcdc: Make FB_DEVICE dependency optional
From: Chintan Patel @ 2026-01-06 5:07 UTC (permalink / raw)
To: Andy Shevchenko, Helge Deller
Cc: Helge Deller, andy, linux-fbdev, linux-omap, linux-kernel,
dri-devel
In-Reply-To: <aVkWigAQWC1dZBAv@smile.fi.intel.com>
On 1/3/26 05:15, Andy Shevchenko wrote:
> On Sat, Jan 03, 2026 at 10:59:44AM +0100, Helge Deller wrote:
>> On 12/30/25 19:25, Chintan Patel wrote:
>>> On 12/30/25 00:13, Helge Deller wrote:
>
> ...
>
>>>>> -ATTRIBUTE_GROUPS(overlay_sysfs);
>>>>
>>>> Instead of replacing the ^ ATTRIBUTE_GROUPS() by the code below,
>>>> isn't it possible to just mark the overlay_sysfs_attrs[] array
>>>> _maybe_unused, and just do:
>>>> + #ifdef CONFIG_FB_DEVICE
>>>> + ATTRIBUTE_GROUPS(overlay_sysfs);
>>>> + #endif
>>>>
>>>> ?
>>>
>>> Yes, the __maybe_unused + #ifdef ATTRIBUTE_GROUPS() approach would work.
>>>
>>> I went with the PTR_IF(IS_ENABLED()) pattern because Andy suggested
>>> using PTR_IF() to conditionally include overlay_sysfs_group in
>>> overlay_sysfs_groups, and to keep .dev_groups always populated while
>>> letting the device core skip NULL groups. This avoids conditional
>>> wiring via #ifdef and keeps the code type-checked without
>>> CONFIG_FB_DEVICE.
>>> If you still prefer the simpler #ifdef ATTRIBUTE_GROUPS() approach
>>> for this driver, I can switch to that, but I wanted to follow Andy’s
>>> guidance here.
>>
>> I assume Andy will agree to my suggested approach, as it's cleaner
>> and avoids code bloat/duplication. Maybe you send out a v4 with my
>> suggested approach, then it's easier to judge... ?
>
> I'm also fine with original code. But a suggested approach would work as well
> (at least like it sounds from the above description). Ideally would be nice to
> get rid of ifdeffery completely (that's why we have PTR_IF() for), although
> it might be not so readable. TL;DR: the most readable solution is the winner.
>
Thank you both! I will send v4 with Helge's suggestion and take it from
there.
^ permalink raw reply
* Re: [PATCH v1 1/4] staging: fbtft: core: avoid large stack usage in DT init parsing
From: sun jian @ 2026-01-06 0:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andy Shevchenko, Greg Kroah-Hartman, linux-staging, linux-fbdev,
dri-devel
In-Reply-To: <aVv_w643SMuIELDE@smile.fi.intel.com>
On Tue, Jan 6, 2026 at 2:15 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Tue, Jan 06, 2026 at 01:00:33AM +0800, sun jian wrote:
>
> > Thanks for the feedback.
>
> You're welcome, but please, do not top-post!
Sorry about that - I'll use inline replies.
>
> How can you test without hardware at hand?
>
>
> I already explained in the response to the cover letter. Please, read it.
>
Given that， I will drop all the changes.
Thanks,
Sun Jian
^ permalink raw reply
* Re: [PATCH v1 1/4] staging: fbtft: core: avoid large stack usage in DT init parsing
From: Andy Shevchenko @ 2026-01-05 18:15 UTC (permalink / raw)
To: sun jian
Cc: Andy Shevchenko, Greg Kroah-Hartman, linux-staging, linux-fbdev,
dri-devel
In-Reply-To: <CABFUUZFeO51MW5n1uDp0tcwJeJvgxDRxY3rDqkj2Z-6cO23TwA@mail.gmail.com>
On Tue, Jan 06, 2026 at 01:00:33AM +0800, sun jian wrote:
> Thanks for the feedback.
You're welcome, but please, do not top-post!
> You are right: changing the DT init path from write_register() to
> fbtft_write_buf_dc() implicitly assumes "cmd byte + payload bytes" and
> does not preserve the generic write_register() semantics (e.g. regwidth /
> bus-specific handling).I only have clang/arm64 build coverage (no
> access to the actual panels),
> so I can’t provide runtime validation yet. For the remaining 3 driver-local
> patches, all affected drivers have .regwidth = 8 and the sequences are
> “1-byte command + N bytes data” (gamma/LUT). The intent was to avoid the
> huge write_reg() varargs call that triggers -Wframe-larger-than=1024.
>
> Given the lack of hardware, would you prefer one of the following?
How can you test without hardware at hand?
> 1. Drop the driver changes and instead bump -Wframe-larger-than for these
> specific objects in the Makefile as an exception; or
>
> 2. Keep the driver changes but I should provide a detailed test pattern /
> list of tested devices — if so, what level of detail would be acceptable
> (exact panel model + wiring/bus type + expected output), and is “build-only”
> ever sufficient for warning-only changes in fbtft?
>
> Happy to follow the approach you think is appropriate for this staging driver.
I already explained in the response to the cover letter. Please, read it.
> On Tue, Jan 6, 2026 at 12:28 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Sun, Jan 04, 2026 at 07:06:35PM +0800, Sun Jian wrote:
> > > Clang reports a large stack frame for fbtft_init_display_from_property()
> > > (-Wframe-larger-than=1024) when the init sequence is emitted through a
> > > fixed 64-argument write_register() call.
> > >
> > > write_reg()/write_register() relies on NUMARGS((int[]){...}) and large
> > > varargs which inflates stack usage. Switch the DT "init" path to send the
> > > command byte and the payload via fbtft_write_buf_dc() instead.
> > >
> > > No functional change intended: the same register values are sent in the
> > > same order, only the transport is changed.
> >
> > How did you test this?
...
> > > - par->fbtftops.write_register(par, i,
> > > - buf[0], buf[1], buf[2], buf[3],
> > > - buf[4], buf[5], buf[6], buf[7],
> > > - buf[8], buf[9], buf[10], buf[11],
> > > - buf[12], buf[13], buf[14], buf[15],
> > > - buf[16], buf[17], buf[18], buf[19],
> > > - buf[20], buf[21], buf[22], buf[23],
> > > - buf[24], buf[25], buf[26], buf[27],
> > > - buf[28], buf[29], buf[30], buf[31],
> > > - buf[32], buf[33], buf[34], buf[35],
> > > - buf[36], buf[37], buf[38], buf[39],
> > > - buf[40], buf[41], buf[42], buf[43],
> > > - buf[44], buf[45], buf[46], buf[47],
> > > - buf[48], buf[49], buf[50], buf[51],
> > > - buf[52], buf[53], buf[54], buf[55],
> > > - buf[56], buf[57], buf[58], buf[59],
> > > - buf[60], buf[61], buf[62], buf[63]);
> > > + /* buf[0] is command, buf[1..i-1] is data */
> > > + ret = fbtft_write_buf_dc(par, &buf[0], 1, 0);
> > > + if (ret < 0)
> > > + goto out_free;
> > > +
> > > + if (i > 1) {
> > > + ret = fbtft_write_buf_dc(par, &buf[1], i - 1, 1);
> > > + if (ret < 0)
> > > + goto out_free;
> > > + }
> >
> > I believe this is incorrect change and has not to be applied. write !=
> > write_register. Without any evidence of testing, definite NAK to it.
> > Otherwise, please provide detailed testing pattern and which devices were
> > tested.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/4] staging: fbtft: core: avoid large stack usage in DT init parsing
From: sun jian @ 2026-01-05 17:00 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andy Shevchenko, Greg Kroah-Hartman, linux-staging, linux-fbdev,
dri-devel
In-Reply-To: <aVvmr2qOrFvoEKGV@smile.fi.intel.com>
Hi Andy,
Thanks for the feedback.
You are right: changing the DT init path from write_register() to
fbtft_write_buf_dc() implicitly assumes "cmd byte + payload bytes" and
does not preserve the generic write_register() semantics (e.g. regwidth /
bus-specific handling).I only have clang/arm64 build coverage (no
access to the actual panels),
so I can’t provide runtime validation yet. For the remaining 3 driver-local
patches, all affected drivers have .regwidth = 8 and the sequences are
“1-byte command + N bytes data” (gamma/LUT). The intent was to avoid the
huge write_reg() varargs call that triggers -Wframe-larger-than=1024.
Given the lack of hardware, would you prefer one of the following?
1. Drop the driver changes and instead bump -Wframe-larger-than for these
specific objects in the Makefile as an exception; or
2. Keep the driver changes but I should provide a detailed test pattern /
list of tested devices — if so, what level of detail would be acceptable
(exact panel model + wiring/bus type + expected output), and is “build-only”
ever sufficient for warning-only changes in fbtft?
Happy to follow the approach you think is appropriate for this staging driver.
Best regards,
Sun Jian
On Tue, Jan 6, 2026 at 12:28 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Sun, Jan 04, 2026 at 07:06:35PM +0800, Sun Jian wrote:
> > Clang reports a large stack frame for fbtft_init_display_from_property()
> > (-Wframe-larger-than=1024) when the init sequence is emitted through a
> > fixed 64-argument write_register() call.
> >
> > write_reg()/write_register() relies on NUMARGS((int[]){...}) and large
> > varargs which inflates stack usage. Switch the DT "init" path to send the
> > command byte and the payload via fbtft_write_buf_dc() instead.
> >
> > No functional change intended: the same register values are sent in the
> > same order, only the transport is changed.
>
> How did you test this?
>
> ...
>
> > struct device *dev = par->info->device;
> > - int buf[64], count, index, i, j, ret;
> > + u8 buf[64];
> > + int count, index, i, j, ret;
>
> Please, try to preserve reversed xmas tree order.
>
> > u32 *values;
> > u32 val;
> >
>
> ...
>
> > - buf[i++] = val;
> > + buf[i++] = val & 0xFF;
>
> Unneeded change, I suppose.
>
> ...
>
> > - par->fbtftops.write_register(par, i,
> > - buf[0], buf[1], buf[2], buf[3],
> > - buf[4], buf[5], buf[6], buf[7],
> > - buf[8], buf[9], buf[10], buf[11],
> > - buf[12], buf[13], buf[14], buf[15],
> > - buf[16], buf[17], buf[18], buf[19],
> > - buf[20], buf[21], buf[22], buf[23],
> > - buf[24], buf[25], buf[26], buf[27],
> > - buf[28], buf[29], buf[30], buf[31],
> > - buf[32], buf[33], buf[34], buf[35],
> > - buf[36], buf[37], buf[38], buf[39],
> > - buf[40], buf[41], buf[42], buf[43],
> > - buf[44], buf[45], buf[46], buf[47],
> > - buf[48], buf[49], buf[50], buf[51],
> > - buf[52], buf[53], buf[54], buf[55],
> > - buf[56], buf[57], buf[58], buf[59],
> > - buf[60], buf[61], buf[62], buf[63]);
> > + /* buf[0] is command, buf[1..i-1] is data */
> > + ret = fbtft_write_buf_dc(par, &buf[0], 1, 0);
> > + if (ret < 0)
> > + goto out_free;
> > +
> > + if (i > 1) {
> > + ret = fbtft_write_buf_dc(par, &buf[1], i - 1, 1);
> > + if (ret < 0)
> > + goto out_free;
> > + }
>
> I believe this is incorrect change and has not to be applied. write !=
> write_register. Without any evidence of testing, definite NAK to it.
> Otherwise, please provide detailed testing pattern and which devices were
> tested.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v1 4/4] staging: fbtft: hx8353d: send LUT via buffer to reduce stack usage
From: Andy Shevchenko @ 2026-01-05 16:36 UTC (permalink / raw)
To: Sun Jian
Cc: Andy Shevchenko, Greg Kroah-Hartman, linux-staging, linux-fbdev,
dri-devel
In-Reply-To: <20260104110638.532615-5-sun.jian.kdev@gmail.com>
On Sun, Jan 04, 2026 at 07:06:38PM +0800, Sun Jian wrote:
> Clang reports a large stack frame in init_display()
> (-Wframe-larger-than=1024) due to the very large
> write_reg(MIPI_DCS_WRITE_LUT, ...) call.
>
> Send MIPI_DCS_WRITE_LUT followed by the LUT payload using
> fbtft_write_buf_dc() to avoid the varargs/NUMARGS stack blow-up.
>
> No functional change intended.
...
> +static const u8 lut[] = {
> + 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30,
> + 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62,
> + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
> + 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
> + 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
> + 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
> + 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30,
> + 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62,
> + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
> + 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
> + 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
> + 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
Two tabs too many on each line.
> + };
> +
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 0/4] staging: fbtft: reduce stack usage by avoiding large write_reg() varargs
From: Andy Shevchenko @ 2026-01-05 16:32 UTC (permalink / raw)
To: Sun Jian
Cc: Andy Shevchenko, Greg Kroah-Hartman, linux-staging, linux-fbdev,
dri-devel
In-Reply-To: <20260104110638.532615-1-sun.jian.kdev@gmail.com>
On Sun, Jan 04, 2026 at 07:06:34PM +0800, Sun Jian wrote:
> This series fixes clang `-Wframe-larger-than=1024` warnings in the fbtft
> staging drivers.
>
> The warnings are triggered by very large `write_reg()`/`write_register()`
> varargs calls, which result in excessive stack usage.
>
> Switch the affected paths to send a u8 command byte followed by the u8
> payload using `fbtft_write_buf_dc()`. The register values and ordering are
> kept unchanged; only the transfer method is updated.
Looking at the patches I think this is wrong. W.o. detailed test pattern
provided and the list of the devices, NAK.
If you want to address a warning without HW being accessible, perhaps you just
need a simple bump in the Makefile as an exception, however it's also doubtful
as it will hide a potential issue with the stack in the future.
--
With Best Regards,
Andy Shevchenko
^ 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