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

Message-ID:
 <FR2PPF4571F02BC1A8F6E7F098A498E0B9C8C57A@FR2PPF4571F02BC.DEUP281.PROD.OUTLOOK.COM>
Date: Tue, 15 Jul 2025 15:26:48 +0000
From: Remi Buisson <Remi.Buisson@....com>
To: Andy Shevchenko <andriy.shevchenko@...el.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

>
>
>From: Andy Shevchenko <andriy.shevchenko@...el.com> 
>Sent: Tuesday, July 15, 2025 12:43 PM
>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-iio@...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 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:
>
>...
>
>> >> >> +#define INV_ICM45600_SENSOR_CONF_INIT                        {-1, -1, -1, -1}
>> >> >
>> >> >Unused.
>> >> This is used in later patch of the serie.
>> >> I will move this definition to the patch using it.
>> >
>> >Yes, unused in this code. You should compile the series incrementally,
>> >so each patch will get a compilation test. This is called compile-time
>> >bisectability. Also run the system each time to confirm no regressions
>> >(this is called run-time bisectability).
>
>> Yes I did that for each patch, everything build successfully.
>> In that case, nothing is broken due to this early definition of the macro.
>> But I'll definitely move it to later patch for clarity. 
>
>Yeah, the problem is that the (unused) definitions are not warned even when
>`make W=1`. And I guess I understand why. We have tons of unused definitions
>in the drivers that usually substitute (on whatever reasons) the actual
>documentation. It's hard to catch for the definitions like this without reading
>the code.
>
>...
>
>> >> 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?
>
>-- 
>With Best Regards,
>Andy Shevchenko
>
>
>