From: Dan Carpenter <error27@gmail.com>
To: Batu Ada Tutkun <batuadatutkun@gmail.com>
Cc: parthiban.veerasooran@microchip.com,
christian.gromm@microchip.com, gregkh@linuxfoundation.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: most: dim2: use dev_err_probe() for clock errors in rcar enable functions
Date: Wed, 24 Jun 2026 09:27:51 +0300 [thread overview]
Message-ID: <ajt4563Z0OcyenaU@stanley.mountain> (raw)
In-Reply-To: <6a3ae2f8.cf2df9a4.132dbf.1a50@mx.google.com>
On Tue, Jun 23, 2026 at 10:46:07PM +0300, Batu Ada Tutkun wrote:
> rcar_gen2_enable() and rcar_gen3_enable() use the old pattern of
> dev_err() followed by return PTR_ERR() when devm_clk_get() fails.
> fsl_mx6_enable() in the same file was already converted to use
> dev_err_probe() by a previous cleanup series.
>
> Convert the remaining two functions for consistency. devm_clk_get()
> calls clk_get() which can return -EPROBE_DEFER if the clock provider
> has not yet registered. Using dev_err_probe() suppresses the log at
> error level in that case, avoiding misleading "cannot get clock" output
> during a normal deferred probe.
>
> clk_prepare_enable() cannot return -EPROBE_DEFER since the clock handle
> is already acquired at that point, so those error paths are left as
> dev_err().
>
> Signed-off-by: Batu Ada Tutkun <batuadatutkun@gmail.com>
> ---
> Compile tested only. No R-Car hardware available. This is a correctness
> fix for the deferred probe path, not a response to a reported
> user visible issue.
>
> Changes in v2:
> - Mention clk_get() explicitly in commit message
> - Add testing note under --- cut off line
>
Wrong patch for the commit message.
> drivers/staging/most/video/video.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/most/video/video.c b/drivers/staging/most/video/video.c
> index 04351f8cc..1e1ff3c52 100644
> --- a/drivers/staging/most/video/video.c
> +++ b/drivers/staging/most/video/video.c
> @@ -33,14 +33,14 @@ struct most_video_dev {
> bool mute;
>
> struct list_head pending_mbos;
> - spinlock_t list_lock;
> + spinlock_t list_lock; /* protects pending_mbos and mute */
It doesn't protect mute, really. Only half heartedly. And
protecting mute is unnecessary.
>
> struct v4l2_device v4l2_dev;
> atomic_t access_ref;
> struct video_device *vdev;
> unsigned int ctrl_input;
>
> - struct mutex lock;
> + struct mutex lock; /* serializes V4L2 ioctls */
I kind of hate this checkpatch warning... It's really hard to judge
if this comment is accurate or useful.
regards,
dan carpenter
>
> wait_queue_head_t wait_data;
> };
> --
> 2.53.0
prev parent reply other threads:[~2026-06-24 6:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 12:42 [PATCH] staging: most: dim2: use dev_err_probe() for clock errors in rcar enable functions Batu Ada Tutkun
2026-06-23 12:35 ` [PATCH v2] " Batu Ada Tutkun
2026-06-24 6:22 ` Dan Carpenter
2026-06-23 13:16 ` [PATCH] " Dan Carpenter
2026-06-23 17:41 ` Batu Ada Tutkun
2026-06-23 18:35 ` Dan Carpenter
2026-06-23 19:46 ` [PATCH v2] " Batu Ada Tutkun
2026-06-24 6:27 ` Dan Carpenter [this message]
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=ajt4563Z0OcyenaU@stanley.mountain \
--to=error27@gmail.com \
--cc=batuadatutkun@gmail.com \
--cc=christian.gromm@microchip.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=parthiban.veerasooran@microchip.com \
/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.