Received-SPF: pass (google.com: domain of linux-kernel+bounces-205838-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <3f1a6ccf23cb901473bd490b1ca7330db51a1313.camel@gmail.com>
Subject: Re: [PATCH v3 2/4] iio: temperature: ltc2983: convert to
 dev_err_probe()
From: Nuno =?ISO-8859-1?Q?S=E1?= <noname.nuno@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Nuno Sa <nuno.sa@analog.com>, Petr Mladek <pmladek@suse.com>, Jonathan
 Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Olivier
 Moysan <olivier.moysan@foss.st.com>, Jyoti Bhayana <jbhayana@google.com>,
 Chris Down <chris@chrisdown.name>, John Ogness <john.ogness@linutronix.de>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Andi Shyti
 <andi.shyti@kernel.org>, linux-kernel@vger.kernel.org, 
 linux-iio@vger.kernel.org
Date: Fri, 07 Jun 2024 12:41:37 +0200
In-Reply-To: <ZmHD63_tvC75To8r@smile.fi.intel.com>
References: <20240606-dev-add_dev_errp_probe-v3-0-51bb229edd79@analog.com>
	 <20240606-dev-add_dev_errp_probe-v3-2-51bb229edd79@analog.com>
	 <ZmGMwwglUlS6_NI_@smile.fi.intel.com>
	 <da57a64e4f5cdda7ee6b794c448995eee648c436.camel@gmail.com>
	 <ZmHD63_tvC75To8r@smile.fi.intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.2 
Precedence: bulk
MIME-Version: 1.0

On Thu, 2024-06-06 at 17:12 +0300, Andy Shevchenko wrote:
> On Thu, Jun 06, 2024 at 02:27:03PM +0200, Nuno S=C3=A1 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:
>=20
> ...
>=20
> > > > +			return dev_err_ptr_probe(&st->spi->dev, -
> > > > EINVAL,
> > >=20
> > > You can make all these lines shorter by using
> > >=20
> > > 	struct device *dev =3D &st->spi->dev; // or analogue
> > >=20
> > > at the top of the function.
> > >=20
> >=20
> > 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.
>=20
> 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 ma=
ny
> changes will be done, whichever diff is shorter, choose that one.
>=20

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

- Nuno S=C3=A1