Re: [BUG] exynos5_i2c_xfer_atomic() can sleep.

[Marek Szyprowski <m.szyprowski@samsung.com>]

On 06.05.2026 08:51, Sebastian Andrzej Siewior wrote:
> While looking into the xfer_atomic i2c thingy, I've been looking at the
> exynos5_i2c_xfer_atomic() function and noticed that it has a
> disable_irq() invocation. Given that i2c_algorithm::xfer_atomic is
> called from atomic context (with either preemption or interrupts
> disabled) the might_sleep() in disable_irq() must lead to splat here.

Its me, who added that code, commit 445094c8a9fb1. I've tested that in the reboot/shutdown path and I'm quite sure that I've copied that irq_disable/enable from some other driver. I also cannot locate that might_sleep() in disable_irq(), where exactly it is?


> This looks very light tested because exynos5_i2c_poll_irqs_timeout()
> which should be invoked from atomic context has usleep_range(). This
> will schedule from atomic context is not good. I *think* this gets back
> with enabled interrupts.

Indeed this should be replaced with udelay.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland