[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VfC4vpkxghLCC9rsP+p1kezSh3HLCbjV6gqLgdtPJzX1w@mail.gmail.com>
Date: Sat, 29 May 2021 12:50:23 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: Amireddy Mallikarjuna reddy <mallikarjunax.reddy@...ux.intel.com>,
Linus Walleij <linus.walleij@...aro.org>,
Marek BehĂșn <marek.behun@....cz>,
Abanoub Sameh <abanoubsameh8@...il.com>,
Dan Murphy <dmurphy@...com>,
Krzysztof Kozlowski <krzk@...nel.org>,
linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 21/28] leds: lm3697: Make error handling more robust
On Fri, May 28, 2021 at 1:51 PM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Fri, May 28, 2021 at 12:10:57PM +0200, Pavel Machek wrote:
> > On Mon 2021-05-10 12:50:38, Andy Shevchenko wrote:
> > > It's easy to miss necessary clean up, e.g. firmware node reference counting,
> > > during error path in ->probe(). Make it more robust by moving to a single
> > > point of return.
> > >
> > > Signed-off-by: Andy Shevchenko <andy.shevchenko@...il.com>
> >
> > You are now putting the handle even in the success case. Is that
> > right?
>
> Let's put it this way: it's no-op in successful case.
>
> But yeah, I would prefer to have a separate case for error, I'll revisit this.
I have added return 0; for a successful case.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists