Received-SPF: pass (google.com: domain of linux-kernel+bounces-152269-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Sat, 20 Apr 2024 14:06:35 +0100
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Aren Moynihan <aren@peacevolution.org>, Lars-Peter Clausen
 <lars@metafoo.de>, Rob Herring <robh@kernel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>,
 Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>,
 Samuel Holland <samuel@sholland.org>, Liam Girdwood <lgirdwood@gmail.com>,
 Mark Brown <broonie@kernel.org>, Ondrej Jirman <megi@xff.cz>, Uwe
 =?UTF-8?B?S2xlaW5lLUvDtm5pZw==?= <u.kleine-koenig@pengutronix.de>,
 linux-iio@vger.kernel.org, phone-devel@vger.kernel.org,
 devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, Willow
 Barraco <contact@willowbarraco.fr>
Subject: Re: [PATCH 3/4] iio: light: stk3310: log error if reading the chip
 id fails
Message-ID: <20240420140635.6dffa2fb@jic23-huawei>
In-Reply-To: <CAHp75Vf_JX1Uv=_cvoiukzSaTVWbmQSW0P_nneP8C-kxX4fBXQ@mail.gmail.com>
References: <20240414175300.956243-1-aren@peacevolution.org>
	<20240414175716.958831-1-aren@peacevolution.org>
	<20240414175716.958831-3-aren@peacevolution.org>
	<CAHp75Vf_JX1Uv=_cvoiukzSaTVWbmQSW0P_nneP8C-kxX4fBXQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 15 Apr 2024 18:05:54 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Sun, Apr 14, 2024 at 8:57=E2=80=AFPM Aren Moynihan <aren@peacevolution=
org> wrote:
> >
> > If the chip isn't powered, this call is likely to return an error.
> > Without a log here the driver will silently fail to probe. Common errors
> > are ENXIO (when the chip isn't powered) and ETIMEDOUT (when the i2c bus
> > isn't powered). =20
>=20
> >         ret =3D regmap_read(data->regmap, STK3310_REG_ID, &chipid);
> > -       if (ret < 0)
> > +       if (ret < 0) {
> > +               dev_err(&client->dev, "failed to read chip id: %d", ret=
);
> >                 return ret;
> > +       } =20
>=20
> Briefly looking at the code it seems that this one is strictly part of
> the probe phase, which means we may use
>=20
>   return dev_err_probe(...);
>=20
> pattern. Yet, you may add another patch to clean up all of them:
> _probe(), _init(), _regmap_init() to use the same pattern everywhere.
>=20

Yes, a precursor patch to use dev_err_probe() throughout the probe only
functions in this driver would be excellent.

Jonathan