Cover a missed execution path with a new check.
Fixes: 0acf24ad7e ("ACPICA: Add support for PCC Opregion special context data")
Link: f421dd9dd8
Signed-off-by: Alexey Simakov <bigalex934@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3030574.e9J7NaK4W3@rafael.j.wysocki
The Trusted Computing Group has designed multiple interface extensions
around TPM 2.0 devices including the ACPI start method, hardware
information and memory clear features. Add the associated UUIDs to the
list of known UUIDs so that the ASL compiler stops complaining about
them.
Link: 0e8b10b058
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2254685.irdbgypaU6@rafael.j.wysocki
Microsoft has designed an interface for reading/writing fan speed
trip points. Add the associated UUID to the list of known UUIDs so
that the ASL compiler stops complaining about it.
Link: 67f0202c0f
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/5045837.GXAFRqVoOG@rafael.j.wysocki
acpi_ut_create_internal_object() may allocate memory from a slab cache
via kmem_cache_zalloc(), but the code currently frees it with ACPI_FREE(),
which calls kfree().
This mismatch prevents the object from being released properly and may
lead to memory leaks or other issues.
Fix this by replacing ACPI_FREE() with acpi_ut_delete_object_desc(),
which matches the allocation method used for internal objects.
Link: a1c55dfea1
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/4710853.LvFx2qVVIh@rafael.j.wysocki
Define a new the ACPI Table, structure and registers, related with it, according
to the latest version of the Intel TXT DMA Protection Ranges (TPR) specification
(Revision 0.73):
* DTPR ACPI Table
* TPR Base Register
* TPR Serialize Request Register
* TPR Limit Register
* TPR Instance Structure
* DMAR TXT Protected Reporting Structure
These structures will be used to handle TPRs on the Intel CPU's.
Link: 10e7a88f70
Link: https://uefi.org/sites/default/files/resources/633933_Intel_TXT_DMA_Protection_Ranges_rev_0p73.pdf
Signed-off-by: Michal Camacho Romero <michal.camacho.romero@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/6234415.lOV4Wx5bFT@rafael.j.wysocki
the next peripheral, Nano Pi M5 sound was not working correctly, the
adc-keys voltage levels for 2 buttons on the Pinephone Pro were wrong
and a really wrong PCIe linkspeed was removed from helios64.
Apart from that there are a number of dt-cleanlieness fixes.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmlmRpMQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdga/NB/4rqhVfKrxotl5AmAdDmJrz86C1Qxa6cOxB
WD011An0u00V0oSARJM0r9Ng7ZpFUy1wf1VpRl4oSKiGWJKdAiJ0IzvUQyy9T7nM
vleEyST80y9t+Xq0ePXzDs3ADDhO5d9g1uJ2E9d+g2rsOFBVUWmUizeqiuY8YRmy
kgaHsz6xrPsvdS+bMHhhgsXdFXOU6TFITLMpliPr6QCBi539R/N6o4cVhh6gK+Fd
4TqoNne3cYiWsOrQ5qf57N3HPQ0sNBk4aikVFb2wrJYsMl+yFGML64CmXzhyfpIb
v4vg3T90l0OontCKJ7/lP4LZdiO47pUSct29o52XJBfty7KpCso1
=XPJU
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmlpHOwACgkQmmx57+YA
GNnbjQ/+NWB20eyslWokB53g9ZCI2K3ORWtrrzDNPHPRfcF85Cjm/Gp50QrT3yR/
xNGOz9T2iDFVa0uwTWEpRZhjDzew46YxMeAWCvYl5LNnPpgpISeTQ3nc3uRs1qFo
SKRNd7CL2qkRYAwANoV8VIHhXa6u8N+TlPykUKvVnmfwJEJdzjYLz14E2NJDytSr
c57JjLae4FwLoPFTMwTqhBKUVVFj22HK4leZ6nGRbOt8Z3opMwtFBPfQURir19+w
rNHOHJatqdRKiaVlDCJSHaav+hijx4Ik7JQp+nXbZLWX6BJKHhID90Bs63OrhNxc
OR3i399y3Smi9dg9HLmGoB1XJYLiz39Oh/FVl3/C8qDnqddurhuwbrvJroauOMw4
4gv2j8FtZ5rXxWblvP2t3otEx71Vo5kTMzz8Xa25gomhxoOZx3k5CDwIPcE2gxsC
zj1xshF7yzDOm32EVeJ7F/b8BgsFi5E6otafgxitgnsYoIuwOplZYcHOolRbBhJ2
+Wb0tTf6Q0Mk/OgeR0rJNDmRb0ucL6U3rexOotnPsm6yuKPKoeb7l/xhlFjLbie8
SzsVOuaT07LxdbOndVn3+/4kvPcSuz5JQXqu4SlZANeDcDZ1MQafGrEXERQihNOO
JsWkAq5mMyBC67I0Ydg1ce+7dbVlyVUOkn+arj9TUaLwE8plgu8=
=nISS
-----END PGP SIGNATURE-----
Merge tag 'v6.19-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
In terms of bigger fixes, RK3576 GPU register range was overflowing into
the next peripheral, Nano Pi M5 sound was not working correctly, the
adc-keys voltage levels for 2 buttons on the Pinephone Pro were wrong
and a really wrong PCIe linkspeed was removed from helios64.
Apart from that there are a number of dt-cleanlieness fixes.
* tag 'v6.19-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: Drop unsupported properties
arm64: dts: rockchip: Fix gpio pinctrl node names
arm64: dts: rockchip: Fix pinctrl property typo on rk3326-odroid-go3
arm64: dts: rockchip: Drop "sitronix,st7789v" fallback compatible from rk3568-wolfvision
arm64: dts: rockchip: Fix wrong register range of rk3576 gpu
arm64: dts: rockchip: Configure MCLK for analog sound on NanoPi M5
arm64: dts: rockchip: Fix headphones widget name on NanoPi M5
arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s
arm64: dts: rockchip: remove dangerous max-link-speed from helios64
arm64: dts: rockchip: fix unit-address for RK3588 NPU's core1 and core2's IOMMU
arm64: dts: rockchip: Fix wifi interrupts flag on Sakura Pi RK3308B
arm64: dts: rockchip: Fix voltage threshold for volume keys for Pinephone Pro
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This update includes:
- fix access to the PHYs on the Microchip LAN966X PCB8290 board
- fix the ranges DT property for flexcom9 on the Microchip SAMA7D65 SoC
- fix the #size-cells DT property for i2c3 on the Microchip SAMA7D65 SoC
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCaWdU+AAKCRCejrg/N2X7
/dCsAQDF+piTRi9FgWPkAnMQMjiDHOYfJG4hklYnMARxpDt+ggEAi0dIKJ/aqvuK
2xdNjoo8Umj/eTCl0pkZW4lMMhJvpQY=
=KHIn
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmlpGZcACgkQmmx57+YA
GNkOOA//aQa4zdODO1Q6DoK1PUEHYFl553gcfXEnn7QcBfErh5OkqkHVQAGqS6A+
jOSNaQTUrMVsRnJ0BlwbCzH5yNNOxpz9U9aa76BJlIIJPNPzd6Pw/Qz16TEVvZgY
2ytEYeJPL1omPf6r+rdasb8WD859/Y3IVIJL+iRUcDPBzlyHRSERbKUjaGcuxecV
727nmQwNU3tEybFf/x5vrlzaNtRcfdsa9m2cAoXv7KefZQcrpisJiatLM61koH/f
2GeD9jC5rzVlYu2ZfiCQN25yAkJxtnVGuv2YLOBnQyj/KPeHCBb4WK0KU9Amp99P
xjQ0G6uroUbghc7uNYI1W+4zYZ3tMLgpW1cSWqM092VOICmeCXQUKNXPY7CZ/IIB
QrXBdgFpegYqyqMvhxweulDV2mQFniy0R/D5geh8BZ3s8Iw/yxw9gbcmYZjDSrlA
gQzKDoIF+CnyN3WnNw31sNxDGHh30w1wU3kZF2eYxNVPvTE1KaUpz3lam7OWN8qw
06+5wWRz7WMDKE60hz2I2Q2XQ/xCMHMOmvtmqxZzgwGnxOZAF8UXzbclfOEe22FV
D4hcbsLeOfXzIwWEA+1aOoPn8r7PquZtr24PxiyGdcgLSt/pla+inGrC1cq7a/ZM
27ZZXkfwIJw7wg4gjiWeX8K9SrKxl42ip9FLhjN0jvJ6DsLFdLQ=
=uidV
-----END PGP SIGNATURE-----
Merge tag 'at91-fixes-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/fixes
Microchip AT91 fixes for v6.19
This update includes:
- fix access to the PHYs on the Microchip LAN966X PCB8290 board
- fix the ranges DT property for flexcom9 on the Microchip SAMA7D65 SoC
- fix the #size-cells DT property for i2c3 on the Microchip SAMA7D65 SoC
* tag 'at91-fixes-6.19' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: dts: microchip: sama7d65: fix size-cells property for i2c3
ARM: dts: microchip: sama7d65: fix the ranges property for flx9
ARM: dts: microchip: lan966x: Fix the access to the PHYs for pcb8290
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
Tegra210") populated interconnect properties for Tegra210 and this is
preventing the Tegra DRM driver from probing successfully. The following
error is observed on boot ...
drm drm: failed to initialize 54240000.dc: -517
For now revert this change, until a fix is available.
Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
For protected VMs, the guest's timer offset state should not be
controlled by the host and must always run with a virtual counter offset
of 0. The existing timer logic allowed the host to set and manage the
timer counter offsets for protected VMs in certain cases.
Disable all host-side management of timer offsets for protected VMs by
adding checks in the relevant code paths.
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-10-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Certain VM IOCTLs are tied to specific VM features. Since pKVM does not
support all features, restrict which IOCTLs are allowed depending on
whether the associated feature is supported.
Use the existing VM capability check as the source of truth to whether
an IOCTL is allowed for a particular VM by mapping the IOCTLs with their
associated capabilities.
Suggested-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-9-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Track KVM IOCTLs (VM IOCTLs for now), and the associated KVM capability
that enables that IOCTL. Add a function that performs the lookup.
This will be used by CoCo VM Hypervisors (e.g., pKVM) to determine
whether a particular KVM IOCTL is allowed for its VMs.
Suggested-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
[maz: don't expose KVM_CAP_BASIC to userspace, and rely on NR_VCPUS
as a proxy for this]
Link: https://patch.msgid.link/20251211104710.151771-8-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Supporting MTE in pKVM introduces significant complexity to the
hypervisor at EL2, even for non-protected VMs, since it would require
EL2 to handle tag management.
For now, do not allow KVM_CAP_ARM_MTE for any VM type in protected mode.
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-7-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Certain features and capabilities are restricted in protected mode. Most
of these features are restricted only for protected VMs, but some
are restricted for ALL VMs in protected mode.
Extend the pKVM capability check to pass the VM (kvm), and use that when
determining supported features.
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-6-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
This 12-bit FAR fault IPA offset mask is hard-coded as 'GENMASK(11, 0)'
in several places to reconstruct the full fault IPA.
Introduce FAR_TO_FIPA_OFFSET() to calculate this value in a shared
header and replace all open-coded instances to improve readability.
No functional change intended.
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-5-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
The function pkvm_init_features_from_host() initializes guest
features, propagating them from the host. The logic to propagate
KVM_ARCH_FLAG_MTE_ENABLED (Memory Tagging Extension)
has a couple of issues.
First, the check was in the common path, before the divergence for
protected and non-protected VMs. For non-protected VMs, this was
unnecessary, as 'kvm->arch.flags' is completely overwritten by
host_arch_flags immediately after, which already contains the MTE flag.
For protected VMs, this was setting the flag even if the feature is not
allowed.
Second, the check was reading 'host_kvm->arch.flags' instead of using
the local 'host_arch_flags', which is read once from the host flags.
Fix these by moving the MTE flag check inside the protected-VM-only
path, checking if the feature is allowed, and changing it to use the
correct host_arch_flags local variable. This ensures non-protected VMs
get the flag via the bulk copy, and protected VMs get it via an explicit
check.
Fixes: b7f345fbc3 ("KVM: arm64: Fix FEAT_MTE in pKVM")
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
The E2TB bits in MDCR_EL2 control trapping of Trace Buffer system
register accesses. These accesses are trapped to EL2 when the bits are
clear.
The trap initialization logic for protected VMs in pvm_init_traps_mdcr()
had the polarity inverted. When a guest did not support the Trace Buffer
feature, the code was setting E2TB. This incorrectly disabled the trap,
potentially allowing a protected guest to access registers for a feature
it was not given.
Fix this by inverting the operation.
Fixes: f50758260b ("KVM: arm64: Group setting traps for protected VMs by control register")
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
For protected VMs in pKVM, the hypervisor should trap accesses to trace
buffer system registers if Trace Buffer isn't supported by the VM.
However, the current code only traps if Trace Buffer External Mode isn't
supported.
Fix this by checking for FEAT_TRBE (Trace Buffer) rather than
FEAT_TRBE_EXT.
Fixes: 9d52612690 ("KVM: arm64: Trap external trace for protected VMs")
Reported-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
On FPGA Development boards with GPIOs the OpenRISC architecture uses the
opencores gpio verilog rtl. This is compatible with the gpio-mmio. Add
the compatible string to allow probing this driver from the devicetree.
Link: https://opencores.org/projects/gpio
Signed-off-by: Stafford Horne <shorne@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20260115151014.3956805-3-shorne@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
In commit f48b5e8bc2 ("dt-bindings: gpio-mmio: Add compatible string
for opencores,gpio") we marked opencores,gpio to be allowed with
brcm,bcm6345-gpio. This was wrong, opencores,gpio is not compatible with
brcm,bcm6345-gpio. It has a different register map and is 8-bit vs
Broadcom which is 32-bit. Change opencores,gpio to be a separate
compatible string for MMIO GPIO.
Also, as this change rewrote the entire enum, I took this opportunity to
alphabetically sort the list.
Fixes: f48b5e8bc2 ("dt-bindings: gpio-mmio: Add compatible string for opencores,gpio")
Signed-off-by: Stafford Horne <shorne@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260115151014.3956805-2-shorne@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Since commit 56344e241c ("i2c: tegra: Fix reset error handling with
ACPI") replace reset_control_reset() with device_reset(), the rst
is no longer used, remove it.
Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20251217081601.93856-1-kanie@linux.alibaba.com
The pg_remaining calculation in ftrace_process_locs() assumes that
ENTRIES_PER_PAGE multiplied by 2^order equals the actual capacity of the
allocated page group. However, ENTRIES_PER_PAGE is PAGE_SIZE / ENTRY_SIZE
(integer division). When PAGE_SIZE is not a multiple of ENTRY_SIZE (e.g.
4096 / 24 = 170 with remainder 16), high-order allocations (like 256 pages)
have significantly more capacity than 256 * 170. This leads to pg_remaining
being underestimated, which in turn makes skip (derived from skipped -
pg_remaining) larger than expected, causing the WARN(skip != remaining)
to trigger.
Extra allocated pages for ftrace: 2 with 654 skipped
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7295 ftrace_process_locs+0x5bf/0x5e0
A similar problem in ftrace_allocate_records() can result in allocating
too many pages. This can trigger the second warning in
ftrace_process_locs().
Extra allocated pages for ftrace
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7276 ftrace_process_locs+0x548/0x580
Use the actual capacity of a page group to determine the number of pages
to allocate. Have ftrace_allocate_pages() return the number of allocated
pages to avoid having to calculate it. Use the actual page group capacity
when validating the number of unused pages due to skipped entries.
Drop the definition of ENTRIES_PER_PAGE since it is no longer used.
Cc: stable@vger.kernel.org
Fixes: 4a3efc6baf ("ftrace: Update the mcount_loc check of skipped entries")
Link: https://patch.msgid.link/20260113152243.3557219-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
clangd reports many "unused header" warnings throughout the Xe driver.
Start working to clean this up by removing unnecessary includes in our
.c files and/or replacing them with explicit includes of other headers
that were previously being included indirectly.
By far the most common offender here was unnecessary inclusion of
xe_gt.h. That likely originates from the early days of xe.ko when
xe_mmio did not exist and all register accesses, including those
unrelated to GTs, were done with GT functions.
There's still a lot of additional #include cleanup that can be done in
the headers themselves; that will come as a followup series.
v2:
- Squash the 79-patch series down to a single patch. (MattB)
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260115032803.4067824-2-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
During device unmapping (triggered by module unload or explicit unmap),
a refcount underflow occurs causing a use-after-free warning:
[14747.574913] ------------[ cut here ]------------
[14747.574916] refcount_t: underflow; use-after-free.
[14747.574917] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x55/0x90, CPU#9: kworker/9:1/378
[14747.574924] Modules linked in: rnbd_client(-) rtrs_client rnbd_server rtrs_server rtrs_core ...
[14747.574998] CPU: 9 UID: 0 PID: 378 Comm: kworker/9:1 Tainted: G O N 6.19.0-rc3lblk-fnext+ #42 PREEMPT(voluntary)
[14747.575005] Workqueue: rnbd_clt_wq unmap_device_work [rnbd_client]
[14747.575010] RIP: 0010:refcount_warn_saturate+0x55/0x90
[14747.575037] Call Trace:
[14747.575038] <TASK>
[14747.575038] rnbd_clt_unmap_device+0x170/0x1d0 [rnbd_client]
[14747.575044] process_one_work+0x211/0x600
[14747.575052] worker_thread+0x184/0x330
[14747.575055] ? __pfx_worker_thread+0x10/0x10
[14747.575058] kthread+0x10d/0x250
[14747.575062] ? __pfx_kthread+0x10/0x10
[14747.575066] ret_from_fork+0x319/0x390
[14747.575069] ? __pfx_kthread+0x10/0x10
[14747.575072] ret_from_fork_asm+0x1a/0x30
[14747.575083] </TASK>
[14747.575096] ---[ end trace 0000000000000000 ]---
Befor this patch :-
The bug is a double kobject_put() on dev->kobj during device cleanup.
Kobject Lifecycle:
kobject_init_and_add() sets kobj.kref = 1 (initialization)
kobject_put() sets kobj.kref = 0 (should be called once)
* Before this patch:
rnbd_clt_unmap_device()
rnbd_destroy_sysfs()
kobject_del(&dev->kobj) [remove from sysfs]
kobject_put(&dev->kobj) PUT #1 (WRONG!)
kref: 1 to 0
rnbd_dev_release()
kfree(dev) [DEVICE FREED!]
rnbd_destroy_gen_disk() [use-after-free!]
rnbd_clt_put_dev()
refcount_dec_and_test(&dev->refcount)
kobject_put(&dev->kobj) PUT #2 (UNDERFLOW!)
kref: 0 to -1 [WARNING!]
The first kobject_put() in rnbd_destroy_sysfs() prematurely frees the
device via rnbd_dev_release(), then the second kobject_put() in
rnbd_clt_put_dev() causes refcount underflow.
* After this patch :-
Remove kobject_put() from rnbd_destroy_sysfs(). This function should
only remove sysfs visibility (kobject_del), not manage object lifetime.
Call Graph (FIXED):
rnbd_clt_unmap_device()
rnbd_destroy_sysfs()
kobject_del(&dev->kobj) [remove from sysfs only]
[kref unchanged: 1]
rnbd_destroy_gen_disk() [device still valid]
rnbd_clt_put_dev()
refcount_dec_and_test(&dev->refcount)
kobject_put(&dev->kobj) ONLY PUT (CORRECT!)
kref: 1 to 0 [BALANCED]
rnbd_dev_release()
kfree(dev) [CLEAN DESTRUCTION]
This follows the kernel pattern where sysfs removal (kobject_del) is
separate from object destruction (kobject_put).
Fixes: 581cf833ca ("block: rnbd: add .release to rnbd_dev_ktype")
Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Reviewed-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Add Intel Nova Lake PCH-S SPI serial flash PCI ID to the list of
supported devices. This is the same controller found in previous
generations.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260115120305.10080-1-alan.borzeszkowski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
During an SPI read operation, even if the xspi->txbuf passed to the
cdns_spi_writerinterface is empty, it is still necessary to call
cdns_spi_write(xspi, CDNS_SPI_TXD, txw); otherwise, the read operation
will fail to obtain data correctly due to a lack of clocks.
Fixes: 4e00135b2d ("spi: spi-cadence: supports transmission with bits_per_word of 16 and 32")
Reported-by: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>
Closes: https://lore.kernel.org/all/lbijvnnwsnddonmm5pveqzap6iibxhl4maneq43x4j6w64dev6@u75qhm5cwiob/
Signed-off-by: Jun Guo <jun.guo@cixtech.com>
Link: https://patch.msgid.link/20260115091924.844179-1-jun.guo@cixtech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A moderately large collection of fixes since I missed a week, plus a few
new device IDs and quirks. It's all fairly minor, including a bunch of
work on the device tree bindings fixes which have no runtime effect.
There's one SoundWire change here exporting a symbol which was required
for a fix to the ASoC SoundWire code.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmlo7B4ACgkQJNaLcl1U
h9ARAAf/TTsq6PAtYduc9VZvvFumdCQVozcthVVA7IklymKjWrSbtXn/ouorz8Kt
wqnwsBql+jCWfTO7trOw2lWKWHVIN6GV2q9QvYM92vWSXTSiEKvSnlR9CSZDrBHE
Cy82FFldB4RNEv6NwpDfgUgGGI4ceEYUXiFqSpwzRDwT3+cJMyxf2iBJhOvh/lkE
JKXpdyeQC4tANxX2b+Mk32gGoe/1L1mPhNSjhJrd4h/sM3530ck6VvlEGobVDRkb
paMHoNI9vBdhQcCTqcXiKypWRzfwyZX5pXYa3lCdE6kEGAsMFqtlELnkIBxkav32
xRKfFOdaIa61LnvCiPonswOHsP2zgw==
=YL/h
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v6.19-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.19
A moderately large collection of fixes since I missed a week, plus a few
new device IDs and quirks. It's all fairly minor, including a bunch of
work on the device tree bindings fixes which have no runtime effect.
There's one SoundWire change here exporting a symbol which was required
for a fix to the ASoC SoundWire code.
Disabling OOBE is an important step to be able to fully control the
hardware in TUF laptops that requires this command, but the command
has been incorrectly tied to deprecated attributes: restore sending
the OOBE exit command.
Fixes: c683651b67 ("platform/x86: asus-wmi: deprecate bios features")
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260102234344.366227-3-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add TDP data for laptop model FA617XT.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260112215038.575883-4-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add TDP data for laptop model FA401UV.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260112215038.575883-3-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add TDP data for laptop model GV302XV.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260112215038.575883-2-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add the DMI entry and power limits for the Asus ROG Strix G15
Advantage Edition (G513QY). This laptop requires manual fan curves
and specific APU/Platform PPT limits.
Signed-off-by: Shresth Sarthak Awasthi <bengdeeba@gmail.com>
Link: https://patch.msgid.link/20260109130557.78720-1-bengdeeba@gmail.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The tmp buffer is allocated using kcalloc() but is not freed if
acpi_evaluate_dsm() fails. This causes a memory leak in the error path.
Fix this by explicitly freeing the tmp buffer in the error handling
path of acpi_evaluate_dsm().
Fixes: 58e82a6266 ("platform/x86/amd: Add support for AMD ACPI based Wifi band RFI mitigation feature")
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Link: https://patch.msgid.link/20260106091318.747019-1-zilin@seu.edu.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
In SN5640/SN5610 platforms should be used XDR style LED data with
predefined slot index per led_fan.
Fixes: 317bbe169c ("platform: mellanox: mlx-platform: Add support for new Nvidia system")
Signed-off-by: Oleksandr Shamray <oleksandrs@nvidia.com>
Reviewed-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://patch.msgid.link/20260107142548.916556-1-oleksandrs@nvidia.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Fix minor documentation errors in `kvm_util.h` and `kvm_util.c`.
- Correct the argument description for `vcpu_args_set` in `kvm_util.h`,
which incorrectly listed `vm` instead of `vcpu`.
- Fix a typo in the comment for `kvm_selftest_arch_init` ("exeucting" ->
"executing").
- Correct the return value description for `vm_vaddr_unused_gap` in
`kvm_util.c` to match the implementation, which returns an address "at
or above" `vaddr_min`, not "at or below".
No functional change intended.
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-6-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
To avoid code duplication, move page_align() to the shared `kvm_util.h`
header file. Rename it to vm_page_align(), to make it clear that the
alignment is done with respect to the guest's base page size.
No functional change intended.
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-5-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
The implementation of `page_align()` in `processor.c` calculates
alignment incorrectly for values that are already aligned. Specifically,
`(v + vm->page_size) & ~(vm->page_size - 1)` aligns to the *next* page
boundary even if `v` is already page-aligned, potentially wasting a page
of memory.
Fix the calculation to use standard alignment logic: `(v + vm->page_size
- 1) & ~(vm->page_size - 1)`.
Fixes: 3e06cdf105 ("KVM: selftests: Add initial support for RISC-V 64-bit")
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
The implementation of `page_align()` in `processor.c` calculates
alignment incorrectly for values that are already aligned. Specifically,
`(v + vm->page_size) & ~(vm->page_size - 1)` aligns to the *next* page
boundary even if `v` is already page-aligned, potentially wasting a page
of memory.
Fix the calculation to use standard alignment logic: `(v + vm->page_size
- 1) & ~(vm->page_size - 1)`.
Fixes: 7a6629ef74 ("kvm: selftests: add virt mem support for aarch64")
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
KVM selftests map all guest code and data into the lower virtual address
range (0x0000...) managed by TTBR0_EL1. The upper range (0xFFFF...)
managed by TTBR1_EL1 is unused and uninitialized.
If a guest accesses the upper range, the MMU attempts a translation
table walk using uninitialized registers, leading to unpredictable
behavior.
Set `TCR_EL1.EPD1` to disable translation table walks for TTBR1_EL1,
ensuring that any access to the upper range generates an immediate
Translation Fault. Additionally, set `TCR_EL1.TBI1` (Top Byte Ignore) to
ensure that tagged pointers in the upper range also deterministically
trigger a Translation Fault via EPD1.
Define `TCR_EPD1_MASK`, `TCR_EPD1_SHIFT`, and `TCR_TBI1` in
`processor.h` to support this configuration. These are based on their
definitions in `arch/arm64/include/asm/pgtable-hwdef.h`.
Suggested-by: Will Deacon <will@kernel.org>
Reviewed-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Use LIST_HEAD() for initializing an on-stack list head in two places and
remove an empty code line added by mistake.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/12825056.O9o76ZdvQC@rafael.j.wysocki
After starting to use platform devices for representing buttons
enumerated via ACPI, acpi_mark_gpe_for_wake() is insufficient for
preparing their GPEs to wake up the system from sleep because it
does not change the "dispatch type" of the given GPE to
ACPI_GPE_DISPATCH_NOTIFY. Subsequently, this causes acpi_enable_gpe()
in __acpi_device_wakeup_enable() to fail and system suspend transitions
to be aborted.
Address this by updating acpi_wakeup_gpe_init() to use
acpi_setup_gpe_for_wake() for buttons like for any other devices.
This allows acpi_setup_gpe_for_wake() to be simplified further because
buttons are not a special case in it any more, so do that as well.
Fixes: 52d8640196 ("ACPI: button: Convert the driver to a platform one")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Xi Pardee <xi.pardee@linux.intel.com>
Link: https://patch.msgid.link/2259694.irdbgypaU6@rafael.j.wysocki
It is pointless to attach the generic ACPI PM domain to devices whose
ACPI companions don't support ACPI power management and don't have a
wakeup GPE, so update acpi_dev_pm_attach() to skip such devices.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/5050298.GXAFRqVoOG@rafael.j.wysocki
Sadly, there is quite a bit of technical debt related to the
kernel's ACPI support subsystem and one of the most significant
pieces of it is the existence and use of ACPI drivers represented
by struct acpi_driver objects.
Those drivers are bound directly to struct acpi_device objects, also
referred to as "ACPI device nodes", representing device objects in the
ACPI namespace defined as:
A hierarchical tree structure in OS-controlled memory that contains
named objects. These objects may be data objects, control method
objects, bus/device package objects, and so on.
according to the ACPI specification [1].
The above definition implies, although rather indirectly, that the
objects in question don't really represent hardware. They are just
"device package objects" containing some information on the devices
present in the given platform that is known to the platform firmware.
Although the platform firmware can be the only source of information on
some devices, the information provided by it alone may be insufficient
for device enumeration in general. If that is the case, binding a
driver directly to a given ACPI device node clearly doesn't make sense.
If the device in question is enumerated through a hardware interface, it
will be represented by a device object matching that interface, like
a struct pci_dev, and the ACPI device node corresponding to it will be
treated as its "ACPI companions" whose role is to amend the "native"
enumeratiom mechanism.
For the sake of consistency and confusion avoidance, it is better to
treat ACPI device nodes in general as ACPI companions of other device
objects representing hardware. In some cases though it appeared easier
to take a shortcut and use an ACPI driver binding directly to an ACPI
device node. Moreover, there were corner cases in which that was the
only choice, but they all have been addressed now.
In all cases in which an ACPI driver might be used, the ACPI device
node it might bind to is an ACPI companion of another device object
representing a piece of hardware. It is thus better to use a driver
binding to the latter than to use an ACPI driver and leave the other
device object alone, not just because doing so is more consistent and
less confusing, but also because using ACPI drivers may lead to
potential functional deficiencies, like possible ordering issues
related to power management.
Unfortunately, there are quite a few ACPI drivers in use and, as a rule,
they bind to ACPI device nodes that are ACPI companions of platform
devices, so in fact they play the role of platform drivers although in
a kind of convoluted way. An effort has been under way to replace them
with platform drivers, which is relatively straightforward in the vast
majority of cases, but it has not been pursued very aggressively so far,
mostly due to the existence of the corner cases mentioned above.
However, since those corner cases are gone now, it makes sense to spend
more time on driver conversions with the ultimate goal to get rid of
struct acpi_driver and the related code from the kernel.
To that end, add a document explaining why using ACPI drivers is not
a good idea, so it need not be explained from scratch on every attempt
to convert an ACPI driver to a platform one.
Link: https://uefi.org/specs/ACPI/6.6/02_Definition_of_Terms.html#term-ACPI-Namespace [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/2396510.ElGaqSPkdT@rafael.j.wysocki
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI video driver to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/1957556.tdWV9SEqCh@rafael.j.wysocki
