rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14 ?

rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14 ?

[Christoph Fritz]

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

Re: rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14 ?

[Alexandre Belloni]

On 22/12/2017 at 13:50:27 +0100, Christoph Fritz wrote:
> Hey Troy and Alexandre,
> 
>  any objections asking Greg to add following recent v4.15 changes into
> stable branch 4.14?
> 

No objection, they can be safely backported.

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

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14

[Christoph Fritz]

Hi Greg

On Fri, 2017-12-22 at 14:05 +0100, Alexandre Belloni wrote:
> On 22/12/2017 at 13:50:27 +0100, Christoph Fritz wrote:
> > Hey Troy and Alexandre,
> > 
> >  any objections asking Greg to add following recent v4.15 changes into
> > stable branch 4.14?
> > 
> 
> No objection, they can be safely backported.

@Greg: Could you queue the following commits for 4.14.9 ?

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

<snip>

Thanks
 -- Christoph

Re: rtc: m41t80rtc: recent v4.15 changes ready for stable branch 4.14

[Greg Kroah-Hartman]

On Fri, Dec 22, 2017 at 03:47:03PM +0100, Christoph Fritz wrote:
> Hi Greg
> 
> On Fri, 2017-12-22 at 14:05 +0100, Alexandre Belloni wrote:
> > On 22/12/2017 at 13:50:27 +0100, Christoph Fritz wrote:
> > > Hey Troy and Alexandre,
> > > 
> > >  any objections asking Greg to add following recent v4.15 changes into
> > > stable branch 4.14?
> > > 
> > 
> > No objection, they can be safely backported.
> 
> @Greg: Could you queue the following commits for 4.14.9 ?
> 
> > > 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

All now queued up, sorry for the delay, been a bit busy lately :)

greg k-h