Re: [BUG] exynos5_i2c_xfer_atomic() can sleep.

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-05-08 17:28:10 [+0200], Marek Szyprowski wrote:
> On 08.05.2026 12:42, Sebastian Andrzej Siewior wrote:
> > On 2026-05-08 12:35:51 [+0200], Marek Szyprowski wrote:
> >> Ah, it looks that I've checked irq_disable() code, so that's why I
> >> didn't find might_sleep() call. In the case of exynos5_i2c driver,
> >> probably switching to disable_irq_nosync() will be enough. I assume
> >> that all previous transfers have to be finished to start this atomic
> >> one, so waiting for interrupts to finish is not needed.
> > This looks kind of odd. Are the "other" transfers really done at this
> > point? Do you have a backtrace for me from the atomic path?
> 
> I thought that i2c core somehow serializes the transfers for the given master.
> 
> > Is this needed because you need to send the "power off" command via i2c?
> 
> Yes, most embedded boards do power off by sending i2c command to PMIC chip.

I'm wondering if you could "avoid" the interrupts-off part since
kernel_power_off() is called from preemtible context.

> 
> > Could you try to test with PREEMPT_RT? I'm sure how this works there.
> 
> I will check this, but so far I run all my tests without PREEMPT_RT

Right. I am curious if interrupts are really disabled on PREEMPT_RT or
if this happens as a side-effect of something that does not happen with
PREEMPT_RT enabled.

> Best regards

Sebastian