* Re: [PATCH 1/3] staging: sm750fb: fix static const char array warning
From: Greg KH @ 2026-01-11 12:58 UTC (permalink / raw)
To: Lorenzo Simonelli
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev
In-Reply-To: <20260107094714.300380-2-lorenzosimonelli02@gmail.com>
On Wed, Jan 07, 2026 at 10:47:12AM +0100, Lorenzo Simonelli wrote:
> 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
>
Please ALWAYS test-build your patches before sending them out. That way
you catch obvious bugs like the one that this change introduces :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Helge Deller @ 2026-01-11 18:50 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, gregkh
In-Reply-To: <20260107044258.528624-2-chintanlike@gmail.com>
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.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v4 3/4] fbdev: omapfb: Make FB_DEVICE dependency optional
From: Helge Deller @ 2026-01-11 18:52 UTC (permalink / raw)
To: Thomas Zimmermann, Chintan Patel, linux-fbdev, linux-staging,
linux-omap
Cc: linux-kernel, dri-devel, andy, gregkh
In-Reply-To: <aa922030-b0a1-4503-a3c0-7ce4c36c236e@suse.de>
On 1/7/26 08:33, Thomas Zimmermann wrote:
>
>
> 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>
applied to fbdev.
Thanks!
Helge
>> ---
>> drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
>> .../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 ++++++++++++++----
>> 2 files changed, 16 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 0/7] video/logo: allow custom boot logo and simplify logic
From: Helge Deller @ 2026-01-11 18:59 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Geert Uytterhoeven, linux-fbdev, dri-devel, linux-kernel,
linux-sh, linux-m68k
In-Reply-To: <20260108-custom-logo-v3-0-5a7aada7a6d4@kernel.org>
On 1/8/26 20:04, Vincent Mailhol wrote:
> This series allows the user to replace the default kernel boot logo by
> a custom one directly in the kernel configuration. This makes it
> easier to customise the boot logo without the need to modify the
> sources and allows such customisation to remain persistent after
> applying the configuration to another version of the kernel.
>
> Patch #1 and #2 are clean-up and preparation while patch #3 is the
> main feature of this series: making the boot logo customisable.
>
> While working on this, I realised that managing the logo file directly
> in Kbuild allows us to simplify how we handle the different existing
> variants of the Tux logo. This series thus ends with a clean-up which
> moves all the logo selection logic to Kbuild except from one special
> case (details in the patch description), simplifying the Makefile and
> the C code.
>
> Patch #4 and #5 do a tree-wide clean-up on the Kconfig symbols that
> are to be removed in patch #7. Patch #6 removes the Macintosh 68k logo
> which is conflicting with our simplification plans. Patch #7 finally
> simplifies the logic as explained above.
>
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
series applied to fbdev git tree.
Thanks!
Helge
> Changes in v3:
>
> - v2 broke the logo selection for m68k resulting in the MAC logo
> replacing the default logo on some machine where it shouldn't.
> v3 resolves the conflict by removing that logo.
>
> - Typo fix in patch #4 description.
>
> Link to v2: https://lore.kernel.org/r/20260101-custom-logo-v2-0-8eec06dfbf85@kernel.org
>
> Changes in v2:
>
> - By removing the logo_spe_clut224.o target from the Makefile, v1
> also removed the logo_spe_clut224 object which is still being
> referenced in
>
> arch/powerpc/platforms/cell/spu_base.c
>
> Restore the logo_spe_clut224.o target.
>
> Link to v1: https://lore.kernel.org/r/20251230-custom-logo-v1-0-4736374569ee@kernel.org
>
> ---
> Vincent Mailhol (7):
> video/logo: remove orphan .pgm Makefile rule
> video/logo: add a type parameter to the logo makefile function
> video/logo: allow custom logo
> newport_con: depend on LOGO_LINUX_CLUT224 instead of LOGO_SGI_CLUT224
> sh: defconfig: remove CONFIG_LOGO_SUPERH_*
> video/logo: remove logo_mac_clut224
> video/logo: move logo selection logic to Kconfig
>
> arch/sh/configs/dreamcast_defconfig | 2 -
> arch/sh/configs/ecovec24_defconfig | 2 -
> arch/sh/configs/kfr2r09_defconfig | 2 -
> arch/sh/configs/migor_defconfig | 2 -
> arch/sh/configs/rts7751r2d1_defconfig | 2 -
> arch/sh/configs/rts7751r2dplus_defconfig | 2 -
> arch/sh/configs/se7724_defconfig | 2 -
> arch/sh/configs/se7780_defconfig | 2 -
> arch/sh/configs/sh7785lcr_defconfig | 3 -
> arch/sh/configs/urquell_defconfig | 3 -
> drivers/video/console/newport_con.c | 4 +-
> drivers/video/logo/Kconfig | 82 +-
> drivers/video/logo/Makefile | 29 +-
> drivers/video/logo/logo.c | 46 +-
> drivers/video/logo/logo_mac_clut224.ppm | 1604 ------------------------------
> include/linux/linux_logo.h | 8 -
> 16 files changed, 63 insertions(+), 1732 deletions(-)
> ---
> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> change-id: 20251227-custom-logo-932df316a02c
>
> Best regards,
^ permalink raw reply
* 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
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