2024-01-04 08:17:29

by Benjamin Bara

[permalink] [raw]
Subject: [PATCH] i2c: core: Fix atomic xfer check for non-preempt config

From: Benjamin Bara <[email protected]>

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: [email protected] # v5.2+
Signed-off-by: Benjamin Bara <[email protected]>
---
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/[email protected]/
---
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 <[email protected]>



2024-01-04 09:19:18

by Michael Walle

[permalink] [raw]
Subject: Re: [PATCH] i2c: core: Fix atomic xfer check for non-preempt config

> From: Benjamin Bara <[email protected]>
>
> 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: [email protected] # v5.2+
> Signed-off-by: Benjamin Bara <[email protected]>

Tested-by: Michael Walle <[email protected]>

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

-michael

2024-01-04 09:33:51

by Tor Vic

[permalink] [raw]
Subject: Re: [PATCH] i2c: core: Fix atomic xfer check for non-preempt config



On 1/4/24 09:17, Benjamin Bara wrote:
> From: Benjamin Bara <[email protected]>
>
> 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: [email protected] # v5.2+
> Signed-off-by: Benjamin Bara <[email protected]>

On x86_64 and 6.7-rc8 with voluntary preemption:

Tested-by: Tor Vic <[email protected]>

Thanks for the fix!

>
> Best regards,

2024-01-04 17:05:07

by Wolfram Sang

[permalink] [raw]
Subject: Re: [PATCH] i2c: core: Fix atomic xfer check for non-preempt config

On Thu, Jan 04, 2024 at 09:17:08AM +0100, Benjamin Bara wrote:
> From: Benjamin Bara <[email protected]>
>
> 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: [email protected] # v5.2+
> Signed-off-by: Benjamin Bara <[email protected]>

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!


Attachments:
(No filename) (1.75 kB)
signature.asc (849.00 B)
Download all attachments