Merge tag 'v6.6.82' into for/openbmc/dev-6.6

This is the 6.6.82 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfNV3AACgkQONu9yGCS
# aT6JOQ//f9BSrRC

Merge tag 'v6.6.82' into for/openbmc/dev-6.6

This is the 6.6.82 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfNV3AACgkQONu9yGCS
# aT6JOQ//f9BSrRC1JvkfJeUJ4sOjA7k/Lo22WSxTydbtNR64s/okTUxlE+nF910s
# ZDs0E3UAPsZxnGimVVrgN612NFiylQYtESttM5wSCioqyvk76/WugQjz6MQegm1g
# sGV8GhiC4dZDzqV5tiiWV0aAAW73H0kQRYepe1RqP/A5nfb5e0ikfY2iu/mFg1UG
# 9hUX3iwPFi/Y4JN8UPjZcbJ5E9MlHFfLpmjvMEcBOZjRgjLFRYcMwbX0WSZl0HLJ
# x+4Rahnfx2bF6zqoMff8vdxj6UvO9Fc1AucSNxdtWJUxF71NVeQ3GipzL0fEnxwV
# SP6oQ0h6rEfwZpZoagtjVlGAgjSTQUMiiKyK2qgPne3JDMo8bx2OhzNZU3L9ltt2
# LmlMqOJR2qv2tFyAl+ei1jre/6OG+AEPC6pnmQc8tNuahIpYaFN5fybeFAxSPvbo
# Jyv0pzI1th/kwd5bn8LHHca9OSA/PHT4DPIChVZdpSOuYi2lFVkpbvVocbgOi56S
# BuUoV+QfeOrg+QBLPOeKL98UoJI5EJZuBFAQgs3XJH/IUy4MIFLdBzFPzB6alvNl
# 8EuI54+IkArDil8YYUyZkH1odG7Ch3o48dZ0v71qZalraC2NhNgxxxj/nDpFNc+h
# ZtzyOq96fK6GWtvmwYvUOH5nX7gHq6kjqDkXAj6+DakOedhLjJI=
# =e2Yd
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 09 Mar 2025 19:25:12 ACDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [marginal]
# gpg: gregkh@kernel.org: Verified 11 signatures in the past 7 weeks. Encrypted
# 0 messages.
# gpg: Warning: you have yet to encrypt a message to this key!
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

show more ...

x86/boot/32: Temporarily map initrd for microcode loading

commit 4c585af7180c147062c636a927a2fc2b6a7072f5 upstream

Early microcode loading on 32-bit runs in physical address mode because
the initrd

x86/boot/32: Temporarily map initrd for microcode loading

commit 4c585af7180c147062c636a927a2fc2b6a7072f5 upstream

Early microcode loading on 32-bit runs in physical address mode because
the initrd is not covered by the initial page tables. That results in
a horrible mess all over the microcode loader code.

Provide a temporary mapping for the initrd in the initial page tables by
appending it to the actual initial mapping starting with a new PGD or
PMD depending on the configured page table levels ([non-]PAE).

The page table entries are located after _brk_end so they are not
permanently using memory space. The mapping is invalidated right away in
i386_start_kernel() after the early microcode loader has run.

This prepares for removing the physical address mode oddities from all
over the microcode loader code, which in turn allows further cleanups.

Provide the map and unmap code and document the place where the
microcode loader needs to be invoked with a comment.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231017211722.292291436@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Merge tag 'v6.6.81' into for/openbmc/dev-6.6

This is the 6.6.81 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfLFMMACgkQONu9yGCS
# aT6riRAAjyTT+Ia

Merge tag 'v6.6.81' into for/openbmc/dev-6.6

This is the 6.6.81 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfLFMMACgkQONu9yGCS
# aT6riRAAjyTT+IaZXhdNjx56GXicO4l4Spr9VmgecZWBJceNkDETDMof3dhhIHeV
# u+wKZKyL/ZBfElLqvMbOUKUK5aw4odI5d1Ri8C3ViYYrCsSTJNXUZ27YnF2xHyql
# Aw+otwwNTqDEJENFCLtdXhFBPinBXop5piv/eQeP5qHa1D8OGzl0Ntb1Lan5OIf3
# PIMoX7T5CQUd9cuUiJE9uX8t/VD18hqOrivOUGy7avyIOvaE7GaDt3xEz5Pw+b4l
# D+VOaskhFoLcehDlOmLxbKmdUFYMG/h1eSVE9azd9scFRjU5EEbRtOfkMFb8XE6D
# rgLY39Zol7dqdxBerqNvmbj1CRFIQfxoOSadKjiSRyZ2POttfSs3IADGOTRj/T/k
# +Hj1kFs3wLFoQ5RDRKDrzCq91pC2RcXFe3zQZWxla19Dhx3DwZZa5WlfHzIuFEZX
# mfJ7VR4k/ue9EFyvNGHZuAWfB0OcCCZ2WAlc8mXfvp3cIA5arEGvPGnffr/3/jCs
# gXxt186um11iSNYzVT1Ia6b7xz33EtHjMXUAnixlyuDK9dUPg6m48KIcTta5WPoP
# 7cqPNKDb59sua26TVyf91nb7r+7jp4Zfb9Be/7BxZoLTLxwPeD4gl7Sk7PYDycIk
# xmWetnoFhE8aNHJ5hId2LC7zd6jxn8xYHJQffJJ4yCU2ZmRBKI8=
# =VWtK
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 08 Mar 2025 02:16:11 ACDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [marginal]
# gpg: gregkh@kernel.org: Verified 10 signatures in the past 6 weeks. Encrypted
# 0 messages.
# gpg: Warning: you have yet to encrypt a message to this key!
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

show more ...

x86/microcode: Handle "offline" CPUs correctly

commit 8f849ff63bcbc77670da03cb8f2b78b06257f455 upstream

Offline CPUs need to be parked in a safe loop when microcode update is
in progress on the pri

x86/microcode: Handle "offline" CPUs correctly

commit 8f849ff63bcbc77670da03cb8f2b78b06257f455 upstream

Offline CPUs need to be parked in a safe loop when microcode update is
in progress on the primary CPU. Currently, offline CPUs are parked in
mwait_play_dead(), and for Intel CPUs, its not a safe instruction,
because the MWAIT instruction can be patched in the new microcode update
that can cause instability.

- Add a new microcode state 'UCODE_OFFLINE' to report status on per-CPU
basis.
- Force NMI on the offline CPUs.

Wake up offline CPUs while the update is in progress and then return
them back to mwait_play_dead() after microcode update is complete.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231002115903.660850472@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

x86/microcode: Rendezvous and load in NMI

commit 7eb314a22800457396f541c655697dabd71e44a7 upstream

stop_machine() does not prevent the spin-waiting sibling from handling
an NMI, which is obviously

x86/microcode: Rendezvous and load in NMI

commit 7eb314a22800457396f541c655697dabd71e44a7 upstream

stop_machine() does not prevent the spin-waiting sibling from handling
an NMI, which is obviously violating the whole concept of rendezvous.

Implement a static branch right in the beginning of the NMI handler
which is nopped out except when enabled by the late loading mechanism.

The late loader enables the static branch before stop_machine() is
invoked. Each CPU has an nmi_enable in its control structure which
indicates whether the CPU should go into the update routine.

This is required to bridge the gap between enabling the branch and
actually being at the point where it is required to enter the loader
wait loop.

Each CPU which arrives in the stopper thread function sets that flag and
issues a self NMI right after that. If the NMI function sees the flag
clear, it returns. If it's set it clears the flag and enters the
rendezvous.

This is safe against a real NMI which hits in between setting the flag
and sending the NMI to itself. The real NMI will be swallowed by the
microcode update and the self NMI will then let stuff continue.
Otherwise this would end up with a spurious NMI.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231002115903.489900814@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

x86/microcode/32: Move early loading after paging enable

commit 0b62f6cb07738d7211d926c39f6946b87f72e792 upstream.

32-bit loads microcode before paging is enabled. The commit which
introduced that

x86/microcode/32: Move early loading after paging enable

commit 0b62f6cb07738d7211d926c39f6946b87f72e792 upstream.

32-bit loads microcode before paging is enabled. The commit which
introduced that has zero justification in the changelog. The cover
letter has slightly more content, but it does not give any technical
justification either:

"The problem in current microcode loading method is that we load a
microcode way, way too late; ideally we should load it before turning
paging on. This may only be practical on 32 bits since we can't get
to 64-bit mode without paging on, but we should still do it as early
as at all possible."

Handwaving word salad with zero technical content.

Someone claimed in an offlist conversation that this is required for
curing the ATOM erratum AAE44/AAF40/AAG38/AAH41. That erratum requires
an microcode update in order to make the usage of PSE safe. But during
early boot, PSE is completely irrelevant and it is evaluated way later.

Neither is it relevant for the AP on single core HT enabled CPUs as the
microcode loading on the AP is not doing anything.

On dual core CPUs there is a theoretical problem if a split of an
executable large page between enabling paging including PSE and loading
the microcode happens. But that's only theoretical, it's practically
irrelevant because the affected dual core CPUs are 64bit enabled and
therefore have paging and PSE enabled before loading the microcode on
the second core. So why would it work on 64-bit but not on 32-bit?

The erratum:

"AAG38 Code Fetch May Occur to Incorrect Address After a Large Page is
Split Into 4-Kbyte Pages

Problem: If software clears the PS (page size) bit in a present PDE
(page directory entry), that will cause linear addresses mapped through
this PDE to use 4-KByte pages instead of using a large page after old
TLB entries are invalidated. Due to this erratum, if a code fetch uses
this PDE before the TLB entry for the large page is invalidated then it
may fetch from a different physical address than specified by either the
old large page translation or the new 4-KByte page translation. This
erratum may also cause speculative code fetches from incorrect addresses."

The practical relevance for this is exactly zero because there is no
splitting of large text pages during early boot-time, i.e. between paging
enable and microcode loading, and neither during CPU hotplug.

IOW, this load microcode before paging enable is yet another voodoo
programming solution in search of a problem. What's worse is that it causes
at least two serious problems:

1) When stackprotector is enabled, the microcode loader code has the
stackprotector mechanics enabled. The read from the per CPU variable
__stack_chk_guard is always accessing the virtual address either
directly on UP or via %fs on SMP. In physical address mode this
results in an access to memory above 3GB. So this works by chance as
the hardware returns the same value when there is no RAM at this
physical address. When there is RAM populated above 3G then the read
is by chance the same as nothing changes that memory during the very
early boot stage. That's not necessarily true during runtime CPU
hotplug.

2) When function tracing is enabled, the relevant microcode loader
functions and the functions invoked from there will call into the
tracing code and evaluate global and per CPU variables in physical
address mode. What could potentially go wrong?

Cure this and move the microcode loading after the early paging enable, use
the new temporary initrd mapping and remove the gunk in the microcode
loader which is required to handle physical address mode.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231017211722.348298216@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

Merge drm/drm-fixes into drm-misc-fixes

Forwarding to v6.6-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge tag 'x86-cleanups-2023-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull misc x86 cleanups from Ingo Molnar:
"The following commit deserves special mention:

22dc02f81cd

Merge tag 'x86-cleanups-2023-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull misc x86 cleanups from Ingo Molnar:
"The following commit deserves special mention:

22dc02f81cddd Revert "sched/fair: Move unused stub functions to header"

This is in x86/cleanups, because the revert is a re-application of a
number of cleanups that got removed inadvertedly"

[ This also effectively undoes the amd_check_microcode() microcode
declaration change I had done in my microcode loader merge in commit
42a7f6e3ffe0 ("Merge tag 'x86_microcode_for_v6.6_rc1' [...]").

I picked the declaration change by Arnd from this branch instead,
which put it in <asm/processor.h> instead of <asm/microcode.h> like I
had done in my merge resolution - Linus ]

* tag 'x86-cleanups-2023-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/platform/uv: Refactor code using deprecated strncpy() interface to use strscpy()
x86/hpet: Refactor code using deprecated strncpy() interface to use strscpy()
x86/platform/uv: Refactor code using deprecated strcpy()/strncpy() interfaces to use strscpy()
x86/qspinlock-paravirt: Fix missing-prototype warning
x86/paravirt: Silence unused native_pv_lock_init() function warning
x86/alternative: Add a __alt_reloc_selftest() prototype
x86/purgatory: Include header for warn() declaration
x86/asm: Avoid unneeded __div64_32 function definition
Revert "sched/fair: Move unused stub functions to header"
x86/apic: Hide unused safe_smp_processor_id() on 32-bit UP
x86/cpu: Fix amd_check_microcode() declaration

show more ...

Merge tag 'x86_microcode_for_v6.6_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 microcode loading updates from Borislav Petkov:
"The first, cleanup part of the microcode lo

Merge tag 'x86_microcode_for_v6.6_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 microcode loading updates from Borislav Petkov:
"The first, cleanup part of the microcode loader reorg tglx has been
working on. The other part wasn't fully ready in time so it will
follow on later.

This part makes the loader core code as it is practically enabled on
pretty much every baremetal machine so there's no need to have the
Kconfig items.

In addition, there are cleanups which prepare for future feature
enablement"

* tag 'x86_microcode_for_v6.6_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/microcode: Remove remaining references to CONFIG_MICROCODE_AMD
x86/microcode/intel: Remove pointless mutex
x86/microcode/intel: Remove debug code
x86/microcode: Move core specific defines to local header
x86/microcode/intel: Rename get_datasize() since its used externally
x86/microcode: Make reload_early_microcode() static
x86/microcode: Include vendor headers into microcode.h
x86/microcode/intel: Move microcode functions out of cpu/intel.c
x86/microcode: Hide the config knob
x86/mm: Remove unused microcode.h include
x86/microcode: Remove microcode_mutex
x86/microcode/AMD: Rip out static buffers

show more ...

Merge branch 'for-linus' into for-next

Back-merge the 6.5-devel branch for the clean patch application for
6.6 and resolving merge conflicts.

Signed-off-by: Takashi Iwai <tiwai@suse.de>

BackMerge tag 'v6.5-rc7' into drm-next

Linux 6.5-rc7

This is needed for the CI stuff and the msm pull has fixes in it.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'v6.5-rc6' into icc-next

The fixes that got merged into v6.5-rc6 are needed here.

Signed-off-by: Georgi Djakov <djakov@kernel.org>

Merge tag 'v6.5-rc6' into iommufd for-next

Required for following patches.

Resolve merge conflict by using the hunk from the for-next branch and
shifting the iommufd_object_deref_user() into iommuf

Merge tag 'v6.5-rc6' into iommufd for-next

Required for following patches.

Resolve merge conflict by using the hunk from the for-next branch and
shifting the iommufd_object_deref_user() into iommufd_hw_pagetable_put()

Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

show more ...

x86/microcode: Move core specific defines to local header

There is no reason to expose all of this globally. Move everything which is
not required outside of the microcode specific code to local hea

x86/microcode: Move core specific defines to local header

There is no reason to expose all of this globally. Move everything which is
not required outside of the microcode specific code to local header files
and into the respective source files.

No functional change.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230812195727.952876381@linutronix.de

show more ...

x86/microcode: Make reload_early_microcode() static

fe055896c040 ("x86/microcode: Merge the early microcode loader") left this
needlessly public. Git archaeology provided by Borislav.

Signed-off-by

x86/microcode: Make reload_early_microcode() static

fe055896c040 ("x86/microcode: Merge the early microcode loader") left this
needlessly public. Git archaeology provided by Borislav.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230812195727.834943153@linutronix.de

show more ...

x86/microcode: Include vendor headers into microcode.h

Currently vendor specific headers are included explicitly when used in
common code. Instead, include the vendor specific headers in
microcode.h

x86/microcode: Include vendor headers into microcode.h

Currently vendor specific headers are included explicitly when used in
common code. Instead, include the vendor specific headers in
microcode.h, and include that in all usages.

No functional change.

Suggested-by: Boris Petkov <bp@alien8.de>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230812195727.776541545@linutronix.de

show more ...

x86/microcode: Hide the config knob

In reality CONFIG_MICROCODE is enabled in any reasonable configuration when
Intel or AMD support is enabled. Accommodate to reality.

Suggested-by: Borislav Petko

x86/microcode: Hide the config knob

In reality CONFIG_MICROCODE is enabled in any reasonable configuration when
Intel or AMD support is enabled. Accommodate to reality.

Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230812195727.660453052@linutronix.de

show more ...

Merge remote-tracking branch 'torvalds/master' into perf-tools-next

To pick up the fixes that were just merged from perf-tools/perf-tools
for v6.5.

Signed-off-by: Arnaldo Carvalho de Melo <acme@red

Merge remote-tracking branch 'torvalds/master' into perf-tools-next

To pick up the fixes that were just merged from perf-tools/perf-tools
for v6.5.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

show more ...

Merge tag 'asoc-fix-v6.5-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fix for v6.5

Not really a fix, but rather a licensing update for the fsl_micfil
d

Merge tag 'asoc-fix-v6.5-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fix for v6.5

Not really a fix, but rather a licensing update for the fsl_micfil
driver.

show more ...

Merge 6.5-rc4 into tty-next

We need the serial/tty fixes in here as well for testing and future
development.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 6.5-rc4 into usb-next

We need the USB fixes in here for testing and for other patches to be
applied on top of.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 6.5-rc4 into staging-next

We need the staging driver fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 6.5-rc4 into char-misc-next

We need the char-misc fixes in here as well for testing.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: Merge up fixes from Linus' tree

Gets us pine64plus back if nothing else.

regulator: Merge up fixes from Linus' tree

Gets us pine64plus back if nothing else.