* Re: [PATCH] video/logo: don't select LOGO_LINUX_MONO and LOGO_LINUX_VGA16 by default
From: Helge Deller @ 2026-01-11 19:12 UTC (permalink / raw)
To: Vincent Mailhol; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260110-mono_and_vga16_logos_default_to_no-v1-1-30f36da979b4@kernel.org>
On 1/10/26 13:23, Vincent Mailhol wrote:
> Nowadays, nearly all systems have a color depth of eight or more and
> are thus able to display the clut224 logo. This means that the
> monochrome and vga16 logos will never be displayed on an average
> machine and are thus just a waste of bytes.
>
> Set CONFIG_LOGO_LINUX_MONO and CONFIG_LOGO_LINUX_VGA16 configuration
> symbols to no by default.
I agree, that on basically every system today there is no need for the
monochrome or VGA16 logo.
But I'm not sure about the historic/exotic platforms, e.g. m68, sparc
and so on.
So, maybe instead of dropping the default "y", we should e.g. do:
+ default y if SUPERH
+ default y if XYZ (some other architecture/platform) ???
+ default n (for all others)
The question is: Which arches may have needed the VGA16 or monochrome logo?
Helge
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> To be applied on top of my previous "video/logo: allow custom boot
> logo and simplify logic" series:
>
> Link: https://lore.kernel.org/all/20260108-custom-logo-v3-0-5a7aada7a6d4@kernel.org/
> ---
> drivers/video/logo/Kconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/logo/Kconfig b/drivers/video/logo/Kconfig
> index 34ee207e5e77..cda15b95891e 100644
> --- a/drivers/video/logo/Kconfig
> +++ b/drivers/video/logo/Kconfig
> @@ -20,7 +20,6 @@ config FB_LOGO_EXTRA
>
> config LOGO_LINUX_MONO
> bool "Standard black and white Linux logo"
> - default y
>
> config LOGO_LINUX_MONO_FILE
> string "Monochrome logo .pbm file"
> @@ -38,7 +37,6 @@ config LOGO_LINUX_MONO_FILE
>
> config LOGO_LINUX_VGA16
> bool "Standard 16-color Linux logo"
> - default y
>
> config LOGO_LINUX_VGA16_FILE
> string "16-color logo .ppm file"
>
> ---
> base-commit: f10c325a345fef0a688a2bcdfab1540d1c924148
> change-id: 20260110-mono_and_vga16_logos_default_to_no-fea83b350250
> prerequisite-change-id: 20251227-custom-logo-932df316a02c:v3
> prerequisite-patch-id: 5053eddfae57689a621f3224acc18742a25c2887
> prerequisite-patch-id: 2fd02272fb8f94575c67124366f58811dcceb6ad
> prerequisite-patch-id: 81d5632ac8717a56b335bb356e8fe5d9e8b1639f
> prerequisite-patch-id: 268d8fb7ce93d0cb137c32b6f149fda376da37e8
> prerequisite-patch-id: f6229ba399af73d57a647050a8f0f6871c4a96ef
> prerequisite-patch-id: 6a6d392a9acf6eb2fe2827e3beebbc4b341f50a5
> prerequisite-patch-id: 359180711835dc73be129380a5664210e19d50f1
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Chintan Patel @ 2026-01-11 19:51 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, gregkh
In-Reply-To: <40911dd0-52e1-46de-b060-0372988291ca@gmx.de>
On 1/11/26 10:50, Helge Deller wrote:
> On 1/7/26 05:42, Chintan Patel wrote:
>> 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(+)
>
> Whole v4 series applied to fbdev git tree.
>
Appreciate Helge and everyone who reviewed it! This was my first kernel
series and it was good learning experience for me.
^ permalink raw reply
* Re: [PATCH] video/logo: don't select LOGO_LINUX_MONO and LOGO_LINUX_VGA16 by default
From: Vincent Mailhol @ 2026-01-11 21:25 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <d48231e4-6c69-4948-99a9-121cd17e2db0@gmx.de>
On 11/01/2026 at 20:12, Helge Deller wrote:
> On 1/10/26 13:23, Vincent Mailhol wrote:
>> Nowadays, nearly all systems have a color depth of eight or more and
>> are thus able to display the clut224 logo. This means that the
>> monochrome and vga16 logos will never be displayed on an average
>> machine and are thus just a waste of bytes.
>>
>> Set CONFIG_LOGO_LINUX_MONO and CONFIG_LOGO_LINUX_VGA16 configuration
>> symbols to no by default.
>
> I agree, that on basically every system today there is no need for the
> monochrome or VGA16 logo.
> But I'm not sure about the historic/exotic platforms, e.g. m68, sparc
> and so on.
>
> So, maybe instead of dropping the default "y", we should e.g. do:
> + default y if SUPERH
SUPERH also has a clut224 logo, so I assume we can also default to no
for it.
> + default y if XYZ (some other architecture/platform) ???
> + default n (for all others)
>
> The question is: Which arches may have needed the VGA16 or monochrome logo?
My wild guess would be none. Furthermore, no one "needs" a logo. It is
just a fun thing to add. This is why the LOGO sub menu is turned off by
default and that none of the defconfig would automatically select a LOGO.
And so, because a user interaction is needed anyway, the few who still
want a monochrome or vga16 logo can turn the option back on just after
selecting the LOGO sub-menu.
I guess the same could be said in reverse: we could keep all the logo on
by default as it is now and the users who only need the clut224 can turn
off the monochrome and vga16. But let's go for the majority ;)
Well, if someone can come with the list you are looking for, I will
happily add it to the patch. We can wait for a couple weeks if you want,
no rush here!
Or your can already stage it in fbdev-next and I will send you a v2 as
needed. Maybe we will get more comments if this reaches linux-next?
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Chintan Patel @ 2026-01-12 1:07 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel, kernel test robot
This fixes commit
a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
from my previous v4 series:
https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
All direct accesses to info->dev or fb_info->dev are replaced with
dev_of_fbinfo() helper, improving readability and ensuring
compilation succeeds when CONFIG_FB_DEVICE=n.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
drivers/staging/fbtft/fbtft-core.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index 8a5ccc8ae0a1..309e81d7d208 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
{
unsigned int val;
int ret = 1;
+ struct device *dev = dev_of_fbinfo(info);
- dev_dbg(info->dev,
+ dev_dbg(dev,
"%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
__func__, regno, red, green, blue, transp);
@@ -389,9 +390,10 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
static int fbtft_fb_blank(int blank, struct fb_info *info)
{
struct fbtft_par *par = info->par;
+ struct device *dev = dev_of_fbinfo(info);
int ret = -EINVAL;
- dev_dbg(info->dev, "%s(blank=%d)\n",
+ dev_dbg(dev, "%s(blank=%d)\n",
__func__, blank);
if (!par->fbtftops.blank)
@@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
char text2[50] = "";
struct fbtft_par *par = fb_info->par;
struct spi_device *spi = par->spi;
+ struct device *dev = dev_of_fbinfo(fb_info);
/* sanity checks */
if (!par->fbtftops.init_display) {
@@ -793,7 +796,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
if (spi)
sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
- dev_info(fb_info->dev,
+ dev_info(dev,
"%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
fb_info->fix.smem_len >> 10, text1,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Greg KH @ 2026-01-12 6:48 UTC (permalink / raw)
To: Chintan Patel
Cc: linux-fbdev, linux-staging, linux-omap, linux-kernel, dri-devel,
tzimmermann, andy, deller, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
On Sun, Jan 11, 2026 at 05:07:39PM -0800, Chintan Patel wrote:
> This fixes commit
> a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
>
> from my previous v4 series:
> https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
>
> All direct accesses to info->dev or fb_info->dev are replaced with
> dev_of_fbinfo() helper, improving readability and ensuring
> compilation succeeds when CONFIG_FB_DEVICE=n.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
> ---
> drivers/staging/fbtft/fbtft-core.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index 8a5ccc8ae0a1..309e81d7d208 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> {
> unsigned int val;
> int ret = 1;
> + struct device *dev = dev_of_fbinfo(info);
>
> - dev_dbg(info->dev,
> + dev_dbg(dev,
> "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
> __func__, regno, red, green, blue, transp);
>
> @@ -389,9 +390,10 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> static int fbtft_fb_blank(int blank, struct fb_info *info)
> {
> struct fbtft_par *par = info->par;
> + struct device *dev = dev_of_fbinfo(info);
> int ret = -EINVAL;
>
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> + dev_dbg(dev, "%s(blank=%d)\n",
> __func__, blank);
>
> if (!par->fbtftops.blank)
> @@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> char text2[50] = "";
> struct fbtft_par *par = fb_info->par;
> struct spi_device *spi = par->spi;
> + struct device *dev = dev_of_fbinfo(fb_info);
>
> /* sanity checks */
> if (!par->fbtftops.init_display) {
> @@ -793,7 +796,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> if (spi)
> sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
> spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
> - dev_info(fb_info->dev,
> + dev_info(dev,
> "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
> fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> fb_info->fix.smem_len >> 10, text1,
> --
> 2.43.0
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Andy Shevchenko @ 2026-01-12 7:07 UTC (permalink / raw)
To: Chintan Patel
Cc: linux-fbdev, linux-staging, linux-omap, linux-kernel, dri-devel,
tzimmermann, andy, deller, gregkh, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
On Mon, Jan 12, 2026 at 3:07 AM Chintan Patel <chintanlike@gmail.com> wrote:
> This fixes commit
> a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
Convert to be as Fixes tag instead.
> from my previous v4 series:
> https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
This is unneeded churn in the commit message, also this patch wrongly
marked as v5 that triggered Greg's bot response. You had to number it
as v1, but now please, address the above and below comments and make
it v6 with a Changelog added (explaining changes in v5 and in v6).
> All direct accesses to info->dev or fb_info->dev are replaced with
> dev_of_fbinfo() helper, improving readability and ensuring
> compilation succeeds when CONFIG_FB_DEVICE=n.
...
> @@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> {
> unsigned int val;
> int ret = 1;
> + struct device *dev = dev_of_fbinfo(info);
Try to keep it in reversed xmas tree order.
...
> static int fbtft_fb_blank(int blank, struct fb_info *info)
> {
> struct fbtft_par *par = info->par;
> + struct device *dev = dev_of_fbinfo(info);
> int ret = -EINVAL;
Ditto.
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> + dev_dbg(dev, "%s(blank=%d)\n",
> __func__, blank);
Since you are changing it anyway, make it one line.
...
> @@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> char text2[50] = "";
> struct fbtft_par *par = fb_info->par;
> struct spi_device *spi = par->spi;
> + struct device *dev = dev_of_fbinfo(fb_info);
Reversed xmas tree order (as much as it's possible with this added line).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Greg KH @ 2026-01-12 7:17 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chintan Patel, linux-fbdev, linux-staging, linux-omap,
linux-kernel, dri-devel, tzimmermann, andy, deller,
kernel test robot
In-Reply-To: <CAHp75VeF+Sj=dxA4RZAvVddGSG3brUsy8kz7mvtst2YpqNm99w@mail.gmail.com>
On Mon, Jan 12, 2026 at 09:07:42AM +0200, Andy Shevchenko wrote:
> On Mon, Jan 12, 2026 at 3:07 AM Chintan Patel <chintanlike@gmail.com> wrote:
> > - dev_dbg(info->dev, "%s(blank=%d)\n",
> > + dev_dbg(dev, "%s(blank=%d)\n",
> > __func__, blank);
>
> Since you are changing it anyway, make it one line.
Wait, why would dev_dbg() ever had __func__ added to it? That's
automatically included in the output if the user wants it, please do not
duplicate it again.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Thomas Zimmermann @ 2026-01-12 8:36 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
Hi
Am 12.01.26 um 02:07 schrieb Chintan Patel:
> This fixes commit
> a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
>
> from my previous v4 series:
> https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
>
> All direct accesses to info->dev or fb_info->dev are replaced with
> dev_of_fbinfo() helper, improving readability and ensuring
> compilation succeeds when CONFIG_FB_DEVICE=n.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
> ---
> drivers/staging/fbtft/fbtft-core.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index 8a5ccc8ae0a1..309e81d7d208 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> {
> unsigned int val;
> int ret = 1;
> + struct device *dev = dev_of_fbinfo(info);
>
> - dev_dbg(info->dev,
> + dev_dbg(dev,
> "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
> __func__, regno, red, green, blue, transp);
Rather use fb_dbg() from <linux/fb.h>. It will format the output
appropriately.
>
> @@ -389,9 +390,10 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> static int fbtft_fb_blank(int blank, struct fb_info *info)
> {
> struct fbtft_par *par = info->par;
> + struct device *dev = dev_of_fbinfo(info);
> int ret = -EINVAL;
>
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> + dev_dbg(dev, "%s(blank=%d)\n",
> __func__, blank);
>
> if (!par->fbtftops.blank)
> @@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> char text2[50] = "";
> struct fbtft_par *par = fb_info->par;
> struct spi_device *spi = par->spi;
> + struct device *dev = dev_of_fbinfo(fb_info);
>
> /* sanity checks */
> if (!par->fbtftops.init_display) {
> @@ -793,7 +796,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> if (spi)
> sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
> spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
> - dev_info(fb_info->dev,
> + dev_info(dev,
fb_info() here.
Best regards
Thomas
> "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
> fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> fb_info->fix.smem_len >> 10, text1,
--
--
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 v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: kernel test robot @ 2026-01-12 10:05 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: llvm, oe-kbuild-all, linux-kernel, dri-devel, tzimmermann, andy,
deller, gregkh, Chintan Patel, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
Hi Chintan,
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/Chintan-Patel/staging-fbtft-use-dev_of_fbinfo-instead-of-info-dev/20260112-091221
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260112010740.186248-1-chintanlike%40gmail.com
patch subject: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
config: x86_64-randconfig-005-20260112 (https://download.01.org/0day-ci/archive/20260112/202601121705.2kgxpvsS-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260112/202601121705.2kgxpvsS-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/202601121705.2kgxpvsS-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fbtft-core.c:367:23: error: call to undeclared function 'dev_of_fbinfo'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
367 | struct device *dev = dev_of_fbinfo(info);
| ^
>> drivers/staging/fbtft/fbtft-core.c:367:17: error: incompatible integer to pointer conversion initializing 'struct device *' with an expression of type 'int' [-Wint-conversion]
367 | struct device *dev = dev_of_fbinfo(info);
| ^ ~~~~~~~~~~~~~~~~~~~
drivers/staging/fbtft/fbtft-core.c:393:23: error: call to undeclared function 'dev_of_fbinfo'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
393 | struct device *dev = dev_of_fbinfo(info);
| ^
drivers/staging/fbtft/fbtft-core.c:393:17: error: incompatible integer to pointer conversion initializing 'struct device *' with an expression of type 'int' [-Wint-conversion]
393 | struct device *dev = dev_of_fbinfo(info);
| ^ ~~~~~~~~~~~~~~~~~~~
drivers/staging/fbtft/fbtft-core.c:744:23: error: call to undeclared function 'dev_of_fbinfo'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
744 | struct device *dev = dev_of_fbinfo(fb_info);
| ^
drivers/staging/fbtft/fbtft-core.c:744:17: error: incompatible integer to pointer conversion initializing 'struct device *' with an expression of type 'int' [-Wint-conversion]
744 | struct device *dev = dev_of_fbinfo(fb_info);
| ^ ~~~~~~~~~~~~~~~~~~~~~~
6 errors generated.
vim +/dev_of_fbinfo +367 drivers/staging/fbtft/fbtft-core.c
360
361 static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
362 unsigned int green, unsigned int blue,
363 unsigned int transp, struct fb_info *info)
364 {
365 unsigned int val;
366 int ret = 1;
> 367 struct device *dev = dev_of_fbinfo(info);
368
369 dev_dbg(dev,
370 "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
371 __func__, regno, red, green, blue, transp);
372
373 switch (info->fix.visual) {
374 case FB_VISUAL_TRUECOLOR:
375 if (regno < 16) {
376 u32 *pal = info->pseudo_palette;
377
378 val = chan_to_field(red, &info->var.red);
379 val |= chan_to_field(green, &info->var.green);
380 val |= chan_to_field(blue, &info->var.blue);
381
382 pal[regno] = val;
383 ret = 0;
384 }
385 break;
386 }
387 return ret;
388 }
389
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 1/4] staging: sm750fb: Convert sw_i2c_read_sda to return bool
From: Karthikey Kadati @ 2026-01-12 10:25 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Karthikey Kadati,
Unix Antigravity
The sw_i2c_read_sda function currently returns unsigned char (1 or 0).
Standardize it to return bool (true or false) to match kernel standards.
Signed-off-by: Unix Antigravity <unix.antigravity@test.com>
Signed-off-by: Karthikey Kadati <karthikey3608@gmail.com>
---
drivers/staging/sm750fb/ddk750_swi2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index 0ef8d4ff2..9d48673d3 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -180,7 +180,7 @@ static void sw_i2c_sda(unsigned char value)
* Return Value:
* The SDA data bit sent by the Slave
*/
-static unsigned char sw_i2c_read_sda(void)
+static bool sw_i2c_read_sda(void)
{
unsigned long gpio_dir;
unsigned long gpio_data;
@@ -196,9 +196,9 @@ static unsigned char sw_i2c_read_sda(void)
/* Now read the SDA line */
gpio_data = peek32(sw_i2c_data_gpio_data_reg);
if (gpio_data & (1 << sw_i2c_data_gpio))
- return 1;
+ return true;
else
- return 0;
+ return false;
}
/*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/4] staging: sm750fb: Convert sw_i2c_read_sda to return bool
From: Greg KH @ 2026-01-12 10:31 UTC (permalink / raw)
To: Karthikey Kadati
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel, Unix Antigravity
In-Reply-To: <20260112102502.19761-1-karthikey3608@gmail.com>
On Mon, Jan 12, 2026 at 03:55:02PM +0530, Karthikey Kadati wrote:
> The sw_i2c_read_sda function currently returns unsigned char (1 or 0).
>
> Standardize it to return bool (true or false) to match kernel standards.
>
> Signed-off-by: Unix Antigravity <unix.antigravity@test.com>
You have to be a legal person to sign off on a patch, with a valid email
address :(
Also, your patches were a patch series, but not connected to each other,
nor were they related. I see them in my inbox as:
1 T Jan 12 Karthikey Kadat (2.0K) [PATCH 4/4] staging: atomisp: Replace ia_css_region with v4l2_rect
2 T Jan 12 Karthikey Kadat (2.4K) [PATCH 2/4] staging: octeon: Remove port status typedefs
3 T Jan 12 Karthikey Kadat (9.1K) [PATCH 3/4] staging: atomisp: Remove input_system typedefs
4 T Jan 12 Karthikey Kadat (1.1K) [PATCH 1/4] staging: sm750fb: Convert sw_i2c_read_sda to return bool
But not threaded, so that's a bit odd. Perhaps you didn't use git
send-email for these?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] staging: sm750fb: Convert sw_i2c_read_sda to return bool
From: Karthikey Kadati @ 2026-01-12 10:38 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Karthikey Kadati
The sw_i2c_read_sda function currently returns unsigned char (1 or 0).
Standardize it to return bool (true or false) to match kernel standards.
Signed-off-by: Karthikey Kadati <karthikey3608@gmail.com>
---
drivers/staging/sm750fb/ddk750_swi2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index 0ef8d4ff2..9d48673d3 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -180,7 +180,7 @@ static void sw_i2c_sda(unsigned char value)
* Return Value:
* The SDA data bit sent by the Slave
*/
-static unsigned char sw_i2c_read_sda(void)
+static bool sw_i2c_read_sda(void)
{
unsigned long gpio_dir;
unsigned long gpio_data;
@@ -196,9 +196,9 @@ static unsigned char sw_i2c_read_sda(void)
/* Now read the SDA line */
gpio_data = peek32(sw_i2c_data_gpio_data_reg);
if (gpio_data & (1 << sw_i2c_data_gpio))
- return 1;
+ return true;
else
- return 0;
+ return false;
}
/*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] staging: sm750fb: Convert sw_i2c_read_sda to return bool
From: Greg KH @ 2026-01-12 10:49 UTC (permalink / raw)
To: Karthikey Kadati
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260112103838.22890-1-karthikey3608@gmail.com>
On Mon, Jan 12, 2026 at 04:08:38PM +0530, Karthikey Kadati wrote:
> The sw_i2c_read_sda function currently returns unsigned char (1 or 0).
>
> Standardize it to return bool (true or false) to match kernel standards.
>
> Signed-off-by: Karthikey Kadati <karthikey3608@gmail.com>
> ---
> drivers/staging/sm750fb/ddk750_swi2c.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
> index 0ef8d4ff2..9d48673d3 100644
> --- a/drivers/staging/sm750fb/ddk750_swi2c.c
> +++ b/drivers/staging/sm750fb/ddk750_swi2c.c
> @@ -180,7 +180,7 @@ static void sw_i2c_sda(unsigned char value)
> * Return Value:
> * The SDA data bit sent by the Slave
> */
> -static unsigned char sw_i2c_read_sda(void)
> +static bool sw_i2c_read_sda(void)
> {
> unsigned long gpio_dir;
> unsigned long gpio_data;
> @@ -196,9 +196,9 @@ static unsigned char sw_i2c_read_sda(void)
> /* Now read the SDA line */
> gpio_data = peek32(sw_i2c_data_gpio_data_reg);
> if (gpio_data & (1 << sw_i2c_data_gpio))
> - return 1;
> + return true;
> else
> - return 0;
> + return false;
> }
>
> /*
> --
> 2.43.0
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* [PATCH] fbdev: vt8500lcdfb: fix missing dma_free_coherent()
From: Thomas Fourier @ 2026-01-12 14:00 UTC (permalink / raw)
Cc: Thomas Fourier, stable, Alexey Charkov, Krzysztof Kozlowski,
Helge Deller, Tony Prisk, linux-arm-kernel, linux-fbdev,
dri-devel, linux-kernel
fbi->fb.screen_buffer is alloced with dma_free_coherent() but is not
freed if the error path is reached.
Fixes: e7b995371fe1 ("video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
---
drivers/video/fbdev/vt8500lcdfb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c
index b08a6fdc53fd..85c7a99a7d64 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -369,7 +369,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
if (fbi->palette_cpu == NULL) {
dev_err(&pdev->dev, "Failed to allocate palette buffer\n");
ret = -ENOMEM;
- goto failed_free_io;
+ goto failed_free_mem_virt;
}
irq = platform_get_irq(pdev, 0);
@@ -432,6 +432,9 @@ static int vt8500lcd_probe(struct platform_device *pdev)
failed_free_palette:
dma_free_coherent(&pdev->dev, fbi->palette_size,
fbi->palette_cpu, fbi->palette_phys);
+failed_free_mem_virt:
+ dma_free_coherent(&pdev->dev, fbi->fb.fix.smem_len,
+ fbi->fb.screen_buffer, fbi->fb.fix.smem_start);
failed_free_io:
iounmap(fbi->regbase);
failed_free_res:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] fbdev: vt8500lcdfb: fix missing dma_free_coherent()
From: Markus Elfring @ 2026-01-12 14:46 UTC (permalink / raw)
To: Thomas Fourier, linux-fbdev, dri-devel, linux-arm-kernel,
Alexey Charkov, Helge Deller, Krzysztof Kozlowski
Cc: stable, LKML
In-Reply-To: <20260112140031.63594-2-fourier.thomas@gmail.com>
> fbi->fb.screen_buffer is alloced with dma_free_coherent() but is not
allocated with a dma_alloc_coherent() call?
https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/video/fbdev/vt8500lcdfb.c#L352-L362
> freed if the error path is reached.
See also once more:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc4#n94
You should probably not only specify message recipients in the header field “Cc”.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: kernel test robot @ 2026-01-12 17:31 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: oe-kbuild-all, linux-kernel, dri-devel, tzimmermann, andy, deller,
gregkh, Chintan Patel, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
Hi Chintan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/Chintan-Patel/staging-fbtft-use-dev_of_fbinfo-instead-of-info-dev/20260112-091221
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260112010740.186248-1-chintanlike%40gmail.com
patch subject: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
config: nios2-allmodconfig (https://download.01.org/0day-ci/archive/20260113/202601130026.1M3d4LWk-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260113/202601130026.1M3d4LWk-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/202601130026.1M3d4LWk-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_fb_setcolreg':
drivers/staging/fbtft/fbtft-core.c:367:30: error: implicit declaration of function 'dev_of_fbinfo'; did you mean 'dev_info'? [-Werror=implicit-function-declaration]
367 | struct device *dev = dev_of_fbinfo(info);
| ^~~~~~~~~~~~~
| dev_info
>> drivers/staging/fbtft/fbtft-core.c:367:30: warning: initialization of 'struct device *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_fb_blank':
drivers/staging/fbtft/fbtft-core.c:393:30: warning: initialization of 'struct device *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
393 | struct device *dev = dev_of_fbinfo(info);
| ^~~~~~~~~~~~~
drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_register_framebuffer':
drivers/staging/fbtft/fbtft-core.c:744:30: warning: initialization of 'struct device *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
744 | struct device *dev = dev_of_fbinfo(fb_info);
| ^~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +367 drivers/staging/fbtft/fbtft-core.c
360
361 static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
362 unsigned int green, unsigned int blue,
363 unsigned int transp, struct fb_info *info)
364 {
365 unsigned int val;
366 int ret = 1;
> 367 struct device *dev = dev_of_fbinfo(info);
368
369 dev_dbg(dev,
370 "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
371 __func__, regno, red, green, blue, transp);
372
373 switch (info->fix.visual) {
374 case FB_VISUAL_TRUECOLOR:
375 if (regno < 16) {
376 u32 *pal = info->pseudo_palette;
377
378 val = chan_to_field(red, &info->var.red);
379 val |= chan_to_field(green, &info->var.green);
380 val |= chan_to_field(blue, &info->var.blue);
381
382 pal[regno] = val;
383 ret = 0;
384 }
385 break;
386 }
387 return ret;
388 }
389
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: kernel test robot @ 2026-01-12 18:26 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: oe-kbuild-all, linux-kernel, dri-devel, tzimmermann, andy, deller,
gregkh, Chintan Patel, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
Hi Chintan,
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/Chintan-Patel/staging-fbtft-use-dev_of_fbinfo-instead-of-info-dev/20260112-091221
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260112010740.186248-1-chintanlike%40gmail.com
patch subject: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260113/202601130116.rVB5C8Xx-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260113/202601130116.rVB5C8Xx-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/202601130116.rVB5C8Xx-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_fb_setcolreg':
>> drivers/staging/fbtft/fbtft-core.c:367:30: error: implicit declaration of function 'dev_of_fbinfo'; did you mean 'dev_info'? [-Wimplicit-function-declaration]
367 | struct device *dev = dev_of_fbinfo(info);
| ^~~~~~~~~~~~~
| dev_info
>> drivers/staging/fbtft/fbtft-core.c:367:30: error: initialization of 'struct device *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_fb_blank':
drivers/staging/fbtft/fbtft-core.c:393:30: error: initialization of 'struct device *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
393 | struct device *dev = dev_of_fbinfo(info);
| ^~~~~~~~~~~~~
drivers/staging/fbtft/fbtft-core.c: In function 'fbtft_register_framebuffer':
drivers/staging/fbtft/fbtft-core.c:744:30: error: initialization of 'struct device *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
744 | struct device *dev = dev_of_fbinfo(fb_info);
| ^~~~~~~~~~~~~
vim +367 drivers/staging/fbtft/fbtft-core.c
360
361 static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
362 unsigned int green, unsigned int blue,
363 unsigned int transp, struct fb_info *info)
364 {
365 unsigned int val;
366 int ret = 1;
> 367 struct device *dev = dev_of_fbinfo(info);
368
369 dev_dbg(dev,
370 "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
371 __func__, regno, red, green, blue, transp);
372
373 switch (info->fix.visual) {
374 case FB_VISUAL_TRUECOLOR:
375 if (regno < 16) {
376 u32 *pal = info->pseudo_palette;
377
378 val = chan_to_field(red, &info->var.red);
379 val |= chan_to_field(green, &info->var.green);
380 val |= chan_to_field(blue, &info->var.blue);
381
382 pal[regno] = val;
383 ret = 0;
384 }
385 break;
386 }
387 return ret;
388 }
389
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: backlight: gpio-backlight: allow multiple GPIOs
From: tessolveupstream @ 2026-01-13 4:45 UTC (permalink / raw)
To: Daniel Thompson
Cc: lee, danielt, jingoohan1, deller, pavel, robh, krzk+dt, conor+dt,
dri-devel, linux-fbdev, linux-leds, devicetree, linux-kernel
In-Reply-To: <aVuKdAyXfWLs-WJI@aspen.lan>
On 05-01-2026 15:25, Daniel Thompson wrote:
> On Mon, Jan 05, 2026 at 02:21:19PM +0530, Sudarshan Shetty wrote:
>> Update the gpio-backlight binding to support configurations that require
>> more than one GPIO for enabling/disabling the backlight.
>>
>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
>> ---
>> .../bindings/leds/backlight/gpio-backlight.yaml | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
>> index 584030b6b0b9..1483ce4a3480 100644
>> --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
>> +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml
>> @@ -17,7 +17,8 @@ properties:
>>
>> gpios:
>> description: The gpio that is used for enabling/disabling the backlight.
>> - maxItems: 1
>> + minItems: 1
>> + maxItems: 2
>
> Why 2?
>
In the current design, the LVDS panel has a single backlight that
is controlled by two GPIOs. Initially, It described as two separate
backlight devices using the same gpio-backlight driver, since the
existing driver supports only one GPIO per instance.
So the maintainer suggested to extend the gpio-backlight driver
and bindings to support multiple GPIOs.
https://lore.kernel.org/all/q63bdon55app4gb2il5e7skyc6z2amcnaiqbqlhen7arkxphtb@3jejbelji2ti/
>
> Daniel.
^ permalink raw reply
* [PATCH v6] staging: fbtft: Use fbdev logging helpers when FB_DEVICE is disabled
From: Chintan Patel @ 2026-01-13 4:59 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel, kernel test robot
Replace direct accesses to info->dev with fb_dbg() and fb_info()
helpers to avoid build failures when CONFIG_FB_DEVICE=n.
Fixes: a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Changes in v6:
- Switch debug/info logging to fb_dbg() and fb_info()(suggested by Thomas Zimmermann)
- Drop dev_of_fbinfo() usage in favor of framebuffer helpers that implicitly
handle the debug/info context.
- Drop __func__ usage per review feedback(suggested by greg k-h)
- Add Fixes tag for a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
(suggested by Andy Shevchenko)
Changes in v5:
- Initial attempt to replace info->dev accesses using
dev_of_fbinfo() helper
---
drivers/staging/fbtft/fbtft-core.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index 8a5ccc8ae0a1..1b3b62950205 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -365,9 +365,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
unsigned int val;
int ret = 1;
- dev_dbg(info->dev,
- "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
- __func__, regno, red, green, blue, transp);
+ fb_dbg(info,
+ "regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X\n",
+ regno, red, green, blue, transp);
switch (info->fix.visual) {
case FB_VISUAL_TRUECOLOR:
@@ -391,8 +391,7 @@ static int fbtft_fb_blank(int blank, struct fb_info *info)
struct fbtft_par *par = info->par;
int ret = -EINVAL;
- dev_dbg(info->dev, "%s(blank=%d)\n",
- __func__, blank);
+ fb_dbg(info, "blank=%d\n", blank);
if (!par->fbtftops.blank)
return ret;
@@ -793,11 +792,11 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
if (spi)
sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
- dev_info(fb_info->dev,
- "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
- fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
- fb_info->fix.smem_len >> 10, text1,
- HZ / fb_info->fbdefio->delay, text2);
+ fb_info(fb_info,
+ "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
+ fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
+ fb_info->fix.smem_len >> 10, text1,
+ HZ / fb_info->fbdefio->delay, text2);
/* Turn on backlight if available */
if (fb_info->bl_dev) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6] staging: fbtft: Use fbdev logging helpers when FB_DEVICE is disabled
From: Greg KH @ 2026-01-13 6:16 UTC (permalink / raw)
To: Chintan Patel
Cc: linux-fbdev, linux-staging, linux-omap, linux-kernel, dri-devel,
tzimmermann, andy, deller, kernel test robot
In-Reply-To: <20260113045909.336931-1-chintanlike@gmail.com>
On Mon, Jan 12, 2026 at 08:59:09PM -0800, Chintan Patel wrote:
> Replace direct accesses to info->dev with fb_dbg() and fb_info()
> helpers to avoid build failures when CONFIG_FB_DEVICE=n.
Why is there a fb_* specific logging helper? dev_info() and dev_dbg()
should be used instead.
> Fixes: a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
Is this really a bug?
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
>
> Changes in v6:
> - Switch debug/info logging to fb_dbg() and fb_info()(suggested by Thomas Zimmermann)
> - Drop dev_of_fbinfo() usage in favor of framebuffer helpers that implicitly
> handle the debug/info context.
> - Drop __func__ usage per review feedback(suggested by greg k-h)
> - Add Fixes tag for a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
> (suggested by Andy Shevchenko)
>
> Changes in v5:
> - Initial attempt to replace info->dev accesses using
> dev_of_fbinfo() helper
> ---
The changelog stuff goes below the --- line.
> drivers/staging/fbtft/fbtft-core.c | 19 +++++++++----------
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index 8a5ccc8ae0a1..1b3b62950205 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -365,9 +365,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> unsigned int val;
> int ret = 1;
>
> - dev_dbg(info->dev,
> - "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
> - __func__, regno, red, green, blue, transp);
> + fb_dbg(info,
> + "regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X\n",
> + regno, red, green, blue, transp);
I dont understand what is wrong with the existing dev_dbg() line (with
the exception that __func__ should not be in it.
>
> switch (info->fix.visual) {
> case FB_VISUAL_TRUECOLOR:
> @@ -391,8 +391,7 @@ static int fbtft_fb_blank(int blank, struct fb_info *info)
> struct fbtft_par *par = info->par;
> int ret = -EINVAL;
>
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> - __func__, blank);
> + fb_dbg(info, "blank=%d\n", blank);
Same here, what's wrong with dev_dbg()?
>
> if (!par->fbtftops.blank)
> return ret;
> @@ -793,11 +792,11 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> if (spi)
> sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
> spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
> - dev_info(fb_info->dev,
> - "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
> - fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> - fb_info->fix.smem_len >> 10, text1,
> - HZ / fb_info->fbdefio->delay, text2);
> + fb_info(fb_info,
> + "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
> + fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> + fb_info->fix.smem_len >> 10, text1,
> + HZ / fb_info->fbdefio->delay, text2);
When drivers work properly, they are quiet. Why is this needed at all
except as a debug message?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v1 2/2] backlight: gpio: add support for multiple GPIOs for backlight control
From: tessolveupstream @ 2026-01-13 7:17 UTC (permalink / raw)
To: Daniel Thompson
Cc: lee, danielt, jingoohan1, deller, pavel, robh, krzk+dt, conor+dt,
dri-devel, linux-fbdev, linux-leds, devicetree, linux-kernel
In-Reply-To: <aVuN7zVUWJ1qsVh8@aspen.lan>
On 05-01-2026 15:39, Daniel Thompson wrote:
> On Mon, Jan 05, 2026 at 02:21:20PM +0530, Sudarshan Shetty wrote:
>> Extend the gpio-backlight driver to handle multiple GPIOs instead of a
>> single one. This allows panels that require driving several enable pins
>> to be controlled by the backlight framework.
>>
>> Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
>> ---
>> drivers/video/backlight/gpio_backlight.c | 61 +++++++++++++++++-------
>> 1 file changed, 45 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
>> index 728a546904b0..037e1c111e48 100644
>> --- a/drivers/video/backlight/gpio_backlight.c
>> +++ b/drivers/video/backlight/gpio_backlight.c
>> @@ -17,14 +17,18 @@
>>
>> struct gpio_backlight {
>> struct device *dev;
>> - struct gpio_desc *gpiod;
>> + struct gpio_desc **gpiods;
>> + unsigned int num_gpios;
>
> Why not use struct gpio_descs for this?
>
> Once you do that, then most of the gbl->num_gpios loops can be replaced with
> calls to the array based accessors.
>
Based on your feedback, I have updated the implementation to use
struct gpio_descs and array-based accessors, as recommended like
below:
git diff drivers/video/backlight/gpio_backlight.c
diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
index 037e1c111e48..e99d7a9dc670 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -14,22 +14,37 @@
#include <linux/platform_device.h>
#include <linux/property.h>
#include <linux/slab.h>
+#include <linux/bitmap.h>
struct gpio_backlight {
struct device *dev;
- struct gpio_desc **gpiods;
+ struct gpio_descs *gpiods;
unsigned int num_gpios;
};
static int gpio_backlight_update_status(struct backlight_device *bl)
{
struct gpio_backlight *gbl = bl_get_data(bl);
- unsigned int i;
+ unsigned int n = gbl->num_gpios;
int br = backlight_get_brightness(bl);
+ unsigned long *value_bitmap;
+ int words = BITS_TO_LONGS(n);
+
+ value_bitmap = kcalloc(words, sizeof(unsigned long), GFP_KERNEL);
+ if (!value_bitmap)
+ return -ENOMEM;
+
+ if (br)
+ bitmap_fill(value_bitmap, n);
+ else
+ bitmap_zero(value_bitmap, n);
- for (i = 0; i < gbl->num_gpios; i++)
- gpiod_set_value_cansleep(gbl->gpiods[i], br);
+ gpiod_set_array_value_cansleep(gbl->gpiods->ndescs,
+ gbl->gpiods->desc,
+ gbl->gpiods->info,
+ value_bitmap);
+ kfree(value_bitmap);
return 0;
}
@@ -67,22 +82,18 @@ static int gpio_backlight_probe(struct platform_device *pdev)
def_value = device_property_read_bool(dev, "default-on");
- gbl->num_gpios = gpiod_count(dev, NULL);
+ gbl->gpiods = devm_gpiod_get_array(dev, NULL, GPIOD_ASIS);
+ if (IS_ERR(gbl->gpiods)) {
+ if (PTR_ERR(gbl->gpiods) == -ENODEV)
+ return dev_err_probe(dev, -EINVAL,
+ "The gpios parameter is missing or invalid\n");
+ return PTR_ERR(gbl->gpiods);
+ }
+
+ gbl->num_gpios = gbl->gpiods->ndescs;
if (gbl->num_gpios == 0)
return dev_err_probe(dev, -EINVAL,
"The gpios parameter is missing or invalid\n");
- gbl->gpiods = devm_kcalloc(dev, gbl->num_gpios, sizeof(*gbl->gpiods),
- GFP_KERNEL);
- if (!gbl->gpiods)
- return -ENOMEM;
-
- for (i = 0; i < gbl->num_gpios; i++) {
- gbl->gpiods[i] =
- devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
- if (IS_ERR(gbl->gpiods[i]))
- return dev_err_probe(dev, PTR_ERR(gbl->gpiods[i]),
- "Failed to get GPIO at index %u\n", i);
- }
memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
@@ -101,14 +112,26 @@ static int gpio_backlight_probe(struct platform_device *pdev)
: BACKLIGHT_POWER_OFF;
} else {
bool all_high = true;
-
- for (i = 0; i < gbl->num_gpios; i++) {
- if (gpiod_get_value_cansleep(gbl->gpiods[i]) != 0) {
- all_high = false;
- break;
- }
+ unsigned long *value_bitmap;
+ int words = BITS_TO_LONGS(gbl->num_gpios);
+
+ value_bitmap = kcalloc(words, sizeof(unsigned long), GFP_KERNEL);
+ if (!value_bitmap)
+ return -ENOMEM;
+
+ ret = gpiod_get_array_value_cansleep(gbl->gpiods->ndescs,
+ gbl->gpiods->desc,
+ gbl->gpiods->info,
+ value_bitmap);
+ if (ret) {
+ kfree(value_bitmap);
+ return dev_err_probe(dev, ret,
+ "failed to read initial gpio values\n");
}
+ all_high = bitmap_full(value_bitmap, gbl->num_gpios);
+
+ kfree(value_bitmap);
bl->props.power =
all_high ? BACKLIGHT_POWER_ON : BACKLIGHT_POWER_OFF;
}
@@ -118,7 +141,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
init_brightness = backlight_get_brightness(bl);
for (i = 0; i < gbl->num_gpios; i++) {
- ret = gpiod_direction_output(gbl->gpiods[i], init_brightness);
+ ret = gpiod_direction_output(gbl->gpiods->desc[i], init_brightness);
if (ret)
return dev_err_probe(dev, ret,
"failed to set gpio %u direction\n",
Could you please share your thoughts on whether this approach
aligns with your expectations?
>
>> };
>>
>> static int gpio_backlight_update_status(struct backlight_device *bl)
>> {
>> struct gpio_backlight *gbl = bl_get_data(bl);
>> + unsigned int i;
>> + int br = backlight_get_brightness(bl);
>>
>> - gpiod_set_value_cansleep(gbl->gpiod, backlight_get_brightness(bl));
>> + for (i = 0; i < gbl->num_gpios; i++)
>> + gpiod_set_value_cansleep(gbl->gpiods[i], br);
>>
>> return 0;
>> }
>> @@ -52,6 +56,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
>> struct backlight_device *bl;
>> struct gpio_backlight *gbl;
>> int ret, init_brightness, def_value;
>> + unsigned int i;
>>
>> gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
>> if (gbl == NULL)
>> @@ -62,10 +67,22 @@ static int gpio_backlight_probe(struct platform_device *pdev)
>>
>> def_value = device_property_read_bool(dev, "default-on");
>>
>> - gbl->gpiod = devm_gpiod_get(dev, NULL, GPIOD_ASIS);
>> - if (IS_ERR(gbl->gpiod))
>> - return dev_err_probe(dev, PTR_ERR(gbl->gpiod),
>> - "The gpios parameter is missing or invalid\n");
>> + gbl->num_gpios = gpiod_count(dev, NULL);
>> + if (gbl->num_gpios == 0)
>> + return dev_err_probe(dev, -EINVAL,
>> + "The gpios parameter is missing or invalid\n");
>> + gbl->gpiods = devm_kcalloc(dev, gbl->num_gpios, sizeof(*gbl->gpiods),
>> + GFP_KERNEL);
>> + if (!gbl->gpiods)
>> + return -ENOMEM;
>
> This is definitely easier if you simply use devm_get_array().
>
>
>> +
>> + for (i = 0; i < gbl->num_gpios; i++) {
>> + gbl->gpiods[i] =
>> + devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
>> + if (IS_ERR(gbl->gpiods[i]))
>> + return dev_err_probe(dev, PTR_ERR(gbl->gpiods[i]),
>> + "Failed to get GPIO at index %u\n", i);
>> + }
>>
>> memset(&props, 0, sizeof(props));
>> props.type = BACKLIGHT_RAW;
>> @@ -78,22 +95,34 @@ static int gpio_backlight_probe(struct platform_device *pdev)
>> }
>>
>> /* Set the initial power state */
>> - if (!of_node || !of_node->phandle)
>> + if (!of_node || !of_node->phandle) {
>> /* Not booted with device tree or no phandle link to the node */
>> bl->props.power = def_value ? BACKLIGHT_POWER_ON
>> - : BACKLIGHT_POWER_OFF;
>> - else if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
>> - bl->props.power = BACKLIGHT_POWER_OFF;
>> - else
>> - bl->props.power = BACKLIGHT_POWER_ON;
>> + : BACKLIGHT_POWER_OFF;
>> + } else {
>> + bool all_high = true;
>> +
>> + for (i = 0; i < gbl->num_gpios; i++) {
>> + if (gpiod_get_value_cansleep(gbl->gpiods[i]) != 0) {
>
> Why is there a != here?
>
>
>> + all_high = false;
>> + break;
>> + }
>> + }
>> +
>> + bl->props.power =
>> + all_high ? BACKLIGHT_POWER_ON : BACKLIGHT_POWER_OFF;
>> + }
>>
>> bl->props.brightness = 1;
>>
>> init_brightness = backlight_get_brightness(bl);
>> - ret = gpiod_direction_output(gbl->gpiod, init_brightness);
>> - if (ret) {
>> - dev_err(dev, "failed to set initial brightness\n");
>> - return ret;
>> +
>> + for (i = 0; i < gbl->num_gpios; i++) {
>> + ret = gpiod_direction_output(gbl->gpiods[i], init_brightness);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to set gpio %u direction\n",
>> + i);
>> }
>>
>> platform_set_drvdata(pdev, bl);
>
>
> Daniel.
^ permalink raw reply related
* [PATCH] staging: fbtft: Change udelay() to usleep_range()
From: Gideon Adjei @ 2026-01-13 17:27 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman
Cc: Abdun Nihaal, Dan Carpenter, Jianglei Nie, Matthew Wilcox,
dri-devel, linux-fbdev, linux-staging, linux-kernel, Gideon Adjei
Replace udelay() calls >= 100us with usleep_range() to avoid busy-waiting.
This allows the scheduler to run other tasks while waiting.
Signed-off-by: Gideon Adjei <gideonadjei.dev@gmail.com>
---
drivers/staging/fbtft/fb_tinylcd.c | 2 +-
drivers/staging/fbtft/fb_upd161704.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248f2c50..ee8d6b10374a 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -41,7 +41,7 @@ static int init_display(struct fbtft_par *par)
0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
- udelay(250);
+ usleep_range(250, 400);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
return 0;
diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
index c680160d6380..aed5cc7cabde 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -32,7 +32,7 @@ static int init_display(struct fbtft_par *par)
/* oscillator start */
write_reg(par, 0x003A, 0x0001); /*Oscillator 0: stop, 1: operation */
- udelay(100);
+ usleep_range(100, 200);
/* y-setting */
write_reg(par, 0x0024, 0x007B); /* amplitude setting */
@@ -60,7 +60,7 @@ static int init_display(struct fbtft_par *par)
/* Power supply setting */
write_reg(par, 0x0019, 0x0000); /* DC/DC output setting */
- udelay(200);
+ usleep_range(200, 400);
write_reg(par, 0x001A, 0x1000); /* DC/DC frequency setting */
write_reg(par, 0x001B, 0x0023); /* DC/DC rising setting */
write_reg(par, 0x001C, 0x0C01); /* Regulator voltage setting */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] staging: fbtft: Change udelay() to usleep_range()
From: Matthew Wilcox @ 2026-01-13 17:53 UTC (permalink / raw)
To: Gideon Adjei
Cc: Andy Shevchenko, Greg Kroah-Hartman, Abdun Nihaal, Dan Carpenter,
Jianglei Nie, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260113172756.14744-1-gideonadjei.dev@gmail.com>
On Tue, Jan 13, 2026 at 09:27:56AM -0800, Gideon Adjei wrote:
> Replace udelay() calls >= 100us with usleep_range() to avoid busy-waiting.
> This allows the scheduler to run other tasks while waiting.
Your commit message omits how you know it's safe to sleep in these
situations. Are we holding a spinlock or being called in interrupt
context, for example?
^ permalink raw reply
* [PATCH v2] staging: fbtft: Change udelay() to usleep_range()
From: Gideon Adjei @ 2026-01-13 21:05 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman
Cc: Abdun Nihaal, Dan Carpenter, Jianglei Nie, Matthew Wilcox,
dri-devel, linux-fbdev, linux-staging, linux-kernel, Gideon Adjei
Replace udelay() calls >= 100us with usleep_range() to avoid busy-waiting.
The delays are used in init_display() callbacks. These callbacks are
invoked by fbtft_probe_common() during the driver's probe path. the
probe path runs in process context which already uses sleeping APIs.
This makes usleep_range() safe to use in these situations.
Signed-off-by: Gideon Adjei <gideonadjei.dev@gmail.com>
---
drivers/staging/fbtft/fb_tinylcd.c | 2 +-
drivers/staging/fbtft/fb_upd161704.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248f2c50..ee8d6b10374a 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -41,7 +41,7 @@ static int init_display(struct fbtft_par *par)
0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
- udelay(250);
+ usleep_range(250, 400);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
return 0;
diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
index c680160d6380..aed5cc7cabde 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -32,7 +32,7 @@ static int init_display(struct fbtft_par *par)
/* oscillator start */
write_reg(par, 0x003A, 0x0001); /*Oscillator 0: stop, 1: operation */
- udelay(100);
+ usleep_range(100, 200);
/* y-setting */
write_reg(par, 0x0024, 0x007B); /* amplitude setting */
@@ -60,7 +60,7 @@ static int init_display(struct fbtft_par *par)
/* Power supply setting */
write_reg(par, 0x0019, 0x0000); /* DC/DC output setting */
- udelay(200);
+ usleep_range(200, 400);
write_reg(par, 0x001A, 0x1000); /* DC/DC frequency setting */
write_reg(par, 0x001B, 0x0023); /* DC/DC rising setting */
write_reg(par, 0x001C, 0x0C01); /* Regulator voltage setting */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] staging: fbtft: Change udelay() to usleep_range()
From: Andy Shevchenko @ 2026-01-13 21:13 UTC (permalink / raw)
To: Gideon Adjei
Cc: Andy Shevchenko, Greg Kroah-Hartman, Abdun Nihaal, Dan Carpenter,
Jianglei Nie, Matthew Wilcox, dri-devel, linux-fbdev,
linux-staging, linux-kernel
In-Reply-To: <20260113210559.3020-1-gideonadjei.dev@gmail.com>
On Tue, Jan 13, 2026 at 11:06 PM Gideon Adjei <gideonadjei.dev@gmail.com> wrote:
>
> Replace udelay() calls >= 100us with usleep_range() to avoid busy-waiting.
>
> The delays are used in init_display() callbacks. These callbacks are
> invoked by fbtft_probe_common() during the driver's probe path. the
> probe path runs in process context which already uses sleeping APIs.
> This makes usleep_range() safe to use in these situations.
Nice, now can we switch to modern API, i.e. fsleep()?
--
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