linux-stable.git/Documentation/admin-guide, branch v7.1.9

x86/CPU: Add a tlbi= cmdline switch

2026-08-19T16:20:29+00:00

commit abe7c8b09bd72a9c726016257c6281f129b4c02d upstream.

With the recently found INVLPGB / TLBSYNC issue, there has been some
interest in disabling INVLPGB-based TLB flushing, in order to rule out
that CPU issue as a cause of userspace crashes.

Add a kernel command line option to control the TLB flushing behavior.

If the need arises, we will add a "tlbi=broadcast" for the case when TLB
invalidation broadcasts need to be explicitly selected, but this is not
needed now yet.

  [ bp: Rewrite commit message, move to cpu/common.c, add documentation. ]

Fixes: 767ae437a32d ("x86/mm: Add INVLPGB feature and Kconfig entry")
Suggested-by: Borislav Petkov 
Signed-off-by: Rik van Riel 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://patch.msgid.link/20260729204341.3eb0b5ea@fangorn
Signed-off-by: Greg Kroah-Hartman

usb: core: Add quirk for 255-bytes initial config read

2026-08-19T16:20:21+00:00

commit 152f174a13618bec1f842d2deb69245cb2ace51f upstream.

Certain third-party USB game controllers exposing (or spoofing) an Xbox
360-compatible interface (VID:PID 045e:028e) fail to enumerate under Linux.
The device disconnects from the bus without responding to the initial
GET_DESCRIPTOR(CONFIGURATION) request, and the kernel logs 'unable to read
config index 0 descriptor/start: -71'.

The device then falls back to a secondary Android HID mode (with a
different VID:PID), losing XInput functionality including rumble support.
The failure reproduces across multiple machines, host controller types, and
kernel versions including current mainline and LTS. The device enumerates
correctly and remains in XInput mode under Windows. Notably, the device
enumerates correctly in Android mode when the same 9-byte request
is issued for that mode's configuration descriptor, confirming the firmware
bug is specific to the XInput mode.

usbmon traces from Linux and Wireshark/USBPcap traces from Windows are
identical up to the point of failure, with no visible protocol-level
difference explaining the divergence. The root cause was identified when
Michal Pecio discovered via a QEMU bus-level capture that Windows does not
use wLength=9 for the initial config descriptor request; it uses
wLength=255. Alan Stern subsequently confirmed this with a bus
analyzer on a different USB 2.0 device, and Michal verified the behavior
goes back to Windows 95 OSR2.1.

So, add a new quirk flag USB_QUIRK_WINDOWS_CONFIG_REQ_SIZE which causes
usb_get_configuration() to issue a 255 byte sized configuration request
instead of USB_DT_CONFIG_SIZE (9) for the initial
GET_DESCRIPTOR(CONFIGURATION) request, mimicking long-standing Windows
behavior.

This patch intentionally does not add any new VID:PID entries using this
quirk. Some affected Xbox 360-compatible controllers spoof Microsoft's
VID:PID, while genuine Microsoft controllers already enumerate correctly
and do not require this quirk. Other affected clone devices use their own
VID:PID pairs and can be added individually as they are identified.

Suggested-by: Alan Stern 
Suggested-by: Michal Pecio 
Closes: https://lore.kernel.org/linux-usb/CAFgddh+JWdT4LLwMc5qjM8q_pBu-fRo2qADR5ovAKoGHWMQrRw@mail.gmail.com/
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable 
Acked-by: Alan Stern 
Signed-off-by: Nikhil Solanke 
Link: https://patch.msgid.link/20260728195158.65162-2-nikhilsolanke5@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

Docs/admin-guide/cgroup-v2: fix memory.stat doc details

2026-08-03T09:25:16+00:00

[ Upstream commit 46d65096ce8d278abf4528e254878c14ddd0b459 ]

Fix minor cgroup v2 memory.stat documentation issues.  Correct the
vmalloc per-node marker now that vmalloc uses the native NR_VMALLOC node
stat, and document zswap_incomp as a byte-valued memory amount instead
of as a page counter.

Fixes: c466412c73c3 ("mm: memcontrol: switch to native NR_VMALLOC vmstat counter")
Fixes: 5ad41a38c364 ("mm: zswap: add per-memcg stat for incompressible pages")
Signed-off-by: Doehyun Baek 
Reviewed-by: Nhat Pham 
Acked-by: Michal Koutný 
Signed-off-by: Tejun Heo 
Signed-off-by: Sasha Levin

cpufreq: Documentation: fix conservative governor freq_step description

2026-07-24T14:19:37+00:00

[ Upstream commit 03120e1425262c7d11f93362a88e579a1720390b ]

The conservative governor documentation incorrectly states that setting
freq_step to 0 will use the default 5% frequency step. In reality, since
at least commit 8e677ce83bf4 ("[CPUFREQ] conservative: fixup governor to
function more like ondemand logic"), freq_step=0 has always caused the
governor to skip frequency updates entirely.

Correct the documentation to reflect the actual behavior: freq_step=0
disables frequency changes by the governor entirely.

Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation")
Signed-off-by: Pengjie Zhang 
Reviewed-by: Zhongqiu Han 
[ rjw: Subject adjustment ]
Link: https://patch.msgid.link/20260603055635.1549943-1-zhangpengjie2@huawei.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

cpufreq: Documentation: fix sampling_down_factor range

2026-07-24T14:19:19+00:00

[ Upstream commit 85524e651d20944399322d46fb97960337831d43 ]

The ondemand governor implementation accepts sampling_down_factor values
from 1 to 100000 via MAX_SAMPLING_DOWN_FACTOR, but the documentation in
admin-guide/pm/cpufreq.rst still says the valid range is 1 to 100.

Update the documentation to match the actual code.

Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation")
Reviewed-by: Zhongqiu Han 
Signed-off-by: Pengjie Zhang 
Link: https://patch.msgid.link/20260518133457.2408463-1-zhangpengjie2@huawei.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

Documentation/arch/x86: Hide clearcpuid=

2026-05-26T03:37:20+00:00

This option was never meant to be used in production because it solely
clears the X86_FEATURE kernel-internal representation of what CPUID bits
it has detected and doesn't do any *proper* feature disablement like
clearing CR4.CET in the user shadow stack case, for example.

So remove its documentation so that it doesn't get used in production
and people get silly ideas. It is meant strictly for debugging; and if
a chicken bit for properly disabling a feature is warranted, then that
would need proper enablement.

No functional changes.

Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Ingo Molnar 
Cc: Mathias Krause 
Cc: Linus Torvalds 
Link: https://patch.msgid.link/20260520202508.160112-1-bp@kernel.org

Merge tag 'platform-drivers-x86-v7.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

2026-05-22T22:45:26+00:00

Pull x86 platform driver fixes from

 - Add ACPI_HANDLE()/ACPI_COMPANION() NULL checks (many drivers) to
   handle match overrides gracefully

 - asus-armoury:
    - Fix mini-LED mode get/set
    - Add support for FA401EA, FX607VU, G614FR, and GU605CP

 - bitland-mifs-wmi:
    - Add CONFIG_LEDS_CLASS dependency

 - hp-wmi:
    - Add thermal support for Omen 16-c0xxx (board 8902)

 - intel/vsec:
    - Fix enable_cnt imbalance due to PCIe error recovery

 - surface/aggregator_registry:
    - Remove battery & AC nodes on Surface Laptop 7 to avoid duplicated
      devices

 - uniwill-laptop:
    - Handle uninitialized and invalid charging threshold values
    - Accept charging threshold of 0 through power supply sysfs ABI and
      clamp it to 1
    - Make 'force' parameter to work also when device descriptor is
      found
    - Do not enable charging limit despite the 'force' parameter to
      avoid permanent damage to battery

* tag 'platform-drivers-x86-v7.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (35 commits)
  platform/x86: bitland-mifs-wmi: add CONFIG_LEDS_CLASS dependency
  platform/x86: wireless-hotkey: Check ACPI_COMPANION() against NULL
  platform/x86: toshiba_haps: Check ACPI_COMPANION() against NULL
  platform/x86: toshiba_bluetooth: Check ACPI_COMPANION() against NULL
  platform/x86: toshiba_acpi: Check ACPI_COMPANION() against NULL
  platform/x86: system76: Check ACPI_COMPANION() against NULL
  platform/x86: sony-laptop: Check ACPI_COMPANION() against NULL
  platform/x86: panasonic-laptop: Check ACPI_COMPANION() against NULL
  platform/x86: lg-laptop: Check ACPI_COMPANION() against NULL
  platform/x86: intel/smartconnect: Check ACPI_HANDLE() against NULL
  platform/x86: intel/rst: Check ACPI_COMPANION() against NULL
  platform/x86: fujitsu-tablet: Check ACPI_COMPANION() against NULL
  platform/x86: fujitsu: Check ACPI_COMPANION() against NULL
  platform/x86: eeepc-laptop: Check ACPI_COMPANION() against NULL
  platform/x86: dell/dell-rbtn: Check ACPI_COMPANION() against NULL
  platform/x86: asus-laptop: Check ACPI_COMPANION() against NULL
  platform/x86: acer-wireless: Check ACPI_COMPANION() against NULL
  platform/x86: asus-armoury: add support for GU605CP
  platform/x86: asus-armoury: add support for FA401EA
  platform/x86: asus-armoury: add support for G614FR
  ...

Merge tag 'amd-pstate-v7.1-2026-05-14' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux into pm-cpufreq-fixes

2026-05-20T20:03:41+00:00

Merge amd-pstate fixes for 7.1 (05/14/2026) from Mario Limonciello:

"A number of fixes to the dynamic epp feature which was new
 to kernel 7.1, including making it opt in only."

* tag 'amd-pstate-v7.1-2026-05-14' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux:
  cpufreq/amd-pstate: Drop Kconfig option for dynamic EPP
  cpufreq/amd-pstate-ut: Drop policy reference before driver switch
  cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled
  cpufreq/amd-pstate: Reorder notifier unregistration and floor perf reset
  cpufreq/amd-pstate: Allow writes to dynamic_epp when state isn't modified
  cpufreq/amd-pstate: Return -ENOMEM on failure to allocate profile_name
  cpufreq/amd-pstate: Grab "amd_pstate_driver_lock" when toggling dynamic_epp

platform/x86: uniwill-laptop: Do not enable the charging limit even when forced

2026-05-19T13:52:49+00:00

It seems that on some older models (~2020) the battery charging limit
can permanently damage the battery. Prevent users from enabling this
feature thru the "force" module parameter to avoid causing permanent
hardware damage on such devices.

Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver")
Link: https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/
Reviewed-by: Werner Sembach 
Reviewed-by: Ilpo Järvinen 
Signed-off-by: Armin Wolf 
Link: https://patch.msgid.link/20260512232145.329260-5-W_Armin@gmx.de
Signed-off-by: Ilpo Järvinen

cpufreq/amd-pstate: Drop Kconfig option for dynamic EPP

2026-05-14T13:47:48+00:00

There are some performance issues being identified by dynamic EPP
and we don't want to have distributions turning it on by default
exposing them to users at this time.

Drop the kconfig option, and require an explicit opt in from kernel
command line or runtime sysfs option to turn it on.

Reported-by: Viktor Jägersküpper 
Closes: https://lore.kernel.org/linux-pm/14a87c99-785c-4b16-bfce-35ecbf053448@freenet.de/
Reported-by: Stuart Meckle 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221473
Signed-off-by: Mario Limonciello 
Reviewed-by: K Prateek Nayak 
Link: https://lore.kernel.org/r/20260512221947.1652988-1-mario.limonciello@amd.com
(fix sysfs file path)
Signed-off-by: Mario Limonciello (AMD)