From: Benjamin Bara <benjamin.bara@skidata.com>

Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when
!preemptible"), the whole reboot/power off sequence on non-preempt kernels
is using atomic i2c xfer, as !preemptible() always results to 1.

During device_shutdown(), the i2c might be used a lot and not all busses
have implemented an atomic xfer handler. This results in a lot of
avoidable noise, like:

[   12.687169] No atomic I2C transfer handler for 'i2c-0'
[   12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118
...

Fix this by allowing non-atomic xfer when the interrupts are enabled, as
it was before.

Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
---
Hi!

As there are a couple of bug reports already about missing atomic i2c
xfer handler warnings on non-preemptive configs around [1], this is an
attempt to reduce the avoidable noise.

thanks & regards
Benjamin

[1] https://lore.kernel.org/all/20230327-tegra-pmic-reboot-v7-2-18699d5dcd76@skidata.com/
---
 drivers/i2c/i2c-core.h | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
index 05b8b8dfa9bd..e48c0cd21438 100644
--- a/drivers/i2c/i2c-core.h
+++ b/drivers/i2c/i2c-core.h
@@ -3,6 +3,7 @@
  * i2c-core.h - interfaces internal to the I2C framework
  */
 
+#include <linux/kconfig.h>
 #include <linux/rwsem.h>
 
 struct i2c_devinfo {
@@ -29,7 +30,14 @@ int i2c_dev_irq_from_resources(const struct resource *resources,
  */
 static inline bool i2c_in_atomic_xfer_mode(void)
 {
-	return system_state > SYSTEM_RUNNING && !preemptible();
+	/*
+	 * non-atomic xfers often use wait_for_completion*() calls to wait
+	 * efficiently (schedule out voluntarily) on the completion of the xfer,
+	 * which are then "completed" by an IRQ. If the constraints are not
+	 * satisfied, fall back to an atomic xfer.
+	 */
+	return system_state > SYSTEM_RUNNING &&
+	       (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? !preemptible() : irqs_disabled());
 }
 
 static inline int __i2c_lock_bus_helper(struct i2c_adapter *adap)

---
base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
change-id: 20240104-i2c-atomic-2435f835b598

Best regards,
-- 
Benjamin Bara <benjamin.bara@skidata.com>

On Thu, Jan 04, 2024 at 09:17:08AM +0100, Benjamin Bara wrote:
> From: Benjamin Bara <benjamin.bara@skidata.com>
> 
> Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when
> !preemptible"), the whole reboot/power off sequence on non-preempt kernels
> is using atomic i2c xfer, as !preemptible() always results to 1.
> 
> During device_shutdown(), the i2c might be used a lot and not all busses
> have implemented an atomic xfer handler. This results in a lot of
> avoidable noise, like:
> 
> [   12.687169] No atomic I2C transfer handler for 'i2c-0'
> [   12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118
> ...
> 
> Fix this by allowing non-atomic xfer when the interrupts are enabled, as
> it was before.
> 
> Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible")
> Cc: stable@vger.kernel.org # v5.2+
> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>

Thanks! The code looks what I also would have suggested reading the bug
reports. So:

Applied to for-current, thanks!

> +	/*
> +	 * non-atomic xfers often use wait_for_completion*() calls to wait
> +	 * efficiently (schedule out voluntarily) on the completion of the xfer,
> +	 * which are then "completed" by an IRQ. If the constraints are not
> +	 * satisfied, fall back to an atomic xfer.
> +	 */
> +	return system_state > SYSTEM_RUNNING &&
> +	       (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? !preemptible() : irqs_disabled());

I removed the comment, though. I don't think it explains the following
code well enough, i.e. why we have a decision based on a Kconfig
symbol. We can (and should) fix this incrementally, though. I hope this
is OK with everyone.

Thanks to everyone putting work into this. Much appreciated!

On 1/4/24 09:17, Benjamin Bara wrote:
> From: Benjamin Bara <benjamin.bara@skidata.com>
> 
> Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when
> !preemptible"), the whole reboot/power off sequence on non-preempt kernels
> is using atomic i2c xfer, as !preemptible() always results to 1.
> 
> During device_shutdown(), the i2c might be used a lot and not all busses
> have implemented an atomic xfer handler. This results in a lot of
> avoidable noise, like:
> 
> [   12.687169] No atomic I2C transfer handler for 'i2c-0'
> [   12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118
> ...
> 
> Fix this by allowing non-atomic xfer when the interrupts are enabled, as
> it was before.
> 
> Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible")
> Cc: stable@vger.kernel.org # v5.2+
> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>

On x86_64 and 6.7-rc8 with voluntary preemption:

Tested-by: Tor Vic <torvic9@mailbox.org>

Thanks for the fix!

> 
> Best regards,

> From: Benjamin Bara <benjamin.bara@skidata.com>
> 
> Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when
> !preemptible"), the whole reboot/power off sequence on non-preempt 
> kernels
> is using atomic i2c xfer, as !preemptible() always results to 1.
> 
> During device_shutdown(), the i2c might be used a lot and not all 
> busses
> have implemented an atomic xfer handler. This results in a lot of
> avoidable noise, like:
> 
> [   12.687169] No atomic I2C transfer handler for 'i2c-0'
> [   12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 
> i2c_smbus_xfer+0x100/0x118
> ...
> 
> Fix this by allowing non-atomic xfer when the interrupts are enabled, 
> as
> it was before.
> 
> Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when 
> !preemptible")
> Cc: stable@vger.kernel.org # v5.2+
> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>

Tested-by: Michael Walle <mwalle@kernel.org>

Thanks for the fix, if there will be a -rc9 this should definitely go 
in.

-michael