From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: chen zhang <chenzhang@kylinos.cn>
Cc: hdegoede@redhat.com, Hans de Goede <hansg@kernel.org>,
frank@f-seidel.de, platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
chenzhang_0901@163.com
Subject: Re: [PATCH] platform/x86: Switch to guard(mutex)
Date: Tue, 23 Dec 2025 11:44:05 +0200 (EET) [thread overview]
Message-ID: <5e94a03f-193b-895f-0ba3-712240908db0@linux.intel.com> (raw)
In-Reply-To: <20251215032924.50854-1-chenzhang@kylinos.cn>
On Mon, 15 Dec 2025, chen zhang wrote:
You're using too generic prefix from the shortlog (in the Subject).
> Instead of using the 'goto label; mutex_unlock()' pattern use
> 'guard(mutex)' which will release the mutex when it goes out of scope.
>
> Signed-off-by: chen zhang <chenzhang@kylinos.cn>
> ---
> drivers/platform/x86/hdaps.c | 37 +++++++++++++++---------------------
> 1 file changed, 15 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/platform/x86/hdaps.c b/drivers/platform/x86/hdaps.c
> index f11f726d2062..2a11bcaa52f2 100644
> --- a/drivers/platform/x86/hdaps.c
> +++ b/drivers/platform/x86/hdaps.c
> @@ -147,18 +147,16 @@ static int hdaps_readb_one(unsigned int port, u8 *val)
> {
> int ret;
>
> - mutex_lock(&hdaps_mtx);
> + guard(mutex)(&hdaps_mtx);
>
> /* do a sync refresh -- we need to be sure that we read fresh data */
> ret = __device_refresh_sync();
> if (ret)
> - goto out;
> + return ret;
>
> *val = inb(port);
> __device_complete();
>
> -out:
> - mutex_unlock(&hdaps_mtx);
> return ret;
return 0;
> }
>
> @@ -208,12 +206,12 @@ static int hdaps_device_init(void)
> {
> int total, ret = -ENXIO;
>
> - mutex_lock(&hdaps_mtx);
> + guard(mutex)(&hdaps_mtx);
>
> outb(0x13, 0x1610);
> outb(0x01, 0x161f);
> if (__wait_latch(0x161f, 0x00))
> - goto out;
> + return ret;
This is not an acceptable conversion. You clearly no longer need ret
variable to carry the information here but can just write:
return -ENXIO;
Please do realize if you make this kind of conversion changes to old code
which are on borderline whether they're more noise and burden (to
maintainers and reviewers) than useful, you should know all these
conventions so that no review cycles is wasted on trivial style issues
like this.
I know some subsystems do push back on patches like this. I find them
still somewhat useful but you should think the patch through before
sending, which you clearly didn't here. Cleaning up/refactoring is not
"easy" unless you do it the wrong way which is to offload thinking to the
reviewers/maintainers.
> /*
> * Most ThinkPads return 0x01.
> @@ -226,7 +224,7 @@ static int hdaps_device_init(void)
> if (__check_latch(0x1611, 0x03) &&
> __check_latch(0x1611, 0x02) &&
> __check_latch(0x1611, 0x01))
> - goto out;
> + return ret;
>
> printk(KERN_DEBUG "hdaps: initial latch check good (0x%02x)\n",
> __get_latch(0x1611));
> @@ -235,29 +233,29 @@ static int hdaps_device_init(void)
> outb(0x81, 0x1611);
> outb(0x01, 0x161f);
> if (__wait_latch(0x161f, 0x00))
> - goto out;
> + return ret;
> if (__wait_latch(0x1611, 0x00))
> - goto out;
> + return ret;
> if (__wait_latch(0x1612, 0x60))
> - goto out;
> + return ret;
> if (__wait_latch(0x1613, 0x00))
> - goto out;
> + return ret;
> outb(0x14, 0x1610);
> outb(0x01, 0x1611);
> outb(0x01, 0x161f);
> if (__wait_latch(0x161f, 0x00))
> - goto out;
> + return ret;
> outb(0x10, 0x1610);
> outb(0xc8, 0x1611);
> outb(0x00, 0x1612);
> outb(0x02, 0x1613);
> outb(0x01, 0x161f);
> if (__wait_latch(0x161f, 0x00))
> - goto out;
> + return ret;
> if (__device_refresh_sync())
> - goto out;
> + return ret;
> if (__wait_latch(0x1611, 0x00))
> - goto out;
> + return ret;
>
> /* we have done our dance, now let's wait for the applause */
> for (total = INIT_TIMEOUT_MSECS; total > 0; total -= INIT_WAIT_MSECS) {
> @@ -273,8 +271,6 @@ static int hdaps_device_init(void)
> msleep(INIT_WAIT_MSECS);
> }
>
> -out:
> - mutex_unlock(&hdaps_mtx);
> return ret;
> }
>
> @@ -322,17 +318,14 @@ static void hdaps_mousedev_poll(struct input_dev *input_dev)
> {
> int x, y;
>
> - mutex_lock(&hdaps_mtx);
> + guard(mutex)(&hdaps_mtx);
>
> if (__hdaps_read_pair(HDAPS_PORT_XPOS, HDAPS_PORT_YPOS, &x, &y))
> - goto out;
> + return;
>
> input_report_abs(input_dev, ABS_X, x - rest_x);
> input_report_abs(input_dev, ABS_Y, y - rest_y);
> input_sync(input_dev);
> -
> -out:
> - mutex_unlock(&hdaps_mtx);
> }
>
>
>
--
i.
next prev parent reply other threads:[~2025-12-23 9:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-15 3:29 chen zhang
2025-12-23 9:44 ` Ilpo Järvinen [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-12-15 3:27 chen zhang
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=5e94a03f-193b-895f-0ba3-712240908db0@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=chenzhang@kylinos.cn \
--cc=chenzhang_0901@163.com \
--cc=frank@f-seidel.de \
--cc=hansg@kernel.org \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®