All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: dmitry.torokhov@gmail.com, dri-devel@lists.freedesktop.org,
	linux-input@vger.kernel.org
Subject: Re: [PATCH 6/6] fbdev: sh_mobile_lcdc: check for fb_deferred_io_init() error
Date: Sat, 26 Sep 2026 13:33:54 +0000	[thread overview]
Message-ID: <20260926133355.717B91F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260926-fix-fbdefio-error-handling-v1-6-a94810b6e263@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] fbdev: sh_mobile_lcdc: clock leak on fb_deferred_io_init() failure
--

commit 5d69f4a8e3d4f95bd3f24c9c5188ad04101636e7
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>

fbdev: sh_mobile_lcdc: check for fb_deferred_io_init() error

This commit updates sh_mobile_lcdc_start() to check the return value of
fb_deferred_io_init(). If it fails, info->fbdefio is cleared to prevent
sh_mobile_lcdc_stop() from cleaning up uninitialized deferred I/O state,
and the function returns the error.

> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> index e8324b01700f6..1409a5cc736b0 100644
> --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> @@ -1042,7 +1042,11 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
>  			ch->defio.deferred_io = sh_mobile_lcdc_deferred_io;
>  			ch->defio.delay = msecs_to_jiffies(tmp);
>  			ch->info->fbdefio = &ch->defio;
> -			fb_deferred_io_init(ch->info);
> +			ret = fb_deferred_io_init(ch->info);
> +			if (ret) {
> +				ch->info->fbdefio = NULL;
> +				return ret;
> +			}

[Severity: High]
Does this early return bypass unwinding the clocks and stopping the hardware?

Earlier in sh_mobile_lcdc_start(), the clocks are enabled and the hardware is
started. When called via the FBIOPUT_VSCREENINFO ioctl through
sh_mobile_lcdc_set_par(), a failure here exits without disabling the clocks or
stopping the hardware:

drivers/video/fbdev/sh_mobile_lcdcfb.c:sh_mobile_lcdc_set_par() {
    ...
	ret = sh_mobile_lcdc_start(ch->lcdc);
	if (ret < 0)
		dev_err(info->dev, "%s: unable to restart LCDC\n", __func__);
    ...
}

Additionally, in a multi-channel setup during probe, the failure on one
channel bypasses sh_mobile_lcdc_channel_fb_register(). This causes the error
handler sh_mobile_lcdc_stop() to explicitly call clk_on() for the successful
channel, creating an unmatched increment:

drivers/video/fbdev/sh_mobile_lcdcfb.c:sh_mobile_lcdc_stop() {
    ...
		if (ch->info && ch->info->fbdefio) {
			...
			sh_mobile_lcdc_clk_on(priv);
		}
    ...
}

Could this lead to a permanent leak of the hardware clock reference count
(priv->hw_usecnt) and leave the LCDC hardware running in an error state?

>  		}
>  
>  		sh_mobile_lcdc_display_on(ch);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-fix-fbdefio-error-handling-v1-0-a94810b6e263@kernel.org?part=6

  reply	other threads:[~2026-09-26 13:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-26 13:16 [PATCH 0/6] fbdev: fixup callers which ignore errors from fb_deferred_io_init() Lorenzo Stoakes (ARM)
2026-09-26 13:16 ` [PATCH 1/6] fbdev: ssd1307fb: check for fb_deferred_io_init() error Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 2/6] fbdev: xen-fbfront: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 3/6] HID: picoLCD: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 4/6] fbdev: udlfb: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 5/6] fbdev: smscufx: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 6/6] fbdev: sh_mobile_lcdc: " Lorenzo Stoakes (ARM)
2026-09-26 13:33   ` sashiko-bot [this message]
2026-10-12 16:48 ` [PATCH 0/6] fbdev: fixup callers which ignore errors from fb_deferred_io_init() Lorenzo Stoakes (ARM)
2026-10-12 21:07   ` Helge Deller
2026-10-13 10:17     ` Lorenzo Stoakes (ARM)

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=20260926133355.717B91F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-input@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.