With preemption disabled, this boils down to
return system_state > SYSTEM_RUNNING (&& !0)
and will then generate a backtrace splash on each reboot on our
board:
# reboot -f
[ 12.687169] No atomic I2C transfer handler for 'i2c-0'
...
[ 12.806359] Call trace:
[ 12.808793] i2c_smbus_xfer+0x100/0x118
...
I'm not sure if this is now the expected behavior or not. There will be
no backtraces, if I build a preemptible kernel, nor will there be
backtraces if I revert this patch.
thanks for the report.
In your case, the warning comes from shutting down a regulator during
device_shutdown(), so nothing really problematic here.
However, later in
the "restart sequence", IRQs are disabled before the restart handlers
are called. If the reboot handlers would rely on irq-based
("non-atomic") i2c transfer, they might not work properly.
OTOH, the driver I'm using (drivers/i2c/busses/i2c-mt65xx.c) has no
*_atomic(). So the warning is correct. There is also [1], which seems to
be the same issue I'm facing.
-michael
[1] https://lore.kernel.org/linux-i2c/13271b9b-4132-46ef-abf8-2c311967bb46@xxxxxxxxxxx/
I tried to implement an atomic handler for the mt65xx, but I don't have
the respective hardware available to test it. I decided to use a similar
approach as done in drivers/i2c/busses/i2c-rk3x.c, which calls the IRQ
handler in a while loop if an atomic xfer is requested. IMHO, this
should work with IRQs enabled and disabled, but I am not sure if this is
the best approach...