linux-kernel - Re: [PATCH v2 2/8] iio: imu: inv_icm45600: add new inv

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] [day] [month] [year] [list]

Message-ID: <aHdwJ--tK4ANBlT4@smile.fi.intel.com>
Date: Wed, 16 Jul 2025 12:25:59 +0300
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Remi Buisson <Remi.Buisson@....com>
Cc: Jonathan Cameron <jic23@...nel.org>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 2/8] iio: imu: inv_icm45600: add new inv_icm45600
 driver

On Tue, Jul 15, 2025 at 03:26:48PM +0000, Remi Buisson wrote:
> >From: Andy Shevchenko <andriy.shevchenko@...el.com> 
> >Sent: Tuesday, July 15, 2025 12:43 PM
> >On Tue, Jul 15, 2025 at 09:11:47AM +0000, Remi Buisson wrote:
> >> >From: Andy Shevchenko <andriy.shevchenko@...el.com> 
> >> >Sent: Friday, July 11, 2025 1:56 PM
> >> >On Fri, Jul 11, 2025 at 11:32:48AM +0000, Remi Buisson wrote:
> >> >> >From: Andy Shevchenko andriy.shevchenko@...el.com<mailto:andriy.shevchenko@...el.com>
> >> >> >Sent: Thursday, July 10, 2025 11:30 AM
> >> >> >On Thu, Jul 10, 2025 at 08:57:57AM +0000, Remi Buisson via B4 Relay wrote:

...

> >> >> It's probably safer to keep the delay even in case of failure to make sure
> >> >> the device is ready before next operation.
> >> >
> >> >I am not sure about it. Why? This has to be well justified as it's quite
> >> >unusual pattern.
> >
> >> Ok I understand, the hardware needs that delay if the access was actually
> >> done on the bus (to not jeopardize next access).  If a regmap error means
> >> that no real access occured then the delay is avoidable.
> >
> >Perhaps you need to have this delay embedded in the IO accessors? Also do
> >read _and_ write need this or only one of them?

> It's required for both indirect read and write BUT not when writing the first data
> which need to be done in a single burst.
> Could you please be more specific on how to add delays to IO accessors?

I don't remember if regmap core supports already such a delay, but always
working case is to redefine your own regmap_read()/regmap_write() callbacks.

-- 
With Best Regards,
Andy Shevchenko