From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jeff LaBundy <jeff@labundy.com>
Cc: "Markus Elfring" <Markus.Elfring@web.de>,
linux-input@vger.kernel.org, kernel-janitors@vger.kernel.org,
"Rob Herring" <robh@kernel.org>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Input: iqs626a - Use common error handling code in iqs626_parse_events()
Date: Sun, 3 Mar 2024 20:29:49 -0800 [thread overview]
Message-ID: <ZeVOPSt0L1D4BxuZ@google.com> (raw)
In-Reply-To: <ZeU8ENmnPj3sKxAv@nixie71>
On Sun, Mar 03, 2024 at 09:12:16PM -0600, Jeff LaBundy wrote:
> Hi Markus,
>
> On Sat, Mar 02, 2024 at 12:42:08PM +0100, Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Sat, 2 Mar 2024 11:44:17 +0100
> >
> > Add a jump target so that a bit of exception handling can be better reused
> > at the end of this function implementation.
> >
> > This issue was transformed by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> > ---
> > drivers/input/misc/iqs626a.c | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/misc/iqs626a.c b/drivers/input/misc/iqs626a.c
> > index 0dab54d3a060..fa9570755f7b 100644
> > --- a/drivers/input/misc/iqs626a.c
> > +++ b/drivers/input/misc/iqs626a.c
> > @@ -530,8 +530,7 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> > dev_err(&client->dev,
> > "Invalid input type: %u\n",
> > val);
> > - fwnode_handle_put(ev_node);
> > - return -EINVAL;
> > + goto put_fwnode;
> > }
> >
> > iqs626->kp_type[ch_id][i] = val;
> > @@ -545,8 +544,7 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> > dev_err(&client->dev,
> > "Invalid %s channel hysteresis: %u\n",
> > fwnode_get_name(ch_node), val);
> > - fwnode_handle_put(ev_node);
> > - return -EINVAL;
> > + goto put_fwnode;
> > }
> >
> > if (i == IQS626_EVENT_DEEP_DN ||
> > @@ -566,8 +564,7 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> > dev_err(&client->dev,
> > "Invalid %s channel threshold: %u\n",
> > fwnode_get_name(ch_node), val);
> > - fwnode_handle_put(ev_node);
> > - return -EINVAL;
> > + goto put_fwnode;
> > }
> >
> > if (ch_id == IQS626_CH_HALL)
> > @@ -580,6 +577,10 @@ iqs626_parse_events(struct iqs626_private *iqs626,
> > }
> >
> > return 0;
> > +
> > +put_fwnode:
> > + fwnode_handle_put(ev_node);
> > + return -EINVAL;
> > }
> >
> > static noinline_for_stack int
> > --
> > 2.44.0
> >
>
> Thank you for this patch, but it seems like a NAK to me. I think this is
> a matter of personal preference, and according to mine, it is much more
> confusing to insert a goto label after a function's primary return path
> than to have 2-3 calls to fwnode_handle_put().
>
> If you feel strongly otherwise, then I would suggest a helper function as
> recommended by Dmitry in another thread. However, maybe that helper should
> live in the driver core, as I suspect this driver is not the only place we
> can avoid calling fwnode_handle_put() in an error path that returns an int.
Yes, it should go into include/linux/fwnode.h, something like
DEFINE_FREE(fwnode, struct fwnode_handle *, if (_T) fwnode_hanlde_put(_T));
Then drivers can do:
struct fwnode_handle *ev_node __free(fwnode) =
fwnode_get_named_child_node(ch_node, ev_name);
and have it automatically be "put" once execution leaves the variable
scope.
Ah, we actually already have it defined in include/linux/property.h, all
the better.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2024-03-04 4:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-02 11:42 [PATCH] Input: iqs626a - Use common error handling code in iqs626_parse_events() Markus Elfring
2024-03-04 3:12 ` Jeff LaBundy
2024-03-04 4:29 ` Dmitry Torokhov [this message]
2024-03-04 8:18 ` Dan Carpenter
2024-03-04 12:31 ` Markus Elfring
2024-03-04 10:52 ` [PATCH v2] Input: iqs626a - Use scope-based resource management " Markus Elfring
2024-03-04 10:55 ` Julia Lawall
2024-03-04 11:32 ` Dan Carpenter
2024-03-04 13:30 ` Markus Elfring
2024-03-04 12:10 ` [PATCH v2] " Markus Elfring
2024-03-04 17:16 ` Dmitry Torokhov
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=ZeVOPSt0L1D4BxuZ@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=Markus.Elfring@web.de \
--cc=jeff@labundy.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=u.kleine-koenig@pengutronix.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.