Several issues in the inline vlan support:
- The layer 2 encapsulation representation in the tuple takes encap[0] as
the outer header and encap[1] as the inner header as seen from the ingress
path. Reverse the encap loop to push first the inner then the outer vlan
header.
- Postpone pushing the layer 2 header once destination device is known.
This allows to calculate the needed hearoom via LL_RESERVED_SPACE to
accommodate the layer 2 headers.
- Add and use nf_flow_vlan_push() as suggested by Eric Woudstra, this
is a simplified version of skb_vlan_push() for egress path only.
Fixes: c653d5a78f ("netfilter: flowtable: inline vlan encapsulation in xmit path")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This reverts commit 20e0c19780.
Despite claiming to add GA100 support, that commit actually has quite
a few problems. It falsely claims that there is no VBIOS. GA100 does
have a VBIOS, but it has no display engine, so it cannot use the
PRAMIN method the read VBIOS and must fall back to using PROM.
For whatever reason, the VBIOS on GA100 has an "Init-from-ROM"
(IFR) header where the PCI Expansion ROM would normally be found.
So to find that ROM, Nouveau needs to parse the IFR header.
The commit also falsely claimed that there is no graphics (GR) engine.
So rather than try to fix that commit, just revert it and start over
from scratch.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260430223838.2530778-2-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The functions show_fan(), show_pwm1(), show_temp11(),
temp2_crit_hyst_show(), and show_lut_temp_hyst() access shared cached
data without holding the update lock. This can cause TOCTOU races if
the cached values change between the checks and the later calculations.
Those cached values are updated in lm63_update_device(). In the general
case, the affected functions combine multiple cached values without
locking and can therefore observe a mixed old/new snapshot. In
addition, show_fan() reads data->fan[nr] locklessly while
lm63_update_device() updates data->fan[0] in two steps, which can
expose an intermediate torn value and potentially trigger a
divide-by-zero error. This means that converting the macro to a
function is not sufficient to fix show_fan().
Hold the update lock across the whole read and calculation sequence so
that the values remain stable.
Check the other functions in the driver as well. Keep them unchanged
because they either do not access shared cached values multiple times
or already do so under lock.
Link: https://lore.kernel.org/linux-hwmon/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Fixes: e872c91e72 ("hwmon: (lm63) Add support for unsigned upper temperature limits")
Fixes: d216f6809e ("hwmon: (lm63) Expose automatic fan speed control lookup table")
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
Link: https://lore.kernel.org/r/20260416135703.53262-1-hanguidong02@gmail.com
[groeck: Use lm63_update_device() to get driver data in temp2_crit_hyst_store]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add thermal cooling device support to control the temperature by throttling data
transmission. Throttling is performed by suspending data TX queues according to
a configured duty-cycle off percentage. The thermal cooling device allows users
to configure the duty-cycle off percentage and operate the device with the
selected value.
User configuration updates a single duty-cycle off percentage, which is applied
uniformly by the host and treated as only one temperature level. This value
remains in effect until updated again by the user. All other thermal throttling
parameters continue to use their default firmware provided values.
Reject invalid duty-cycle off percentage values that fall outside the supported
range. Register a cooling device to allow the thermal framework to query and set
the current throttle state, report the maximum supported state, and keep the
host state in sync with successful firmware updates. A throttle state of zero
restores the default firmware thermal configuration.
Command to set the duty-cycle off percent:
echo 40 > /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device0/cur_state
Command to read duty-cycle off percent:
cat /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device0/cur_state
Command to read the maximum duty-cycle off percent:
cat /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device0/max_state
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260413153840.1969931-6-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
A later change adds thermal cooling device sysfs under the wiphy device kobject.
With the current teardown order, MAC/wiphy are unregistered before per-device
cleanup, so any subsequent thermal sysfs removal would run after the wiphy kobject
is gone. That ordering is asymmetric with setup and would risk kernfs issues during
removal.
This change also adjusts the position of ath12k_mac_mlo_teardown(). Previously
it ran before per-device cleanup/MAC unregister. MLO teardown issues WMI to teardown
multi-link state and is part of the MAC teardown sequence. Placing it alongside
MAC unregister (after per-device cleanup) preserves setup/teardown symmetry and
avoids racing with remaining netdev/wiphy state.
Reorder hw_group_stop() so per-device cleanup (including thermal/hwmon sysfs
removal) runs while the wiphy still exists. After per-device cleanup completes,
unregister the MAC (dropping wiphys), run ath12k_mac_mlo_teardown(), and finally
destroy the MAC. This mirrors the setup sequence and keeps sysfs cleanup safe
when introduced in a later patch.
To keep start/stop symmetry, add ath12k_core_device_setup() to encapsulate the
per-device bring-up steps (pdev create, IRQ enable, rfkill config) that were
previously open-coded in hw_group_start(). Use this helper in hw_group_start()
to match the existing per-device cleanup helper used by hw_group_stop().
Note that set_bit(ATH12K_FLAG_REGISTERED, &ab->dev_flags) is now executed outside
the ab->core_lock critical section. The core_lock has not provided protection for
the REGISTERED flag, readers do not rely on core_lock for this bit, and the flag
is only toggled in the serialized group start/stop path using atomic bitops.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260413153840.1969931-5-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Both the error path in thermal registration and the normal thermal unregister
path performed the same hwmon device unregistration and pointer cleanup.
Consolidate this logic into a single helper to reduce code duplication and ensure
consistent cleanup across all paths. Add a helper to set up the hwmon registration
during thermal registration to keep symmetry with thermal cleanup.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260413153840.1969931-4-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Ath12k firmware supports thermal-throttling but requires the host to explicitly
program throttle levels and mitigation actions via WMI. Without this configuration,
firmware-driven thermal mitigation remains inactive or relies on platform-specific
defaults.
Add host-side support to build and send thermal-throttle configuration using
WMI_THERM_THROT_SET_CONF_CMDID during MAC radio start, ensuring thermal parameters
are programmed before data traffic begins.
Maintain per-radio storage for thermal throttle levels and provide conservative
default level tables for Internal Power Amplifier Device (IPA) and External Power
Amplifier Device or External Front End Module (XFEM) targets. The appropriate
default table is selected based on firmware-advertised service bits, allowing the
host to align with target thermal mitigation capabilities. If the WMI TLV service
WMI_TLV_SERVICE_IS_TARGET_IPA bit is set, then host selects the thermal throttle
values from IPA index from the table and selects values from XFEM index from the
table if this WMI TLV service bit is not set.
Build and send the thermal throttle configuration request with either 4 or
5 levels depending on firmware capability, and populate optional fields
(pout reduction and tx chain mask) only when the corresponding service bits
are advertised.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260413153840.1969931-3-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Add handling for WMI_THERM_THROT_STATS_EVENTID by defining the
wmi_therm_throt_stats_event TLV and parsing pdev_id, temperature and
throttle level.
The firmware can emit this event periodically, including when the
throttle level is 0.
Log the received thermal throttle stats to get the current temperature level,
temperature and thermal throttling levels.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260413153840.1969931-2-maharaja.kennadyrajan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
This is purely cosmetic changes that simplifies & standardizes error
handling for functions that ends with a ath12k_wmi_cmd_send() followed
by trivial error handling. Saves a few lines of code too.
Compile tested only.
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260422163208.3013496-1-nico.escande@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
A reboot can crash the kernel if it overlaps with WLAN firmware crash
recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown
path while freeing DMA-backed MHI contexts.
Simplified trace:
dma_free_attrs
mhi_deinit_dev_ctxt [mhi]
ath11k_pci_power_down [ath11k_pci]
ath11k_pci_shutdown [ath11k_pci]
device_shutdown
kernel_restart
On the host side, SSR is driven by the MHI RDDM callback, which queues
reset_work to perform device recovery. reset_work power-cycles the device
by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The
power-down phase deinitializes MHI and frees DMA resources.
Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR
recovery flow. As a result, the shutdown path
(ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR
recovery sequence.
Fix this by canceling SSR-related work items during PCI shutdown, marking
the device as unregistering, and serializing the RDDM callback path that
checks and queues reset_work. This ensures that no new SSR recovery work
can be queued once teardown has started, and that any in-flight recovery
work is fully synchronized before device power-down, preventing MHI
teardown and DMA resource freeing from running more than once.
Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k
devices do not queue reset_work in normal SSR flows.
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Fixes: 13da397f88 ("ath11k: add support for device recovery for QCA6390/WCN6855")
Fixes: 5edbb148bc ("wifi: ath11k: Add firmware coredump collection support")
Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260404043050.3433754-1-wei.zhang@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
Add __counted_by to get extra runtime analysis. Move counting variable
assignment immediately after allocation before any potential accesses.
kzalloc_flex does this anyway for GCC >= 15.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260421213544.6238-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The driver does not currently set any rx_flag for frames received with
decap type DP_RX_DECAP_TYPE_8023. When the hardware reports
LLC-encapsulated packets whose length field is below 0x0600, the MSDU_END
descriptor may indicate decap type DP_RX_DECAP_TYPE_8023.
These frames are effectively equivalent to Ethernet-II (DIX) packets,
similar to those decoded as DP_RX_DECAP_TYPE_ETHERNET2_DIX. If the
driver does not set RX_FLAG_8023 for these frames, mac80211 will
misinterpret them as 802.11 frames. This causes valid frames such as
Bridge Protocol Data Units (BPDUs) to be dropped. BPDUs are exchanged
between switches to maintain and manage network topology, and must
be treated as Ethernet frames.
Set RX_FLAG_8023 for decap type DP_RX_DECAP_TYPE_8023 in
ath12k_dp_rx_h_undecap() to ensure mac80211 handles these frames
correctly. Also add multicast packet handling support for the
DP_RX_DECAP_TYPE_8023 decap type.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260418163620.3633959-1-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260427070040.17928-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Instead of defining a local macro with a custom name for the QMI
service identifier, use the one provided in qmi.h and remove the
locally defined macro.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Link: https://patch.msgid.link/20260316171419.2619620-3-daniel.lezcano@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a
4-bit hardware field (0-15), but the txq array only has
ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array
access.
Add a bounds check on ts.qid before using it as an array index.
Fixes: fce041beb0 ("ath9k: unify edma and non-edma tx code, improve tx fifo handling")
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260415222343.1540564-1-tristmd@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Simplifies the code slightly by removing temporary variables.
multiplication overflow is also gained for free.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260223224445.27352-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
There is no need for dynamic allocation for a simple string.
request_firmware_nowait copies the string internally anyway.
The error message on failure is also wrong. It's an allocation failure,
not a find failure.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260223224254.27081-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
There's absolutely no need to extend the lifetime of cell to post
removal of the driver. It's only used in this function.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260223025021.19008-1-rosenp@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Since commit a8bb74acd8 ("rcu: Consolidate RCU-sched update-side function definitions")
there is no difference between rcu_read_lock(), rcu_read_lock_bh() and
rcu_read_lock_sched() in terms of RCU read section and the relevant grace
period. That means that spin_lock(), which implies rcu_read_lock_sched(),
also implies rcu_read_lock().
There is no need no explicitly start a RCU read section if one has already
been started implicitly by spin_lock().
Simplify the code and remove the inner rcu_read_lock() invocation.
Cc: Toke <toke@toke.dk>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: pengdonglin <pengdonglin@xiaomi.com>
Signed-off-by: pengdonglin <dolinux.peng@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20250916044735.2316171-15-dolinux.peng@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Fixes: bca4b02ef9 ("remoteproc: xlnx: Add attach detach support")
Reviewed-by: Beleswar Padhi <b-padhi@ti.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
When a field has been initialized, `init!`/`pin_init!` create a reference
or pinned reference to the field so it can be accessed later during the
initialization of other fields. However, the reference it created is
incorrectly `&'static` rather than just the scope of the initializer.
This means that you can do
init!(Foo {
a: 1,
_: {
let b: &'static u32 = a;
}
})
which is unsound.
This is caused by `&mut (*#slot).#ident`, which actually allows arbitrary
lifetime, so this is effectively `'static`. Somewhat ironically, the safety
justification of creating the accessor is.. "SAFETY: TODO".
Fix it by adding `let_binding` method on `DropGuard` to shorten lifetime.
This results in exactly what we want for these accessors. The safety and
invariant comments of `DropGuard` have been reworked; instead of reasoning
about what caller can do with the guard, express it in a way that the
ownership is transferred to the guard and `forget` takes it back, so the
unsafe operations within the `DropGuard` can be more easily justified.
Fixes: 42415d163e ("rust: pin-init: add references to previously initialized fields")
Cc: stable@vger.kernel.org
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260427-pin-init-fix-v3-2-496a699674dd@garyguo.net
[ Reworded for missing word. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Instead of having the reference creation serving dual-purpose as both for
let bindings and alignment check, detangle them so that the alignment check
is done explicitly in `make_field_check`. This is more robust against
refactors that may change the way let bindings are created.
Cc: stable@vger.kernel.org
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260427-pin-init-fix-v3-1-496a699674dd@garyguo.net
[ Reworded for typo. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
32-bit UML builds can be configured either by setting CONFIG_64BIT=n or
with SUBARCH=i386. Both work with Rust-for-Linux when clang is the
compiler, but when SUBARCH=i386, we don't set a bindgen target correctly if
gcc is the compiler.
Add the appropriate bindgen target configuration for i386, as is done in
Makefile.clang.
[ For reference, the errors look like:
BINDGEN rust/bindings/bindings_generated.rs
error: unsupported option '-mno-sse' for target ''
...
error: unknown target triple 'unknown'
panicked at .../bindgen-0.72.1/ir/context.rs:562:15:
libclang error; possible causes include:
...
- Miguel ]
Fixes: ab0f4cedc3 ("arch: um: rust: Add i386 support for Rust")
Signed-off-by: David Gow <david@davidgow.net>
Link: https://patch.msgid.link/20260425034125.53866-1-david@davidgow.net
[ Added space in title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
We're currently dumping skb info in our fragment input test, which makes
interpreting the TAP test output a bit awkward.
Remove the skb dumps.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260429-dev-mctp-test-skb-dump-v1-1-13fd5789ef71@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jeremy Kerr says:
====================
net: mctp: test: minor kunit test fixes
This series provides two fixes in the MCTP kunit tests - one exposed by
ktr, and one found while debugging the former on different VM configs.
====================
Link: https://patch.msgid.link/20260429-dev-mctp-test-fixes-v1-0-1127b7425809@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In our test cases, we typically feed a packet sequence into the routing
code, then inspect the device's TXed skbs to assert specific behaviours.
Using dev_queue_xmit() for our TX path introduces a fair bit of
complexity between the test packet sequence and the test device's
ndo_start_xmit callback; which may mean that the skbs have not hit the
device at the point we're inspecting the TXed skb list.
Use dev_direct_xmit instead, as we want a direct a path as possible
here, and the test dev does not need any queueing, scheduling or flow
control.
Fixes: 6ab578739a ("net: mctp: test: move TX packetqueue from dst to dev")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202604281320.525eee17-lkp@intel.com
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260429-dev-mctp-test-fixes-v1-2-1127b7425809@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Invalid sockaddr padding will cause bind() to fail; ensure we have a
zeroed address in the testcase.
Fixes: 0d8647bc74 ("net: mctp: don't require a route for null-EID ingress")
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260429-dev-mctp-test-fixes-v1-1-1127b7425809@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The variable this_hwcap is initialized to 0 for each loop, it is not
necessary to do the bit clearance since this_hwcap is still 0 at this
point, clearing the source_isa is enough here.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://patch.msgid.link/20260430045350.22213-1-hui.wang@canonical.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Merge assorted ACPI support fixes for 7.1-rc2:
- Fix EINJV2 memory error injection in APEI (Tony Luck)
- Add missing notifier_block structure forward declaration to
acpi_bus.h (Bartosz Golaszewski)
- Fix related_cpus inconsistency during CPU hotplug in the ACPI CPPC
library (Jinjie Ruan)
- Add a quirk to force native backlight on HP OMEN 16 (8A44) in the
ACPI video bus driver (Shivam Kalra)
* acpi-apei:
ACPI: APEI: EINJ: Fix EINJV2 memory error injection
ACPICA: Provide #defines for EINJV2 error types
* acpi-bus:
ACPI: bus: add missing forward declaration to acpi_bus.h
* acpi-cppc:
ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug
* acpi-video:
ACPI: video: force native backlight on HP OMEN 16 (8A44)
When parsing device properties from ftrace data, the devprops() function
assumes that each line has at least three fields and that the third field
(f[2]) always contains a valid integer. However, due to incomplete or
corrupted ftrace logs, f[2] may be missing, empty, or non-existent.
This can lead to the following error:
Traceback (most recent call last):
File "../sleepgraph.py", line 7142, in <module>
stamp = rerunTest(sysvals.outdir)
File "../sleepgraph.py", line 6255, in rerunTest
testruns, stamp = processData()
File "../sleepgraph.py", line 6181, in processData
testruns, error = parseTraceLog(live)
File "../sleepgraph.py", line 3470, in parseTraceLog
tp, tf = loadTraceLog()
File "../sleepgraph.py", line 3398, in loadTraceLog
if tp.stampInfo(line, sysvals):
File "../sleepgraph.py", line 3073, in stampInfo
self.parsePlatformInfo(line, sv)
File "../sleepgraph.py", line 3177, in parsePlatformInfo
sv.devprops = self.devprops(sv.b64unzip(info))
File "../sleepgraph.py", line 3158, in devprops
if int(f[2]):
ValueError: invalid literal for int() with base 10: ''
To prevent this crash, add proper validation before accessing.
Signed-off-by: Gongwei Li <ligongwei@kylinos.cn>
Acked-by: Todd Brandt <todd.e.brandt@intel.com>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20260424071208.3610628-1-13875017792@163.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
corsairpsu_probe() opens the HID device before sending the device init
and firmware-info commands. If either command fails, the error path jumps
directly to fail_and_stop and skips hid_hw_close().
Use the existing fail_and_close label for those post-open failures so the
open count and low-level close callback are balanced before hid_hw_stop().
Fixes: d115b51e0e ("hwmon: add Corsair PSU HID controller driver")
Cc: stable@vger.kernel.org
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Link: https://lore.kernel.org/r/20260424135107.13720-1-mhun512@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
kconfiglint reports:
X001: CONFIG_SENSORS_SBRMI referenced in Makefile but not defined
in any Kconfig
The SB-RMI hardware monitoring driver was originally introduced in
commit 5a0f50d110 ("hwmon: Add support for SB-RMI power module") with
both a Kconfig entry (CONFIG_SENSORS_SBRMI) and a Makefile line
(obj-$(CONFIG_SENSORS_SBRMI) += sbrmi.o) in drivers/hwmon/.
Commit e156586764 ("hwmon/misc: amd-sbi: Move core sbrmi from hwmon to
misc")
moved the driver to drivers/misc/amd-sbi/ to support additional
functionality beyond hardware monitoring. That commit correctly removed the
Kconfig entry from drivers/hwmon/Kconfig, moved the source file
drivers/hwmon/sbrmi.c to drivers/misc/amd-sbi/sbrmi.c, and created new
Kconfig/Makefile entries in drivers/misc/amd-sbi/ with a renamed symbol
(CONFIG_AMD_SBRMI_I2C).
However, the Makefile line in drivers/hwmon/Makefile was not removed in
that commit. The orphaned line references a CONFIG symbol that no longer
exists and a source file that is no longer present, so it has no effect
on the build — but it is dead code that should be cleaned up.
Remove the stale Makefile reference.
Assisted-by: Claude:claude-opus-4-6 kconfiglint
Signed-off-by: Sasha Levin <sashal@kernel.org>
Link: https://lore.kernel.org/r/20260426000319.55908-1-sashal@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ideapad-laptop.c file now exists inside drivers/platform/x86/lenovo/
directory. Updating the GitHub link to the correct path.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Link: https://lore.kernel.org/r/20260417191411.713958-1-ninadnaik07@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ltc2992_get_power() computes the divisor for mul_u64_u32_div() as
r_sense_uohm * 1000. This multiplication overflows u32 when
r_sense_uohm exceeds about 4.29 ohms (4294967 micro-ohms), producing
a truncated divisor and an incorrect power reading.
Cancel the factor of 1000 from both the numerator
(VADC_UV_LSB * IADC_NANOV_LSB = 312500000) and the divisor
(r_sense_uohm * 1000), giving (VADC_UV_LSB / 1000) * IADC_NANOV_LSB
= 312500 as the numerator and plain r_sense_uohm as the divisor.
The cancellation is exact because LTC2992_VADC_UV_LSB (25000) is
divisible by 1000.
This is the read-path counterpart of the write-path fix applied in
the preceding patch.
Fixes: b0bd407e94 ("hwmon: (ltc2992) Add support")
Cc: stable@vger.kernel.org
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Link: https://lore.kernel.org/r/20260416215904.101969-3-sanman.pradhan@hpe.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ltc2992_set_voltage(), ltc2992_set_current(), and ltc2992_set_power()
do not validate the user-supplied value before converting it to a
register value. This can result in:
1. Negative input values wrapping to large positive register values.
For power, the negative long is implicitly cast to u64 in
mul_u64_u32_div(), producing an incorrect value. For voltage and
current, the negative converted value wraps when passed to
ltc2992_write_reg() as a u32.
2. Intermediate arithmetic exceeding the range representable in u64 on
64-bit platforms. In ltc2992_set_voltage(), (u64)val * 1000 can
exceed U64_MAX when val is a large positive long. In
ltc2992_set_current(), (u64)val * r_sense_uohm can overflow
similarly. In ltc2992_set_power(), the computed value may not fit
in u64.
3. Register values exceeding the hardware field width. Voltage and
current threshold registers are 12-bit (stored left-justified in
16 bits), and power threshold registers are 24-bit. Without
clamping, bits above the field width are truncated in
ltc2992_write_reg().
Fix by clamping negative values to zero, clamping positive values to
the rounded hardware-representable maximum (the value returned by the
read path for a full-scale register) to prevent intermediate overflow,
and clamping the converted register value to the hardware field width
before writing. The existing conversion formula and rounding behavior
are preserved.
In the power write path, cancel the factor of 1000 from both the
numerator (r_sense_uohm * 1000) and the denominator
(VADC_UV_LSB * IADC_NANOV_LSB) to also eliminate a u32 overflow of
r_sense_uohm * 1000 when r_sense_uohm exceeds about 4.29 ohms.
Fixes: b0bd407e94 ("hwmon: (ltc2992) Add support")
Cc: stable@vger.kernel.org
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Link: https://lore.kernel.org/r/20260416215904.101969-2-sanman.pradhan@hpe.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The PAI crypto counter design allows for user space and kernel space
PAI counter increment recording. This is achieved by splitting the
recording page in half. The upper part of the 4KB page records user
space increments of PAI crypto counter and the lower half records
kernel space increments. The page itself looks like:
lowcore ptr ---> ++++++++++++++++++++++++
|user space area |
+----------------------+
|kernel space area |
++++++++++++++++++++++++
User space and kernel space entries are handled via a kernel_offset
value when wrting. For PAI crypto counters this offset is 2048 or
half of a page size.
For PAI NNPA counter design this distinction was not needed. There is
no user and kernel space part for the page pointed to by lowcore.
The set up is:
lowcore ptr ---> ++++++++++++++++++++++++
|user + kernel space |
|area |
| |
++++++++++++++++++++++++
There is always only one counter value recorded and saved.
Depending on number of CPUs and machine load, the number of PAI NNPA
counter increment differs between counting (perf stat) and recording
(perf record). The number reported by sampling was double the number
shown by counting.
This was caused by a double read of the PAI NNPA values in function
pai_copy(). The first part of that function reads the kernel space part.
The offset into the kernel page part must be larger than zero.
The second part of that function reads the user space part, which
begins of offset zero. This works fine for PAI crypto counters.
It fails for PAI NNPA counters because the PMU device driver does
not support that feature and has a kernel_offset value of 0x0.
Executing both user and kernel space read out might end up reading
user space value twice.
For the PAI NNPA PMU prohibit the kernel space part read out.
Cc: stable@vger.kernel.org
Fixes: f124735413 ("s390/pai_crypto: Rename paicrypt_copy() to pai_copy()")
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Prepare pci-ep-msi for non-MSI doorbell backends.
Factor MSI doorbell allocation into a helper and extend struct
pci_epf_doorbell_msg with:
- irq_flags: required IRQ request flags (e.g. IRQF_SHARED for some
backends)
- type: doorbell backend type
- bar/offset: pre-exposed doorbell target location, if any
Initialize these fields for the existing MSI-backed doorbell
implementation.
Also add PCI_EPF_DOORBELL_EMBEDDED type, which is to be implemented in a
follow-up patch.
No functional changes.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260414141514.1341429-5-den@valinux.co.jp
Implement the EPC aux-resource API for DesignWare endpoint controllers
with integrated eDMA.
Currently, only report an interrupt-emulation doorbell register
(PCI_EPC_AUX_DOORBELL_MMIO), including its Linux IRQ and the write data
needed to trigger the interrupt.
If the DMA controller MMIO window is already exposed via a
platform-owned fixed BAR subregion, also provide the BAR number and
offset so EPF drivers can reuse it without reprogramming the BAR.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260414141514.1341429-4-den@valinux.co.jp
Some DesignWare PCIe controllers integrate an eDMA block whose registers
are located in a dedicated register window.
The EP-side aux-resource code exposes an interrupt-emulation doorbell
register (DOORBELL_MMIO) from that window. Its location is derived from
the start of the eDMA register window plus the doorbell offset already
provided by dw-edma, and the window size is used to validate the
computed register location.
Record the physical base and size of the integrated eDMA register window
in struct dw_pcie so the EP-side DesignWare aux-resource provider can
construct that doorbell resource.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260414141514.1341429-3-den@valinux.co.jp
Endpoint controller drivers may integrate auxiliary blocks (e.g. DMA
engines) whose register windows and descriptor memories metadata need to
be exposed to a remote peer. Endpoint function drivers need a generic
way to discover such resources without hard-coding controller-specific
helpers.
Add pci_epc_get_aux_resources_count() / pci_epc_get_aux_resources() and
the corresponding pci_epc_ops callbacks. The count helper returns the
number of available resources, while the get helper fills a
caller-provided array of resources described by type, physical address
and size, plus type-specific metadata.
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Suggested-by: Frank Li <Frank.li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260414141514.1341429-2-den@valinux.co.jp
Add an MMU_AS_CONTROL local iomem pointer to struct panthor_mmu and
switch AS register accesses to that base.
Interrupt accesses remain routed through the IRQ-local iomem base, while
the MMU register definitions are adjusted so AS registers are expressed
relative to the local MMU AS window. This completes the conversion away
from using the global device mapping for MMU AS register accesses.
No functional change intended.
v3:
- Pick up R-bs from Liviu and Steve
v2:
- Pick up Ack from Boris.
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Karunika Choo <karunika.choo@arm.com>
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260427155934.416502-9-karunika.choo@arm.com
Add an MCU_CONTROL-local iomem pointer to struct panthor_fw and use it
for firmware control and status register accesses.
Job interrupt accesses continue to go through the IRQ-local base, while
doorbell writes stay on the device-wide mapping because they live
outside the MCU control window. This keeps firmware register accesses
scoped to the component that owns them.
No functional change intended.
v3:
- Pick up R-bs from Liviu and Steve
v2:
- Pick up Ack from Boris.
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Karunika Choo <karunika.choo@arm.com>
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260427155934.416502-8-karunika.choo@arm.com
Add a PWR_CONTROL-local iomem pointer to struct panthor_pwr and switch
power controller register accesses to that base.
Update IRQ-local iomem base to use PWR_CONTROl-local iomem and update
the register definitions so the PWR block can be addressed relative to
its local base. This removes the remaining dependence on the global
device MMIO mapping for PWR register accesses. Update
panthor_gpu_info_init() to also use the correct PWR_CONTROL iomem for
the *_PRESENT registers.
No functional change intended.
v3:
- Clean up definitions for pwr->iomem and pwr->irq.iomem.
- Update PWR_INT_BASE to be relative to pwr->iomem.
v2:
- Update panthor_gpu_info_init() to use block-local iomem pointer.
Signed-off-by: Karunika Choo <karunika.choo@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260427155934.416502-7-karunika.choo@arm.com
Add a GPU_CONTROL-local iomem pointer to struct panthor_gpu and use it
for GPU register accesses.
This limits GPU register accesses to the GPU block instead of using the
device-wide MMIO mapping directly. Interrupt register accesses continue
to use the IRQ-local base provided by the common IRQ helpers. Update
panthor_gpu_info_init() to also use a local iomem offset for GPU
features and capability.
This is a refactoring only and does not change behaviour.
v3:
- Pick up R-bs from Liviu and Steve
v2:
- Update panthor_gpu_info_init() to use block-local iomem pointer.
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Karunika Choo <karunika.choo@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260427155934.416502-6-karunika.choo@arm.com
Update common IRQ handling code to work from an IRQ-local iomem base
instead of referencing block-specific interrupt register offsets.
Store the interrupt base address iomem pointer in struct panthor_irq and
switch the shared IRQ helpers to use generic INT_* offsets from that
local base. This removes the need for each caller to expose absolute IRQ
register addresses while keeping the common IRQ flow unchanged.
No functional change intended.
v3:
- Clean up definition of pwr->irq.iomem.
v2:
- Change IRQ request function to accept an iomem pointer instead of
computing it from an offset argument.
Signed-off-by: Karunika Choo <karunika.choo@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260427155934.416502-5-karunika.choo@arm.com
Stop reaching into other components' registers directly and route those
operations through the component that owns them.
Move the timestamp/coherency helpers into panthor_gpu, add a doorbell
helper, and update call sites accordingly. This keeps register knowledge
local to each block and avoids spreading cross-component register
accesses across the driver.
This is a preparatory cleanup for using per-component iomem bases.
v3:
- Pick up Ack from Boris and R-bs from Liviu and Steve
v2:
- Fix incorrect spelling of timestamp helpers
- Fix unintended trailing backslash
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Karunika Choo <karunika.choo@arm.com>
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/20260427155934.416502-4-karunika.choo@arm.com
