linux-kernel - Re: [PATCH v3 2/4] iio: temperature: ltc2983: convert to dev_err

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f1a6ccf23cb901473bd490b1ca7330db51a1313.camel@gmail.com>
Date: Fri, 07 Jun 2024 12:41:37 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Nuno Sa <nuno.sa@...log.com>, Petr Mladek <pmladek@...e.com>, Jonathan
 Cameron <jic23@...nel.org>, Lars-Peter Clausen <lars@...afoo.de>, Olivier
 Moysan <olivier.moysan@...s.st.com>, Jyoti Bhayana <jbhayana@...gle.com>,
 Chris Down <chris@...isdown.name>, John Ogness <john.ogness@...utronix.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Andi Shyti
 <andi.shyti@...nel.org>, linux-kernel@...r.kernel.org, 
 linux-iio@...r.kernel.org
Subject: Re: [PATCH v3 2/4] iio: temperature: ltc2983: convert to
 dev_err_probe()

On Thu, 2024-06-06 at 17:12 +0300, Andy Shevchenko wrote:
> On Thu, Jun 06, 2024 at 02:27:03PM +0200, Nuno Sá wrote:
> > On Thu, 2024-06-06 at 13:17 +0300, Andy Shevchenko wrote:
> > > On Thu, Jun 06, 2024 at 09:22:38AM +0200, Nuno Sa wrote:
> 
> ...
> 
> > > > +			return dev_err_ptr_probe(&st->spi->dev, -
> > > > EINVAL,
> > > 
> > > You can make all these lines shorter by using
> > > 
> > > 	struct device *dev = &st->spi->dev; // or analogue
> > > 
> > > at the top of the function.
> > > 
> > 
> > Well, I had that in v2 (making the whole driver coherent with the local
> > struct
> > device helper but you kind of "complained" for a precursor patch (on a
> > devm_kzalloc() call). So basically I deferred that change for a follow up
> > patch.
> 
> Hmm... I don't remember the story behind this, but probably it's good to have
> this done one (precursor) or the other way (follow up). Just check how many
> changes will be done, whichever diff is shorter, choose that one.
> 

Well that has not much to do with the current series. I would prefer to have a
follow up when we're done with the current changes. Right now I would really
prefer to focus on the new dev_err_* APIs and see if anything else is needed for
this to be acceptable.

- Nuno Sá