From: Greg KH <gregkh@linuxfoundation.org>
To: Chintan Patel <chintanlike@gmail.com>
Cc: linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, tzimmermann@suse.de,
andy@kernel.org, deller@gmx.de, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v6] staging: fbtft: Use fbdev logging helpers when FB_DEVICE is disabled
Date: Tue, 13 Jan 2026 07:16:27 +0100 [thread overview]
Message-ID: <2026011341-chomp-protegee-6be5@gregkh> (raw)
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
next prev parent reply other threads:[~2026-01-13 6:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 4:59 [PATCH v6] staging: fbtft: Use fbdev logging helpers when FB_DEVICE is disabled Chintan Patel
2026-01-13 6:16 ` Greg KH [this message]
2026-01-14 4:47 ` Chintan Patel
2026-01-14 7:15 ` Andy Shevchenko
2026-01-14 11:38 ` Thomas Zimmermann
2026-01-15 4:05 ` Chintan Patel
2026-01-15 7:55 ` Thomas Zimmermann
2026-01-16 2:59 ` Chintan Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026011341-chomp-protegee-6be5@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=andy@kernel.org \
--cc=chintanlike@gmail.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=lkp@intel.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.