From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Xichao Zhao <zhao.xichao@vivo.com>,
cristian.marussi@arm.com, jassisinghbrar@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mailbox: arm_mhuv3: Remove dev_err_probe() if error is -ENOMEM
Date: Thu, 21 Aug 2025 11:00:48 +0100 [thread overview]
Message-ID: <aKbuUC_sQbRjs_iv@pluto> (raw)
In-Reply-To: <aKbsjmEnXIOka7QM@bogus>
On Thu, Aug 21, 2025 at 10:53:18AM +0100, Sudeep Holla wrote:
> On Thu, Aug 21, 2025 at 05:32:53PM +0800, Xichao Zhao wrote:
Hi,
> > The dev_err_probe() doesn't do anything when error is '-ENOMEM'.
> > Therefore, remove the useless call to dev_err_probe(), and just
> > return the value instead.
> >
>
Looking at dev_err_probe() comments...
/**
* dev_err_probe - probe error check and log helper
* @dev: the pointer to the struct device
* @err: error value to test
* @fmt: printf-style format string
* @...: arguments as specified in the format string
[snip]
* Using this helper in your probe function is totally fine even if @err <<<<
* is known to never be -EPROBE_DEFER.
* The benefit compared to a normal dev_err() is the standardized format
* of the error code, which is emitted symbolically (i.e. you get "EAGAIN"
* instead of "-35"), and having the error code returned allows more
* compact error paths.
*
* Returns @err.
I have not a strong opinion but it seems to me un-needed and potentially
impacting future backporting...IOW for me, as the mailbox maintaner prefers.
Thanks,
Cristian
prev parent reply other threads:[~2025-08-21 10:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 9:32 [PATCH] mailbox: arm_mhuv3: Remove dev_err_probe() if error is -ENOMEM Xichao Zhao
2025-08-21 9:53 ` Sudeep Holla
2025-08-21 10:00 ` Cristian Marussi [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=aKbuUC_sQbRjs_iv@pluto \
--to=cristian.marussi@arm.com \
--cc=jassisinghbrar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sudeep.holla@arm.com \
--cc=zhao.xichao@vivo.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.