1. 14 May, 2024 1 commit
  2. 09 May, 2024 1 commit
    • Stephen Boyd's avatar
      Merge tag 'samsung-clk-6.10-2' of... · ce689628
      Stephen Boyd authored
      Merge tag 'samsung-clk-6.10-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into clk-samsung
      
      Pull Samsung clk driver updates from Krzysztof Kozlowski:
      
       - Allow choice of manual or firmware-driven control over PLLs, needed
         to fully implement CPU clock controllers on Exynos850
       - Correct PLL clock IDs on ExynosAutov9
       - Propagate certain clock rates to allow setting proper SPI clock
         rates on Google GS101
       - Add HSI0 and HSI2 clock controllers for Google GS101
       - Mark certain Google GS101 clocks critical
       - Convert old S3C64xx clock controller bindings to DT schema
      
      * tag 'samsung-clk-6.10-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
        clk: samsung: gs101: drop unused HSI2 clock parent data
        clk: samsung: gs101: mark some apm UASC and XIU clocks critical
        clk: samsung: gs101: add support for cmu_hsi2
        clk: samsung: gs101: add support for cmu_hsi0
        dt-bindings: clock: google,gs101-clock: add HSI2 clock management unit
        dt-bindings: clock: google,gs101-clock: add HSI0 clock management unit
        clk: samsung: gs101: propagate PERIC1 USI SPI clock rate
        clk: samsung: gs101: propagate PERIC0 USI SPI clock rate
        clk: samsung: exynosautov9: fix wrong pll clock id value
        dt-bindings: clock: samsung,s3c6400-clock: convert to DT Schema
        clk: samsung: exynos850: Add CMU_CPUCL0 and CMU_CPUCL1
        clk: samsung: Implement manual PLL control for ARM64 SoCs
      ce689628
  3. 07 May, 2024 1 commit
  4. 03 May, 2024 1 commit
  5. 29 Apr, 2024 4 commits
  6. 25 Apr, 2024 1 commit
  7. 22 Apr, 2024 2 commits
    • Tudor Ambarus's avatar
      clk: samsung: gs101: propagate PERIC1 USI SPI clock rate · 7cf0324b
      Tudor Ambarus authored
      When SPI transfer is being prepared, the spi-s3c64xx driver will call
      clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
      is a gate (leaf) clock, so it must propagate the rate change up the
      clock tree, so that corresponding MUX/DIV clocks can actually change
      their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
      all USI instances in GS101 PERIC1: USI{0, 9, 10, 11, 12, 13}. This change
      involves the following clocks:
      
      PERIC1 USI*:
      
          Clock                              Div range    MUX Selection
          -------------------------------------------------------------------
          gout_peric1_peric1_top0_ipclk_*    -            -
          dout_peric1_usi*_usi               /1..16       -
          mout_peric1_usi*_usi_user          -            {24.5 MHz, 400 MHz}
      
      With input clock of 400 MHz this scheme provides the following IPCLK
      rate range, for each USI block:
      
          PERIC1 USI*:       1.5 MHz ... 400 MHz
      
      Accounting for internal /4 divider in SPI blocks, and because the max
      SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
      
          PERIC1 USI_SPI*:   384 KHz ... 49.9 MHz
      
      Which shall be fine for the applications of the SPI bus.
      
      Note that with this we allow the reparenting of the MUX_USIx clocks to
      OSCCLK. Each instance of the USI IP has its own MUX_USI clock, thus the
      reparenting of a MUX_USI clock corresponds to a single instance of the
      USI IP. The datasheet mentions OSCCLK just in the low-power mode
      context, but the downstream driver reparents too the MUX_USI clocks to
      OSCCLK. Follow the downstream driver and do the same.
      
      Fixes: 2999e786 ("clk: samsung: gs101: add support for cmu_peric1")
      Reviewed-by: default avatarPeter Griffin <peter.griffin@linaro.org>
      Acked-by: default avatarAndré Draszik <andre.draszik@linaro.org>
      Signed-off-by: default avatarTudor Ambarus <tudor.ambarus@linaro.org>
      Link: https://lore.kernel.org/r/20240419100915.2168573-3-tudor.ambarus@linaro.orgSigned-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      7cf0324b
    • Tudor Ambarus's avatar
      clk: samsung: gs101: propagate PERIC0 USI SPI clock rate · 7b54d911
      Tudor Ambarus authored
      Introduce nMUX() for MUX clocks that can be reparented on clock rate
      change. "nMUX" comes from "n-to-1 selector", hopefully emphasising that
      the selector can change on clock rate changes. Ideally MUX/MUX_F()
      should change to not have the CLK_SET_RATE_NO_REPARENT flag set by
      default, and all their users to be updated to add the flag back
      (like in the case of DIV and GATE). But this is a very intrusive change
      and because for now only GS101 allows MUX reparenting on clock rate
      change, stick with nMUX().
      
      GS101 defines MUX clocks that are dedicated for each instance of the IP.
      One example is USI IP (SPI, I2C, serial). The reparenting of these MUX
      clocks will not affect other instances of the same IP or different IPs
      altogether.
      
      When SPI transfer is being prepared, the spi-s3c64xx driver will call
      clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
      is a gate (leaf) clock, so it must propagate the rate change up the
      clock tree, so that corresponding MUX/DIV clocks can actually change
      their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
      all USI instances in GS101 PERIC0: USI{1-8, 14}. This change involves the
      following clocks:
      
      PERIC0 USI*:
      
          Clock                              Div range    MUX Selection
          -------------------------------------------------------------------
          gout_peric0_peric0_top0_ipclk_*    -            -
          dout_peric0_usi*_usi               /1..16       -
          mout_peric0_usi*_usi_user          -            {24.5 MHz, 400 MHz}
      
      With input clock of 400 MHz this scheme provides the following IPCLK
      rate range, for each USI block:
      
          PERIC0 USI*:       1.5 MHz ... 400 MHz
      
      Accounting for internal /4 divider in SPI blocks, and because the max
      SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
      
          PERIC0 USI_SPI*:   384 KHz ... 49.9 MHz
      
      Fixes: 893f133a ("clk: samsung: gs101: add support for cmu_peric0")
      Reviewed-by: default avatarPeter Griffin <peter.griffin@linaro.org>
      Acked-by: default avatarAndré Draszik <andre.draszik@linaro.org>
      Signed-off-by: default avatarTudor Ambarus <tudor.ambarus@linaro.org>
      Link: https://lore.kernel.org/r/20240419100915.2168573-2-tudor.ambarus@linaro.orgSigned-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      7b54d911
  8. 31 Mar, 2024 1 commit
  9. 26 Mar, 2024 3 commits
    • Krzysztof Kozlowski's avatar
    • Sam Protsenko's avatar
      clk: samsung: exynos850: Add CMU_CPUCL0 and CMU_CPUCL1 · dedf8734
      Sam Protsenko authored
      Implement support for CPU clock management units:
        - CMU_CPUCL0: clocks for cluster 0: 4 x Cortex-A55 (cpu0..cpu3)
        - CMU_CPUCL1: clocks for cluster 1: 4 x Cortex-A55 (cpu4..cpu7)
      
      CPU PLLs are generating main CPU clocks for each cluster, and there are
      alternate ("switch") clocks that can be used temporarily while
      re-configuring the PLL for a new rate. ACLK, ATCLK, PCLKDBG and
      PERIPHCLK clocks are driving corresponding buses. CLK_CLUSTERx_SCLK are
      actual leaf CPU clocks and should be used to change CPU rates. Also some
      CoreSight clocks can be derived from DBG_USER (debug clock).
      
      PLL table was extracted from ECT table. ECT stands for "Exynos
      Characteristic Table", it's a Samsung specific binary data populated by
      BL2 bootloader in RAM at 0x90000000 address, containing PLL tables for
      various CMUs and other hardware specific information.
      
      The particular PLL type used in CMU_CPUCL0 and CMU_CPUCL1 (pll0822x) is
      an integer PLL with middle FVCO. The equation to calculate its output
      rate is:
      
          fout = fin * M / (P*2^S)
      
      where:
      
          fin = 26 MHz (OSCCLK frequency)
          M = 64..1023
          P = 1..63
          S = 0..6
      
      The PLL table tries to keep "P" value low to reduce the locking time,
      which for pll0822x is "t = P * 150" (in OSCCLK cycles).
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Link: https://lore.kernel.org/r/20240301015118.30072-2-semen.protsenko@linaro.orgSigned-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      dedf8734
    • Sam Protsenko's avatar
      clk: samsung: Implement manual PLL control for ARM64 SoCs · 7fa37084
      Sam Protsenko authored
      Some ARM64 Exynos chips are capable to control PLL clocks automatically.
      For those chips, whether the PLL is controlled automatically or manually
      is chosen in PLL_CON1 register with next bits:
      
          [28]  ENABLE_AUTOMATIC_CLKGATING
          [1]   MANUAL_PLL_CTRL
          [0]   AUTO_PLL_CTRL
      
      The bl2 bootloader sets 0x10000001 value for some PLL_CON1 registers,
      which means any attempt to control those PLLs manually (e.g.
      disabling/enabling those PLLs or changing MUX parent clocks) would lead
      to PLL lock timeout with error message like this:
      
          Could not lock PLL ...
      
      At the moment, all Samsung clock drivers implement manual clock control.
      So in order to make it possible to control PLLs, corresponding PLL_CON1
      registers should be set to 0x2 first.
      
      Some older ARM64 chips don't implement the automatic clock control
      though. It also might be desirable to configure some PLLs for manual
      control, while keeping the default configuration for the rest. So it'd
      convenient to choose this PLL mode for each CMU separately. Introduce
      .manual_plls field to CMU structure to choose the PLL control mode.
      Because it'll be initialized with "false" in all existing CMU
      structures by default, it won't affect any existing clock drivers,
      allowing for this feature to be enabled gradually when it's needed with
      no change for the rest of users. In case .manual_plls is set, set
      PLL_CON1 registers to manual control, akin to what's already done for
      gate clocks in exynos_arm64_init_clocks(). Of course, PLL_CON1 registers
      should be added to corresponding struct samsung_cmu_info::clk_regs array
      to make sure they get initialized.
      
      No functional change. This patch adds a feature, but doesn't enable it
      for any users.
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Link: https://lore.kernel.org/r/20240301015118.30072-1-semen.protsenko@linaro.orgSigned-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      7fa37084
  10. 24 Mar, 2024 13 commits
    • Linus Torvalds's avatar
      Linux 6.9-rc1 · 4cece764
      Linus Torvalds authored
      4cece764
    • Linus Torvalds's avatar
      Merge tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi · ab8de2db
      Linus Torvalds authored
      Pull EFI fixes from Ard Biesheuvel:
      
       - Fix logic that is supposed to prevent placement of the kernel image
         below LOAD_PHYSICAL_ADDR
      
       - Use the firmware stack in the EFI stub when running in mixed mode
      
       - Clear BSS only once when using mixed mode
      
       - Check efi.get_variable() function pointer for NULL before trying to
         call it
      
      * tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
        efi: fix panic in kdump kernel
        x86/efistub: Don't clear BSS twice in mixed mode
        x86/efistub: Call mixed mode boot services on the firmware's stack
        efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min or higher address
      ab8de2db
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5e74df2f
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
      
       - Ensure that the encryption mask at boot is properly propagated on
         5-level page tables, otherwise the PGD entry is incorrectly set to
         non-encrypted, which causes system crashes during boot.
      
       - Undo the deferred 5-level page table setup as it cannot work with
         memory encryption enabled.
      
       - Prevent inconsistent XFD state on CPU hotplug, where the MSR is reset
         to the default value but the cached variable is not, so subsequent
         comparisons might yield the wrong result and as a consequence the
         result prevents updating the MSR.
      
       - Register the local APIC address only once in the MPPARSE enumeration
         to prevent triggering the related WARN_ONs() in the APIC and topology
         code.
      
       - Handle the case where no APIC is found gracefully by registering a
         fake APIC in the topology code. That makes all related topology
         functions work correctly and does not affect the actual APIC driver
         code at all.
      
       - Don't evaluate logical IDs during early boot as the local APIC IDs
         are not yet enumerated and the invoked function returns an error
         code. Nothing requires the logical IDs before the final CPUID
         enumeration takes place, which happens after the enumeration.
      
       - Cure the fallout of the per CPU rework on UP which misplaced the
         copying of boot_cpu_data to per CPU data so that the final update to
         boot_cpu_data got lost which caused inconsistent state and boot
         crashes.
      
       - Use copy_from_kernel_nofault() in the kprobes setup as there is no
         guarantee that the address can be safely accessed.
      
       - Reorder struct members in struct saved_context to work around another
         kmemleak false positive
      
       - Remove the buggy code which tries to update the E820 kexec table for
         setup_data as that is never passed to the kexec kernel.
      
       - Update the resource control documentation to use the proper units.
      
       - Fix a Kconfig warning observed with tinyconfig
      
      * tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/boot/64: Move 5-level paging global variable assignments back
        x86/boot/64: Apply encryption mask to 5-level pagetable update
        x86/cpu: Add model number for another Intel Arrow Lake mobile processor
        x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
        Documentation/x86: Document that resctrl bandwidth control units are MiB
        x86/mpparse: Register APIC address only once
        x86/topology: Handle the !APIC case gracefully
        x86/topology: Don't evaluate logical IDs during early boot
        x86/cpu: Ensure that CPU info updates are propagated on UP
        kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address
        x86/pm: Work around false positive kmemleak report in msr_build_context()
        x86/kexec: Do not update E820 kexec table for setup_data
        x86/config: Fix warning for 'make ARCH=x86_64 tinyconfig'
      5e74df2f
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · b136f68e
      Linus Torvalds authored
      Pull scheduler doc clarification from Thomas Gleixner:
       "A single update for the documentation of the base_slice_ns tunable to
        clarify that any value which is less than the tick slice has no effect
        because the scheduler tick is not guaranteed to happen within the set
        time slice"
      
      * tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/doc: Update documentation for base_slice_ns and CONFIG_HZ relation
      b136f68e
    • Linus Torvalds's avatar
      Merge tag 'dma-mapping-6.9-2024-03-24' of git://git.infradead.org/users/hch/dma-mapping · 864ad046
      Linus Torvalds authored
      Pull dma-mapping fixes from Christoph Hellwig:
       "This has a set of swiotlb alignment fixes for sometimes very long
        standing bugs from Will. We've been discussion them for a while and
        they should be solid now"
      
      * tag 'dma-mapping-6.9-2024-03-24' of git://git.infradead.org/users/hch/dma-mapping:
        swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE
        iommu/dma: Force swiotlb_max_mapping_size on an untrusted device
        swiotlb: Fix alignment checks when both allocation and DMA masks are present
        swiotlb: Honour dma_alloc_coherent() alignment in swiotlb_alloc()
        swiotlb: Enforce page alignment in swiotlb_alloc()
        swiotlb: Fix double-allocation of slots due to broken alignment handling
      864ad046
    • Oleksandr Tymoshenko's avatar
      efi: fix panic in kdump kernel · 62b71cd7
      Oleksandr Tymoshenko authored
      Check if get_next_variable() is actually valid pointer before
      calling it. In kdump kernel this method is set to NULL that causes
      panic during the kexec-ed kernel boot.
      
      Tested with QEMU and OVMF firmware.
      
      Fixes: bad267f9 ("efi: verify that variable services are supported")
      Signed-off-by: default avatarOleksandr Tymoshenko <ovt@google.com>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      62b71cd7
    • Ard Biesheuvel's avatar
      x86/efistub: Don't clear BSS twice in mixed mode · df7ecce8
      Ard Biesheuvel authored
      Clearing BSS should only be done once, at the very beginning.
      efi_pe_entry() is the entrypoint from the firmware, which may not clear
      BSS and so it is done explicitly. However, efi_pe_entry() is also used
      as an entrypoint by the mixed mode startup code, in which case BSS will
      already have been cleared, and doing it again at this point will corrupt
      global variables holding the firmware's GDT/IDT and segment selectors.
      
      So make the memset() conditional on whether the EFI stub is running in
      native mode.
      
      Fixes: b3810c5a ("x86/efistub: Clear decompressor BSS in native EFI entrypoint")
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      df7ecce8
    • Ard Biesheuvel's avatar
      x86/efistub: Call mixed mode boot services on the firmware's stack · cefcd4fe
      Ard Biesheuvel authored
      Normally, the EFI stub calls into the EFI boot services using the stack
      that was live when the stub was entered. According to the UEFI spec,
      this stack needs to be at least 128k in size - this might seem large but
      all asynchronous processing and event handling in EFI runs from the same
      stack and so quite a lot of space may be used in practice.
      
      In mixed mode, the situation is a bit different: the bootloader calls
      the 32-bit EFI stub entry point, which calls the decompressor's 32-bit
      entry point, where the boot stack is set up, using a fixed allocation
      of 16k. This stack is still in use when the EFI stub is started in
      64-bit mode, and so all calls back into the EFI firmware will be using
      the decompressor's limited boot stack.
      
      Due to the placement of the boot stack right after the boot heap, any
      stack overruns have gone unnoticed. However, commit
      
        5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code")
      
      moved the definition of the boot heap into C code, and now the boot
      stack is placed right at the base of BSS, where any overruns will
      corrupt the end of the .data section.
      
      While it would be possible to work around this by increasing the size of
      the boot stack, doing so would affect all x86 systems, and mixed mode
      systems are a tiny (and shrinking) fraction of the x86 installed base.
      
      So instead, record the firmware stack pointer value when entering from
      the 32-bit firmware, and switch to this stack every time a EFI boot
      service call is made.
      
      Cc: <stable@kernel.org> # v6.1+
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      cefcd4fe
    • Tom Lendacky's avatar
      x86/boot/64: Move 5-level paging global variable assignments back · 9843231c
      Tom Lendacky authored
      Commit 63bed966 ("x86/startup_64: Defer assignment of 5-level paging
      global variables") moved assignment of 5-level global variables to later
      in the boot in order to avoid having to use RIP relative addressing in
      order to set them. However, when running with 5-level paging and SME
      active (mem_encrypt=on), the variables are needed as part of the page
      table setup needed to encrypt the kernel (using pgd_none(), p4d_offset(),
      etc.). Since the variables haven't been set, the page table manipulation
      is done as if 4-level paging is active, causing the system to crash on
      boot.
      
      While only a subset of the assignments that were moved need to be set
      early, move all of the assignments back into check_la57_support() so that
      these assignments aren't spread between two locations. Instead of just
      reverting the fix, this uses the new RIP_REL_REF() macro when assigning
      the variables.
      
      Fixes: 63bed966 ("x86/startup_64: Defer assignment of 5-level paging global variables")
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Link: https://lore.kernel.org/r/2ca419f4d0de719926fd82353f6751f717590a86.1711122067.git.thomas.lendacky@amd.com
      9843231c
    • Tom Lendacky's avatar
      x86/boot/64: Apply encryption mask to 5-level pagetable update · 4d0d7e78
      Tom Lendacky authored
      When running with 5-level page tables, the kernel mapping PGD entry is
      updated to point to the P4D table. The assignment uses _PAGE_TABLE_NOENC,
      which, when SME is active (mem_encrypt=on), results in a page table
      entry without the encryption mask set, causing the system to crash on
      boot.
      
      Change the assignment to use _PAGE_TABLE instead of _PAGE_TABLE_NOENC so
      that the encryption mask is set for the PGD entry.
      
      Fixes: 533568e0 ("x86/boot/64: Use RIP_REL_REF() to access early_top_pgt[]")
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Link: https://lore.kernel.org/r/8f20345cda7dbba2cf748b286e1bc00816fe649a.1711122067.git.thomas.lendacky@amd.com
      4d0d7e78
    • Tony Luck's avatar
    • Adamos Ttofari's avatar
      x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD · 10e4b516
      Adamos Ttofari authored
      Commit 67236547 ("x86/fpu: Update XFD state where required") and
      commit 8bf26758 ("x86/fpu: Add XFD state to fpstate") introduced a
      per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in
      order to avoid unnecessary writes to the MSR.
      
      On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which
      wipes out any stale state. But the per CPU cached xfd value is not
      reset, which brings them out of sync.
      
      As a consequence a subsequent xfd_update_state() might fail to update
      the MSR which in turn can result in XRSTOR raising a #NM in kernel
      space, which crashes the kernel.
      
      To fix this, introduce xfd_set_state() to write xfd_state together
      with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.
      
      Fixes: 67236547 ("x86/fpu: Update XFD state where required")
      Signed-off-by: default avatarAdamos Ttofari <attofari@amazon.de>
      Signed-off-by: default avatarChang S. Bae <chang.seok.bae@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lore.kernel.org/r/20240322230439.456571-1-chang.seok.bae@intel.com
      
      Closes: https://lore.kernel.org/lkml/20230511152818.13839-1-attofari@amazon.de
      10e4b516
    • Tony Luck's avatar
      Documentation/x86: Document that resctrl bandwidth control units are MiB · a8ed59a3
      Tony Luck authored
      The memory bandwidth software controller uses 2^20 units rather than
      10^6. See mbm_bw_count() which computes bandwidth using the "SZ_1M"
      Linux define for 0x00100000.
      
      Update the documentation to use MiB when describing this feature.
      It's too late to fix the mount option "mba_MBps" as that is now an
      established user interface.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Link: https://lore.kernel.org/r/20240322182016.196544-1-tony.luck@intel.com
      a8ed59a3
  11. 23 Mar, 2024 11 commits
    • Linus Torvalds's avatar
      Merge tag 'timers-urgent-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 70293240
      Linus Torvalds authored
      Pull timer fixes from Thomas Gleixner:
       "Two regression fixes for the timer and timer migration code:
      
         - Prevent endless timer requeuing which is caused by two CPUs racing
           out of idle. This happens when the last CPU goes idle and therefore
           has to ensure to expire the pending global timers and some other
           CPU come out of idle at the same time and the other CPU wins the
           race and expires the global queue. This causes the last CPU to
           chase ghost timers forever and reprogramming it's clockevent device
           endlessly.
      
           Cure this by re-evaluating the wakeup time unconditionally.
      
         - The split into local (pinned) and global timers in the timer wheel
           caused a regression for NOHZ full as it broke the idle tracking of
           global timers. On NOHZ full this prevents an self IPI being sent
           which in turn causes the timer to be not programmed and not being
           expired on time.
      
           Restore the idle tracking for the global timer base so that the
           self IPI condition for NOHZ full is working correctly again"
      
      * tag 'timers-urgent-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        timers: Fix removed self-IPI on global timer's enqueue in nohz_full
        timers/migration: Fix endless timer requeue after idle interrupts
      70293240
    • Linus Torvalds's avatar
      Merge tag 'timers-core-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 00164f47
      Linus Torvalds authored
      Pull more clocksource updates from Thomas Gleixner:
       "A set of updates for clocksource and clockevent drivers:
      
         - A fix for the prescaler of the ARM global timer where the prescaler
           mask define only covered 4 bits while it is actully 8 bits wide.
           This obviously restricted the possible range of prescaler
           adjustments
      
         - A fix for the RISC-V timer which prevents a timer interrupt being
           raised while the timer is initialized
      
         - A set of device tree updates to support new system on chips in
           various drivers
      
         - Kernel-doc and other cleanups all over the place"
      
      * tag 'timers-core-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        clocksource/drivers/timer-riscv: Clear timer interrupt on timer initialization
        dt-bindings: timer: Add support for cadence TTC PWM
        clocksource/drivers/arm_global_timer: Simplify prescaler register access
        clocksource/drivers/arm_global_timer: Guard against division by zero
        clocksource/drivers/arm_global_timer: Make gt_target_rate unsigned long
        dt-bindings: timer: add Ralink SoCs system tick counter
        clocksource: arm_global_timer: fix non-kernel-doc comment
        clocksource/drivers/arm_global_timer: Remove stray tab
        clocksource/drivers/arm_global_timer: Fix maximum prescaler value
        clocksource/drivers/imx-sysctr: Add i.MX95 support
        clocksource/drivers/imx-sysctr: Drop use global variables
        dt-bindings: timer: nxp,sysctr-timer: support i.MX95
        dt-bindings: timer: renesas: ostm: Document RZ/Five SoC
        dt-bindings: timer: renesas,tmu: Document input capture interrupt
        clocksource/drivers/ti-32K: Fix misuse of "/**" comment
        clocksource/drivers/stm32: Fix all kernel-doc warnings
        dt-bindings: timer: exynos4210-mct: Add google,gs101-mct compatible
        clocksource/drivers/imx: Fix -Wunused-but-set-variable warning
      00164f47
    • Linus Torvalds's avatar
      Merge tag 'irq-urgent-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 1a391931
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A series of fixes for the Renesas RZG21 interrupt chip driver to
        prevent spurious and misrouted interrupts.
      
         - Ensure that posted writes are flushed in the eoi() callback
      
         - Ensure that interrupts are masked at the chip level when the
           trigger type is changed
      
         - Clear the interrupt status register when setting up edge type
           trigger modes
      
         - Ensure that the trigger type and routing information is set before
           the interrupt is enabled"
      
      * tag 'irq-urgent-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/renesas-rzg2l: Do not set TIEN and TINT source at the same time
        irqchip/renesas-rzg2l: Prevent spurious interrupts when setting trigger type
        irqchip/renesas-rzg2l: Rename rzg2l_irq_eoi()
        irqchip/renesas-rzg2l: Rename rzg2l_tint_eoi()
        irqchip/renesas-rzg2l: Flush posted write in irq_eoi()
      1a391931
    • Linus Torvalds's avatar
      Merge tag 'core-entry-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 976b029d
      Linus Torvalds authored
      Pull core entry fix from Thomas Gleixner:
       "A single fix for the generic entry code:
      
        The trace_sys_enter() tracepoint can modify the syscall number via
        kprobes or BPF in pt_regs, but that requires that the syscall number
        is re-evaluted from pt_regs after the tracepoint.
      
        A seccomp fix in that area removed the re-evaluation so the change
        does not take effect as the code just uses the locally cached number.
      
        Restore the original behaviour by re-evaluating the syscall number
        after the tracepoint"
      
      * tag 'core-entry-2024-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        entry: Respect changes to system call number by trace_sys_enter()
      976b029d
    • Linus Torvalds's avatar
      Merge tag 'powerpc-6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 484193fe
      Linus Torvalds authored
      Pull more powerpc updates from Michael Ellerman:
      
       - Handle errors in mark_rodata_ro() and mark_initmem_nx()
      
       - Make struct crash_mem available without CONFIG_CRASH_DUMP
      
      Thanks to Christophe Leroy and Hari Bathini.
      
      * tag 'powerpc-6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        powerpc/kdump: Split KEXEC_CORE and CRASH_DUMP dependency
        powerpc/kexec: split CONFIG_KEXEC_FILE and CONFIG_CRASH_DUMP
        kexec/kdump: make struct crash_mem available without CONFIG_CRASH_DUMP
        powerpc: Handle error in mark_rodata_ro() and mark_initmem_nx()
      484193fe
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm · 02fb638b
      Linus Torvalds authored
      Pull ARM updates from Russell King:
      
       - remove a misuse of kernel-doc comment
      
       - use "Call trace:" for backtraces like other architectures
      
       - implement copy_from_kernel_nofault_allowed() to fix a LKDTM test
      
       - add a "cut here" line for prefetch aborts
      
       - remove unnecessary Kconfing entry for FRAME_POINTER
      
       - remove iwmmxy support for PJ4/PJ4B cores
      
       - use bitfield helpers in ptrace to improve readabililty
      
       - check if folio is reserved before flushing
      
      * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
        ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
        ARM: 9354/1: ptrace: Use bitfield helpers
        ARM: 9352/1: iwmmxt: Remove support for PJ4/PJ4B cores
        ARM: 9353/1: remove unneeded entry for CONFIG_FRAME_POINTER
        ARM: 9351/1: fault: Add "cut here" line for prefetch aborts
        ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed()
        ARM: 9349/1: unwind: Add missing "Call trace:" line
        ARM: 9334/1: mm: init: remove misuse of kernel-doc comment
      02fb638b
    • Linus Torvalds's avatar
      Merge tag 'hardening-v6.9-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · b7187139
      Linus Torvalds authored
      Pull more hardening updates from Kees Cook:
      
       - CONFIG_MEMCPY_SLOW_KUNIT_TEST is no longer needed (Guenter Roeck)
      
       - Fix needless UTF-8 character in arch/Kconfig (Liu Song)
      
       - Improve __counted_by warning message in LKDTM (Nathan Chancellor)
      
       - Refactor DEFINE_FLEX() for default use of __counted_by
      
       - Disable signed integer overflow sanitizer on GCC < 8
      
      * tag 'hardening-v6.9-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        lkdtm/bugs: Improve warning message for compilers without counted_by support
        overflow: Change DEFINE_FLEX to take __counted_by member
        Revert "kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST"
        arch/Kconfig: eliminate needless UTF-8 character in Kconfig help
        ubsan: Disable signed integer overflow sanitizer on GCC < 8
      b7187139
    • Thomas Gleixner's avatar
      x86/mpparse: Register APIC address only once · f2208aa1
      Thomas Gleixner authored
      The APIC address is registered twice. First during the early detection and
      afterwards when actually scanning the table for APIC IDs. The APIC and
      topology core warn about the second attempt.
      
      Restrict it to the early detection call.
      
      Fixes: 81287ad6 ("x86/apic: Sanitize APIC address setup")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20240322185305.297774848@linutronix.de
      f2208aa1
    • Thomas Gleixner's avatar
      x86/topology: Handle the !APIC case gracefully · 5e25eb25
      Thomas Gleixner authored
      If there is no local APIC enumerated and registered then the topology
      bitmaps are empty. Therefore, topology_init_possible_cpus() will die with
      a division by zero exception.
      
      Prevent this by registering a fake APIC id to populate the topology
      bitmap. This also allows to use all topology query interfaces
      unconditionally. It does not affect the actual APIC code because either
      the local APIC address was not registered or no local APIC could be
      detected.
      
      Fixes: f1f758a8 ("x86/topology: Add a mechanism to track topology via APIC IDs")
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20240322185305.242709302@linutronix.de
      5e25eb25
    • Thomas Gleixner's avatar
      x86/topology: Don't evaluate logical IDs during early boot · 7af541ce
      Thomas Gleixner authored
      The local APICs have not yet been enumerated so the logical ID evaluation
      from the topology bitmaps does not work and would return an error code.
      
      Skip the evaluation during the early boot CPUID evaluation and only apply
      it on the final run.
      
      Fixes: 380414be ("x86/cpu/topology: Use topology logical mapping mechanism")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20240322185305.186943142@linutronix.de
      7af541ce
    • Thomas Gleixner's avatar
      x86/cpu: Ensure that CPU info updates are propagated on UP · c90399fb
      Thomas Gleixner authored
      The boot sequence evaluates CPUID information twice:
      
        1) During early boot
      
        2) When finalizing the early setup right before
           mitigations are selected and alternatives are patched.
      
      In both cases the evaluation is stored in boot_cpu_data, but on UP the
      copying of boot_cpu_data to the per CPU info of the boot CPU happens
      between #1 and #2. So any update which happens in #2 is never propagated to
      the per CPU info instance.
      
      Consolidate the whole logic and copy boot_cpu_data right before applying
      alternatives as that's the point where boot_cpu_data is in it's final
      state and not supposed to change anymore.
      
      This also removes the voodoo mb() from smp_prepare_cpus_common() which
      had absolutely no purpose.
      
      Fixes: 71eb4893 ("x86/percpu: Cure per CPU madness on UP")
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Link: https://lore.kernel.org/r/20240322185305.127642785@linutronix.de
      c90399fb
  12. 22 Mar, 2024 1 commit