Replace strcpy with strscpy in drivers/md/dm-zoned-metadata.c.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
- Fix memory leak and a potential race in the OPP core (Abdun Nihaal,
and Di Shen).
- Mark Rust OPP methods as inline (Nicolás Antinori)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEx73Crsp7f6M6scA70rkcPK6BEhwFAmomWtIACgkQ0rkcPK6B
EhyfnQ/8D16I3iIJHkg/Pnz7nazV99essmCTpsp/+2Z+pECfkn5+WnnKrFE/LEn3
kE0Fy2lggV25pQkhTJjUjtmCg6OMHlnIFljHeiAAK4ug8kg5Ab5pPxk9uto9qlCy
cvkxS09xOlmT/Pmo00sovJWOAcNVPy6FAebJ/roJVmI54wOnOf6MZeQmQKxvd6BN
B17NlXUF0nYot05vF+iiJ4NvrhLmWQdDCG+lBhIBLAUm87pz5QB1YN69aa1J6QWv
x8Rki0nGqQABQZvgvPJ+RTEqT8E898VGGK2+QE+XBtDQU2eDNlwJfCj2yuG/svWo
E9ui62EhRmfQKt73KC+WBW7J/n/JSve0/55rFNq1lYE9JJPS60Zlcsbfhat5jndt
RfvQutz/nP382dxYRHiPzfCVOS7HuH3BJL6IcysnteoPkCYoC9RkJeQJKU5Yp5zQ
9/syMd1zPpH+bKhvPrWidjQm2Xv9YorEQpCK3Oi0OqRnB2+mOdfCzwuHyhTT89I/
bbKs8GHJZsXhLnST/hMNEDumCR7Q9W7CcBZ0sHtsQE8Zjxx47o41v/n6zC2XI0u8
nBTihRWIlSBTTpVUR3+lmOVmiAU+MSCYjrnkWsAJ0ZzLEdmZDVblhHIsTyh9vU+K
+s3nVWIMBwcq0hM3c0Az28YlIpfqJOlqGXs/Mw1qKqFF0SjMmj0=
=9mEx
-----END PGP SIGNATURE-----
Merge tag 'opp-updates-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
Pull OPP updates for 7.2 from Viresh Kumar:
"- Fix memory leak and a potential race in the OPP core (Abdun Nihaal,
and Di Shen).
- Mark Rust OPP methods as inline (Nicolás Antinori)"
* tag 'opp-updates-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
opp: rust: mark OPP methods as inline
OPP: of: Fix potential memory leak in opp_parse_supplies()
OPP: Fix race between OPP addition and lookup
When building for m68k with CONFIG_M68000=y and C=1:
drivers/clk/rockchip/clk-rk3528.c: note: in included file (through include/linux/hash.h, include/linux/slab.h):
arch/m68k/include/asm/hash.h:57:24: warning: cast truncates bits from constant value (18720 becomes 8720)
arch/m68k/include/asm/hash.h:57:24: warning: cast truncates bits from constant value (1e8e8 becomes e8e8)
Sparse does not realize the truncation is intentional.
Make this explicit by using the lower_16_bits() helper instead, which
also masks the unwanted bits.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605191434.PQkj2Rki-lkp@intel.com/
Reported-by: Heiko Stuebner <heiko@sntech.de>
Closes: https://lore.kernel.org/20260603213726.1025094-1-heiko@sntech.de/
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Daniel Palmer <daniel@thingy.jp>
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Link: https://patch.msgid.link/b55e9bd0532c0cad519809c86e0a8400060d75a1.1780559561.git.geert@linux-m68k.org
Commit 7a8c994cbb ("ACPI: processor: idle: Optimize ACPI idle
driver registration") moved the ACPI idle driver registration to
acpi_processor_driver_init(), but it didn't check whether a cpuidle
driver was already registered.
For example, on Intel platforms, if the intel_idle driver is already
loaded, the code would still evaluate the _CST object in the ACPI
table and attempt to register the acpi_idle driver. This registration
would fail with -EBUSY due to the existing check in cpuidle_register_driver.
Add a check at the beginning of acpi_processor_register_idle_driver()
to avoid unnecessary _CST evaluate and potential registration failures.
Fixes: 7a8c994cbb ("ACPI: processor: idle: Optimize ACPI idle driver registration")
Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
Link: https://patch.msgid.link/20260608190359.3254-1-TonyWWang-oc@zhaoxin.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_ipmi_space_handler() takes an extra reference on tx_msg before
checking whether the selected IPMI device is dead. The reference
belongs to the tx_msg_list entry and is normally dropped by
ipmi_cancel_tx_msg() or ipmi_flush_tx_msg() after the message is removed
from the list.
On the dead-device path, the message has not been queued yet, but the
error path still calls ipmi_msg_release() directly. That bypasses
kref_put() and frees tx_msg while the queued-message reference is still
recorded in the kref count.
Take the queued-message reference only after the dead-device check
succeeds, immediately before adding tx_msg to the list.
Fixes: 7b98447722 ("ACPI / IPMI: Add reference counting for ACPI IPMI transfers")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Link: https://patch.msgid.link/20260603163108.2149359-1-dbgh9129@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The definition of reg->access_width changes depending on the
reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses
access_width to indicate the PCC region, which can result in a UBSAN
if the value is greater than 4.
For example:
UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9
shift exponent 32 is too large for 32-bit type 'int'
CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy)
Hardware name: To be filled by O.E.M.
Call trace:
...(trimming)
ubsan_epilogue+0x10/0x48
__ubsan_handle_shift_out_of_bounds+0xdc/0x1e0
cpc_write+0x4d0/0x670
cppc_set_perf+0x18c/0x490
cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq]
... (trimming)
Lets fix this by validating the region type, as well as whether
access_width has a value. Then since we are returning bit_width
directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting
the size.
Fixes: 2f4a4d63a1 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Jarred White <jarredwhite@linux.microsoft.com>
Reviewed-by: Jarred White <jarredwhite@linux.microsoft.com>
Reviewed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
Cc: All applicable <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260601235808.1113137-1-jeremy.linton@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CVS (Computer Vision Sensing) is an ACPI-enumerated device that sits
inline in the CSI-2 path between the camera sensor and Intel IPU.
On platforms where CVS is present, the camera sensor's ACPI node
declares a _DEP dependency on the CVS device.
The CVS driver must be fully initialized before camera sensor drivers
probe, because CVS controls the CSI-2 link ownership handshake (via
GPIO REQ/RESP), the MIPI/CSI-2 lane configuration, and the camera
power domain. Without CVS ready, the sensor driver can bind but the
CSI-2 stream will not function correctly.
The CVS driver calls acpi_dev_clear_dependencies() at the end of its
probe() to unblock waiting consumers once it is ready.
Move the CVS HIDs from acpi_ignore_dep_ids[] to acpi_honor_dep_ids[]
so that camera sensor enumeration is deferred until the CVS driver has
finished probing, matching the behavior already in place for IVSC.
Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/20260601194040.18223-1-miguel.vadillo@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 0c5b5c40dc ("spi: cadence-xspi: Add COMPILE_TEST support")
allows this driver to be built for 32-bit platforms, which causes a
semantic conflict with commit 4954d4eca4 ("spi: cadence-xspi: Support
32bit and 64bit slave dma interface"), as readsq() and writesq() are
only available when targeting 64-bit platforms:
drivers/spi/spi-cadence-xspi.c: In function 'cdns_xspi_sdma_read':
drivers/spi/spi-cadence-xspi.c:601:25: error: implicit declaration of function 'readsq'; did you mean 'readsl'? [-Wimplicit-function-declaration]
601 | readsq(src, buf, len >> 3);
| ^~~~~~
| readsl
drivers/spi/spi-cadence-xspi.c: In function 'cdns_xspi_sdma_write':
drivers/spi/spi-cadence-xspi.c:623:25: error: implicit declaration of function 'writesq'; did you mean 'writesl'? [-Wimplicit-function-declaration]
623 | writesq(dst, buf, len >> 3);
| ^~~~~~~
| writesl
As there are no known 32-bit platforms that use this controller, revert
compile testing support to restrict the driver to 64-bit platforms to
avoid burdening the driver with workarounds.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Fixes: 4954d4eca4 ("spi: cadence-xspi: Support 32bit and 64bit slave dma interface")
Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20260606-spi-cadence-xspi-revert-compile-testing-v1-1-76219ea378bd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
After commit 9b311b7313 ("ACPI: NFIT: Install Notify() handler before
getting NFIT table"), ACPI NFIT driver removal may deadlock if an ACPI
notify on the NFIT device is triggered concurrently. A similar deadlock
may occur if an ACPI notify on the NFIT device is triggered during a
failing driver probe.
The deadlock is possible because acpi_dev_remove_notify_handler() calls
acpi_os_wait_events_complete() after removing the notify handler and the
driver core invokes it under the NFIT platform device lock which is also
acquired by acpi_nfit_notify(). Thus acpi_os_wait_events_complete() may
be waiting for acpi_nfit_notify() to complete, but the latter may not be
able to acquire the device lock which is being held by the driver core
while the former is being executed.
Moreover, after commit 03667e146f ("ACPI: NFIT: core: Convert the
driver to a platform one"), there are no sysfs notifications regarding
NVDIMM devices because __acpi_nvdimm_notify() always bails out after
checking the driver data pointer of the device's parent. That parent
is the ACPI companion of the platform device used for driver binding,
so its driver data pointer is always NULL after the commit in question
which was overlooked by it.
A remedy for the deadlock is to use a special separate lock for ACPI
notify synchronization with driver probe and removal instead of the
device lock of the NFIT device, while a remedy for the second issue
is to populate the driver data pointer of the NFIT device's ACPI
companion when the driver is ready to operate, so do both these things.
However, since the new lock is not held across the entire teardown and
acpi_nfit_notify() should do nothing when teardown is in progress, make
it check the driver data pointer of the NFIT device's ACPI companion, in
analogy with the existing check in __acpi_nvdimm_notify(), and bail out
if that pointer is NULL.
Fixes: 9b311b7313 ("ACPI: NFIT: Install Notify() handler before getting NFIT table")
Fixes: 03667e146f ("ACPI: NFIT: core: Convert the driver to a platform one")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org> # 9995e4404e: ACPI: NFIT: core: Eliminate redundant local variable
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/3420096.aeNJFYEL58@rafael.j.wysocki
Eliminate local variable acpi_desc from __acpi_nvdimm_notify() because it
is redundant (its value is only checked against NULL once and the value
assigned to it may be checked directly instead) and update the subsequent
comment to reflect the code change.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/14028918.uLZWGnKmhe@rafael.j.wysocki
If acpi_nfit_init() fails after adding the acpi_desc object to the
acpi_descs list, that object is never removed from that list because
the acpi_nfit_shutdown() devm action is not added for the NFIT device
in that case. Next, the acpi_nfit_init() failure causes
acpi_nfit_probe() to fail, the acpi_desc object is freed, and a
dangling pointer is left behind in the acpi_descs. Any subsequent
ACPI Machine Check Exception will trigger nfit_handle_mce() which
iterates over acpi_descs and so a use-after-free will occur.
Moreover, if acpi_nfit_probe() returns 0 after installing a notify
handler for the NFIT device and without allocating the acpi_desc
object and setting the NFIT device's driver data pointer, the
acpi_desc object will be allocated by acpi_nfit_update_notify()
and acpi_nfit_init() will be called to initialize it. Regardless
of whether or not acpi_nfit_init() fails in that case, the
acpi_nfit_shutdown() devm action is not added for the NFIT device
and acpi_desc is never removed from the acpi_descs list. If the
acpi_desc object is freed subsequently on driver removal, any
subsequent ACPI MCE will lead to a use-after-free like in the
previous case.
To address the first issue mentioned above, make acpi_nfit_probe()
call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and
to address the other one, add a remove callback to the driver and
make it call acpi_nfit_shutdown(). Also, since it is now possible to
pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it
may not have been initialized, add checks against NULL for acpi_desc and
its nvdimm_bus field to that function and make acpi_nfit_unregister()
clear the latter after unregistering the NVDIMM bus.
Fixes: a61fe6f790 ("nfit, tools/testing/nvdimm: unify common init for acpi_nfit_desc")
Fixes: fbabd829fe ("acpi, nfit: fix module unload vs workqueue shutdown race")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/1963615.tdWV9SEqCh@rafael.j.wysocki
After commit 9b311b7313 ("ACPI: NFIT: Install Notify() handler before
getting NFIT table"), acpi_nfit_probe() installs an ACPI notify handler
for the NFIT device before checking the presence of the NFIT table. If
that table is not there, 0 is returned without allocating the acpi_desc
object and setting the driver data pointer of the NFIT device. If the
platform firmware triggers an NFIT_NOTIFY_UC_MEMORY_ERROR notification
on the NFIT device at that point, acpi_nfit_uc_error_notify() will
dereference a NULL pointer.
Prevent that from occurring by adding an acpi_desc check against NULL
to acpi_nfit_uc_error_notify().
Fixes: 9b311b7313 ("ACPI: NFIT: Install Notify() handler before getting NFIT table")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/2418508.ElGaqSPkdT@rafael.j.wysocki
Add a pointer to the struct acpi_device used for installing the ACPI
notify handler to struct acpi_notify_handler_devres so it need not
be retrieved from the owner device via ACPI_COMPANION() in
devm_acpi_notify_handler_release().
While at it, drop the function name from one of the messages printed
by devm_acpi_install_notify_handler() for consistency and fix up white
space in its kerneldoc comment.
No intentional functional impact.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2841496.mvXUDI8C0e@rafael.j.wysocki
klsi_105_prepare_write_buffer() is called by the generic write path
with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It
stores a two-byte length header at the start of the buffer and copies
the payload from the write fifo starting at buf + KLSI_HDR_LEN, but
passes the full buffer size as the number of bytes to copy:
count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN,
size, &port->lock);
When the fifo holds at least size bytes, size bytes are copied starting
two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its
end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for
the header as safe_serial already does.
Writing bulk_out_size or more bytes to the tty triggers a slab
out-of-bounds write, observed with KASAN by emulating the device with
dummy_hcd and raw-gadget:
BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0
Write of size 64 at addr ffff888112c62202 by task python3
kfifo_copy_out
klsi_105_prepare_write_buffer [kl5kusb105]
usb_serial_generic_write_start [usbserial]
Allocated by task 139:
usb_serial_probe [usbserial]
The buggy address is located 2 bytes inside of allocated 64-byte region
The out-of-bounds write no longer occurs with this change applied.
Fixes: 60b3013cda ("USB: kl5usb105: reimplement using generic framework")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
wrmsrl() is a deprecated synonym for wrmsrq(). Switch its users to
wrmsrq().
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Long Li <longli@microsoft.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Link: https://patch.msgid.link/20260608082809.3492719-4-jgross@suse.com
rdmsrl() is a deprecated synonym for rdmsrq(). Switch its users to
rdmsrq().
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Long Li <longli@microsoft.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Link: https://patch.msgid.link/20260608082809.3492719-2-jgross@suse.com
OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs and are private to GPIOLIB anyway so there's
really no reason to select it explicitly.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260506081959.5221-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs and are private to GPIOLIB anyway so there's
really no reason to select it explicitly.
Link: https://patch.msgid.link/20260506082211.5624-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The length of the string is calculated in order to allocate the correct
sized memory block, use the same length to copy the string.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
Link: https://patch.msgid.link/20260606202633.5018-3-david.laight.linux@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The consumer drivers can make use of the pwrseq device's 'dev' pointer to
query the pwrseq provider's DT node to check for existence of specific
properties.
Hence, add an API to return the pwrseq device's 'dev' pointer to consumers.
Note that since pwrseq_get() would've increased the pwrseq refcount, there
is no need to increase the refcount in this API again.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-6-b39dc2ae3966@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
wrmsr_safe_on_cpu() has no users left. Delete it.
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: https://patch.msgid.link/20260608051741.3207435-12-jgross@suse.com
In order to prepare retiring wrmsr_safe_on_cpu() switch
wrmsr_safe_on_cpu() users to wrmsrq_safe_on_cpu().
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Daniel Lezcano <daniel.lezcano@kernel.org>
Link: https://patch.msgid.link/20260608051741.3207435-11-jgross@suse.com
rdmsr_safe_on_cpu() has no users left. Delete it.
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: https://patch.msgid.link/20260608051741.3207435-10-jgross@suse.com
In order to prepare retiring rdmsr_safe_on_cpu() switch
rdmsr_safe_on_cpu() users to rdmsrq_safe_on_cpu().
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Daniel Lezcano <daniel.lezcano@kernel.org>
Link: https://patch.msgid.link/20260608051741.3207435-9-jgross@suse.com
In order to prepare removal of rdmsr_safe_on_cpu(), don't use it in
rdmsrq_safe_on_cpu(), but replace it with open coding it.
This will create a nearly verbatim copy of the same code, but this is
only temporary until rdmsr_safe_on_cpu() is removed.
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: https://patch.msgid.link/20260608051741.3207435-8-jgross@suse.com
wrmsr_on_cpu() has no users left. Delete it.
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: https://patch.msgid.link/20260608051741.3207435-7-jgross@suse.com
In order to prepare retiring wrmsr_on_cpu() switch wrmsr_on_cpu() users
to wrmsrq_on_cpu().
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Daniel Lezcano <daniel.lezcano@kernel.org>
Link: https://patch.msgid.link/20260608051741.3207435-6-jgross@suse.com
rdmsr_on_cpu() has no users left. Delete it.
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: https://patch.msgid.link/20260608051741.3207435-5-jgross@suse.com
rdmsrl_on_cpu() has no users left. Delete it.
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Link: https://patch.msgid.link/20260608051741.3207435-3-jgross@suse.com
rdmsrl_on_cpu() is a deprecated synonym for rdmsrq_on_cpu().
Switch its only user to rdmsrq_on_cpu().
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260608051741.3207435-2-jgross@suse.com
Currently, pwrseq_pcie_m2_create_bt_node() hardcodes the BT compatible for
creating the devicetree node. But to allow adding support for more devices
in the future, create the BT node based on the pci_device_id[] table. The
BT compatible is passed using 'driver_data'.
Co-developed-by: Wei Deng <wei.deng@oss.qualcomm.com>
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-5-b39dc2ae3966@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
So far, the driver is registering a notifier to create serdev for the PCI
devices that are going to be attached after probe. But it doesn't handle
the devices present before probe. Due to this, serdev is not getting
created for those existing devices.
Hence, create serdev for PCI devices available before probe as well.
Note that the serdev for available devices are created before
registering the notifier. There is a small window where a device could
appear after pwrseq_pcie_m2_create_serdev(), before notifier registration.
But since M.2 cards are fixed to a slot, they are mostly added either
before booting the host or after using hotplug. So this window is mostly
theoretical.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-4-b39dc2ae3966@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Instead of hardcoding the PCI device check, use pci_match_id() to check for
the known IDs using the pwrseq_m2_pci_ids[] array.
This makes adding support for new devices easier.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-3-b39dc2ae3966@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Current code makes it possible to create serdev for only one PCI device.
But for scaling this driver, it is necessary to allow creating serdev for
multiple PCI devices.
Hence, add provision for it by creating 'struct pwrseq_pci_dev' for each
PCI device that requires serdev and add them to
'pwrseq_pcie_m2_ctx::pci_devices' list.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-2-b39dc2ae3966@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
All functions in this driver follow 'pwrseq_pcie_m2' prefix except a few.
Fix them to avoid inconsistency.
Tested-by: Wei Deng <wei.deng@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260519-pwrseq-m2-bt-v3-1-b39dc2ae3966@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
A single bugfix for the Rust I2C abstractions, targeting 7.1.
`I2cAdapter::get` calls `i2c_get_adapter()` which returns a pointer with
an already-incremented refcount. The code then converts the raw pointer to
an `ARef` via `.into()`, which calls `inc_ref()` again through the
`From<&T> for ARef<T>` impl — resulting in a leaked device and module
reference on every call.
The fix uses `ARef::from_raw()` instead, which takes ownership of the
existing refcount without incrementing it.
Signed-off-by: Igor Korotin <igor.korotin@linux.dev>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEG0Kepq7dYk2deNuvoxQiWQ2T6tUFAmokUrYACgkQoxQiWQ2T
6tXfcw//SeqQ76PJjSQf1DKf7uTEgR73RZIVEEAWEYaABPOVmwZpIAniqMz+Np2s
CBNVpttdcbgjCsbxQny9zbgCbeOGbexP2sMEuugjxDYwXAHo5OFnY3q0ReJVQIGa
I6HB38lQpK1+p20W+CzqH7TIT5Tj7VOCpuIRu86lMUVTFVAgJSW8VMGkKqjO7ler
VshMUQe8SJaIxC6XAj1ChsELfHptJozZw7zUZhj2wCmfs+pl43onE079DqNfxQJ8
YWgaF3oSBxh2/CFORJKpCy5S7J4P6JQ4j0U8G7Gvs01lhnXggPewA0oJTQlpfNPj
UGKLnSo9pG0BdGcxFqiPKqfxrAq29LO776IcrRSQa7sEcSlwRh4L4h0LFY0TUvmY
5nR5BoXLOYpmrNP7WFCUISvjVXJaX8F3MEnVC7R/PmnOUhXWLBXZyzqzgUrAPkgl
R4Ofye3yWpdJRes4O7diR3vnvRdxLMpfehJi2WHUjB90StxrLkYGZRK5fGj6+90m
Pmefu7Qic1mos5jy0/9UjfaIaUS1W23KxX8HcNoMLZF/tl8YJ1FtMpm6ZrRSxM/v
1LiEXLZkQOfuNebjfyUZwzWIptYtq9h4N9X9ANykLPTiTncJmxQmzaPsoRE4ew0T
AD7P/WpLFbLs2XI/J5JuAVrfnOe+UjnvsixBxuPxEtgVY5K2pjA=
=LhTi
-----END PGP SIGNATURE-----
Merge tag 'rust-i2c-7.1-rc7' of https://github.com/ikrtn/linux into i2c/for-current
rust: i2c: fix I2cAdapter refcount double increment
Now that lazy mmu state tracking no longer relies on the Xen specific
one, cpu lazy mode is the only user of the Xen generic lazy tracking.
Replace the Xen generic lazy tracking with a cpu lazy specific one.
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260526150514.129330-6-jgross@suse.com>
There are only very few use cases of XEN_LAZY_MMU left. Get rid of
them in order to avoid having to call enter_lazy(XEN_LAZY_MMU) and
leave_lazy(XEN_LAZY_MMU).
The query in xen_batched_set_pte() can be replaced by using
is_lazy_mmu_mode_active() instead.
As xen_flush_lazy_mmu() will be called only with lazy MMU mode being
active, the test for the lazy mode can just be dropped.
In xen_start_context_switch() and xen_end_context_switch() use
__task_lazy_mmu_mode_pause() and __task_lazy_mmu_mode_resume(),
allowing to drop xen_enter_lazy_mmu() and xen_leave_lazy_mmu()
completely.
Call arch_flush_lazy_mmu_mode() from arch_leave_lazy_mmu_mode(), as
this is the only required action now.
Drop the lazy mmu enter and leave paravirt hooks, leaving the flush
hook as the only needed one.
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260526150514.129330-5-jgross@suse.com>
In order to allow pausing and resuming MMU lazy mode for other tasks
than current, refactor lazy_mmu_mode_pause() and
lazy_mmu_mode_resume().
This will be needed when dropping the Xen PV private lazy MMU
bookkeeping.
Acked-by: "David Hildenbrand (Arm)" <david@kernel.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260526150514.129330-4-jgross@suse.com>
Today xen_mc_issue() is deciding whether to call xen_mc_flush() or not
based on the lazy mode input parameter passed.
Modify this interface to pass a boolean indicating whether the flush
should be done.
For querying lazy mmu mode use the is_lazy_mmu_mode_active() helper.
This is done in preparation for dropping the xen_lazy_mode percpu
variable.
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260526150514.129330-3-jgross@suse.com>
Drop the lazy mode (cpu or mmu) from the xen_mc_batch and xen_mc_issue
trace entries.
This is done in preparation of removing the xen_lazy_mode percpu
variable.
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260526150514.129330-2-jgross@suse.com>
The only Xen file in debugfs is for dumping the p2m table when running
as a Xen PV guest. This might have been useful when the PV code was
young, but there haven't been any p2m related bugs requiring the p2m
dump since ages.
Remove the code and the related config option.
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260522152114.77319-4-jgross@suse.com>
Since dropping Xen-PV support for 32-bit, include/trace/events/xen.h
contains several stale trace point definitions. Remove them.
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260522152114.77319-3-jgross@suse.com>
A lot of arch/x86/xen/xen-ops.h is meant to be for PV only. Guard all
of it with CONFIG_XEN_PV in order to avoid someone misusing it in
non-PV builds. Additionally any 64-bit tests for now guarded items can
be dropped.
Move the enum pt_level definition to mmu_pv.c, as it is used only there.
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260522152114.77319-2-jgross@suse.com>
Replace sprintf() calls with sysfs_emit() to follow current kernel
coding standards.
sysfs_emit() is the preferred method for formatting sysfs output as it
provides better bounds checking and is more secure.
Signed-off-by: Yash Suthar <yashsuthar983@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260517133817.29691-1-yashsuthar983@gmail.com>
The 'g_physinfo' and 'ncpus' variables are initialized only during the
init phase in the 'bind_virq_for_mce' function and never changed. So,
mark them as __ro_after_init.
The 'xen_mce_chrdev_device' variable is initialized only in the
declaration and never changed. So, this variable could be 'const', but
using the 'misc_register' and 'misc_deregister' functions discards the
'const' qualifier. Therefore, as an alternative, mark it as
__ro_after_init.
Signed-off-by: Len Bao <len.bao@gmx.us>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260523132802.25391-1-len.bao@gmx.us>
