1. 16 Aug, 2023 3 commits
  2. 10 Aug, 2023 2 commits
  3. 08 Aug, 2023 3 commits
  4. 04 Aug, 2023 4 commits
  5. 02 Aug, 2023 5 commits
  6. 12 Jul, 2023 3 commits
    • Palmer Dabbelt's avatar
      RISC-V: Don't include Zicsr or Zifencei in I from ACPI · ab2dbc7a
      Palmer Dabbelt authored
      ACPI ISA strings are based on a specification after Zicsr and Zifencei
      were split out of I, so we shouldn't be treating them as part of I.  We
      haven't release an ACPI-based kernel yet, so we don't need to worry
      about compatibility with the old ISA strings.
      
      Fixes: 07edc327 ("RISC-V: always report presence of extensions formerly part of the base ISA")
      Reviewed-by: default avatarConor Dooley <conor.dooley@microchip.com>
      Reviewed-by: default avatarSunil V L <sunilvl@ventanamicro.com>
      Link: https://lore.kernel.org/r/20230711224600.10879-1-palmer@rivosinc.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      ab2dbc7a
    • Jisheng Zhang's avatar
      riscv: mm: fix truncation warning on RV32 · b690e266
      Jisheng Zhang authored
      lkp reports below sparse warning when building for RV32:
      arch/riscv/mm/init.c:1204:48: sparse: warning: cast truncates bits from
      constant value (100000000 becomes 0)
      
      IMO, the reason we didn't see this truncates bug in real world is "0"
      means MEMBLOCK_ALLOC_ACCESSIBLE in memblock and there's no RV32 HW
      with more than 4GB memory.
      
      Fix it anyway to make sparse happy.
      
      Fixes: decf89f8 ("riscv: try to allocate crashkern region from 32bit addressible memory")
      Signed-off-by: default avatarJisheng Zhang <jszhang@kernel.org>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Closes: https://lore.kernel.org/oe-kbuild-all/202306080034.SLiCiOMn-lkp@intel.com/
      Link: https://lore.kernel.org/r/20230709171036.1906-1-jszhang@kernel.orgSigned-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      b690e266
    • Eric Lin's avatar
      perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start() · 66843b14
      Eric Lin authored
      Since commit 096b52fd ("perf: RISC-V: throttle perf events") the
      perf_sample_event_took() function was added to report time spent in
      overflow interrupts. If the interrupt takes too long, the perf framework
      will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.
      When hwc->interrupts is larger than max_samples_per_tick, the
      hwc->interrupts will be set to MAX_INTERRUPTS, and events will be
      throttled within the __perf_event_account_interrupt() function.
      
      However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the
      PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()
      function to avoid throttling. When the perf framework unthrottled the event
      in the timer interrupt handler, it triggers riscv_pmu_start() function
      and causes a WARN_ON_ONCE() warning, as shown below:
      
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e
       Modules linked in:
       CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1
       Hardware name: SiFive (DT)
       epc : riscv_pmu_start+0x7c/0x8e
        ra : riscv_pmu_start+0x28/0x8e
       epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0
        gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0
        t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720
        s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000
        a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000
        a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030
        s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00
        s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000
        s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340
        s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796
        t5 : 0000000700000000 t6 : ffffaf8005269870
       status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
       [<ffffffff80aef864>] riscv_pmu_start+0x7c/0x8e
       [<ffffffff80185b56>] perf_adjust_freq_unthr_context+0x15e/0x174
       [<ffffffff80188642>] perf_event_task_tick+0x88/0x9c
       [<ffffffff800626a8>] scheduler_tick+0xfe/0x27c
       [<ffffffff800b5640>] update_process_times+0x9a/0xba
       [<ffffffff800c5bd4>] tick_sched_handle+0x32/0x66
       [<ffffffff800c5e0c>] tick_sched_timer+0x64/0xb0
       [<ffffffff800b5e50>] __hrtimer_run_queues+0x156/0x2f4
       [<ffffffff800b6bdc>] hrtimer_interrupt+0xe2/0x1fe
       [<ffffffff80acc9e8>] riscv_timer_interrupt+0x38/0x42
       [<ffffffff80090a16>] handle_percpu_devid_irq+0x90/0x1d2
       [<ffffffff8008a9f4>] generic_handle_domain_irq+0x28/0x36
      
      After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,
      they don't call *_pmu_stop() to update with PERF_HES_STOPPED flag
      after perf_event_overflow() function nor do they add PERF_HES_STOPPED
      flag checking in *_pmu_start() which don't cause this warning.
      
      Thus, it's recommended to remove this unnecessary check in
      riscv_pmu_start() function to prevent this warning.
      Signed-off-by: default avatarEric Lin <eric.lin@sifive.com>
      Link: https://lore.kernel.org/r/20230710154328.19574-1-eric.lin@sifive.com
      Fixes: 096b52fd ("perf: RISC-V: throttle perf events")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      66843b14
  7. 11 Jul, 2023 1 commit
  8. 09 Jul, 2023 10 commits
  9. 08 Jul, 2023 9 commits