Received-SPF: pass (google.com: domain of linux-kernel+bounces-195071-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240529162958.18081-1-johan+linaro@kernel.org>
 <20240529162958.18081-4-johan+linaro@kernel.org> <CAHp75VdnTQJFfqOdxC99gWckxebdUr4hV0wp3ZTs1Pey7q_fsA@mail.gmail.com>
 <Zlgz3nDjfRO5LYnY@hovoldconsulting.com>
In-Reply-To: <Zlgz3nDjfRO5LYnY@hovoldconsulting.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Thu, 30 May 2024 11:34:55 +0300
Message-ID: <CAHp75VewzRUiKQvQ9D9HWPOo6Yfqtv+AV+AVTPQO=foRzMoegw@mail.gmail.com>
Subject: Re: [PATCH v2 03/14] mfd: pm8008: deassert reset on probe
To: Johan Hovold <johan@kernel.org>
Cc: Johan Hovold <johan+linaro@kernel.org>, Lee Jones <lee@kernel.org>, 
	Mark Brown <broonie@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, 
	Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, 
	Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>, Conor Dooley <conor+dt@kernel.org>, 
	Liam Girdwood <lgirdwood@gmail.com>, Das Srinagesh <quic_gurus@quicinc.com>, 
	Satya Priya Kakitapalli <quic_skakitap@quicinc.com>, Stephen Boyd <swboyd@chromium.org>, 
	"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>, linux-arm-msm@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-gpio@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 30, 2024 at 11:08=E2=80=AFAM Johan Hovold <johan@kernel.org> wr=
ote:
> On Wed, May 29, 2024 at 10:45:40PM +0300, Andy Shevchenko wrote:
> > On Wed, May 29, 2024 at 7:30=E2=80=AFPM Johan Hovold <johan+linaro@kern=
el.org> wrote:
> > >
> > > Request and deassert any (optional) reset gpio during probe in case i=
t
> > > has been left asserted by the boot firmware.
> > >
> > > Note the reset line is not asserted to avoid reverting to the default
> > > I2C address in case the firmware has configured an alternate address.

..

> > > +       /*
> > > +        * The PMIC does not appear to require a post-reset delay, bu=
t wait
> > > +        * for a millisecond for now anyway.
> > > +        */
> >
> > > +       usleep_range(1000, 2000);
> >
> > fsleep() ?
>
> No, I'd only use fsleep() when the argument is variable.

Okay, this is basically the same issue as with use of dev_err_probe()
with known errors. fsleep() hides the choice between let's say
msleep() / usleep_range() / udelay() from the caller. This, in
particular, might allow shifting constraints if the timer core is
changed or becomes more granular. It's independent to the variable or
constant parameter(s). Whatever, I'm not going to insist.

--=20
With Best Regards,
Andy Shevchenko