linux-kernel - RE: [PATCH v5 3/9] iio: imu: inv_icm45600: add buffer support in iio devices

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:
 <FR2PPF4571F02BCC81AF28562AE548DBC228C12A@FR2PPF4571F02BC.DEUP281.PROD.OUTLOOK.COM>
Date: Mon, 22 Sep 2025 08:52:00 +0000
From: Remi Buisson <Remi.Buisson@....com>
To: Remi Buisson <Remi.Buisson@....com>,
        Andy Shevchenko
	<andriy.shevchenko@...el.com>,
        Alexandre Belloni
	<alexandre.belloni@...tlin.com>,
        Frank Li <Frank.Li@....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 v5 3/9] iio: imu: inv_icm45600: add buffer support in iio
 devices


>>+Cc I³C people to comment on the returned values on the regmap. See below.
I did not see any feedback yet on the below I3C slicing issue, but I may have missed it.
How should we proceed going forward?

>>
>>On Thu, Sep 04, 2025 at 01:01:32PM +0000, Remi Buisson wrote:
>>> >From: Andy Shevchenko <andriy.shevchenko@...el.com> 
>>> >Sent: Thursday, August 21, 2025 11:21 AM
>>> >On Wed, Aug 20, 2025 at 02:24:21PM +0000, Remi Buisson via B4 Relay wrote:
>>
>>
>>> >> +	/* Try to read all FIFO data in internal buffer. */
>>> >> +	st->fifo.count = fifo_nb * packet_size;
>>> >> +	ret = regmap_noinc_read(st->map, INV_ICM45600_REG_FIFO_DATA,
>>> >> +				st->fifo.data, st->fifo.count);
>>> >> +	if (ret == -ENOTSUPP || ret == -EFBIG) {
>>> >
>>> >Strictly speaking this is a bit of layering issue, do we have other means to
>>> >check the support before even trying?
>>> 
>>> No unfortunately, we can't with current I3C regmap implementation.
>>> I2C and SPI regmaps are able to split transfers according to max_read_len.
>>> But for I3C, it is left to the controller driver, which usually only returns an error.
>>
>>Have it been discussed with I³C maintainers / stakeholders? Because this kind of APIs
>>will be hard to follow and even change for both sides caller and callee.
>Thanks for opening the discussion.
>We implemented the management of error, in a way that (we think) makes sense,
>whatever the below layers are doing.No feedback from I3C,
>
>>
>>> >> +		/* Read full fifo is not supported, read samples one by one. */
>>> >> +		ret = 0;
>>> >> +		for (i = 0; i < st->fifo.count && ret == 0; i += packet_size)
>>> >> +			ret = regmap_noinc_read(st->map, INV_ICM45600_REG_FIFO_DATA,
>>> >> +						&st->fifo.data[i], packet_size);
>>> >> +	}
>>> >> +	if (ret)
>>> >> +		return ret;
>>
>