1. 29 Mar, 2024 1 commit
  2. 28 Mar, 2024 7 commits
  3. 27 Mar, 2024 1 commit
  4. 26 Mar, 2024 2 commits
    • Mark Brown's avatar
      ASoC: SOF: ipc4/Intel: Fix delay reporting · 3849c4d6
      Mark Brown authored
      Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
      
      The current version of delay reporting code can report incorrect
      values when paired with a firmware which enables this feature.
      
      Unfortunately there are several smaller issues that needed to be addressed
      to correct the behavior:
      
      Wrong information was used for the host side of counter
      For MTL/LNL used incorrect (in a sense that it was verified only on MTL)
      link side counter function.
      The link side counter needs compensation logic if pause/resume is used.
      The offset values were not refreshed from firmware.
      Finally, not strictly connected, but the ALSA buffer size needs to be
      constrained to avoid constant xrun from media players (like mpv)
      
      The series applies cleanly for 6.9 and 6.8.y stable, but older stable
      would need manual backport, but it is questionable if it is needed as
      MTL/LNL is missing features.
      3849c4d6
    • Charles Keepax's avatar
      ASoC: cs42l43: Correct extraction of data pointer in suspend/resume · 56ebbd19
      Charles Keepax authored
      The current code is pulling the wrong pointer causing it to disable the
      wrong IRQ. Correct the code to pull the correct cs42l43 core data
      pointer.
      
      Fixes: 64353af4 ("ASoC: cs42l43: Add system suspend ops to disable IRQ")
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://msgid.link/r/20240326105434.852907-1-ckeepax@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      56ebbd19
  5. 25 Mar, 2024 20 commits
  6. 24 Mar, 2024 9 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