1. 21 Feb, 2017 4 commits
  2. 12 Feb, 2017 3 commits
  3. 11 Feb, 2017 2 commits
  4. 01 Feb, 2017 8 commits
  5. 24 Jan, 2017 2 commits
  6. 22 Jan, 2017 3 commits
    • Amelie Delaunay's avatar
      rtc: stm32: fix comparison warnings · 1d70ba3b
      Amelie Delaunay authored
      This patches fixes comparison between signed and unsigned values as it
      could produce an incorrect result when the signed value is converted to
      drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_valid_alrm':
      drivers/rtc/rtc-stm32.c:404:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
        if ((((tm->tm_year > cur_year) &&
      It also fixes comparison always true or false due to the fact that unsigned
      value is compared against zero with >= or <:
      drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_init':
      drivers/rtc/rtc-stm32.c:514:35: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
        for (pred_a = pred_a_max; pred_a >= 0; pred_a-- ) {
      drivers/rtc/rtc-stm32.c:530:44: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
           (rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
      Fixes: 4e64350f ("rtc: add STM32 RTC driver")
      Signed-off-by: default avatarAmelie Delaunay <[email protected]>
      Signed-off-by: default avatarAlexandre Belloni <[email protected]>
    • Amelie Delaunay's avatar
      rtc: stm32: use 0 instead of ~PWR_CR_DBP in regmap_update_bits · a560c527
      Amelie Delaunay authored
      Using the ~ operator on a BIT() constant results in a large 'unsigned long'
      constant that won't fit into an 'unsigned int' function argument on 64-bit
      architectures, resulting in a harmless build warning in x86 allmodconfig:
      drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_probe':
      drivers/rtc/rtc-stm32.c:651:51: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
        regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
      As PWR_CR_DBP mask prevents other bits to be cleared, replace all
      ~PWR_CR_DBP by 0.
      Fixes: 4e64350f ("rtc: add STM32 RTC driver")
      Signed-off-by: default avatarArnd Bergmann <[email protected]>
      Signed-off-by: default avatarAmelie Delaunay <[email protected]>
      Signed-off-by: default avatarAlexandre Belloni <[email protected]>
    • Thierry Reding's avatar
      rtc: tegra: Implement clock handling · 5fa40869
      Thierry Reding authored
      Accessing the registers of the RTC block on Tegra requires the module
      clock to be enabled. This only works because the RTC module clock will
      be enabled by default during early boot. However, because the clock is
      unused, the CCF will disable it at late_init time. This causes the RTC
      to become unusable afterwards. This can easily be reproduced by trying
      to use the RTC:
      	$ hwclock --rtc /dev/rtc1
      This will hang the system. I ran into this by following up on a report
      by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It
      turns out that the rtc-tegra driver's ->shutdown() implementation will
      hang the CPU, because of the disabled clock, before the system can be
      What confused me for a while is that the same driver is used on prior
      Tegra generations where the hang can not be observed. However, as Peter
      De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC
      clock is enabled by the tegra20_timer.c clocksource driver, which uses
      the RTC to provide a persistent clock. This code is never enabled on
      64-bit Tegra because the persistent clock infrastructure does not exist
      on 64-bit ARM.
      The proper fix for this is to add proper clock handling to the RTC
      driver in order to ensure that the clock is enabled when the driver
      requires it. All device trees contain the clock already, therefore
      no additional changes are required.
      Reported-by: Martin Michlmayr's avatarMartin Michlmayr <[email protected]>
      Acked-By Peter De Schrijver <[email protected]>
      Signed-off-by: default avatarThierry Reding <[email protected]>
      Signed-off-by: default avatarAlexandre Belloni <[email protected]>
  7. 13 Jan, 2017 5 commits
  8. 12 Jan, 2017 1 commit
    • Russell King's avatar
      rtc: armada38x: make struct rtc_class_ops const · d748c981
      Russell King authored
      Armada38x wants to modify its rtc_class_ops to remove the interrupt
      handling when there is no usable interrupt, but this means we leave
      function pointers in writable memory.
      Since rtc_class_ops is small, arrange to have two instances, one for
      when we have interrupts, and one for when we have none, both marked
      const.  This allows the compiler to place them in read-only memory,
      which is better than placing them in __ro_after_init.
      Thanks to Bhumika Goyal <[email protected]> for pointing out that
      the structure was writable and submitting a patch to add
      Signed-off-by: default avatarRussell King <[email protected]>
      Signed-off-by: default avatarAlexandre Belloni <[email protected]>
  9. 11 Jan, 2017 6 commits
  10. 10 Jan, 2017 2 commits
  11. 04 Jan, 2017 1 commit
    • Fabien Lahoudere's avatar
      rtc: rx8010: change lock mechanism · 666b5d1e
      Fabien Lahoudere authored
      Remove spinlock and use the "rtc->ops_lock" from RTC subsystem instead.
      spin_lock_irqsave() is not needed here because we do not have hard IRQs.
      This patch fixes the following issue:
      [email protected] b850v3:~# hwclock --systohc
      [email protected] b850v3:~# hwclock --systohc
      [email protected] b850v3:~# hwclock --systohc
      [email protected] b850v3:~# hwclock --systohc
      [email protected] b850v3:~# hwclock --systohc
      [   82.108175] BUG: spinlock wrong CPU on CPU#0, hwclock/855
      [   82.113660]  lock: 0xedb4899c, .magic: dead4ead, .owner: hwclock/855, .owner_cpu: 1
      [   82.121329] CPU: 0 PID: 855 Comm: hwclock Not tainted 4.8.0-00042-g09d5410-dirty #20
      [   82.129078] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      [   82.135609] Backtrace:
      [   82.138090] [<8010d378>] (dump_backtrace) from [<8010d5c0>] (show_stack+0x20/0x24)
      [   82.145664]  r7:ec936000 r6:600a0013 r5:00000000 r4:81031680
      [   82.151402] [<8010d5a0>] (show_stack) from [<80401518>] (dump_stack+0xb4/0xe8)
      [   82.158636] [<80401464>] (dump_stack) from [<8017b8b0>] (spin_dump+0x84/0xcc)
      [   82.165775]  r10:00000000 r9:ec936000 r8:81056090 r7:600a0013 r6:edb4899c r5:edb4899c
      [   82.173691]  r4:e5033e00 r3:00000000
      [   82.177308] [<8017b82c>] (spin_dump) from [<8017bcb0>] (do_raw_spin_unlock+0x108/0x130)
      [   82.185314]  r5:edb4899c r4:edb4899c
      [   82.188938] [<8017bba8>] (do_raw_spin_unlock) from [<8094b93c>] (_raw_spin_unlock_irqrestore+0x34/0x54)
      [   82.198333]  r5:edb4899c r4:600a0013
      [   82.201953] [<8094b908>] (_raw_spin_unlock_irqrestore) from [<8065b090>] (rx8010_set_time+0x14c/0x188)
      [   82.211261]  r5:00000020 r4:edb48990
      [   82.214882] [<8065af44>] (rx8010_set_time) from [<80653fe4>] (rtc_set_time+0x70/0x104)
      [   82.222801]  r7:00000051 r6:edb39da0 r5:edb39c00 r4:ec937e8c
      [   82.228535] [<80653f74>] (rtc_set_time) from [<80655774>] (rtc_dev_ioctl+0x3c4/0x674)
      [   82.236368]  r7:00000051 r6:7ecf1b74 r5:00000000 r4:edb39c00
      [   82.242106] [<806553b0>] (rtc_dev_ioctl) from [<80284034>] (do_vfs_ioctl+0xa4/0xa6c)
      [   82.249851]  r8:00000003 r7:80284a40 r6:ed1e9c80 r5:edb44e60 r4:7ecf1b74
      [   82.256642] [<80283f90>] (do_vfs_ioctl) from [<80284a40>] (SyS_ioctl+0x44/0x6c)
      [   82.263953]  r10:00000000 r9:ec936000 r8:7ecf1b74 r7:4024700a r6:ed1e9c80 r5:00000003
      [   82.271869]  r4:ed1e9c80
      [   82.274432] [<802849fc>] (SyS_ioctl) from [<80108520>] (ret_fast_syscall+0x0/0x1c)
      [   82.282005]  r9:ec936000 r8:801086c4 r7:00000036 r6:00000000 r5:00000003 r4:0008e1bc
      [email protected] b850v3:~#
      Message from [email protected] at Dec  3 11:17:08 ...
       kernel:[   82.108175] BUG: spinlock wrong CPU on CPU#0, hwclock/855
      Message from [email protected] at Dec  3 11:17:08 ...
       kernel:[   82.113660]  lock: 0xedb4899c, .magic: dead4ead, .owner: hwclock/855, .owner_cpu: 1
      hwclock --systohc
      [email protected] b850v3:~#
      Signed-off-by: default avatarFabien Lahoudere <[email protected]>
      Signed-off-by: default avatarAlexandre Belloni <[email protected]>
  12. 26 Dec, 2016 2 commits
    • Linus Torvalds's avatar
      Linux 4.10-rc1 · 7ce7d89f
      Linus Torvalds authored
    • Larry Finger's avatar
      powerpc: Fix build warning on 32-bit PPC · 8ae679c4
      Larry Finger authored
      I am getting the following warning when I build kernel 4.9-git on my
      PowerBook G4 with a 32-bit PPC processor:
          AS      arch/powerpc/kernel/misc_32.o
        arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef]
      This problem is evident after commit 989cea5c ("kbuild: prevent
      lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an
      error that has been in the code since 2005 when this source file was
      created.  That was with commit 9994a338 ("powerpc: Introduce
      entry_{32,64}.S, misc_{32,64}.S, systbl.S").
      The offending line does not make a lot of sense.  This error does not
      seem to cause any errors in the executable, thus I am not recommending
      that it be applied to any stable versions.
      Thanks to Nicholas Piggin for suggesting this solution.
      Fixes: 9994a338 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S")
      Signed-off-by: default avatarLarry Finger <[email protected]>
      Cc: Nicholas Piggin <[email protected]>
      Cc: Benjamin Herrenschmidt <[email protected]>
      Cc: Paul Mackerras <[email protected]>
      Cc: Michael Ellerman <[email protected]>
      Cc: [email protected]
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
  13. 25 Dec, 2016 1 commit
    • Linus Torvalds's avatar
      avoid spurious "may be used uninitialized" warning · d33d5a6c
      Linus Torvalds authored
      The timer type simplifications caused a new gcc warning:
        drivers/base/power/domain.c: In function ‘genpd_runtime_suspend’:
        drivers/base/power/domain.c:562:14: warning: ‘time_start’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start));
      despite the actual use of "time_start" not having changed in any way.
      It appears that simply changing the type of ktime_t from a union to a
      plain scalar type made gcc check the use.
      The variable wasn't actually used uninitialized, but gcc apparently
      failed to notice that the conditional around the use was exactly the
      same as the conditional around the initialization of that variable.
      Add an unnecessary initialization just to shut up the compiler.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>