When getting register values for ENCLS emulation, use kvm_register_read()
instead of kvm_<reg>_read() so that bits 63:32 of the register are dropped
if the guest is in 32-bit mode.
Note, the misleading/surprising behavior of kvm_<reg>_read() being "raw"
variants under the hood will be addressed once all non-benign bugs are
fixed.
Fixes: 70210c044b ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions")
Fixes: b6f084ca55 ("KVM: VMX: Add ENCLS[EINIT] handler to support SGX Launch Control (LC)")
Acked-by: Kai Huang <kai.huang@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Link: https://patch.msgid.link/20260529222223.870923-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Don't truncate RAX when handling a Xen hypercall for a guest with protected
state, as KVM's ABI is to assume the guest is in 64-bit for such cases
(the guest leaving garbage in 63:32 after a transition to 32-bit mode is
far less likely than 63:32 being necessary to complete the hypercall).
Fixes: b5aead0064 ("KVM: x86: Assume a 64-bit hypercall for guests with protected state")
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20260529222223.870923-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Bug the VM if 32-bit KVM attempts to handle a 64-bit hypercall, primarily
so that a future change to set "input" in mode-specific code doesn't
trigger a false positive warn=>error:
arch/x86/kvm/xen.c:1687:6: error: variable 'input' is used uninitialized
whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
1687 | if (!longmode) {
| ^~~~~~~~~
arch/x86/kvm/xen.c:1708:31: note: uninitialized use occurs here
1708 | trace_kvm_xen_hypercall(cpl, input, params[0], params[1], params[2],
| ^~~~~
x86/kvm/xen.c:1687:2: note: remove the 'if' if its condition is always true
1687 | if (!longmode) {
| ^~~~~~~~~~~~~~
arch/x86/kvm/xen.c:1677:11: note: initialize the variable 'input' to silence this warning
1677 | u64 input, params[6], r = -ENOSYS;
| ^
1 error generated.
Note, params[] also has the same flaw, but -Wsometimes-uninitialized
doesn't seem to be enforced for arrays, presumably because it's difficult
to avoid false positives on specific entries.
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Link: https://patch.msgid.link/20260529222223.870923-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Check for full 64-bit mode, not just long mode, when truncating the
virtual address as part of INVLPGA emulation. Compatibility mode doesn't
support 64-bit addressing.
Note, the FIXME still applies, e.g. if the guest deliberately targeted
EAX while in 64-bit via an address size override. That flaw isn't worth
fixing as it would require decoding the code stream, which would open an
entirely different can of worms, and in practice no sane guest would shove
garbage into RAX[63:32] and execute INVLPGA.
Note #2, VMSAVE, VMLOAD, and VMRUN all suffer from the same architectural
flaw of not providing the full linear address in a VMCB exit information
field, because, quoting the APM verbatim:
the linear address is available directly from the guest rAX register
(VMSAVE, VMLOAD, and VMRUN take a physical address, but their behavior
with respect to rAX is otherwise identical).
Fixes: bc9eff67fc ("KVM: SVM: Use default rAX size for INVLPGA emulation")
Reviewed-by: Yosry Ahmed <yosry@kernel.org>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Link: https://patch.msgid.link/20260529222223.870923-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Remove raw GPIO number usage from S3C6410-based crag6410 board.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmocIvwQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD14zoEACJHKri90EP4qFDAVxvszTjKuySsc6JF8Xr
N17xdXidd7fkR3ZytBzAhBqadX1uKOcPcV2mNAb6tyMxUtG/LhJ3b0KxU0u56TpY
N6Zy9Cu9tnDn0VjA/hJw7V0FYQu+DgNPZXnynWTtpzx+HXNWIPGJgOfuzDQzQqIA
NkgkJl8LVdEvScYthcuKwdX+6Se8wekTArsfsE7sQmsFLdLnQHRSyDJSDGhDRd1d
6S8k9n8hTu6FVi3pMExCqwDrgewnafpYqxpAbfDguLRXS98mXhpVld6ksGsXX5vY
m301ddUKUBm+nwgrOyKROZyNmGsNeomY9rXY5ErOfE2k+dKdjrEgvZcesZUaEm6u
UIwrIJnKSfrKZPcLDmSCd0ypXNyoOmW7nWxvr0U7jarQaOwo43YJjS0CLCnZmSmd
ZLJAw0XfLGNZtE2mt5DBxdmxYR9HSZjUHX8RcydYRdvXGLgeTwUULXtpPUx2RVXq
5o1tPJFYQY6LYbr69TpwLeQ+QBvSKwtOlOzCHhB2QWHmGTAbEq0ncOq4qxt3qDGX
yWv7Pj+kfS10dM/Dm2SG55iuFYGbtbZDuR2az8pMabyKpaUyIh6ypZBG58H7v71K
OWCd/WfZFIjSkbKA2CLHVAB2F/tuMqvsSuc32j6KtcFGy8DytVdm8QrVE30NN57D
63/vKsUx1A==
=ws72
-----END PGP SIGNATURE-----
Merge tag 'samsung-soc-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/arm
Samsung mach/soc changes for v7.2
Remove raw GPIO number usage from S3C6410-based crag6410 board.
* tag 'samsung-soc-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: s3c: use gpio lookup table for LEDs
Signed-off-by: Linus Walleij <linusw@kernel.org>
When a caller provides a `supplied_recv` message to i_ipmi_request(),
the function increments the user's `nr_msgs` reference count. If an
error occurs later, the out_err cleanup path only frees the recv_msg
if the function allocated it itself (i.e., !supplied_recv). In the
supplied_recv case the cleanup is skipped, leaving the reference count
elevated. The caller ipmi_request_supply_msgs() does not release the
supplied_recv on error, so the reference is permanently leaked.
Fix this by explicitly reverting the reference count operations when a
supplied recv_msg with a valid user pointer is present in the error
path: decrement nr_msgs and drop the user's kref.
Cc: stable@vger.kernel.org
Fixes: b52da4054e ("ipmi: Rework user message limit handling")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Message-ID: <20260603120634.3758747-1-vulab@iscas.ac.cn>
Signed-off-by: Corey Minyard <corey@minyard.net>
hid_go_cfg_probe() initialises drvdata.go_cfg_setup and schedules it
to run 2 ms later:
INIT_DELAYED_WORK(&drvdata.go_cfg_setup, &cfg_setup);
schedule_delayed_work(&drvdata.go_cfg_setup, msecs_to_jiffies(2));
cfg_setup() dereferences drvdata.hdev to issue MCU command requests.
hid_go_cfg_remove() tears down sysfs and stops the HID device, but
never drains the delayed work. If the device is unbound within the
2 ms scheduling delay (a probe failure rolling back via remove, or a
fast rmmod after probe), the work fires after hid_destroy_device()
has dropped its reference and released the underlying hdev struct,
leaving cfg_setup() with a stale drvdata.hdev pointer.
Mirror the sibling driver hid-lenovo-go-s.c, whose hid_gos_cfg_remove()
already calls cancel_delayed_work_sync() on its analogous work, and
drain go_cfg_setup at the top of hid_go_cfg_remove(). The cancel
must come before guard(mutex)(&drvdata.cfg_mutex) because cfg_setup()
acquires that mutex; reversing the order would deadlock.
Fixes: d69ccfcbc9 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver")
Cc: stable@vger.kernel.org
Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
1. Exynos850: Implement proper power off to fully shutdown the board and
reduce drawn current.
2. ExynosAutov920: Add UFS storage.
3. Add Peter Griffin as a co-maintainer.
I have multiple subsystems to care of and limited time. Also, with
joining to SoC team I figured out it is good to plan my succession.
Or backup.
Peter shown both time and interest in keeping Samsung Exynos code
working. He already works on and maintains Google Tensor SoC, which
shares a lot with Samsung Exynos processors.
Considering all this, I proposed Peter to become a co-maintainer here
(same for pinctrl, which went via different tree).
I will still be the one handling patches for this and (probably) next
cycle, but in a further timeframe the roles could reverse with me
only providing acks or reviews. If this works then depending on other
duties and amount of work, I might be slowly transitioning to leave
Samsung SoC maintainership.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmocJCMQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD11V8D/9Xi4QVtgGivuu6lpggX/VCLY7TVvDUxZQG
1Ba5ggyW/TCGTUCC2k4kQKpO1J34/jBB3JCooIJV5K1rfcoClIxkrOD58ClxDeIh
Nf4lUVxyTRLL2HkFGh/ZI5a1NrCve1x+Lj2J36DAVKUGI7UciJRHqXud37grVid3
dOVNE6N5UGew1cbRCO0ej4G///+y4exKagX5oLcNRA5o9+t0/xwCTbZg60Jv3/xm
BjPLs75CwDu5+OpnKAPcjZg12AimoIlB8o95l0WU5AggkhEfNFJ6l8EgXfmv9SBr
+/1+N2Hlw6AzDDuzDpy9pDk3rvAozR0mRoYKrC/YWoJfykligMsgtmY5cHAmbPyj
IPf8lbqQnDpCr4Px9YBt378bi+7DZt2qCuBgbHkhprlLFbLN+P+48EU3ClsZrSFz
B09FfIc3eWj9+gzq2ymuYrUV+CGDkw4u7aoWLqcTXYgUPRNMkPKC0y2lLehriJMO
hW88iUf+wgtdOLxfKuIBUReEU4+G1T8b7gfRSLQpaqLPNob7j0G5Y629LQAZtHOc
vAAmloJDepAD0eA8ezLIN+XgEhlipgTnIesQ0FqRBvh2pIT67VkpQm8mBhIsLmWe
WIh7ApcZMIH3bRh6aYAZV8jJqbtZeLqEyasqoM6NZ7Y0DxGXCdC5Z/9HZ2WNYVJg
GbNn2/iXYQ==
=KSPN
-----END PGP SIGNATURE-----
Merge tag 'samsung-dt64-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt
Samsung DTS ARM64 changes for v7.2
1. Exynos850: Implement proper power off to fully shutdown the board and
reduce drawn current.
2. ExynosAutov920: Add UFS storage.
3. Add Peter Griffin as a co-maintainer.
I have multiple subsystems to care of and limited time. Also, with
joining to SoC team I figured out it is good to plan my succession.
Or backup.
Peter shown both time and interest in keeping Samsung Exynos code
working. He already works on and maintains Google Tensor SoC, which
shares a lot with Samsung Exynos processors.
Considering all this, I proposed Peter to become a co-maintainer here
(same for pinctrl, which went via different tree).
I will still be the one handling patches for this and (probably) next
cycle, but in a further timeframe the roles could reverse with me
only providing acks or reviews. If this works then depending on other
duties and amount of work, I might be slowly transitioning to leave
Samsung SoC maintainership.
* tag 'samsung-dt64-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
MAINTAINERS: Add Peter Griffin as a co-maintainer of Samsung Exynos SoCs
arm64: dts: exynos: Add EL2 virtual timer interrupt
arm64: dts: exynosautov920: enable support for ufs controller
arm64: dts: exynosautov920: Add syscon hsi2 node
arm64: dts: exynos850: Add syscon-poweroff node
Signed-off-by: Linus Walleij <linusw@kernel.org>
The bulk of this is various improvements for some of the older ASUS and
LG devices, but there's also support for interconnects on Tegra114 to
help improve memory frequency scaling.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmobyh8ACgkQ3SOs138+
s6GyKg//SkttJ6lDJYWZoc7rSDGMsshA4Dpys+BAb1WEdKraAyVZe9pe7YGxJ3GY
gIuKYHItT3rOuDWJXcEpaHc+0IAePVvH5719KmVwE2yRuUSij9YQpDjDGTmfJXmz
GknYUIT5mxIa96ldLL5lIUtRkUc6hWlHzdpOdWfY+5f2Pysny51HNS/rQHIMgZdI
CwN69JZQ5WKZbXLeueeNK5MxJOqFYQ/dS032cnuftz+aEjwUBuTvMy58O5WU/a98
YtgPpXi0WLFPTav4Do8JONHyn8hbBOkREt4t53GKoyIfoLmiZOU6tSlFb1WAIgWT
26TdolyaOefWlGnOV4FAlY4QCM72dpW2nydMWiUDgWLKri9sxRWLEKzqrWm833D6
0BDIySgmUmvnwmOkzVcZVkhLEFg1mJMhH4J4MSwpqMpTEpnNUNLjP8nyyQRpOuWW
f/cfwPex9qDb77WNG3ExJPjREzvXxsNBKJkrJnojMzsyK3kraXsApPgYR2N07/cE
XZavX2HMmKRnoNAIEGn+C3b8qX/4F+iHKeWoAt8J8qGx4EfhUcby3r024pWHHbgp
Q7Tu0A/Lp+iYDEHRb+VjN9w2niF5Qq0oTSK0X5Altp3F83a/sIsi/V1wWV1RmHg2
4A1deqXUryxZw8vqkovl0R5FuGv45IsfIaj81viLURAabdIdtiM=
=yQew
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-7.2-arm-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
ARM: tegra: Device tree changes for v7.2-rc1
The bulk of this is various improvements for some of the older ASUS and
LG devices, but there's also support for interconnects on Tegra114 to
help improve memory frequency scaling.
* tag 'tegra-for-7.2-arm-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: tf600t: Invert accelerometer calibration matrix
ARM: tegra: tf600t: Drop backlight regulator
ARM: tegra: tf600t: Configure panel
ARM: tegra: transformers: Add connector node for common trees
ARM: tegra: transformer: Add support for front camera
ARM: tegra: grouper: Add support for front camera
ARM: tegra: p880: Lower CPU thermal limit
ARM: tegra: lg-x3: Set PMIC's RTC address
ARM: tegra: lg-x3: Complete video device graph
ARM: tegra: Configure Tegra114 power domains
ARM: tegra: Add DC interconnections for Tegra114
ARM: tegra: Add EMC OPP and ICC properties to Tegra114 EMC and ACTMON device-tree nodes
ARM: tegra: Add #{address,size}-cells to Chromium-based /firmware
dt-bindings: memory: Document Tegra114 External Memory Controller
dt-bindings: memory: Document Tegra114 Memory Controller
Signed-off-by: Linus Walleij <linusw@kernel.org>
This adds a compatible string for an upcoming new chip as well as
changes some maintainership information.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmobx3EACgkQ3SOs138+
s6FTGRAAtVsDzbSVE3Rzc+sTg2cJZDWh8ErH6Im+HDZXpcjfGxIqQ0bqeaQ4v2s+
CePTH5cq37ih/qum+NEqz6neSxXEZJzbJifoxs/KZUGTH0YXrlhLT0p7x9eIJF+4
WqLFEYwmofOQr9lJ58qRvVTiSiFalJT8Po14fPNJ6H6jjTE7egXsI1wGNc349sK9
ZRK1+QLyv7AurpiaFypJU8hnKAW/ZyJ4iH9CX/+Rv4x1lqozBAt7Iu6voLmUMOzp
5GJUkFIa105eAYVnutHFp12PTg7RVuJRNHyvQ7Ca1racvhVIpjSjIqAaFKbWZMO9
ThfddfLYnlrUB/EXruRW6MF9G0jw0/nmRtgrJ79BRVjClEbDczFL/aAj6io1gYX0
avn+Zl/VOdUuK5QSTbRCUjEAFlQ9H05yipGXIOwHq/2uehUNRAZqoniFxLdX9xUS
9hdD04XyA3Ep031h0DGNU7PjOX4JzSw2egPzvN/NIxr5mOX5yKyMJBcoF18Zz7Nd
eLPqTBQQAvgHFWdiObyieSHPIwYB+bAgJKnonhZy878zo9by0bmnd3Kcx9iFdGDY
gEhmooifh3MukOVnCnUYnSvZuIBsKNL3j24GSExNBJB3J+igw16t816SI6vUEzIc
jXE09LEem7ET3NN7yhByFfaU0U8u9SywoQWMnCwuMU6fsYgjvXU=
=RwWK
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-7.2-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
dt-bindings: Changes for v7.2-rc1
This adds a compatible string for an upcoming new chip as well as
changes some maintainership information.
* tag 'tegra-for-7.2-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
dt-bindings: tegra: pmc: Add Tegra238 compatible
dt-bindings: reserved-memory: Change maintainer for BPMP SHMEM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Pull-request includes many random fixes and new features.
Major changes are listed below:
rtl8xxxu:
* declare supported channel width by firmware report
rtw88:
* validate RX descriptor to avoid malformed data causing warnings
rtw89:
* support USB devices RTL8922AU
* add sysfs entry to show SN and UUID for specific USB devices
* support to switch USB 3.0 mode for higher performance
* add more fields (mainly SIG-A/SIG-B) to radiotap in monitor mode
* offload packed IO to firmware to reduce IO time (for USB devices)
* add debugfs to diagnose BB healthy
* more preparations for RTL8922DE
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmof2vIACgkQjlvZYmhs
hd8Zvg//dgZR/XeDKnWS0wrI8kKock83ITTClT2en+N3BKlVRJp2SkU17F1owp5s
XHHFpyc29wWOJFy2+/rYiDr4Av0kL0Mkapsguh+bqHvJYrl3nlAziriEouQjTu/E
wHe3bz0j5wbR6eEGlUQ1dR5978CoQiAz70vtSwzcrULCqGD64DROB4eFidZO41m2
gON9Ldwc1oWWUnoIk3vwe9/19G7gkBcSWB7mSHJaxn5Od0Ma37qE6pXqtJ6o/hk2
WExhtWxfloMGRncyj1Mmcydyfuoh24pxZENnGjUSx0P2ndEpf/YwPtyoYYKL99ic
2dQ6xgZzToq3ykyWxp6Hi336UNRHD88udL1TNgpQ3gXllFfBLuRd39HBXcywPRf7
lViysy7BgS2325It99yumEzTIF13x0znrA5Z9R2wXK30DPxaL3Ov3Z4PSbUDgBCR
3fky5v9GXJ6nNOUETWCvOzJ1gTKrWexxNGX5MTAm2gd84kBg8ndAPH0qcc7wFjJC
o7qHTCtGBCu5pSnxgxL3y8dTrk/WQYhMM0FjqF1ok2ddxJDtgw4FYg/MW82gh2bf
CvS36+GTJg8KF1rHPfMrEpcCFcVMlJQs1l8kfbaXMQrXvpPsvyHjSr3RSKfxEalD
GNiOGWRi0MhL1V9An9JHr5tbWGfCAcEp0DMv/ykvLTQiYwogLWc=
=7iaf
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2026-06-03' of https://github.com/pkshih/rtw
Ping-Ke Shih says:
==================
rtw-next patches for -next
Pull-request includes many random fixes and new features.
Major changes are listed below:
rtl8xxxu:
* declare supported channel width by firmware report
rtw88:
* validate RX descriptor to avoid malformed data causing warnings
rtw89:
* support USB devices RTL8922AU
* add sysfs entry to show SN and UUID for specific USB devices
* support to switch USB 3.0 mode for higher performance
* add more fields (mainly SIG-A/SIG-B) to radiotap in monitor mode
* offload packed IO to firmware to reduce IO time (for USB devices)
* add debugfs to diagnose BB healthy
* more preparations for RTL8922DE
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In AP mode, track the BSS non-DBE bandwidth and apply
that to all non-DBE clients, then track OMP updates
from the clients and enable/disable DBE accordingly.
For now don't send a response, clients need to have a
timer anyway (it's up to the driver to set the right
timeout in UHR capabilities.)
Link: https://patch.msgid.link/20260529102644.be84f2b055cc.I4d2c067dfe54c47621d5a872ca07a0e754d6c20f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's similar code in two places in HT and HE, and we need to add
the same again for UHR. Rename ieee80211_link_sta_rc_update_omi()
to ieee80211_link_sta_update_rc_bw() and move it to sta_info.c and
update existing code that can use it to do so.
Link: https://patch.msgid.link/20260529102644.577c2f304d33.I09df4fce83c4e3e6deddfecbea74ffdbeedb4927@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
UHR requires MLO, not just formally but also in order
for the client to understand AP BSS parameter changes,
since the Critical Update Counter is inside the Multi-
Link Element. Require MLO for UHR connections to avoid
otherwise needed complexity such as not enabling any
feature that would require tracking critical updates.
Link: https://patch.msgid.link/20260529102644.43817ce87042.If4562ae9c5ca83339b397d9a344b68631cb17c4a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
During beacon processing, the parser is always called with
a BSS to find the correct multi-BSSID profile (if any) and
therefore never attempts to parse a multi-link element.
This means the code to handle cross-link CSA can effectively
never do anything.
Fix this by parsing the multi-link element in the regular
parser as well.
Fixes: 7ef8f6821d ("wifi: mac80211: mlme: handle cross-link CSA")
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260529102644.2a74b2659f50.I8f9454bf5e05c419a9b1eb23ecad302a6bf63fbb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A previous commit changed mac80211 to no longer make wrong
calls to cfg80211_defragment_element() with the element
pointing outside of the buffer. Additionally, harden this
function itself against that and always return -EINVAL in
case the element isn't inside the source buffer.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260529102644.198945754054.I5ae8fdebf9008abc6e15d0b0f10c3a7b73d02eab@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When connected to a non-transmitting BSS of multiple BSSID
set with EMA, the correct profile for the connection isn't
always present in the beacon. Indicate this in the parser
and use the information to not check everything in beacon
processing, since the information might not be correct if
taken only from the transmitted BSS.
Link: https://patch.msgid.link/20260529102644.97527a7dfd7b.Iecd0ef578b85a5a0057538cfff5fdff41d19b7ea@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are multiple cases where interface links are removed
and the station links need to be removed with them, e.g.
in mlme.c we have both received and transmitted multi-link
reconfiguration, doing the two things in different order,
the former deleting STA links when the vif link change may
still fail.
It's also not clear that userspace (hostapd) couldn't, at
least in theory, remove a link from an interface without
removing the station links first, or even leave stations
that aren't MLO-capable, using that link.
Unify this code into ieee80211_vif_update_links() so that
it always happens, always happens in the right order and
is transactional (i.e. failures are handled correctly.)
Link: https://patch.msgid.link/20260529102644.c352f73a4658.I7219a5d72dab2abcecea9b5c52e7eb7a50e68d9b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Introduce basic rate encoding/decoding for S1G stas such that the
usermode rx reporting is relevant as it currently uses VHT calculations
which are obviously wildy different to S1G. Sample iw output (with the
associated iw patches applied):
Connected to 0c:bf:74:00:21:c4 (on wlan0)
SSID: wifi_halow
freq: 923.500
RX: 7325230 bytes (4756 packets)
TX: 190044 bytes (2238 packets)
signal: -38 dBm
rx bitrate: 43.3 MBit/s S1G-MCS 9 8MHz short GI S1G-NSS 1
tx bitrate: 43.3 MBit/s S1G-MCS 9 8MHz short GI S1G-NSS 1
bss flags:
dtim period: 1
beacon int: 100
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260602062224.1792985-1-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
qtnf_pcie_topaz_probe() currently calls devm_request_irq() and only then
disable_irq(). request_irq() installs the action in the irq core
immediately, so qtnf_pcie_topaz_interrupt() can run before the Topaz
private IRQ consumers are initialized, if the hardware misbehaves.
This window is reachable on a running system as soon as probe has
successfully registered pdev->irq but before qtnf_pcie_init_shm_ipc()
sets shm_ipc_ep_in/out.irq_handler. If an interrupt is delivered in
this interval, qtnf_pcie_topaz_interrupt() calls
qtnf_shm_ipc_irq_handler() for shm_ipc_ep_in/out while their irq_handler
callbacks are still unset, so the driver can observe an early IRQ
before its IPC consumer state is ready.
The issue was found on Linux v6.18.21 by our static analysis tool while
scanning request_irq()/disable_irq() registration-order bugs in
wireless PCIe drivers, and then manually reviewed.
Request the IRQ with IRQF_NO_AUTOEN instead and keep the existing
enable_irq() in qtnf_post_init_ep() as the point where interrupts
become visible. This closes the early-IRQ window while preserving the
intended bring-up order.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260531145435.701703-1-runyu.xiao@seu.edu.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are no issues with the PERR processing itself; however, to maintain
consistency with the previous PREQ/PREP code modifications, I will create a
new mesh_path_parse_error_frame() function to separately implement the
frame format validation and the "not supported" check.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Link: https://patch.msgid.link/20260529230952.124754-6-masashi.honma@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the AF flag is enabled, hwmp_prep_frame_process() overreads orig_addr
by 2 bytes. Since this occurs within the socket buffer, it does not read
across memory boundaries and therefore poses no security risk; however, we
will fix it as a precaution.
In this fix, a new function mesh_path_parse_reply_frame() is established to
separate the implementation of frame format validation and the check for
unsupported features. This is intended to facilitate future work when
implementing the currently unsupported parts.
Assisted-by: Claude:Sonnet 4.6
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Link: https://patch.msgid.link/20260529230952.124754-5-masashi.honma@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the AF flag is enabled, hwmp_preq_frame_process() overreads
target_addr by 2 bytes. Since this occurs within the socket buffer, it does
not read across memory boundaries and therefore poses no security risk;
however, we will fix it as a precaution.
In this fix, a new function mesh_path_parse_request_frame() is established
to separate the implementation of frame format validation and the check for
unsupported features. This is intended to facilitate future work when
implementing the currently unsupported parts.
Assisted-by: Claude:Sonnet 4.6
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Link: https://patch.msgid.link/20260529230952.124754-4-masashi.honma@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The existing PERR_IE_* macros access HWMP PERR frame fields via hardcoded
byte offsets. Each PERR destination entry contains an optional 6-byte AE
(Address Extension) address followed by a reason code, making offset-based
access error-prone.
Introduce typed packed C structs to represent the PERR frame layout:
- ieee80211_mesh_hwmp_perr: top-level frame containing TTL and
destination count
- ieee80211_mesh_hwmp_perr_dst: per-destination entry with optional AE
address and variable-position reason code
Add ieee80211_mesh_hwmp_perr_get_rcode() to locate the reason code in
each destination entry depending on whether the AE flag is set.
This refactoring makes the PERR processing code consistent with the
struct-based approach adopted for PREQ and PREP in preceding patches.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Link: https://patch.msgid.link/20260529230952.124754-3-masashi.honma@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The existing PREP_IE_* macros access HWMP PREP frame fields via hardcoded
byte offsets. When the AE (Address Extension) flag is set, an additional
6 bytes appear mid-frame, making the offset arithmetic error-prone.
Introduce typed packed C structs to represent the PREP frame layout:
- ieee80211_mesh_hwmp_prep_top: fixed fields before the optional AE
address
- ieee80211_mesh_hwmp_prep_bottom: fields after the optional AE address
Add ieee80211_mesh_hwmp_prep_get_bottom() to locate the bottom struct
correctly based on whether the AE flag is set.
This preparatory refactoring is needed to fix a 2-byte overread of
orig_addr in hwmp_prep_frame_process() when AE is enabled, which is
addressed in a subsequent patch.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Link: https://patch.msgid.link/20260529230952.124754-2-masashi.honma@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The existing PREQ_IE_* macros access HWMP PREQ frame fields via hardcoded
byte offsets. When the AE (Address Extension) flag is set, an additional
6 bytes appear mid-frame, and the macros handle this with conditional
arithmetic (e.g., AE_F_SET(x) ? x + N+6 : x + N). This approach
obscures the frame layout and is prone to miscalculation.
Introduce typed packed C structs to represent the PREQ frame layout:
- ieee80211_mesh_hwmp_preq_top: fixed fields before the optional AE
address
- ieee80211_mesh_hwmp_preq_bottom: fields after the optional AE address
- ieee80211_mesh_hwmp_preq_target: per-target fields
Add ieee80211_mesh_hwmp_preq_get_bottom() to locate the bottom struct
correctly based on whether the AE flag is set.
This preparatory refactoring is needed to fix a 2-byte overread of
target_addr in hwmp_preq_frame_process() when AE is enabled, which is
addressed in a subsequent patch.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Link: https://patch.msgid.link/20260529230952.124754-1-masashi.honma@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove WIPHY_FLAG_SUPPORTS_5_10_MHZ and 5/10 MHz channel
width support. We contemplated this back in early 2023
and didn't do it yet, but nobody stepped up to maintain
it.
It's already _mostly_ dead code since it can really only
be used for AP and maybe IBSS and monitor, but not on a
client since there's no way to scan (and hasn't been in
a very long time, if ever), so the only thing that ever
could really happen with it was run syzbot and trip over
assumptions in the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260529084502.080c5885f0b7.I77cc94485b523c3c006005b9233db13cd4e077b3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a non-MLD station associates with an MLD AP, it does so on a
specific link. However, sta_set_sinfo() never sets mlo_params_valid,
so nl80211 never emits NL80211_ATTR_MLO_LINK_ID in get_station /
dump_station responses. Userspace has no way to determine which link
a non-MLD STA is associated on.
Set mlo_params_valid to 1 and assoc_link_id to sta->deflink.link_id,
when valid_links is set.
Also set the mld_addr copy only for MLD STAs, so that non-MLD STAs
get a zeroed mld_addr as documented.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://patch.msgid.link/20260528105042.835284-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
- Add two new devices: the Verbatim Gigabit NAS and the
Raidsonic IB-4210-B, including ACKed binding updates.
- Fix up boot device for the SQ201.
- Use the right LED trigger for disk activity.
- Add the SSP/SPI block to the SoC.
- Fix up the RUT1xx device tree.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmoX/8IACgkQQRCzN7AZ
XXNyVA//fT/5wTE6Nh6bg4klm6XXPYYUf4GG/QBKXyMomYuCatlh265AzK/W5TAV
hhQr8qh8vixgReV9LYz4kH6tyC4CY4vdexOOU4TMrcTrVYOeV/W4GisJEDTdN0T0
qtwPst4SkQeQycPMJ08hs5jLz9kXXonxNHFOU6pOmiICqSMUhSFNvtpklUvEFa6z
f0srUd9Zy311U5olj8kzED0JepeHArezbcREpFovOnB8VB9oMX4GAEPwUbV/WlxO
2lmvof0qfGLiXQjx+A7zTdVhoDsL47jgQdsmkTa0XaVSipxIJrBeyKf6H0NzoQGv
efmtl8VsgtZFeNR+7dDCOiokNizSTUsLI/AKAqHVu9JtPd3cs1fF0KDOldCl3ha5
SiHZsZaoZkisQjPPK3EzHlUCDxSEvIqRxD0CF1fx6bKVAvFVScMH+V//9OklInGA
u3pdCvc/4Wil3FMLR91DACux8Bp79arLMW8MzvdnGAi4wuYsoqIhQOaBmi9D2hbo
c0qW3JtFFvmCm32hIrVrxt9WAi9bleRmQOJ09wZrmTobRJpCCa+JcyyTdWqaBmP0
CI5u68jvUoVwRdrOsxv8bac13dpdSF+fPa0qZK6dtYnQqVc5fWgRGbFASbjnMOjD
MJsJT9ajSKXgP0BAvaieXwlmB9eeZVXsjlC/CJul7MrNlnA8K44=
=RQ6n
-----END PGP SIGNATURE-----
Merge tag 'gemini-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into soc/dt
Gemini device tree updates:
- Add two new devices: the Verbatim Gigabit NAS and the
Raidsonic IB-4210-B, including ACKed binding updates.
- Fix up boot device for the SQ201.
- Use the right LED trigger for disk activity.
- Add the SSP/SPI block to the SoC.
- Fix up the RUT1xx device tree.
* tag 'gemini-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator:
ARM: dts: gemini: Correct the RUT1xx
ARM: dts: Add a Raidsonic IB-4210-B DTS
ARM: dts: Add a Verbatim Gigabit NAS DTS
dt-bindings: arm: Add two missing Gemini devices
dt-bindings: vendor-prefixes: Add Verbatim Corporation
ARM: dts: gemini: Add SSP/SPI block
ARM: dts: gemini: Tag disk led for disk-activity
ARM: dts: gemini: iTian SQ201 need to boot from mtdblock3
Signed-off-by: Linus Walleij <linusw@kernel.org>
The existing cs42xx8 driver only supported I2C control interface.
Add SPI bus support for the Cirrus Logic CS42448/CS42888 Audio CODEC.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260603095041.3906558-3-chancel.liu@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Codec CS42448/CS42888 supports multiple control interfaces. At present,
only the I2C interface is implemented. Adding support for the SPI
control interface, operating at up to 6MHz.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260603095041.3906558-2-chancel.liu@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Two of the SVE hwcaps added for the SVE features in the 2025 dpISA did
not explicitly call out their dependency on SVE in the ABI documentation.
Do so.
While we're here reorder the SVE and fature specific ID registers for
HWCAP3_SVE_LUT6 which did have the SVE dependency but listed it second
unlike the other SVE specific ID registers.
Fixes: abca5e69ab ("arm64/cpufeature: Define hwcaps for 2025 dpISA features")
Reported-by: Will Deacon <will@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
HiSilicon HIP09 implements TLB entry matching behavior that deviates
from the ARM architecture specification when the CNP (Common not Private)
bit is set in TTBRx_ELx.
When TTBRx.CNP=1, TLB entries may be incorrectly shared between CPU
cores, leading to TLB conflicts and stale mappings. This affects
coherency and can result in incorrect translations.
Add the hardware erratum workaround (Hisilicon erratum 162100125) to
disable CNP on affected HIP09 cores.
Co-developed-by: Tong Tiangen <tongtiangen@huawei.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
The NVIDIA Carmel CNP erratum is not the only case requiring CNP to be
disabled. Abstract this into a common WORKAROUND_DISABLE_CNP capability
to facilitate adding errata for future chips and reduce duplicate
checks in has_useable_cnp().
This serves as a prerequisite for the subsequent Hisilicon erratum
162100125.
Suggested-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
