In order to move arch_register_cpu() to be called via the same path
for initially present CPUs described by ACPI and hotplugged CPUs
ACPI_HOTPLUG_CPU needs to be enabled.

The protection against invalid IDs in acpi_map_cpu() is needed as
at least one production BIOS is in the wild which reports entries
in DSDT (with no _STA method, so assumed enabled and present)
that don't match MADT.
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-18-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

The ARM64 architecture does not support physical CPU HP today.
To avoid any possibility of a bug against such an architecture if defined
in future, check for the physical CPU HP case (not present) and
return an error on any such attempt.

On ARM64 virtual CPU Hotplug relies on the status value that can be
queried via the AML method _STA for the CPU object.

There are two conditions in which the CPU can be registered.
1) ACPI disabled.
2) ACPI enabled and the acpi_handle is available.
   _STA evaluates to the CPU is both enabled and present.
   (Note that in absence of the _STA method they are always in this
    state).

If neither of these conditions is met the CPU is not 'yet' ready
to be used and -EPROBE_DEFER is returned.

Success occurs in the early attempt to register the CPUs if we
are booting with DT (no concept yet of vCPU HP) if not it succeeds
for already enabled CPUs when the ACPI Processor driver attaches to
them.  Finally it may succeed via the CPU Hotplug code indicating that
the CPU is now enabled.

For ACPI if CONFIG_ACPI_PROCESSOR the only path to get to
arch_register_cpu() with that handle set is via
acpi_processor_hot_add_init() which is only called from an ACPI bus
scan in which _STA has already been queried there is no need to
repeat it here. Add a comment to remind us of this in the future.
Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-17-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

When a CPU is marked as disabled, but online capable in the MADT, PSCI
applies some firmware policy to control when it can be brought online.
PSCI returns DENIED to a CPU_ON request if this is not currently
permitted. The OS can learn the current policy from the _STA enabled bit.

Handle the PSCI DENIED return code gracefully instead of printing an
error.

Note the alternatives to the PSCI cpu_boot() callback do not
return -EPERM so the change in smp.c has no affect.

See https://developer.arm.com/documentation/den0022/f/?lang=en page 58.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
[ morse: Rewrote commit message ]
Signed-off-by: James Morse <james.morse@arm.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-16-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

To support virtual CPU hotplug, ACPI has added an 'online capable' bit
to the MADT GICC entries. This indicates a disabled CPU entry may not
be possible to online via PSCI until firmware has set enabled bit in
_STA.

This means that a "usable" GIC redistributor is one that is marked as
either enabled, or online capable. The meaning of the
acpi_gicc_is_usable() would become less clear than just checking the
pair of flags at call sites. As such, drop that helper function.
The test in gic_acpi_match_gicc() remains as testing just the
enabled bit so the count of enabled distributors is correct.

What about the redistributor in the GICC entry? ACPI doesn't want to say.
Assume the worst: When a redistributor is described in the GICC entry,
but the entry is marked as disabled at boot, assume the redistributor
is inaccessible.

The GICv3 driver doesn't support late online of redistributors, so this
means the corresponding CPU can't be brought online either.
Rather than modifying cpu masks that may already have been used,
register a new cpuhp callback to fail this case. This must run earlier
than the main gic_starting_cpu() so that this case can be rejected
before the section of cpuhp that runs on the CPU that is coming up as
that is not allowed to fail. This solution keeps the handling of this
broken firmware corner case local to the GIC driver. As precise ordering
of this callback doesn't need to be controlled as long as it is
in that initial prepare phase, use CPUHP_BP_PREPARE_DYN.

Systems that want CPU hotplug in a VM can ensure their redistributors
are always-on, and describe them that way with a GICR entry in the MADT.
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20240529133446.28446-15-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

gic_acpi_match_gicc() is only called via gic_acpi_count_gicr_regions().
It should only count the number of enabled redistributors, but it
also tries to sanity check the GICC entry, currently returning an
error if the Enabled bit is set, but the gicr_base_address is zero.

Adding support for the online-capable bit to the sanity check will
complicate it, for no benefit. The existing check implicitly depends on
gic_acpi_count_gicr_regions() previous failing to find any GICR regions
(as it is valid to have gicr_base_address of zero if the redistributors
are described via a GICR entry).

Instead of complicating the check, remove it. Failures that happen at
this point cause the irqchip not to register, meaning no irqs can be
requested. The kernel grinds to a panic() pretty quickly.

Without the check, MADT tables that exhibit this problem are still
caught by gic_populate_rdist(), which helpfully also prints what went
wrong:
| CPU4: mpidr 100 has no re-distributor!
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20240529133446.28446-14-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

In a review discussion of the changes to support vCPU hotplug where
a check was added on the GICC being enabled if was online, it was
noted that there is need to map back to the cpu and use that to index
into a cpumask. As such, a valid ID is needed.

If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
for the entry in cpu_madt_gicc[cpu] == NULL.  This function would
then cause a NULL pointer dereference.   Whilst a path to trigger
this has not been established, harden this caller against the
possibility.
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-13-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

ACPI identifies CPUs by UID. get_cpu_for_acpi_id() maps the ACPI UID
to the Linux CPU number.

The helper to retrieve this mapping is only available in arm64's NUMA
code.

Move it to live next to get_acpi_id_for_cpu().
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Link: https://lore.kernel.org/r/20240529133446.28446-12-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

struct acpi_scan_handler has a detach callback that is used to remove
a driver when a bus is changed. When interacting with an eject-request,
the detach callback is called before _EJ0.

This means the ACPI processor driver can't use _STA to determine if a
CPU has been made not-present, or some of the other _STA bits have been
changed. acpi_processor_remove() needs to know the value of _STA after
_EJ0 has been called.

Add a post_eject callback to struct acpi_scan_handler. This is called
after acpi_scan_hot_remove() has successfully called _EJ0. Because
acpi_scan_check_and_detach() also clears the handler pointer,
it needs to be told if the caller will go on to call
acpi_bus_post_eject(), so that acpi_device_clear_enumerated()
and clearing the handler pointer can be deferred.
An extra flag is added to flags field introduced in the previous
patch to achieve this.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-11-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

Precursor patch adds the ability to pass a uintptr_t of flags into
acpi_scan_check_and detach() so that additional flags can be
added to indicate whether to defer portions of the eject flow.
The new flag follows in the next patch.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-10-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

The arm64 specific arch_register_cpu() call may defer CPU registration
until the ACPI interpreter is available and the _STA method can
be evaluated.

If this occurs, then a second attempt is made in
acpi_processor_get_info(). Note that the arm64 specific call has
not yet been added so for now this will be called for the original
hotplug case.

For architectures that do not defer until the ACPI Processor
driver loads (e.g. x86), for initially present CPUs there will
already be a CPU device. If present do not try to register again.

Systems can still be booted with 'acpi=off', or not include an
ACPI description at all as in these cases arch_register_cpu()
will not have deferred registration when first called.

This moves the CPU register logic back to a subsys_initcall(),
while the memory nodes will have been registered earlier.
Note this is where the call was prior to the cleanup series so
there should be no side effects of moving it back again for this
specific case.

[PATCH 00/21] Initial cleanups for vCPU HP.
https://lore.kernel.org/all/ZVyz%2FVe5pPu8AWoA@shell.armlinux.org.uk/
commit 5b95f94c ("x86/topology: Switch over to GENERIC_CPU_DEVICES")
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu@arm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-9-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

If CONFIG_ACPI_PROCESSOR provide a helper to retrieve the
acpi_handle for a given CPU allowing access to methods
in DSDT.
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-8-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

Make the per_cpu(processors, cpu) entries available earlier so that
they are available in arch_register_cpu() as ARM64 will need access
to the acpi_handle to distinguish between acpi_processor_add()
and earlier registration attempts (which will fail as _STA cannot
be checked).

Reorder the remove flow to clear this per_cpu() after
arch_unregister_cpu() has completed, allowing it to be used in
there as well.

Note that on x86 for the CPU hotplug case, the pr->id prior to
acpi_map_cpu() may be invalid. Thus the per_cpu() structures
must be initialized after that call or after checking the ID
is valid (not hotplug path).
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-7-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

If acpi_processor_get_info() returned an error, pr and the associated
pr->throttling.shared_cpu_map were leaked.

The unwind code was in the wrong order wrt to setup, relying on
some unwind actions having no affect (clearing variables that were
never set etc).  That makes it harder to reason about so reorder
and add appropriate labels to only undo what was actually set up
in the first place.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-6-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

Rafael observed [1] that returning 0 from processor_add() will result in
acpi_default_enumeration() being called which will attempt to create a
platform device, but that makes little sense when the processor is known
to be not available.  So just return the error code from acpi_processor_get_info()
instead.

Link: https://lore.kernel.org/all/CAJZ5v0iKU8ra9jR+EmgxbuNm=Uwx2m1-8vn_RAZ+aCiUVLe3Pw@mail.gmail.com/ [1]
Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-5-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

The ACPI bus scan will only result in acpi_processor_add() being called
if _STA has already been checked and the result is that the
processor is enabled and present.  Hence drop this additional check.
Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-4-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

For arm64 the CPU registration cannot complete until the ACPI
interpreter us up and running so in those cases the arch specific
arch_register_cpu() will return -EPROBE_DEFER at this stage and the
registration will be attempted later.
Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-3-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

Separate code paths, combined with a flag set in acpi_processor.c to
indicate a struct acpi_processor was for a hotplugged CPU ensured that
per CPU data was only set up the first time that a CPU was initialized.
This appears to be unnecessary as the paths can be combined by letting
the online logic also handle any CPUs online at the time of driver load.

Motivation for this change, beyond simplification, is that ARM64
virtual CPU HP uses the same code paths for hotplug and cold path in
acpi_processor.c so had no easy way to set the flag for hotplug only.
Removing this necessity will enable ARM64 vCPU HP to reuse the existing
code paths.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240529133446.28446-2-Jonathan.Cameron@huawei.comSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

Merge tag 'perf-tools-fixes-for-v6.10-2-2024-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools

Pull perf tools fixes from Arnaldo Carvalho de Melo:

 - Update copies of kernel headers, which resulted in support for the
   new 'mseal' syscall, SUBVOL statx return mask bit, RISC-V and PPC
   prctls, fcntl's DUPFD_QUERY, POSTED_MSI_NOTIFICATION IRQ vector,
   'map_shadow_stack' syscall for x86-32.

 - Revert perf.data record memory allocation optimization that ended up
   causing a regression, work is being done to re-introduce it in the
   next merge window.

 - Fix handling of minimal vmlinux.h file used with BPF's CO-RE when
   interrupting the build.

* tag 'perf-tools-fixes-for-v6.10-2-2024-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
  perf bpf: Fix handling of minimal vmlinux.h file when interrupting the build
  Revert "perf record: Reduce memory for recording PERF_RECORD_LOST_SAMPLES event"
  tools headers arm64: Sync arm64's cputype.h with the kernel sources
  tools headers uapi: Sync linux/stat.h with the kernel sources to pick STATX_SUBVOL
  tools headers UAPI: Update i915_drm.h with the kernel sources
  tools headers UAPI: Sync kvm headers with the kernel sources
  tools arch x86: Sync the msr-index.h copy with the kernel sources
  tools headers: Update the syscall tables and unistd.h, mostly to support the new 'mseal' syscall
  perf trace beauty: Update the arch/x86/include/asm/irq_vectors.h copy with the kernel sources to pick POSTED_MSI_NOTIFICATION
  perf beauty: Update copy of linux/socket.h with the kernel sources
  tools headers UAPI: Sync fcntl.h with the kernel sources to pick F_DUPFD_QUERY
  tools headers UAPI: Sync linux/prctl.h with the kernel sources
  tools include UAPI: Sync linux/stat.h with the kernel sources

Pull EDAC fixes from Borislav Petkov:

 - Convert PCI core error codes to proper error numbers since latter get
   propagated all the way up to the module loading functions

* tag 'edac_urgent_for_v6.10_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
  EDAC/igen6: Convert PCIBIOS_* return codes to errnos
  EDAC/amd64: Convert PCIBIOS_* return codes to errnos

Pull clk fix from Stephen Boyd:
 "One fix for the SiFive PRCI clocks so that the device boots again.

  This driver was registering clkdev lookups that were always going to
  be useless. This wasn't a problem until clkdev started returning an
  error in these cases, causing this driver to fail probe, and thus boot
  to fail because clks are essential for most drivers. The fix is
  simple, don't use clkdev because this is a DT based system where
  clkdev isn't used"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  clk: sifive: Do not register clkdevs for PRCI clocks

Pull smb client fixes from Steve French:
 "Two small smb3 client fixes:

   - fix deadlock in umount

   - minor cleanup due to netfs change"

* tag '6.10-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: Don't advance the I/O iterator before terminating subrequest
  smb: client: fix deadlock in smb2_find_smb_tcon()

Pull HID fixes from Benjamin Tissoires:

 - fix potential read out of bounds in hid-asus (Andrew Ballance)

 - fix endian-conversion on little endian systems in intel-ish-hid (Arnd
   Bergmann)

 - A couple of new input event codes (Aseda Aboagye)

 - errors handling fixes in hid-nvidia-shield (Chen Ni), hid-nintendo
   (Christophe JAILLET), hid-logitech-dj (José Expósito)

 - current leakage fix while the device is in suspend on a i2c-hid
   laptop (Johan Hovold)

 - other assorted smaller fixes and device ID / quirk entry additions

* tag 'for-linus-2024060801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
  HID: Ignore battery for ELAN touchscreens 2F2C and 4116
  HID: i2c-hid: elan: fix reset suspend current leakage
  dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property
  dt-bindings: HID: i2c-hid: elan: add Elan eKTH5015M
  dt-bindings: HID: i2c-hid: add dedicated Ilitek ILI2901 schema
  input: Add support for "Do Not Disturb"
  input: Add event code for accessibility key
  hid: asus: asus_report_fixup: fix potential read out of bounds
  HID: logitech-hidpp: add missing MODULE_DESCRIPTION() macro
  HID: intel-ish-hid: fix endian-conversion
  HID: nintendo: Fix an error handling path in nintendo_hid_probe()
  HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()
  HID: core: remove unnecessary WARN_ON() in implement()
  HID: nvidia-shield: Add missing check for input_ff_create_memless
  HID: intel-ish-hid: Fix build error for COMPILE_TEST

Merge tag 'kbuild-fixes-v6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:

 - Fix the initial state of the save button in 'make gconfig'

 - Improve the Kconfig documentation

 - Fix a Kconfig bug regarding property visibility

 - Fix build breakage for systems where 'sed' is not installed in /bin

 - Fix a false warning about missing MODULE_DESCRIPTION()

* tag 'kbuild-fixes-v6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  modpost: do not warn about missing MODULE_DESCRIPTION() for vmlinux.o
  kbuild: explicitly run mksysmap as sed script from link-vmlinux.sh
  kconfig: remove wrong expr_trans_bool()
  kconfig: doc: document behavior of 'select' and 'imply' followed by 'if'
  kconfig: doc: fix a typo in the note about 'imply'
  kconfig: gconf: give a proper initial state to the Save button
  kconfig: remove unneeded code for user-supplied values being out of range

Pull media fixes from Mauro Carvalho Chehab:

 - fixes for the new ipu6 driver (and related fixes to mei csi driver)

 - fix a double debugfs remove logic at mgb4 driver

 - a documentation fix

* tag 'media/v6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  media: intel/ipu6: add csi2 port sanity check in notifier bound
  media: intel/ipu6: update the maximum supported csi2 port number to 6
  media: mei: csi: Warn less verbosely of a missing device fwnode
  media: mei: csi: Put the IPU device reference
  media: intel/ipu6: fix the buffer flags caused by wrong parentheses
  media: intel/ipu6: Fix an error handling path in isys_probe()
  media: intel/ipu6: Move isys_remove() close to isys_probe()
  media: intel/ipu6: Fix some redundant resources freeing in ipu6_pci_remove()
  media: Documentation: v4l: Fix ACTIVE route flag
  media: mgb4: Fix double debugfs remove

Pull irq fixes from Ingo Molnar:

 - Fix possible memory leak the riscv-intc irqchip driver load failures

 - Fix boot crash in the sifive-plic irqchip driver caused by recently
   changed boot initialization order

 - Fix race condition in the gic-v3-its irqchip driver

* tag 'irq-urgent-2024-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()
  irqchip/sifive-plic: Chain to parent IRQ after handlers are ready
  irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails

Pull x86 fixes from Ingo Molnar:
 "Miscellaneous fixes:

   - Fix kexec() crash if call depth tracking is enabled

   - Fix SMN reads on inaccessible registers on certain AMD systems"

* tag 'x86-urgent-2024-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/amd_nb: Check for invalid SMN reads
  x86/kexec: Fix bug with call depth tracking

Pull perf event fix from Ingo Molnar:
 "Fix race between perf_event_free_task() and perf_event_release_kernel()
  that can result in missed wakeups and hung tasks"

* tag 'perf-urgent-2024-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/core: Fix missing wakeup when waiting for context reference

Pull locking doc fix from Ingo Molnar:
 "Fix typos in the kerneldoc of some of the atomic APIs"

* tag 'locking-urgent-2024-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/atomic: scripts: fix ${atomic}_sub_and_test() kerneldoc

Merge tag 'mm-hotfixes-stable-2024-06-07-15-24' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Pull misc fixes from Andrew Morton:
 "14 hotfixes, 6 of which are cc:stable.

  All except the nilfs2 fix affect MM and all are singletons - see the
  chagelogs for details"

* tag 'mm-hotfixes-stable-2024-06-07-15-24' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors
  mm: fix xyz_noprof functions calling profiled functions
  codetag: avoid race at alloc_slab_obj_exts
  mm/hugetlb: do not call vma_add_reservation upon ENOMEM
  mm/ksm: fix ksm_zero_pages accounting
  mm/ksm: fix ksm_pages_scanned accounting
  kmsan: do not wipe out origin when doing partial unpoisoning
  vmalloc: check CONFIG_EXECMEM in is_vmalloc_or_module_addr()
  mm: page_alloc: fix highatomic typing in multi-block buddies
  nilfs2: fix potential kernel bug due to lack of writeback flag waiting
  memcg: remove the lockdep assert from __mod_objcg_mlstate()
  mm: arm64: fix the out-of-bounds issue in contpte_clear_young_dirty_ptes
  mm: huge_mm: fix undefined reference to `mthp_stats' for CONFIG_SYSFS=n
  mm: drop the 'anon_' prefix for swap-out mTHP counters

Pull gpio fixes from Bartosz Golaszewski:

 - interrupt handling and Kconfig fixes for gpio-tqmx86

 - add a buffer for storing output values in gpio-tqmx86 as reading back
   the registers always returns the input values

 - add missing MODULE_DESCRIPTION()s to several GPIO drivers

* tag 'gpio-fixes-for-v6.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpio: add missing MODULE_DESCRIPTION() macros
  gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type
  gpio: tqmx86: store IRQ trigger type and unmask status separately
  gpio: tqmx86: introduce shadow register for GPIO output value
  gpio: tqmx86: fix typo in Kconfig label

Pull block fixes from Jens Axboe:

 - Fix for null_blk block size validation (Andreas)

 - NVMe pull request via Keith:
      - Use reserved tags for special fabrics operations (Chunguang)
      - Persistent Reservation status masking fix (Weiwen)

* tag 'block-6.10-20240607' of git://git.kernel.dk/linux:
  null_blk: fix validation of block size
  nvme: fix nvme_pr_* status code parsing
  nvme-fabrics: use reserved tag for reg read/write command

Pull io_uring fixes from Jens Axboe:

 - Fix a locking order issue with setting max async thread workers
   (Hagar)

 - Fix for a NULL pointer dereference for failed async flagged requests
   using ring provided buffers. This doesn't affect the current kernel,
   but it does affect older kernels, and is being queued up for 6.10
   just to make the stable process easier (me)

 - Fix for NAPI timeout calculations for how long to busy poll, and
   subsequently how much to sleep post that if a wait timeout is passed
   in (me)

 - Fix for a regression in this release cycle, where we could end up
   using a partially unitialized match value for io-wq (Su)

* tag 'io_uring-6.10-20240607' of git://git.kernel.dk/linux:
  io_uring: fix possible deadlock in io_register_iowq_max_workers()
  io_uring/io-wq: avoid garbage value of 'match' in io_wq_enqueue()
  io_uring/napi: fix timeout calculation
  io_uring: check for non-NULL file pointer in io_file_can_poll()

Pull btrfs fixes from David Sterba:

 - fix handling of folio private changes.

   The private value holds pointer to our extent buffer structure
   representing a metadata range. Release and create of the range was
   not properly synchronized when updating the private bit which ended
   up in double folio_put, leading to all sorts of breakage

 - fix a crash, reported as duplicate key in metadata, but caused by a
   race of fsync and size extending write. Requires prealloc target
   range + fsync and other conditions (log tree state, timing)

 - fix leak of qgroup extent records after transaction abort

* tag 'for-6.10-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: protect folio::private when attaching extent buffer folios
  btrfs: fix leak of qgroup extent records after transaction abort
  btrfs: fix crash on racing fsync and size-extending write into prealloc

Pull nfsd fix from Chuck Lever:

 - Fix an occasional memory overwrite caused by a fix added in 6.10

* tag 'nfsd-6.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
  SUNRPC: Fix loop termination condition in gss_free_in_token_pages()

Pull RISC-V fixes from Palmer Dabbelt:

 - Another fix to avoid allocating pages that overlap with ERR_PTR,
   which manifests on rv32

 - A revert for the badaccess patch I incorrectly picked up an early
   version of

* tag 'riscv-for-linus-6.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  Revert "riscv: mm: accelerate pagefault when badaccess"
  riscv: fix overlap of allocated page and PTR_ERR

Pull s390 fixes from Alexander Gordeev:

 - Do not create PT_LOAD program header for the kenel image when the
   virtual memory informaton in OS_INFO data is not available. That
   fixes stand-alone dump failures against kernels that do not provide
   the virtual memory informaton

 - Add KVM s390 shared zeropage selftest

* tag 's390-6.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  KVM: s390x: selftests: Add shared zeropage test
  s390/crash: Do not use VM info if os_info does not have it

Pull arm64 fixes from Will Deacon:

 - Fix spurious CPU hotplug warning message from SETEND emulation code

 - Fix the build when GCC wasn't inlining our I/O accessor internals

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/io: add constant-argument check
  arm64: armv8_deprecated: Fix warning in isndep cpuhp starting process

Merge tag 'platform-drivers-x86-v6.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform driver fixes from Hans de Goede:

 -  Default silead touchscreen driver to 10 fingers and drop 10 finger
    setting from all DMI quirks. More of a cleanup then a pure fix, but
    since the DMI quirks always get updated through the fixes branch
    this avoids conflicts.

 -  Kconfig fix for randconfig builds

 -  dell-smbios: Fix wrong token data in sysfs

 -  amd-hsmp: Fix driver poking unsupported hw when loaded manually

* tag 'platform-drivers-x86-v6.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
  platform/x86/amd/hsmp: Check HSMP support on AMD family of processors
  platform/x86: dell-smbios: Simplify error handling
  platform/x86: dell-smbios: Fix wrong token data in sysfs
  platform/x86: yt2-1380: add CONFIG_EXTCON dependency
  platform/x86: touchscreen_dmi: Use 2-argument strscpy()
  platform/x86: touchscreen_dmi: Drop "silead,max-fingers" property
  Input: silead - Always support 10 fingers

Pull iommu fixes from Joerg Roedel:
 "Core:

   - Make iommu-dma code recognize 'force_aperture' again

   - Fix for potential NULL-ptr dereference from iommu_sva_bind_device()
     return value

  AMD IOMMU fixes:

   - Fix lockdep splat for invalid wait context

   - Add feature bit check before enabling PPR

   - Make workqueue name fit into buffer

   - Fix memory leak in sysfs code"

* tag 'iommu-fixes-v6.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/amd: Fix Invalid wait context issue
  iommu/amd: Check EFR[EPHSup] bit before enabling PPR
  iommu/amd: Fix workqueue name
  iommu: Return right value in iommu_sva_bind_device()
  iommu/dma: Fix domain init
  iommu/amd: Fix sysfs leak in iommu init