Re: [BUG] exynos5_i2c_xfer_atomic() can sleep.

On 08.05.2026 17:28, 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 finally had some time to dig into this history. I've added support for atomic

transfers to the s3c23xx, exynos5 and brcmstd i2c controller drivers to get rid

of the warnings observed during the system reboot (example log from v6.7-rc1):

[info] Will now restart.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1788 at drivers/i2c/i2c-core.h:40 i2c_transfer+0xe8/0xf4
No atomic I2C transfer handler for 'i2c-0'
Modules linked in: snd_soc_hdmi_codec s5p_csis s5p_fimc exynos4_is_common v4l2_fwnode v4l2_async snd_soc_i2s snd_soc_idma snd_soc_odroid snd_soc_s3c_dma spi_s3c64xx lima snd_soc_max98090 drm_shmem_helper gpu_sched snd_soc_core ac97_bus snd_pcm_dmaengine snd_pcm snd_timer snd soundcore pwm_samsung s5p_mfc exynosdrm analogix_dp samsung_dsim ehci_exynos s5p_jpeg phy_exynos_usb2 v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videodev videobuf2_common mc exynos_rng s5p_sss s5p_cec rtc_s3c s3c2410_wdt phy_exynos_mipi_video governor_passive exynos_bus pwm_fan exynos_ppmu
CPU: 0 PID: 1788 Comm: reboot Not tainted 6.7.0-rc1-00001-g4ce67e6b4b7a #13398
Hardware name: Samsung Exynos (Flattened Device Tree)
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x40/0x4c
 dump_stack_lvl from __warn+0x78/0x124
 __warn from warn_slowpath_fmt+0x124/0x18c
 warn_slowpath_fmt from i2c_transfer+0xe8/0xf4
 i2c_transfer from regmap_i2c_read+0x64/0x9c
 regmap_i2c_read from _regmap_raw_read+0x10c/0x258
 _regmap_raw_read from _regmap_bus_read+0x40/0x6c
 _regmap_bus_read from _regmap_read+0x60/0x148
 _regmap_read from regmap_read+0x3c/0x60
 regmap_read from regulator_get_voltage_sel_regmap+0x38/0x88
 regulator_get_voltage_sel_regmap from regulator_get_voltage_rdev+0x70/0x170
 regulator_get_voltage_rdev from _regulator_do_set_voltage+0x38/0x600
 _regulator_do_set_voltage from regulator_set_voltage_rdev+0x5c/0x248
 regulator_set_voltage_rdev from regulator_do_balance_voltage+0x338/0x4c8
 regulator_do_balance_voltage from regulator_set_voltage_unlocked+0xd0/0x128
 regulator_set_voltage_unlocked from regulator_set_voltage+0x58/0x94
 regulator_set_voltage from _opp_config_regulator_single+0x44/0x118
 _opp_config_regulator_single from _set_opp+0x110/0x4e0
 _set_opp from dev_pm_opp_set_rate+0x114/0x220
 dev_pm_opp_set_rate from __cpufreq_driver_target+0x178/0x72c
 __cpufreq_driver_target from cpufreq_generic_suspend+0x28/0x50
 cpufreq_generic_suspend from cpufreq_suspend+0x98/0x11c
 cpufreq_suspend from device_shutdown+0x18/0x22c
 device_shutdown from kernel_restart+0x38/0x90
 kernel_restart from __do_sys_reboot+0x164/0x210
 __do_sys_reboot from ret_fast_syscall+0x0/0x54
Exception stack(0xf18edfa8 to 0xf18edff0)
dfa0:                   beb56e14 00000004 fee1dead 28121969 01234567 00000000
dfc0: beb56e14 00000004 004b269c 00000058 004c3000 00000000 00000000 00000000
dfe0: b6f196d0 beb56c78 004b0fec b6f196e8
---[ end trace 0000000000000000 ]---

In meantime the commit a3368e1186e3 ("i2c: core: Fix atomic xfer check for non-preempt

config") has been merged to final v6.7, which removed the need to use atomic i2c

transfers during system reboot/shutdown phases, so it turned out that the atomic

transfers are not really used on my setup.

>> 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

I've added PREEMPT_RT to my test configs but so far I see no issue related to i2c

transfers.

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