linux-stable.git/drivers/rtc, branch v4.14.41

rtc: opal: Fix OPAL RTC driver OPAL_BUSY loops

2018-05-01T19:58:24+00:00

commit 682e6b4da5cbe8e9a53f979a58c2a9d7dc997175 upstream.

The OPAL RTC driver does not sleep in case it gets OPAL_BUSY or
OPAL_BUSY_EVENT from firmware, which causes large scheduling
latencies, up to 50 seconds have been observed here when RTC stops
responding (BMC reboot can do it).

Fix this by converting it to the standard form OPAL_BUSY loop that
sleeps.

Fixes: 628daa8d5abf ("powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks")
Cc: stable@vger.kernel.org # v3.2+
Signed-off-by: Nicholas Piggin 
Acked-by: Alexandre Belloni 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

clk: divider: fix incorrect usage of container_of

2018-04-12T10:32:13+00:00

[ Upstream commit 12a26c298d2a8b1cab498533fa65198e49e3afd3 ]

divider_recalc_rate() is an helper function used by clock divider of
different types, so the structure containing the 'hw' pointer is not
always a 'struct clk_divider'

At the following line:
> div = _get_div(table, val, flags, divider->width);

in several cases, the value of 'divider->width' is garbage as the actual
structure behind this memory is not a 'struct clk_divider'

Fortunately, this width value is used by _get_val() only when
CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
far when the structure is not a 'struct clk_divider'. This is probably
why we did not notice this bug before

Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero")
Signed-off-by: Jerome Brunet 
Acked-by: Alexandre Belloni 
Acked-by: Sylvain Lemieux 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: ac100: Fix multiple race conditions

2018-03-24T10:01:24+00:00

[ Upstream commit 994ec64c0a193940be7a6fd074668b9446d3b6c3 ]

The probe function is not allowed to fail after registering the RTC because
the following may happen:

CPU0:                                CPU1:
sys_load_module()
 do_init_module()
  do_one_initcall()
   cmos_do_probe()
    rtc_device_register()
     __register_chrdev()
     cdev->owner = struct module*
                                     open("/dev/rtc0")
    rtc_device_unregister()
  module_put()
  free_module()
   module_free(mod->module_core)
   /* struct module *module is now
      freed */
                                      chrdev_open()
                                       spin_lock(cdev_lock)
                                       cdev_get()
                                        try_module_get()
                                         module_is_live()
                                         /* dereferences already
                                            freed struct module* */

Also, the interrupt handler: ac100_rtc_irq() is dereferencing chip->rtc but
this may still be NULL when it is called, resulting in:
Unable to handle kernel NULL pointer dereference at virtual address 00000194
pgd = (ptrval)
[00000194] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 72 Comm: irq/71-ac100-rt Not tainted 4.15.0-rc1-next-20171201-dirty #120
Hardware name: Allwinner sun8i Family
task: (ptrval) task.stack: (ptrval)
PC is at mutex_lock+0x14/0x3c
LR is at ac100_rtc_irq+0x38/0xc8
pc : []    lr : []    psr: 60000053
sp : ee9c9f28  ip : 00000000  fp : ee9adfdc
r10: 00000000  r9 : c0a04c48  r8 : c015ed18
r7 : ee9bd600  r6 : ee9c9f28  r5 : ee9af590  r4 : c0a04c48
r3 : ef3cb3c0  r2 : 00000000  r1 : ee9af590  r0 : 00000194
Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 4000406a  DAC: 00000051
Process irq/71-ac100-rt (pid: 72, stack limit = 0x(ptrval))
Stack: (0xee9c9f28 to 0xee9ca000)
9f20:                   00000000 7c2fd1be c015ed18 ee9adf40 ee9c0400 ee9c0400
9f40: ee9adf40 c015ed34 ee9c8000 ee9adf64 ee9c0400 c015f040 ee9adf80 00000000
9f60: c015ee24 7c2fd1be ee9adfc0 ee9adf80 00000000 ee9c8000 ee9adf40 c015eef4
9f80: ef1eba34 c0138f14 ee9c8000 ee9adf80 c0138df4 00000000 00000000 00000000
9fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[] (mutex_lock) from [] (ac100_rtc_irq+0x38/0xc8)
[] (ac100_rtc_irq) from [] (irq_thread_fn+0x1c/0x54)
[] (irq_thread_fn) from [] (irq_thread+0x14c/0x214)
[] (irq_thread) from [] (kthread+0x120/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)

Solve both issues by moving to
devm_rtc_allocate_device()/rtc_register_device()

Reported-by: Quentin Schulz 
Tested-by: Quentin Schulz 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe()

2018-03-19T07:42:49+00:00

[ Upstream commit f2eef045de9defbc6fc6b72b17f0941cbe26c81d ]

brcmstb_waketmr_probe() does not disable timer->clk on error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: c4f07ecee22e ("rtc: brcmstb-waketimer: Add Broadcom STB wake-timer")
Signed-off-by: Alexey Khoroshilov 
Reviewed-by: Florian Fainelli 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc-opal: Fix handling of firmware error codes, prevent busy loops

2018-02-22T14:42:25+00:00

commit 5b8b58063029f02da573120ef4dc9079822e3cda upstream.

According to the OPAL docs:
  skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt
  skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt

OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and
this indicates either a transient or permanent error.

Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a
permanent error particularly well, in that you could end up in a busy
loop.

This was not too hard to trigger on an AMI BMC based OpenPOWER machine
doing a continuous "ipmitool mc reset cold" to the BMC, the result of
that being that we'd get stuck in an infinite loop in
opal_get_rtc_time().

We now retry a few times before returning the error higher up the
stack.

Fixes: 16b1d26e77b1 ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform")
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Stewart Smith 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

rtc: m41t80: remove unneeded checks from m41t80_sqw_set_rate

2018-01-05T14:48:59+00:00

commit 05a03bf260e0480bfc0db91b1fdbc2115e3f193b upstream.

m41t80_sqw_set_rate will be called with the result from
m41t80_sqw_round_rate, so might as well make
m41t80_sqw_set_rate(n) same as
m41t80_sqw_set_rate(m41t80_sqw_round_rate(n))

As Russell King wrote[1],
"clk_round_rate() is supposed to tell you what you end up with if you
ask clk_set_rate() to set the exact same value you passed in - but
clk_round_rate() won't modify the hardware."

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080175.html

Signed-off-by: Troy Kisky 
Signed-off-by: Alexandre Belloni 
Cc: Christoph Fritz 
Signed-off-by: Greg Kroah-Hartman

rtc: m41t80: avoid i2c read in m41t80_sqw_is_prepared

2018-01-05T14:48:59+00:00

commit 13bb1d78f2e372ec0d9b30489ac63768240140fc upstream.

This is a little more efficient and avoids the warning

 WARNING: possible circular locking dependency detected
 4.14.0-rc7-00010 #16 Not tainted
 ------------------------------------------------------
 kworker/2:1/70 is trying to acquire lock:
  (prepare_lock){+.+.}, at: [] clk_prepare_lock+0x80/0xf4

 but task is already holding lock:
  (i2c_register_adapter){+.+.}, at: []
		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+0x20c/0x5d8
        i2c_smbus_read_byte_data+0x38/0x48
        m41t80_sqw_is_prepared+0x18/0x28

Signed-off-by: Troy Kisky 
Signed-off-by: Alexandre Belloni 
Cc: Christoph Fritz 
Signed-off-by: Greg Kroah-Hartman

rtc: m41t80: avoid i2c read in m41t80_sqw_recalc_rate

2018-01-05T14:48:58+00:00

commit 2cb90ed3de1e279dbaf23df141f54eb9fb1861e6 upstream.

This is a little more efficient, and avoids the warning

 WARNING: possible circular locking dependency detected
 4.14.0-rc7-00007 #14 Not tainted
 ------------------------------------------------------
 alsactl/330 is trying to acquire lock:
 (prepare_lock){+.+.}, at: [] clk_prepare_lock+0x80/0xf4

 but task is already holding lock:
 (i2c_register_adapter){+.+.}, at: []
		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+0x20c/0x5d8
        i2c_smbus_read_byte_data+0x38/0x48
        m41t80_sqw_recalc_rate+0x24/0x58

Signed-off-by: Troy Kisky 
Signed-off-by: Alexandre Belloni 
Cc: Christoph Fritz 
Signed-off-by: Greg Kroah-Hartman

rtc: m41t80: fix m41t80_sqw_round_rate return value

2018-01-05T14:48:58+00:00

commit c8384bb04261b9d32fe7402a6068ddaf38913b23 upstream.

Previously it was returning the best of
32768, 8192, 1024, 64, 2, 0

Now, best of
32768, 8192, 4096, 2048, 1024, 512, 256, 128,
64, 32, 16, 8, 4, 2, 1, 0

Signed-off-by: Troy Kisky 
Signed-off-by: Alexandre Belloni 
Cc: Christoph Fritz 
Signed-off-by: Greg Kroah-Hartman

rtc: m41t80: m41t80_sqw_set_rate should return 0 on success

2018-01-05T14:48:58+00:00

commit de6042d2fa8afe22b76e3c68fd6e9584c9415a3b upstream.

Previously it was returning -EINVAL upon success.

Signed-off-by: Troy Kisky 
Signed-off-by: Alexandre Belloni 
Cc: Christoph Fritz 
Signed-off-by: Greg Kroah-Hartman