The mechanism needs information to know which MAC is coexisting with which
Bluetooth and when to enable TDMA with which MAC. So change an variable to
describe the binding target.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-4-pkshih@realtek.com
Separate these two type of initialize entry. Because Wi-Fi power save
leaving will also call the initializing, but don't have to reset all the
stored variables.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-3-pkshih@realtek.com
The version 10 Init info add I/O offload type & variable Bluetooth
function (EX: Zigbee/Thread...etc) into the structure definition.
Firmware need to synchronize these information to do corresponding
setting.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260706025445.18428-2-pkshih@realtek.com
I have volunteered to review Xilinx EDAC related changes. Add myself as
a reviewer to stay aligned with ongoing patch activity and actively contribute
to this subsystem.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260625103749.1416083-1-radhey.shyam.pandey@amd.com
If an empty firmware file is supplied via CONFIG_EXTRA_FIRMWARE, the
build currently succeeds but creates an empty section. While the
firmware loader will not return such sections it is better to avoid
adding them in the first place.
Add a compile-time size check to the filechk_fwbin macro to abort the
build early if a 0-size firmware is encountered.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260426043041.649202-2-dmitry.torokhov@gmail.com
[ Use 'exit 1' to properly fail the build. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Leon Hwang says:
====================
bpf: Fix WARNING in bpf_trampoline_multi_detach
Since tracing_multi link does not set ftrace_managed, it would fail to
release the tracing_multi link when attaching tracing_multi link and
then attaching fentry link.
[ 3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
...
[ 3.733170] bpf_tracing_multi_link_release+0x14/0x30
[ 3.733890] bpf_link_free+0x58/0x130
[ 3.734414] bpf_link_release+0x23/0x30
Fix it by setting 'ftrace_managed = true' in register_fentry_multi().
Note: the reason of targeting bpf-next tree is I'm planning to add
tracing_multi link support for bpf progs, that would rely on the fix and
have code conflict with the test.
Changes:
v1 -> v2:
* Collect Acked-by from Jiri, thanks.
* Check arg using tracing_multi_arg_check() in bpf prog in test.
(per Sashiko)
* v1: https://lore.kernel.org/bpf/20260710144734.78203-1-leon.hwang@linux.dev/
====================
Link: https://patch.msgid.link/20260711124822.29406-1-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Verify that there's no any issue to attach tracing_multi link, then attach
fentry link.
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20260711124822.29406-3-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Since tracing_multi link does not set ftrace_managed, it would fail to
release the tracing_multi link when attaching tracing_multi link and
then attaching fentry link.
[ 3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
...
[ 3.733170] bpf_tracing_multi_link_release+0x14/0x30
[ 3.733890] bpf_link_free+0x58/0x130
[ 3.734414] bpf_link_release+0x23/0x30
Fix it by setting 'ftrace_managed = true' in register_fentry_multi().
Fixes: aef4dfa790 ("bpf: Add bpf_trampoline_multi_attach/detach functions")
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/20260711124822.29406-2-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Nicholas Dudar says:
====================
bpf: require an owned cpumask for bpf_cpumask_populate()
bpf_cpumask_populate() writes its destination with bitmap_copy() but
types it as struct cpumask *, so the verifier accepts a borrowed,
read-only cpumask (for example from scx_bpf_get_online_cpumask()) as a
writable destination. Fix it and add a selftest for coverage.
Changelog:
----------
v2 -> v3 (v1/v2 were a private report to security@kernel.org)
* Split the fix and selftest into separate patches.
* Target bpf-next instead of bpf.
====================
Link: https://patch.msgid.link/20260709182800.2037938-1-main.kalliope@gmail.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
bpf_cpumask_populate() now takes a struct bpf_cpumask *, so update the
kfunc declaration and drop the struct cpumask * casts in the existing
populate tests. Add test_populate_borrowed_destination, which passes a
borrowed task->cpus_ptr and asserts the verifier rejects it as a writable
destination.
Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260709182800.2037938-3-main.kalliope@gmail.com
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
bpf_cpumask_populate() writes to its destination with bitmap_copy(), but
the destination is typed as struct cpumask *. That allows the verifier to
accept borrowed cpumask pointers returned by read-only kfuncs, such as
scx_bpf_get_online_cpumask(), as a writable destination.
Make the destination a struct bpf_cpumask * so populate follows the same
ownership rule as the other mutating cpumask kfuncs. Query kfuncs continue
to accept const struct cpumask * inputs.
Fixes: 950ad93df2 ("bpf: add kfunc for populating cpumask bits")
Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260709182800.2037938-2-main.kalliope@gmail.com
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Currently, the builtin firmware loader allows 0-size firmware to be
returned successfully to drivers. This differs from all other loading
mechanisms (filesystem, sysfs fallback) which reject 0-byte files, and
forces drivers to add boilerplate size checks.
Modify firmware_request_builtin() to reject 0-size firmware. This will
also result in firmware loader falling back to other mechanisms if an
empty built-in firmware is present.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260426043041.649202-1-dmitry.torokhov@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In preparation for removing the strlcat() API[1], replace its uses in
i8042-acpipnpio.h.
i8042_pnp_id_to_string() accumulates a variable number of PNP ids in
a loop, which is what seq_buf is for. The kbd and aux probe functions
build a name from at most three parts that are all known up front, so
the whole construction becomes a single scnprintf() there.
Link: https://github.com/KSPP/linux/issues/370 [1]
Signed-off-by: Ian Bridges <icb@fastmail.org>
Link: https://patch.msgid.link/akyW4xkvCCROM0SE@dev
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
If enabling VIO fails after VDD has been enabled, runtime resume
returns without disabling VDD. Likewise, if device reinitialization
fails, both supplies remain enabled. The runtime PM core keeps the
device suspended when its resume callback fails, so the supplies must
be restored to the suspended state.
Disable the supplies enabled by the callback before returning an error.
Fixes: 97d642e230 ("iio: light: Add a driver for Sharp GP2AP002x00F")
Assisted-by: Codex:gpt-5
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
- A fix for MELFAS MMS114 touchscreen driver to reject invalid touch IDs
and avoid multi-touch slot corruption
- A fix for a crash in Sega Dreamcast (Maple) mouse driver when opening
the device, caused by missing driver data
- Fixes for Maple drivers (keyboard, mouse, joystick) to properly order
setting driver data and device registration to avoid races.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQST2eWILY88ieB2DOtAj56VGEWXnAUCalLC2QAKCRBAj56VGEWX
nLLwAQDExlB/cWm2Hpmim13SIetpNbnRNDDUBXZqlx26U6tCUgD9Ek85LvbRiWOJ
dTqs7ieSn2iPQxHFvHOAZD5ohSGj/wI=
=g2px
-----END PGP SIGNATURE-----
Merge tag 'input-for-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
- fix MELFAS MMS114 touchscreen driver to reject invalid touch IDs and
avoid multi-touch slot corruption
- fix a crash in the Sega Dreamcast (Maple) mouse driver when opening
the device, caused by missing driver data
- fixes for Maple drivers (keyboard, mouse, joystick) to properly order
setting driver data and device registration to avoid races
* tag 'input-for-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: mms114 - fix multi-touch slot corruption
Input: maple_keyb - set driver data before registering input device
Input: maplecontrol - set driver data before registering input device
Input: maplemouse - set driver data before registering input device
Input: maplemouse - fix NULL pointer dereference in open()
rpr0521_runtime_suspend() powers the device down and marks the regmap
cache dirty. rpr0521_runtime_resume() syncs the cache before restoring
enabled ALS/PXS channels, but currently ignores a regcache_sync()
failure and can still return success.
Return the regcache_sync() error so resume does not hide a failed
register restore.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
vcnl4035_runtime_suspend() marks the regmap cache dirty before runtime
suspend. vcnl4035_runtime_resume() then syncs the cache before re-
enabling ALS, but currently ignores a regcache_sync() failure and can
still report resume success.
Return the regcache_sync() error so the PM core sees the failed register
restore.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
m62332_set_value() enables the Vcc regulator on every write of a
non-zero value and disables it on every write of zero, without tracking
the channel's current state. Because the regulator is reference counted,
changing a channel directly from one non-zero value to another enables
it more than once, while a later write of zero disables it only once.
The reference count never returns to zero and the regulator is left
enabled indefinitely.
Only enable the regulator on the transition from zero to non-zero, and
only disable it on the transition from non-zero to zero, using the
previously stored channel value to detect the edge. Balance the
regulator on the I2C error path so the reference count stays consistent
if the write fails.
Fixes: b87b0c0f81 ("iio: add m62332 DAC driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260418130322.106769-1-erick.henrique.rodrigues%40usp.br
Cc: stable@vger.kernel.org
Signed-off-by: Erick Henrique <erick.henrique.rodrigues@usp.br>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Avoid using devm_iio_device_register(), as this driver requires explicit
error handling and teardown ordering.
With devm_iio_device_register(), IIO device remains registered until the
devres cleanup phase. However, driver's remove() callback removes the
sensor hub callback and trigger support. This can create a race window
where IIO device is still visible and read_raw() requests are issued.
These requests might call sensor_hub_input_attr_get_raw_value(), which
waits up to 5 seconds for a response from the sensor hub callback that
has already been removed.
Add an explicit iio_device_unregister() call in the teardown path to
ensure deterministic cleanup, so that userspace can no longer access the
device once backend resources begin to be dismantled.
Fixes: 59d0f2da35 ("iio: hid: Add temperature sensor support")
Cc: stable@vger.kernel.org
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
- dm-era: fix out of bounds memory access; fix crashes on invalid args
- dm-verity: fix buffer overflow in forward error correction
- dm-thin: fix misbehavior on I/O failures
- dm-pcache: fix NULL pointer dereference on invalid arguments
- dm-inlinecrypt: fix memory leak on error handling
- dm-integrity: fix ignoring the 'fix_hmac' option on device open
- dm: don't store the keyring in memory for a long term
- 12 miscellaneous fixes for bugs found by Claude Opus 4.6
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQRnH8MwLyZDhyYfesYTAyx9YGnhbQUCalKUaxQcbXBhdG9ja2FA
cmVkaGF0LmNvbQAKCRATAyx9YGnhbbQwAP9pHgNUinD95o9vnu3d3QNmjnEDmrgZ
+kxNFRpWXvbzKQEArYWPLS/2dwf4nG0Fa8PtJTwkjI/6UeublAy5MrdTqA0=
=pkBx
-----END PGP SIGNATURE-----
Merge tag 'for-7.2/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mikulas Patocka:
- dm-log: fix overflow on 32-bit machines
- dm-era: fix out of bounds memory access; fix crashes on invalid args
- dm-verity: fix buffer overflow in forward error correction
- dm-thin: fix misbehavior on I/O failures
- dm-pcache: fix NULL pointer dereference on invalid arguments
- dm-inlinecrypt: fix memory leak on error handling
- dm-integrity: fix ignoring the 'fix_hmac' option on device open
- dm: don't store the keyring in memory for a long term
- 12 miscellaneous fixes for bugs found by Claude Opus 4.6
* tag 'for-7.2/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: (23 commits)
dm thin metadata: fix superblock refcount leak on snapshot shadow failure
dm-stats: fix dm_jiffies_to_msec64
dm-stats: fix merge accounting
dm-bufio: fix wrong count calculation in dm_bufio_issue_discard
dm-verity: make error counter atomic
dm-verity: increase sprintf buffer size
dm-verity: fix a possible NULL pointer dereference
dm-verity: avoid double increment of &use_bh_wq_enabled
dm-ioctl: fix a possible overflow in list_version_get_info
dm_early_create: fix freeing used table on dm_resume failure
dm-integrity: fix a bug if the bio is out of limits
dm-integrity: don't increment hash_offset twice
dm-integrity: fix leaking uninitialized kernel memory
dm-integrity: fix the 'fix_hmac' option
dm era: fix error code propagation in era_ctr()
dm era: fix NULL pointer dereference in metadata_open()
dm: avoid leaking the caller's thread keyring via the table device file
dm-inlinecrypt: Fix an error handling path in inlinecrypt_ctr()
dm-pcache: reject option groups without values
dm thin metadata: fix metadata snapshot consistency on commit failure
...
Currently the generic __ATTR*() macros are used to initialize kobject
attributes. These are not able to handle the upcoming piece-by-piece
constification of the attribute callback handlers.
Add dedicated macros of kobject attributes. For now these are the same
as the generic macros, but they will change soon. Users will be
converted to these macros as part of the constification, but it is
expected that they will be used generally in the future.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20260707-sysfs-const-attr-kobj-attr-prep-v2-1-35ae1bc0f9ef@weissschuh.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add the clocks required to enable the REFGEN block which provides the
reference current to the PHYs in the SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260707-b4-ipq9650_refgen_clocks-v1-2-e070624d03d2@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the REFGEN clock IDs for the IPQ9650 SoC. These clocks are used
to enable the REFGEN block, which provides the reference current to
the PHYs in the SoC.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260707-b4-ipq9650_refgen_clocks-v1-1-e070624d03d2@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Reverse the logic within "if:then:" when expecting "required-opps"
property to have negative list of only variants which do not require
these. VIDEOCC on SM8650 does not need "required-opps" as explained in
the commit 6720e8dbcb ("dt-bindings: clock: qcom: Drop required-opps
in required on sm8650 videocc"). Requirement on VIDEOCC on SM8475 is
not known.
Reverting the logic in "if:" part has two impacts:
1. Adds requirement of "required-opps" on VIDEOCC on Hamoa (X1E80100),
to match hardware expectation, similarly to existing its variant
X1P42100 (already expressed in DTS).
2. Reduces the chances of forgetting to update constraints when adding
new compatibles (like for X1E80100).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260708-dt-bindings-camcc-required-opps-v1-3-ae0871774210@oss.qualcomm.com
[bjorn: Rebased, assuming the newly added hawi compatible also requires opps]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Reverse the logic within "if:then:" when expecting "required-opps"
property to have negative list of only variants which do not require
these. CAMCC on SM8650 does not need "required-opps" as explained in
the commit db30c1160c ("dt-bindings: clock: qcom: Drop required-opps
in required on SM8650 camcc"). Requirement on CAMCC on SM8475 is not
known.
Reverting the logic in "if:" part has two impacts:
1. Adds requirement of "required-opps" on CAMCC on SM8750 to match
hardware expectation, because it needs minimum voltage levels of MMCX
rail (already expressed in DTS).
2. Reduces the chances of forgetting to update constraints when adding
new compatibles (like for SM8750).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260708-dt-bindings-camcc-required-opps-v1-2-ae0871774210@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
qcom,sc8280xp-camcc compatible was moved to own binding file in
commit 842fa74829 ("dt-bindings: clock: qcom,sm8450-camcc: Move
sc8280xp camcc to sa8775p camcc"), so cleanup redundant entry in
"if:then:" block.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260708-dt-bindings-camcc-required-opps-v1-1-ae0871774210@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The static 'struct qcom_cc_driver_data' and array 'xxx_critical_cbcrs'
are already treated by common.c code as pointers to const, so constify
few remaining pieces.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260705171811.115542-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The static 'struct qcom_cc_desc', 'struct qcom_cc_driver_data' and
array 'xxx_critical_cbcrs' are already treated by common.c code as
pointers to const, so constify few remaining pieces.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260705171811.115542-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Implement ForLt and CovariantForLt for IoMem<'static, SIZE> and
ExclusiveIoMem<'static, SIZE> so that DevresLt can shorten the stored
'static lifetime back to the caller's borrow lifetime.
CovariantForLt is sound because both types only hold &'a Device<Bound>,
which is covariant over 'a.
Since DevresLt::new() handles the lifetime transmutation internally,
into_devres() no longer needs an explicit transmute to 'static.
Add DevresIoMem<SIZE> and DevresExclusiveIoMem<SIZE> type aliases.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260626183630.2585057-8-dakr@kernel.org
[ Add default SIZE parameter to DevresIoMem. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement ForLt and CovariantForLt for Bar<'static, SIZE> so that
DevresLt can shorten the stored 'static lifetime back to the caller's
borrow lifetime.
CovariantForLt is sound because Bar<'a, SIZE> only holds &'a
Device<Bound>, which is covariant over 'a.
Since DevresLt::new() handles the lifetime transmutation internally,
into_devres() no longer needs an explicit transmute to Bar<'static>.
Add a DevresBar<SIZE> type alias for convenience.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260626183630.2585057-7-dakr@kernel.org
[ Add default SIZE parameter to DevresBar. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Devres<T> stores resources as T and returns &'a T from access(). For
lifetime-parameterized types like Bar<'a, SIZE> that are transmuted to
'static for storage, this exposes the synthetic 'static lifetime to
callers -- any method on the stored type that returns a reference with
its lifetime parameter would yield a &'static reference, which is
unsound.
Add DevresLt<F: ForLt>, a thin wrapper around Devres<F::Of<'static>>
that shortens the stored 'static lifetime to the caller's borrow
lifetime in all access methods.
DevresLt::new() is unsafe because the caller must guarantee that the
data remains valid for the device's full bound scope; the internal
transmute from F::Of<'a> to F::Of<'static> would otherwise allow
use-after-free.
Two access patterns are provided:
- CovariantForLt types get direct-reference accessors (access,
try_access) that return shortened references via
CovariantForLt::cast_ref.
- Plain ForLt types use closure-based accessors (access_with,
try_access_with) whose universally quantified lifetime prevents
callers from smuggling in concrete short-lived references.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260626183630.2585057-6-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Extend the auxiliary driver sample to demonstrate both access patterns:
- registration_data() with CovariantForLt!(Data<'_>) for the covariant
data type that holds a plain &'bound reference.
- registration_data_with() with ForLt!(MutexData<'_>) for an invariant
data type that wraps a Mutex<&'bound Device>. Since Mutex<T> is
invariant over T, MutexData cannot implement CovariantForLt and must
use the closure-based accessor.
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260626183630.2585057-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add registration_data_with() taking a for<'a> closure that receives
Pin<&'a F::Of<'a>>, which works with any ForLt type. Taking a for<'a>
closure rather than returning a direct reference prevents callers from
choosing a concrete lifetime for the data, which is required for
soundness with non-covariant ForLt types.
Extract the common null-check, TypeId-check and KBox-borrow logic into a
private registration_data_pinned() helper shared by both
registration_data_with() and the existing registration_data().
Relax Registration's bound from CovariantForLt to ForLt so that
non-covariant types can be registered.
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260626183630.2585057-4-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a new ForLt trait as a base for CovariantForLt:
- ForLt (non-unsafe): represents a type generic over a lifetime, with
no covariance guarantee.
- CovariantForLt (unsafe): becomes a subtrait of ForLt that
additionally proves the type is covariant over its lifetime
parameter, providing a safe cast_ref() method.
This split allows non-covariant types (e.g. types behind a Mutex) to
implement ForLt and participate in DevresLt / registration data patterns
that use HRTB closures for sound access, without requiring a covariance
proof that would fail to compile.
Both macros share the UnsafeForLtImpl helper type, distinguished by
a const generic N: ForLt! emits N = 0 (no covariance proof),
CovariantForLt! emits N = 1 (with compile-time covariance proof).
Reviewed-by: Gary Guo <gary@garyguo.net>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20260626183630.2585057-3-dakr@kernel.org
[ Merge ForLt pub use, inline resolve_hrt/ty_static, add intra-doc
links. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Clock controller drivers are essential for booting up SoCs and are not
really optional for a given platform. Kernel should not ask users
choice of drivers when that choice is obvious and known to the
developers that answer should be 'yes' or 'module'.
Enable drivers for upstreamed or being upstreamed SoCs, which are not
yed enabled in defconfig: Glymur, Hawi, Nord, MSM8976, MSM8998 (GPU CC),
SC7180, SC8180X, SC8280XP, SC7280, SDM660, QDU1000, SM4450, SM7150,
SM8150, SM8450, SM6125, SM6375. Note that main GCC clock controller
drivers are usually already enabled for these.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260703-clk-qcom-defaults-v3-5-78894525e54a@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Clock controller drivers are essential for booting up SoCs and are not
really optional for a given platform. Kernel should not ask users
choice of drivers when that choice is obvious and known to the
developers that answer should be 'yes' or 'module'.
Switch all Qualcomm clock controller drivers which are chosen in
ARM 32-bit qcom defconfig to a default 'yes'.
This has no impact on ARM32 qcom defconfig and ARM64 defconfig
include/generated/autoconf.h, however enables a few drivers for ARM32
multi_v7 defconfig: IPQ_GCC_4019, QCOM_CLK_APCS_SDX55, MSM_LCC_8960,
SDX_GCC_55, QCOM_CLK_RPMH as module, IPQ_GCC_806X, IPQ_LCC_806X and
QCOM_A7PLL. Enabling these on multi_v7 is expected to properly boot
these SoCs with defconfig.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260703-clk-qcom-defaults-v3-4-78894525e54a@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Clock controller drivers are essential for booting up SoCs and are not
really optional for a given platform. Kernel should not ask users
choice of drivers when that choice is obvious and known to the
developers that answer should be 'yes' or 'module'.
Switch all Qualcomm clock controller drivers which are chosen in
defconfig to respective default 'yes' or 'module'.
This has no impact on ARM64 defconfig include/generated/autoconf.h,
however changes few drivers for ARM 32-bit:
1. multi_v7_defconfig: Enable QCOM_CLK_RPMH as module, because SDX55
(ARM 32-bit) uses it.
2. qcom_defconfig: Enable QCOM_A53PLL, QCOM_CLK_APCS_MSM8916 and
MSM_GCC_8916 as built-in, because MSM8916 is also used ARM 32-bit.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260703-clk-qcom-defaults-v3-3-78894525e54a@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
IPQ4019 is ARM 32-bit only SoC and QCOM_A7PLL is used only on SDX55 and
SDX65, which are 32-bit as well.
Do not allow building them for ARM64 to make built kernels smaller and
user choices easier.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260703-clk-qcom-defaults-v3-2-78894525e54a@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Some clock drivers for IPQ5424, IPQ9574, QCM2290, QDU1000 and SA8775
already depend on ARM64. IPQ6018 is ARM64 only SoC (at least upstream)
so should not be a choice for ARM 32-bit builds, to make kernels smaller
and user choices easier.
IPQ_CMN_PLL is used only by the SoCs already having clock controllers
restricted to ARM64
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260703-clk-qcom-defaults-v3-1-78894525e54a@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
- Fix resctrl resource leak (Tony Luck)
- Fix resctrl umount race (Tony Luck)
- Fix resctrl double-free (Reinette Chatre)
- Fix x86 VGA display fallback logic during bootup on
certain multi-GPU systems (Mario Limonciello)
- Re-add a WBINVD call to the SNP bootstrap path to
fix an SNP regression (Tycho Andersen)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmpSKV8RHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1juPhAAsylTtlr70GPw/3gMyMJ/RGcKHxGBQe6W
ARBT/dzULzA37zPQ0UYqab5gwtb8M4mdTiH0756BUgeNpjO0HAyokAyblcnPsrIz
+nQEcnh6eMrr6nEm3evwEsPv7koi1KwdDhA8RAUhzhAc9YGpwXXBPRlsec0slfdR
y7b5rPT89wCCtuQK2va0BiErvWcWvaEOtBGVw4FpJ7oqqWte7Cp4vk93i9CZfhJ9
369+M2O46Za8Qj9AOgm7TQiV3d4EQ0sAxCnb2Q7c87EyJnBBftEN5cfVOtGvBZUz
2Wego8h9iFkZdo87WMTsFwCwn6qbetyKTn2zO15BmKEKPn2gIm5A8CVBnrTji96L
yR7LXZE+tufpRg6rCW2myjkT65QmLRi2D3ZpBpTkmmgnXZITx+YzfCDy+bqR6x7w
nJ/KJx2YYE9Rve/z8P1giVy5omgI5aMEhveas+NlUBxDuX+OvkI7yrxW0GYAloL6
pcGGlDGml5b5S0rADApaptnL0EqA2QwB/OWA4W7cb+3pm5GZJkyalDioKzm9VEmt
hfVDzYrDM/1YHp9tywGLZeshJ7kkRSd7CvL6mU4UQnBMbtBku/Nbr3KEWK0EOY3N
wnpsFNrnS/CWfT9gygQINbJAZKt6LcLhPwwo0ZzxiVAEA2dRkhDkJCS8Vl2STxht
N2wmpqTmMUw=
=3lBD
-----END PGP SIGNATURE-----
Merge tag 'x86-urgent-2026-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- Fix resctrl resource leak (Tony Luck)
- Fix resctrl umount race (Tony Luck)
- Fix resctrl double-free (Reinette Chatre)
- Fix x86 VGA display fallback logic during bootup on
certain multi-GPU systems (Mario Limonciello)
- Re-add a WBINVD call to the SNP bootstrap path to
fix an SNP regression (Tycho Andersen)
* tag 'x86-urgent-2026-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/virt/sev: Revert "Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"
x86/video: Only fall back to vga_default_device() without screen info
fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list
fs/resctrl: Fix use-after-free during unmount
fs/resctrl: Free mon_data structures on rdt_get_tree() failure
unearthed other races in the area (Thomas Gleixner)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmpSJ0gRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1hyKA//W5KqLrRgXjH9cS7tF6PLo9NhbZZn5FhH
jxThPvJosNyCj8UEVD+iCRjkqkNxiY9mzx3px2ZVlJg8K35ez2PeZ/zx0wvuSWlM
sD7k4S3JJQ7vAE4CkYvsf91TxCWqiOMw+NLyo7MgDhwsOdgPgUAAKlCdCyoFzRK7
rAV7FQWMQag24donwPiesk8bnU4pWrooq8BoY7XVCy6aHDwwPVxrs1yPyUEikIXq
AT2HiYFOu9ok6rSlJs+A2JQnmke6M6aIJ5dmUGR7gUDRAqlXesmM6jlwklzK0a4O
j6lpE05ouIhZpYzQVTDxvf8cytp0+rutTX8w0lPRlqxYkaeBVEpktxfBAoqFCsoe
GpK8hK0PM57W29zhnTygQib53QQAk9QBQetp0NwUjLSOu3ouhCAOC3wuoctJ4fKY
oNSKGPBhHwJN5932JuxlEll/xbo+bFyHfP87tqn1SA0bgKMSNet5q7+wYE+1gcTp
9LHQnoMpjyRBjuOupnvxqeOVbN3qlNdY6MINFwxBZuKG7UwmYpTH7l72fuUM/eNr
b4UHKgwv3vuQX/BfBoT1mLnzWQTltrfEywBCXHsEHUQ7KFhdRHEbnh3zVDZCT5S3
5N/RS8aFcryD/0/DhxWEhO2DBTgjDDvmOKplIPYFtikDI1dkjZ9dZ0BCI42u6wMH
by25mw2rF2s=
=2I60
-----END PGP SIGNATURE-----
Merge tag 'timers-urgent-2026-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Ingo Molnar:
- Fix a subtle posix-cpu-timers vs. exec() race, which
unearthed other races in the area (Thomas Gleixner)
* tag 'timers-urgent-2026-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
posix-cpu-timers: Prevent UAF caused by non-leader exec() race
Rename ForLt to CovariantForLt to prepare for the introduction of a new
ForLt base trait that does not require covariance.
The existing ForLt trait requires covariance, which enables the safe
cast_ref() method. This rename preserves the same semantics under a more
precise name, making room for a weaker ForLt trait in a subsequent
commit.
No functional change.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20260626183630.2585057-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
