1. 26 2月, 2020 1 次提交
  2. 18 2月, 2020 2 次提交
  3. 17 2月, 2020 1 次提交
    • T
      x86/vdso: Move VDSO clocksource state tracking to callback · eec399dd
      Thomas Gleixner 提交于
      All architectures which use the generic VDSO code have their own storage
      for the VDSO clock mode. That's pointless and just requires duplicate code.
      
      X86 abuses the function which retrieves the architecture specific clock
      mode storage to mark the clocksource as used in the VDSO. That's silly
      because this is invoked on every tick when the VDSO data is updated.
      
      Move this functionality to the clocksource::enable() callback so it gets
      invoked once when the clocksource is installed. This allows to make the
      clock mode storage generic.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: Michael Kelley <mikelley@microsoft.com>  (Hyper-V parts)
      Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> (VDSO parts)
      Acked-by: Juergen Gross <jgross@suse.com> (Xen parts)
      Link: https://lkml.kernel.org/r/20200207124402.934519777@linutronix.de
      
      eec399dd
  4. 17 1月, 2020 16 次提交
  5. 13 1月, 2020 1 次提交
  6. 06 1月, 2020 1 次提交
  7. 05 1月, 2020 1 次提交
    • Z
      clocksource: riscv: add notrace to riscv_sched_clock · 9d05c18e
      Zong Li 提交于
      When enabling ftrace graph tracer, it gets the tracing clock in
      ftrace_push_return_trace().  Eventually, it invokes riscv_sched_clock()
      to get the clock value.  If riscv_sched_clock() isn't marked with
      'notrace', it will call ftrace_push_return_trace() and cause infinite
      loop.
      
      The result of failure as follow:
      
      command: echo function_graph >current_tracer
      [   46.176787] Unable to handle kernel paging request at virtual address ffffffe04fb38c48
      [   46.177309] Oops [#1]
      [   46.177478] Modules linked in:
      [   46.177770] CPU: 0 PID: 256 Comm: $d Not tainted 5.5.0-rc1 #47
      [   46.177981] epc: ffffffe00035e59a ra : ffffffe00035e57e sp : ffffffe03a7569b0
      [   46.178216]  gp : ffffffe000d29b90 tp : ffffffe03a756180 t0 : ffffffe03a756968
      [   46.178430]  t1 : ffffffe00087f408 t2 : ffffffe03a7569a0 s0 : ffffffe03a7569f0
      [   46.178643]  s1 : ffffffe00087f408 a0 : 0000000ac054cda4 a1 : 000000000087f411
      [   46.178856]  a2 : 0000000ac054cda4 a3 : 0000000000373ca0 a4 : ffffffe04fb38c48
      [   46.179099]  a5 : 00000000153e22a8 a6 : 00000000005522ff a7 : 0000000000000005
      [   46.179338]  s2 : ffffffe03a756a90 s3 : ffffffe00032811c s4 : ffffffe03a756a58
      [   46.179570]  s5 : ffffffe000d29fe0 s6 : 0000000000000001 s7 : 0000000000000003
      [   46.179809]  s8 : 0000000000000003 s9 : 0000000000000002 s10: 0000000000000004
      [   46.180053]  s11: 0000000000000000 t3 : 0000003fc815749c t4 : 00000000000efc90
      [   46.180293]  t5 : ffffffe000d29658 t6 : 0000000000040000
      [   46.180482] status: 0000000000000100 badaddr: ffffffe04fb38c48 cause: 000000000000000f
      Signed-off-by: NZong Li <zong.li@sifive.com>
      Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      [paul.walmsley@sifive.com: cleaned up patch description]
      Fixes: 92e0d143 ("clocksource/drivers/riscv_timer: Provide the sched_clock")
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      9d05c18e
  8. 15 11月, 2019 1 次提交
    • M
      x86/hyperv: Initialize clockevents earlier in CPU onlining · 4df4cb9e
      Michael Kelley 提交于
      Hyper-V has historically initialized stimer-based clockevents late in the
      process of onlining a CPU because clockevents depend on stimer
      interrupts. In the original Hyper-V design, stimer interrupts generate a
      VMbus message, so the VMbus machinery must be running first, and VMbus
      can't be initialized until relatively late. On x86/64, LAPIC timer based
      clockevents are used during early initialization before VMbus and
      stimer-based clockevents are ready, and again during CPU offlining after
      the stimer clockevents have been shut down.
      
      Unfortunately, this design creates problems when offlining CPUs for
      hibernation or other purposes. stimer-based clockevents are shut down
      relatively early in the offlining process, so clockevents_unbind_device()
      must be used to fallback to the LAPIC-based clockevents for the remainder
      of the offlining process.  Furthermore, the late initialization and early
      shutdown of stimer-based clockevents doesn't work well on ARM64 since there
      is no other timer like the LAPIC to fallback to. So CPU onlining and
      offlining doesn't work properly.
      
      Fix this by recognizing that stimer Direct Mode is the normal path for
      newer versions of Hyper-V on x86/64, and the only path on other
      architectures. With stimer Direct Mode, stimer interrupts don't require any
      VMbus machinery. stimer clockevents can be initialized and shut down
      consistent with how it is done for other clockevent devices. While the old
      VMbus-based stimer interrupts must still be supported for backward
      compatibility on x86, that mode of operation can be treated as legacy.
      
      So add a new Hyper-V stimer entry in the CPU hotplug state list, and use
      that new state when in Direct Mode. Update the Hyper-V clocksource driver
      to allocate and initialize stimer clockevents earlier during boot. Update
      Hyper-V initialization and the VMbus driver to use this new design. As a
      result, the LAPIC timer is no longer used during boot or CPU
      onlining/offlining and clockevents_unbind_device() is not called.  But
      retain the old design as a legacy implementation for older versions of
      Hyper-V that don't support Direct Mode.
      Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NDexuan Cui <decui@microsoft.com>
      Reviewed-by: NDexuan Cui <decui@microsoft.com>
      Link: https://lkml.kernel.org/r/1573607467-9456-1-git-send-email-mikelley@microsoft.com
      4df4cb9e
  9. 14 11月, 2019 1 次提交
  10. 06 11月, 2019 1 次提交
    • C
      riscv: abstract out CSR names for supervisor vs machine mode · a4c3733d
      Christoph Hellwig 提交于
      Many of the privileged CSRs exist in a supervisor and machine version
      that are used very similarly.  Provide versions of the CSR names and
      fields that map to either the S-mode or M-mode variant depending on
      a new CONFIG_RISCV_M_MODE kconfig symbol.
      
      Contains contributions from Damien Le Moal <Damien.LeMoal@wdc.com>
      and Paul Walmsley <paul.walmsley@sifive.com>.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: Thomas Gleixner <tglx@linutronix.de> # for drivers/clocksource, drivers/irqchip
      [paul.walmsley@sifive.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      a4c3733d
  11. 04 11月, 2019 5 次提交
  12. 18 10月, 2019 2 次提交
  13. 16 10月, 2019 1 次提交
    • F
      clocksource/drivers/mediatek: Fix error handling · 41d49e79
      Fabien Parent 提交于
      When timer_of_init fails, it cleans up after itself by undoing
      everything it did during the initialization function.
      
      mtk_syst_init and mtk_gpt_init both call timer_of_cleanup if
      timer_of_init fails. timer_of_cleanup try to release the resource
      taken.  Since these resources have already been cleaned up by
      timer_of_init, we end up getting a few warnings printed:
      
      [    0.001935] WARNING: CPU: 0 PID: 0 at __clk_put+0xe8/0x128
      [    0.002650] Modules linked in:
      [    0.003058] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.67+ #1
      [    0.003852] Hardware name: MediaTek MT8183 (DT)
      [    0.004446] pstate: 20400085 (nzCv daIf +PAN -UAO)
      [    0.005073] pc : __clk_put+0xe8/0x128
      [    0.005555] lr : clk_put+0xc/0x14
      [    0.005988] sp : ffffff80090b3ea0
      [    0.006422] x29: ffffff80090b3ea0 x28: 0000000040e20018
      [    0.007121] x27: ffffffc07bfff780 x26: 0000000000000001
      [    0.007819] x25: ffffff80090bda80 x24: ffffff8008ec5828
      [    0.008517] x23: ffffff80090bd000 x22: ffffff8008d8b2e8
      [    0.009216] x21: 0000000000000001 x20: fffffffffffffdfb
      [    0.009914] x19: ffffff8009166180 x18: 00000000002bffa8
      [    0.010612] x17: ffffffc012996980 x16: 0000000000000000
      [    0.011311] x15: ffffffbf004a6800 x14: 3536343038393334
      [    0.012009] x13: 2079726576652073 x12: 7eb9c62c5c38f100
      [    0.012707] x11: ffffff80090b3ba0 x10: ffffff80090b3ba0
      [    0.013405] x9 : 0000000000000004 x8 : 0000000000000040
      [    0.014103] x7 : ffffffc079400270 x6 : 0000000000000000
      [    0.014801] x5 : ffffffc079400248 x4 : 0000000000000000
      [    0.015499] x3 : 0000000000000000 x2 : 0000000000000000
      [    0.016197] x1 : ffffff80091661c0 x0 : fffffffffffffdfb
      [    0.016896] Call trace:
      [    0.017218]  __clk_put+0xe8/0x128
      [    0.017654]  clk_put+0xc/0x14
      [    0.018048]  timer_of_cleanup+0x60/0x7c
      [    0.018551]  mtk_syst_init+0x8c/0x9c
      [    0.019020]  timer_probe+0x6c/0xe0
      [    0.019469]  time_init+0x14/0x44
      [    0.019893]  start_kernel+0x2d0/0x46c
      [    0.020378] ---[ end trace 8c1efabea1267649 ]---
      [    0.020982] ------------[ cut here ]------------
      [    0.021586] Trying to vfree() nonexistent vm area ((____ptrval____))
      [    0.022427] WARNING: CPU: 0 PID: 0 at __vunmap+0xd0/0xd8
      [    0.023119] Modules linked in:
      [    0.023524] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W         4.19.67+ #1
      [    0.024498] Hardware name: MediaTek MT8183 (DT)
      [    0.025091] pstate: 60400085 (nZCv daIf +PAN -UAO)
      [    0.025718] pc : __vunmap+0xd0/0xd8
      [    0.026176] lr : __vunmap+0xd0/0xd8
      [    0.026632] sp : ffffff80090b3e90
      [    0.027066] x29: ffffff80090b3e90 x28: 0000000040e20018
      [    0.027764] x27: ffffffc07bfff780 x26: 0000000000000001
      [    0.028462] x25: ffffff80090bda80 x24: ffffff8008ec5828
      [    0.029160] x23: ffffff80090bd000 x22: ffffff8008d8b2e8
      [    0.029858] x21: 0000000000000000 x20: 0000000000000000
      [    0.030556] x19: ffffff800800d000 x18: 00000000002bffa8
      [    0.031254] x17: 0000000000000000 x16: 0000000000000000
      [    0.031952] x15: ffffffbf004a6800 x14: 3536343038393334
      [    0.032651] x13: 2079726576652073 x12: 7eb9c62c5c38f100
      [    0.033349] x11: ffffff80090b3b40 x10: ffffff80090b3b40
      [    0.034047] x9 : 0000000000000005 x8 : 5f5f6c6176727470
      [    0.034745] x7 : 5f5f5f5f28282061 x6 : ffffff80091c86ef
      [    0.035443] x5 : ffffff800852b690 x4 : 0000000000000000
      [    0.036141] x3 : 0000000000000002 x2 : 0000000000000002
      [    0.036839] x1 : 7eb9c62c5c38f100 x0 : 7eb9c62c5c38f100
      [    0.037536] Call trace:
      [    0.037859]  __vunmap+0xd0/0xd8
      [    0.038271]  vunmap+0x24/0x30
      [    0.038664]  __iounmap+0x2c/0x34
      [    0.039088]  timer_of_cleanup+0x70/0x7c
      [    0.039591]  mtk_syst_init+0x8c/0x9c
      [    0.040060]  timer_probe+0x6c/0xe0
      [    0.040507]  time_init+0x14/0x44
      [    0.040932]  start_kernel+0x2d0/0x46c
      
      This commit remove the calls to timer_of_cleanup when timer_of_init
      fails since it is unnecessary and actually cause warnings to be printed.
      
      Fixes: a0858f93 ("mediatek: Convert the driver to timer-of")
      Signed-off-by: NFabien Parent <fparent@baylibre.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Link: https://lore.kernel.org/linux-arm-kernel/20190919191315.25190-1-fparent@baylibre.com/
      41d49e79
  14. 07 10月, 2019 2 次提交
  15. 03 10月, 2019 1 次提交
    • L
      timer-of: don't use conditional expression with mixed 'void' types · 0f1a7b3f
      Linus Torvalds 提交于
      Randy Dunlap reports on the sparse list that sparse warns about this
      expression:
      
              of_irq->percpu ? free_percpu_irq(of_irq->irq, clkevt) :
                      free_irq(of_irq->irq, clkevt);
      
      and honestly, sparse is correct to warn.  The return type of
      free_percpu_irq() is 'void', while free_irq() returns a 'const void *'
      that is the devname argument passed in to the request_irq().
      
      You can't mix a void type with a non-void types in a conditional
      expression according to the C standard.  It so happens that gcc seems to
      accept it - and the resulting type of the expression is void - but
      there's really no reason for the kernel to have this kind of
      non-standard expression with no real upside.
      
      The natural way to write that expression is with an if-statement:
      
              if (of_irq->percpu)
                      free_percpu_irq(of_irq->irq, clkevt);
              else
                      free_irq(of_irq->irq, clkevt);
      
      which is more legible anyway.
      
      I'm not sure why that timer-of code seems to have this odd pattern.  It
      does the same at allocation time, but at least there the types match,
      and it makes sense as an expression.
      Reported-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f1a7b3f
  16. 05 9月, 2019 1 次提交
  17. 27 8月, 2019 2 次提交