Hey Troy and Alexandre,
any objections asking Greg to add following recent v4.15 changes into
stable branch 4.14?
05a03bf rtc: m41t80: remove unneeded checks from m41t80_sqw_set_rate
13bb1d7 rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared
2cb90ed rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate
c8384bb rtc: m41t80: fix m41t80_sqw_round_rate return value
de6042d rtc: m41t80: m41t80_sqw_set_rate should return 0 on success
Without these patches, deadlock warnings showing up in 4.14:
======================================================
WARNING: possible circular locking dependency detected
4.14.8-00011-gd203938 #11 Not tainted
------------------------------------------------------
kworker/1:2/133 is trying to acquire lock:
(prepare_lock){+.+.}, at: [<c04951d0>] clk_prepare_lock+0x80/0xf4
but task is already holding lock:
(i2c_register_adapter){+.+.}, at: [<c069305c>] i2c_adapter_lock_bus+0x14/0x18
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (i2c_register_adapter){+.+.}:
rt_mutex_lock+0x44/0x5c
i2c_adapter_lock_bus+0x14/0x18
i2c_transfer+0xa8/0xbc
i2c_smbus_xfer+0x214/0x5cc
i2c_smbus_read_byte_data+0x3c/0x4c
m41t80_sqw_recalc_rate+0x24/0x58
clk_register+0x3c8/0x638
m41t80_probe+0x224/0x378
i2c_device_probe+0x1dc/0x26c
driver_probe_device+0x278/0x300
__driver_attach+0xbc/0xc0
bus_for_each_dev+0x74/0xa8
driver_attach+0x20/0x28
bus_add_driver+0x188/0x210
driver_register+0x80/0x100
i2c_register_driver+0x40/0x8c
m41t80_driver_init+0x18/0x20
do_one_initcall+0x44/0x17c
kernel_init_freeable+0x11c/0x1dc
kernel_init+0x10/0x11c
ret_from_fork+0x14/0x20
-> #0 (prepare_lock){+.+.}:
lock_acquire+0x78/0x98
__mutex_lock+0x54/0x988
mutex_lock_nested+0x24/0x2c
clk_prepare_lock+0x80/0xf4
clk_core_get_rate+0x14/0x64
clk_get_rate+0x1c/0x20
i2c_imx_start+0x20/0x1cc
i2c_imx_xfer+0x38/0xb84
__i2c_transfer+0x138/0x27c
i2c_transfer+0x78/0xbc
i2c_master_send+0x44/0x54
regmap_i2c_write+0x18/0x34
_regmap_raw_write+0x56c/0x668
_regmap_bus_raw_write+0x74/0x94
_regmap_write+0x60/0x9c
_regmap_update_bits+0xc8/0xcc
regmap_update_bits_base+0x58/0x7c
regulator_set_voltage_sel_regmap+0x50/0xa0
_regulator_do_set_voltage+0x280/0x35c
regulator_set_voltage_unlocked+0xec/0x254
regulator_set_voltage_unlocked+0x1e8/0x254
regulator_set_voltage+0x30/0x5c
imx6q_set_target+0xb8/0x4e0
__cpufreq_driver_target+0x224/0x540
od_dbs_update+0xa0/0x168
dbs_work_handler+0x34/0x60
process_one_work+0x194/0x41c
worker_thread+0x34/0x538
kthread+0x11c/0x158
ret_from_fork+0x14/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(i2c_register_adapter);
lock(prepare_lock);
lock(i2c_register_adapter);
lock(prepare_lock);
*** DEADLOCK ***
7 locks held by kworker/1:2/133:
#0: ("events"){+.+.}, at: [<c014144c>] process_one_work+0x128/0x41c
#1: ((&policy_dbs->work)){+.+.}, at: [<c014144c>] process_one_work+0x128/0x41c
#2: (&policy_dbs->update_mutex){+.+.}, at: [<c06da1a0>] dbs_work_handler+0x28/0x60
#3: (&rdev->mutex){+.+.}, at: [<c04a8cac>] regulator_lock_supply+0x24/0x44
#4: (&rdev->mutex/1){+.+.}, at: [<c04a8cac>] regulator_lock_supply+0x24/0x44
#5: (da9062_core:870:(config)->lock){+.+.}, at: [<c055f2c8>] regmap_lock_mutex+0x14/0x18
#6: (i2c_register_adapter){+.+.}, at: [<c069305c>] i2c_adapter_lock_bus+0x14/0x18
Thanks
-- Christoph
