[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZuBiWE5lQfwg5PJs@nixie71>
Date: Tue, 10 Sep 2024 10:14:32 -0500
From: Jeff LaBundy <jeff@...undy.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: linux-input@...r.kernel.org,
Michael Hennerich <michael.hennerich@...log.com>,
Ville Syrjala <syrjala@....fi>,
Support Opensource <support.opensource@...semi.com>,
Eddie James <eajames@...ux.ibm.com>,
Andrey Moiseev <o2g.org.ru@...il.com>,
Hans de Goede <hdegoede@...hat.com>,
Javier Carrasco <javier.carrasco.cruz@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/22] Input: iqs7222 - use cleanup facility for fwnodes
Hi Dmitry,
On Sun, Sep 08, 2024 at 06:34:21PM -0700, Dmitry Torokhov wrote:
> Hi Jeff,
>
> On Sun, Sep 08, 2024 at 07:12:10PM -0500, Jeff LaBundy wrote:
> > Hi Dmitry,
> >
> > On Tue, Sep 03, 2024 at 09:48:25PM -0700, Dmitry Torokhov wrote:
> > > Use __free(fwnode_handle) cleanup facility to ensure that references to
> > > acquired fwnodes are dropped at appropriate times automatically.
> > >
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > > ---
> > > drivers/input/misc/iqs7222.c | 30 ++++++++++++++----------------
> > > 1 file changed, 14 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/input/misc/iqs7222.c b/drivers/input/misc/iqs7222.c
> > > index 9ca5a743f19f..d9b87606ff7a 100644
> > > --- a/drivers/input/misc/iqs7222.c
> > > +++ b/drivers/input/misc/iqs7222.c
> > > @@ -2385,9 +2385,9 @@ static int iqs7222_parse_chan(struct iqs7222_private *iqs7222,
> > > for (i = 0; i < ARRAY_SIZE(iqs7222_kp_events); i++) {
> > > const char *event_name = iqs7222_kp_events[i].name;
> > > u16 event_enable = iqs7222_kp_events[i].enable;
> > > - struct fwnode_handle *event_node;
> > >
> > > - event_node = fwnode_get_named_child_node(chan_node, event_name);
> > > + struct fwnode_handle *event_node __free(fwnode_handle) =
> > > + fwnode_get_named_child_node(chan_node, event_name);
> >
> > This leaves a newline amongst the declarations, but not in between the
> > declarations and code. I don't feel strongly against this, but it's
> > opposite of what I understand to be more common; please let me know in
> > case I have misunderstood. This comment applies to the other chunks as
> > well.
>
> Right, so this is actually combining declaration and initialization case
> that I mentioned in the other email, and it is closer in spirit to the
> code and the allocation check below. That is why it is separated from
> the declaration block.
Thanks again for the background information; please feel free to add:
Reviewed-by: Jeff LaBundy <jeff@...undy.com>
>
> Thanks.
>
> --
> Dmitry
Kind regards,
Jeff LaBundy
Powered by blists - more mailing lists