| Message ID | 20240104-i2c-atomic-v1-1-a3a186f21c36@skidata.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | i2c: core: Fix atomic xfer check for non-preempt config | expand |
> 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
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,
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!
Thanks a lot for this patch! It fixed big backtrace I saw at very last stage of reboot. That backtrace occupied whole FullHD screen. Now it is gone. Thanks! My computer is laptop Dell Inspiron. I hope this patch will soon arrive to debian buster lts Askar Safin > 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>
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)