public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	"Andy Shevchenko" <andy@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"David Jander" <david@protonic.nl>
Subject: Re: [PATCH v4 07/13] iio: dac: ds4424: use fsleep() instead of usleep_range()
Date: Tue, 3 Feb 2026 13:45:06 +0200	[thread overview]
Message-ID: <aYHfwpL_2109UcCq@smile.fi.intel.com> (raw)
In-Reply-To: <20260203093434.2548978-8-o.rempel@pengutronix.de>

On Tue, Feb 03, 2026 at 10:34:27AM +0100, Oleksij Rempel wrote:
> The DS4422/DS4424 and DS4402/DS4404 datasheets do not specify a minimum
> delay between power-up (POR) and the availability of the I2C interface.
> 
> The driver previously used `usleep_range(1000, 1200)` to enforce a ~1ms
> delay. Replace this with `fsleep(1000)` to allow the kernel to select the

> most efficient sleep mechanism (usleep or msleep) while retaining the

Information in the parentheses is not needed and may be confusing in the future
if kernel gets some Xsleep on top of the given list (which by the fact misses
udelay).

> existing conservative delay to ensure device readiness.

There is a couple of nit-picks, otherwise LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

> +	/*
> +	 * The datasheet does not specify a power-up to I2C ready time.
> +	 * Maintain the existing conservative 1ms delay to ensure the
> +	 * device is ready for communication.
> +	 */
> +	fsleep(1000);

Perhaps use 1 * USEC_PER_MSEC as an argument?


-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-02-03 11:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03  9:34 [PATCH v4 00/13] iio: dac: ds4424: add DS4402/DS4404 support and scale Oleksij Rempel
2026-02-03  9:34 ` [PATCH v4 01/13] iio: dac: ds4424: reject -128 RAW value Oleksij Rempel
2026-02-03  9:54   ` Andy Shevchenko
2026-02-03 10:28     ` Oleksij Rempel
2026-02-03 11:52       ` Andy Shevchenko
2026-02-05 20:41         ` Jonathan Cameron
2026-02-03  9:34 ` [PATCH v4 02/13] iio: dac: ds4424: refactor raw access to use bitwise operations Oleksij Rempel
2026-02-03  9:34 ` [PATCH v4 03/13] iio: dac: ds4424: ratelimit read errors and use device context Oleksij Rempel
2026-02-03  9:34 ` [PATCH v4 04/13] iio: dac: ds4424: sort headers alphabetically Oleksij Rempel
2026-02-03  9:34 ` [PATCH v4 05/13] iio: dac: ds4424: rename iio_info struct to avoid ambiguity Oleksij Rempel
2026-02-03  9:55   ` Andy Shevchenko
2026-02-03  9:34 ` [PATCH v4 06/13] iio: dac: ds4424: use device match data for chip info Oleksij Rempel
2026-02-03 10:03   ` Andy Shevchenko
2026-02-03 10:17     ` Oleksij Rempel
2026-02-03 11:51       ` Andy Shevchenko
2026-02-03 12:00         ` Oleksij Rempel
2026-02-03 14:56           ` Andy Shevchenko
2026-02-05 20:43             ` Jonathan Cameron
2026-02-06  7:57               ` Oleksij Rempel
2026-02-06  9:59                 ` Andy Shevchenko
2026-02-09  9:22                   ` Oleksij Rempel
2026-02-09 10:29                     ` Andy Shevchenko
2026-02-03  9:34 ` [PATCH v4 07/13] iio: dac: ds4424: use fsleep() instead of usleep_range() Oleksij Rempel
2026-02-03 11:45   ` Andy Shevchenko [this message]
2026-02-03  9:34 ` [PATCH v4 08/13] dt-bindings: iio: dac: maxim,ds4424: add ds4402/ds4404 Oleksij Rempel
2026-02-03  9:34 ` [PATCH v4 09/13] iio: dac: ds4424: add DS4402/DS4404 device IDs Oleksij Rempel
2026-02-03  9:34 ` [PATCH v4 10/13] iio: dac: ds4424: support per-variant output range limits Oleksij Rempel
2026-02-03 11:46   ` Andy Shevchenko
2026-02-03  9:34 ` [PATCH v4 11/13] iio: dac: ds4424: convert to regmap Oleksij Rempel
2026-02-03 11:57   ` Andy Shevchenko
2026-02-03  9:34 ` [PATCH v4 12/13] dt-bindings: iio: dac: maxim,ds4424: add maxim,rfs-ohms property Oleksij Rempel
2026-02-03  9:34 ` [PATCH v4 13/13] iio: dac: ds4424: add Rfs-based scale and per-variant limits Oleksij Rempel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aYHfwpL_2109UcCq@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=david@protonic.nl \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=o.rempel@pengutronix.de \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox