* Re: [PATCH 3/3] wifi: mt76: remove mt76_get_of_data_from_mtd
From: Krzysztof Kozlowski @ 2026-04-28 7:32 UTC (permalink / raw)
To: Rosen Penev
Cc: devicetree, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Johannes Berg, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Thomas Bogendoerfer,
open list:MEDIATEK MT76 WIRELESS LAN DRIVER,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, open list:MIPS
In-Reply-To: <20260427034427.881389-4-rosenp@gmail.com>
On Sun, Apr 26, 2026 at 08:44:27PM -0700, Rosen Penev wrote:
> mt76_get_of_data_from_mtd has been replaced by
> mt76_get_of_data_from_nvmem in all usages.
>
> Remove it to prevent people from using the deprecated
> mediatek,mtd-eeprom binding.
Where did you deprecate it? I cannot find it.
Anyway, as Conor pointed out, this is ABI break and really poorly
explained. Cleanup is not a reason to break ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath11k: cancel SSR work items during PCI shutdown
From: Rameshkumar Sundaram @ 2026-04-28 7:19 UTC (permalink / raw)
To: Wei Zhang, jeff.johnson; +Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
On 4/4/2026 10:00 AM, Wei Zhang wrote:
> 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: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855")
> Fixes: 5edbb148bc57 ("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>
^ permalink raw reply
* Re: [PATCH v2 7/9] wifi: rtw89: switch to using FIELD_GET_SIGNED()
From: Andy Shevchenko @ 2026-04-28 7:10 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Jonathan Cameron,
David Lechner, Johannes Berg, David Laight, Nuno Sá,
Andy Shevchenko, Ping-Ke Shih, Richard Cochran, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexandre Belloni, Yury Norov, Rasmus Villemoes, Hans de Goede,
Linus Walleij, Sakari Ailus, Salah Triki, Achim Gratz,
Ben Collins, x86, linux-kernel, linux-iio, linux-wireless, netdev,
linux-rtc
In-Reply-To: <20260427214127.406067-8-ynorov@nvidia.com>
On Mon, Apr 27, 2026 at 05:41:24PM -0400, Yury Norov wrote:
> Switch from sign_extend32(FIELD_GET()) to the dedicated
> FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
...
> for (i = 0; i < ADDC_T_AVG; i++) {
> tmp = rtw89_phy_read32_mask(rtwdev, R_DBG32_D, MASKDWORD);
> - dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> - dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> + dc_re += FIELD_GET_SIGNED(0xfff000, tmp);
> + dc_im += FIELD_GET_SIGNED(0xfff, tmp);
In the same driver the GENMASK() is being used, why not doing it here while at it?
> }
...
> for (i = 0; i < ADDC_T_AVG; i++) {
> tmp = rtw89_phy_read32_mask(rtwdev, R_DBG32_D, MASKDWORD);
> - dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> - dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> + dc_re += FIELD_GET_SIGNED(0xfff000, tmp);
> + dc_im += FIELD_GET_SIGNED(0xfff, tmp);
> }
Ditto, and it even looks like the same piece repeating twice in different
compilation units of the same driver...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] wireless-regdb: Update regulatory info for Brunei Darussalam (BN) for 2022
From: Chen-Yu Tsai @ 2026-04-28 6:57 UTC (permalink / raw)
To: hfzz7; +Cc: linux-wireless, wireless-regdb
In-Reply-To: <CB87FEAB-DAEC-49D6-83C2-8B8D59025164.1@smtp-inbound1.duck.com>
Hi,
Thank you for the patch and sorry for taking so long to get to it.
On Sat, Oct 25, 2025 at 4:53 PM <hfzz7@duck.com> wrote:
>
> In 2022, Authority for Info-communications Technology Industry of Brunei Darussalam (AITI) updates The Brunei Darussalam Radio Spectrum Plan. [1]
>
> * 2400-2483.5 MHz
> - 200 mW
>
> * 5150-5350 MHz
> - 1000 mW
> (For 5250-5.350 MHz, DFS and TPC are required)
>
> * 5470-5725 MHz
> - 1000 mW
> - DFS
> - TPC
The database nor Linux supports TPC. Here we can follow FCC 15.407 and
limit the power to under 500mW:
Transmit power control (TPC). U-NII devices operating in the
5.25-5.35 GHz band and the 5.47-5.725 GHz band shall employ
a TPC mechanism. The U-NII device is required to have the
capability to operate at least 6 dB below the mean EIRP value
of 30 dBm. A TPC mechanism is not required for systems with
an e.i.r.p. of less than 500 mW.
> * 5725-5850 MHz
> - 4000 mW
>
> Also, add regulatory info for WiGig/60 GHz
> * 57000-66000 MHz
> - 10 W / 10000 mW
This limit is for indoor use only. The remark column says
outdoor use is restricted to maximum EIRP of 25 dBm and maximum
EIRP power spectral density of -2 dBm / MHz
So please add the INDOOR-ONLY flag.
> Note: According to the Telecommunications (Radio-communication) Regulations, 2013 of the Telecommunications Order, 2001 (S 38/2001), "non-localised use" refers to the operations of specified radio-communication equipment or network at a specific frequency or in any specified frequency within the whole of Brunei Darussalam. [2]
Please wrap the commit message to 80 characters per line. This however
doesn't apply to URLs.
Thanks
ChenYu
> [1] https://aiti.gov.bn/media/planjc1p/bd-radio-spectrum-plan-2019.pdf
> [2] https://www.agc.gov.bn/AGC%20Images/LAWS/Gazette_PDF/2013/EN/s086.pdf
>
> Signed-off-by: Hafiz Zafran <hfzz7@duck.com>
> ---
> db.txt | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index 1d17271..8e5cbb5 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -326,11 +326,15 @@ country BM: DFS-FCC
> (5490 - 5730 @ 160), (24), DFS
> (5735 - 5835 @ 80), (30)
>
> -country BN: DFS-JP
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (20), AUTO-BW
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> - (5735 - 5835 @ 80), (20)
> +# https://aiti.gov.bn/media/planjc1p/bd-radio-spectrum-plan-2019.pdf
> +# Section 7.5, Page 244-251
> +country BN: DFS-FCC
> + (2400 - 2483.5 @ 40), (200 mW)
> + (5150 - 5250 @ 80), (1000 mW), AUTO-BW
> + (5250 - 5350 @ 80), (1000 mW), DFS, AUTO-BW
> + (5470 - 5730 @ 160), (1000 mW), DFS
> + (5725 - 5850 @ 80), (4000 mW), AUTO-BW
> + (57000 - 66000 @ 2160), (10000 mW)
>
> country BO: DFS-JP
> (2402 - 2482 @ 40), (20)
> --
> 2.51.1
>
>
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: rt2x00: check for of_get_mac_address error
From: Stanislaw Gruszka @ 2026-04-28 6:50 UTC (permalink / raw)
To: Rosen Penev; +Cc: Johannes Berg, linux-wireless, open list
In-Reply-To: <CAKxU2N_bGO-FBgutLyxLW=E1ZroONnT6FjKBj5hRiB2K6P6KDg@mail.gmail.com>
On Mon, Apr 27, 2026 at 12:29:08PM -0700, Rosen Penev wrote:
> On Mon, Apr 27, 2026 at 3:54 AM Stanislaw Gruszka <stf_xl@wp.pl> wrote:
> >
> > On Mon, Apr 27, 2026 at 12:45:14PM +0200, Johannes Berg wrote:
> > > On Mon, 2026-04-27 at 09:32 +0200, Stanislaw Gruszka wrote:
> > > > On Sun, Apr 26, 2026 at 10:16:52PM -0700, Rosen Penev wrote:
> > > > > is_valid_ether_addr is already a check of of_get_mac_address, in which
> > > > > case it returns an error if false. Just set a random MAC on all errors
> > > > > except for EPROBE_DEFER.
> > > > >
> > > > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > > > Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
> > >
> > > Are you sure? I just randomly checked one caller to see what the
> > > *eeprom_mac_addr would contain, and I see
> > >
> > > mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
> > > rt2x00lib_set_mac_address(rt2x00dev, mac);
> > >
> > > so that case assumes it can get it from EEPROM and override with OF, but
> > > if OF fails then it would still use the EEPROM address as long as it's
> > > valid ...
> >
> > You have right, please drop the patch.
> >
> > BTW, the code should be changed to move getting the address from OF
> > out of _set routine.
> Where should it go?
Never mind, I got confused by "set" word in the rt2x00lib_set_mac_address().
Regards
Stanislaw
^ permalink raw reply
* [PATCH ath-next v2] wifi: ath10k: skip WMI and beacon transmission when device is wedged
From: Kang Yang @ 2026-04-28 6:17 UTC (permalink / raw)
To: ath10k, kang.yang; +Cc: linux-wireless
In ath10k_wmi_cmd_send(), the current code detects ATH10K_STATE_WEDGED
and sets ret to -ESHUTDOWN, but still proceeds to transmit pending
beacons and calls ath10k_wmi_cmd_send_nowait().
This can lead to incorrect behavior, as WMI commands and beacons are
still sent after the device has been marked as wedged, and the original
-ESHUTDOWN return value may be overwritten by the result of the send
path.
The wedged state indicates the hardware is already unreliable, and no
further interaction with firmware is expected or meaningful in this
state.
Fix this by skipping beacon transmission and the WMI send path entirely
once ATH10K_STATE_WEDGED is detected, ensuring consistent return values
and avoiding unnecessary firmware interaction.
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Fixes: c256a94d1b1b ("wifi: ath10k: shutdown driver when hardware is unreliable")
Signed-off-by: Kang Yang <kang.yang@oss.qualcomm.com>
---
v2: remove QUIC copyright.
---
drivers/net/wireless/ath/ath10k/wmi.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 0bdb38edd915..e57588c19c80 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3,7 +3,6 @@
* Copyright (c) 2005-2011 Atheros Communications Inc.
* Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
* Copyright (c) 2018-2019, The Linux Foundation. All rights reserved.
- * Copyright (c) 2021-2024 Qualcomm Innovation Center, Inc. All rights reserved.
* Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
@@ -1947,15 +1946,15 @@ int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id)
ret = -ESHUTDOWN;
ath10k_dbg(ar, ATH10K_DBG_WMI,
"drop wmi command %d, hardware is wedged\n", cmd_id);
- }
- /* try to send pending beacons first. they take priority */
- ath10k_wmi_tx_beacons_nowait(ar);
+ } else {
+ /* try to send pending beacons first. they take priority */
+ ath10k_wmi_tx_beacons_nowait(ar);
- ret = ath10k_wmi_cmd_send_nowait(ar, skb, cmd_id);
-
- if (ret && test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags))
- ret = -ESHUTDOWN;
+ ret = ath10k_wmi_cmd_send_nowait(ar, skb, cmd_id);
+ if (ret && test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags))
+ ret = -ESHUTDOWN;
+ }
(ret != -EAGAIN);
}), 3 * HZ);
base-commit: 34a5329beee86a22a446e27eb37f06caa63479ca
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next] wifi: ath10k: skip WMI and beacon transmission when device is wedged
From: Kang Yang @ 2026-04-28 5:58 UTC (permalink / raw)
To: ath10k, kang.yang; +Cc: linux-wireless
In ath10k_wmi_cmd_send(), the current code detects ATH10K_STATE_WEDGED
and sets ret to -ESHUTDOWN, but still proceeds to transmit pending
beacons and calls ath10k_wmi_cmd_send_nowait().
This can lead to incorrect behavior, as WMI commands and beacons are
still sent after the device has been marked as wedged, and the original
-ESHUTDOWN return value may be overwritten by the result of the send
path.
The wedged state indicates the hardware is already unreliable, and no
further interaction with firmware is expected or meaningful in this
state.
Fix this by skipping beacon transmission and the WMI send path entirely
once ATH10K_STATE_WEDGED is detected, ensuring consistent return values
and avoiding unnecessary firmware interaction.
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Fixes: c256a94d1b1b ("wifi: ath10k: shutdown driver when hardware is unreliable")
Signed-off-by: Kang Yang <kang.yang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 0bdb38edd915..ef1cf6664449 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1947,15 +1947,15 @@ int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id)
ret = -ESHUTDOWN;
ath10k_dbg(ar, ATH10K_DBG_WMI,
"drop wmi command %d, hardware is wedged\n", cmd_id);
- }
- /* try to send pending beacons first. they take priority */
- ath10k_wmi_tx_beacons_nowait(ar);
+ } else {
+ /* try to send pending beacons first. they take priority */
+ ath10k_wmi_tx_beacons_nowait(ar);
- ret = ath10k_wmi_cmd_send_nowait(ar, skb, cmd_id);
-
- if (ret && test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags))
- ret = -ESHUTDOWN;
+ ret = ath10k_wmi_cmd_send_nowait(ar, skb, cmd_id);
+ if (ret && test_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags))
+ ret = -ESHUTDOWN;
+ }
(ret != -EAGAIN);
}), 3 * HZ);
base-commit: 34a5329beee86a22a446e27eb37f06caa63479ca
--
2.34.1
^ permalink raw reply related
* Re: [PATCH ath-next] wifi: ath12k: Handle DP_RX_DECAP_TYPE_8023 type in Rx path
From: Rameshkumar Sundaram @ 2026-04-28 5:03 UTC (permalink / raw)
To: Tamizh Chelvam Raja, ath12k; +Cc: linux-wireless
In-Reply-To: <20260418163620.3633959-1-tamizh.raja@oss.qualcomm.com>
On 4/18/2026 10:06 PM, Tamizh Chelvam Raja wrote:
> 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>
^ permalink raw reply
* Re: [PATCH ath 0/2] fix leaks in some WMI error path
From: Baochen Qiang @ 2026-04-28 3:02 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260424144813.1708214-1-nico.escande@gmail.com>
On 4/24/2026 10:48 PM, Nicolas Escande wrote:
> So this is similar work to what has been posted here [0] for ath12k.
>
> When we use the pattern 'return ath11k_wmi_cmd_send(...)' without
> explicitly checking the return value we fail to free the allocated skb.
>
> This has been split into 2 patches per Jeff's guidance to hopefully
> ease the backporting process.
>
> [0] https://lore.kernel.org/linux-wireless/20260422163258.3013872-1-nico.escande@gmail.com/
>
> Nicolas Escande (2):
> wifi: ath11k: fix leak in error path of some WOW related WMI commands
> wifi: ath11k: fix error path leaks in some WMI calls
>
> drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++++++----
> 1 file changed, 112 insertions(+), 19 deletions(-)
>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: initialize RSSI dBm conversion event state
From: Baochen Qiang @ 2026-04-28 2:54 UTC (permalink / raw)
To: Rameshkumar Sundaram, ath12k; +Cc: linux-wireless
In-Reply-To: <20260427103011.2983269-1-rameshkumar.sundaram@oss.qualcomm.com>
On 4/27/2026 6:30 PM, Rameshkumar Sundaram wrote:
> Currently, the RSSI dBm conversion event handler leaves struct
> ath12k_wmi_rssi_dbm_conv_info_arg uninitialized on the stack before
> calling the TLV parser. If one of the optional sub-TLVs is absent, the
> corresponding *_present flag retains stack garbage and later gets read
> in ath12k_wmi_update_rssi_offsets(). With UBSAN enabled this triggers an
> invalid-load report for _Bool:
>
> UBSAN: invalid-load in drivers/net/wireless/ath/ath12k/wmi.c:9682:15
> load of value 9 is not a valid value for type '_Bool'
> Call Trace:
> ath12k_wmi_rssi_dbm_conversion_params_info_event.cold+0x72/0x85 [ath12k]
> ath12k_wmi_op_rx+0x1871/0x2ab0 [ath12k]
> ath12k_htc_rx_completion_handler+0x44b/0x810 [ath12k]
> ath12k_ce_recv_process_cb+0x554/0x9f0 [ath12k]
> ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k]
> ath12k_pci_ce_workqueue+0x69/0x120 [ath12k]
>
> Initialize the parsed event state to zero before passing it to the TLV
> parser so missing sub-TLVs correctly leave the presence flags false.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
>
> Fixes: 0314ee81a91d ("wifi: ath12k: handle WMI event for real noise floor calculation")
> Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath 0/2] fix leaks in some WMI error path
From: Baochen Qiang @ 2026-04-28 2:53 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260424144813.1708214-1-nico.escande@gmail.com>
On 4/24/2026 10:48 PM, Nicolas Escande wrote:
> So this is similar work to what has been posted here [0] for ath12k.
>
> When we use the pattern 'return ath11k_wmi_cmd_send(...)' without
> explicitly checking the return value we fail to free the allocated skb.
>
> This has been split into 2 patches per Jeff's guidance to hopefully
> ease the backporting process.
>
> [0] https://lore.kernel.org/linux-wireless/20260422163258.3013872-1-nico.escande@gmail.com/
>
> Nicolas Escande (2):
> wifi: ath11k: fix leak in error path of some WOW related WMI commands
> wifi: ath11k: fix error path leaks in some WMI calls
these are ath11k changes and you are sending them to ath12k list.
>
> drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++++++----
> 1 file changed, 112 insertions(+), 19 deletions(-)
>
^ permalink raw reply
* Re: [PATCH ath] wifi: ath12k: fix leak in some ath12k_wmi_xxx() functions
From: Baochen Qiang @ 2026-04-28 2:51 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260422163258.3013872-1-nico.escande@gmail.com>
On 4/23/2026 12:32 AM, Nicolas Escande wrote:
> Some wmi functions were using plain 'return ath12k_wmi_cmd_send(...)'
> without explicitly handling the error code. This leads to leaking the skb
> in case of error.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
>
> Fixes: 66a9448b1b89 ("wifi: ath12k: implement hardware data filter")
> Fixes: 593174170919 ("wifi: ath12k: implement WoW enable and wakeup commands")
> Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities")
> Fixes: 16f474d6d49d ("wifi: ath12k: add WoW net-detect functionality")
> Fixes: 1666108c74c4 ("wifi: ath12k: support ARP and NS offload")
> Fixes: aab4ae566fa1 ("wifi: ath12k: support GTK rekey offload")
> Fixes: 7af01e569529 ("wifi: ath12k: handle keepalive during WoWLAN suspend and resume")
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: unify error handling in some ath12k_wmi_xxx() functions
From: Baochen Qiang @ 2026-04-28 2:42 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <20260422163208.3013496-1-nico.escande@gmail.com>
On 4/23/2026 12:32 AM, Nicolas Escande wrote:
> 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>
^ permalink raw reply
* Re: [PATCHv2 ath-next] wifi: ath11k: use kzalloc_flex
From: Baochen Qiang @ 2026-04-28 2:37 UTC (permalink / raw)
To: Rosen Penev, linux-wireless
Cc: Jeff Johnson, Kees Cook, Gustavo A. R. Silva,
open list:QUALCOMM ATHEROS ATH11K WIRELESS DRIVER, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260421231205.77361-1-rosenp@gmail.com>
On 4/22/2026 7:12 AM, Rosen Penev wrote:
> 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>
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix warning when unbinding
From: Baochen Qiang @ 2026-04-28 2:28 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, jjohnson
Cc: linux-wireless, ath11k, linux-kernel, stable
In-Reply-To: <20260420110130.509670-1-jtornosm@redhat.com>
On 4/20/2026 7:01 PM, Jose Ignacio Tornos Martinez wrote:
> If there is an error during some initialization related to firmware,
> the buffers dp->tx_ring[i].tx_status are released.
> However this is released again when the device is unbinded (ath11k_pci),
> and we get:
> WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
> Call Trace:
> free_large_kmalloc
> ath11k_dp_free
> ath11k_core_deinit
> ath11k_pci_remove
> ...
>
> The issue is always reproducible from a VM because the MSI addressing
> initialization is failing.
MSI initialization runs at probe time but I don't see an error path doing
dp->tx_ring[i].tx_status release. So can you help elaborate? what is the call path when
the dp->tx_ring[i].tx_status is first released?
>
> In order to fix the issue, just set the buffers to NULL after releasing in
> order to avoid the double free.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> drivers/net/wireless/ath/ath11k/dp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/ath/ath11k/dp.c b/drivers/net/wireless/ath/ath11k/dp.c
> index bbb86f165141..5a50b623bd07 100644
> --- a/drivers/net/wireless/ath/ath11k/dp.c
> +++ b/drivers/net/wireless/ath/ath11k/dp.c
> @@ -1040,6 +1040,7 @@ void ath11k_dp_free(struct ath11k_base *ab)
> idr_destroy(&dp->tx_ring[i].txbuf_idr);
> spin_unlock_bh(&dp->tx_ring[i].tx_idr_lock);
> kfree(dp->tx_ring[i].tx_status);
> + dp->tx_ring[i].tx_status = NULL;
> }
>
> /* Deinit any SOC level resource */
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Handle DP_RX_DECAP_TYPE_8023 type in Rx path
From: Baochen Qiang @ 2026-04-28 2:16 UTC (permalink / raw)
To: Tamizh Chelvam Raja, ath12k; +Cc: linux-wireless
In-Reply-To: <20260418163620.3633959-1-tamizh.raja@oss.qualcomm.com>
On 4/19/2026 12:36 AM, Tamizh Chelvam Raja wrote:
> 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: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath11k: cancel SSR work items during PCI shutdown
From: Baochen Qiang @ 2026-04-28 2:05 UTC (permalink / raw)
To: Wei Zhang, jeff.johnson; +Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <20260404043050.3433754-1-wei.zhang@oss.qualcomm.com>
On 4/4/2026 12:30 PM, Wei Zhang wrote:
> 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: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855")
> Fixes: 5edbb148bc57 ("wifi: ath11k: Add firmware coredump collection support")
> Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] NFC: trf7970a: Ignore antenna noise when checking for RF field
From: patchwork-bot+netdevbpf @ 2026-04-28 1:10 UTC (permalink / raw)
To: Paul Geurts
Cc: mgreer, sameo, linux-wireless, netdev, linux-kernel,
martijn.de.gouw
In-Reply-To: <20260422100930.581237-1-paul.geurts@prodrive-technologies.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 22 Apr 2026 12:09:30 +0200 you wrote:
> The main channel Received Signal Strength Indicator (RSSI) measurement
> is used to determine whether an RF field is present or not. RSSI != 0
> is interpreted as an RF Field is present. This does not take RF noise
> and measurement inaccuracy into account, and results in false positives
> in the field.
>
> Define a noise level and make sure the RF field is only interpreted as
> present when the RSSI is above the noise level.
>
> [...]
Here is the summary with links:
- NFC: trf7970a: Ignore antenna noise when checking for RF field
https://git.kernel.org/netdev/net/c/a9bc28aa4e64
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC PATCH v1 7/9] x86: Add unsafe_copy_from_user()
From: Yury Norov @ 2026-04-27 22:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christophe Leroy (CS GROUP), Andrew Morton, David Laight,
Thomas Gleixner, linux-alpha, Yury Norov, linux-kernel,
linux-snps-arc, linux-arm-kernel, linux-mips, linuxppc-dev, kvm,
linux-riscv, linux-s390, sparclinux, linux-um, dmaengine,
linux-efi, linux-fsi, amd-gfx, dri-devel, intel-gfx, linux-wpan,
netdev, linux-wireless, linux-spi, linux-media, linux-staging,
linux-serial, linux-usb, xen-devel, linux-fsdevel, ocfs2-devel,
bpf, kasan-dev, linux-mm, linux-x25, rust-for-linux, linux-sound,
sound-open-firmware, linux-csky, linux-hexagon, loongarch,
linux-m68k, linux-openrisc, linux-parisc, linux-sh, linux-arch
In-Reply-To: <CAHk-=wgPrLy0FR3sEWBYQuNAac1axDASYMnTuPuxEU0WytzL7w@mail.gmail.com>
On Mon, Apr 27, 2026 at 02:52:05PM -0700, Linus Torvalds wrote:
> On Mon, 27 Apr 2026 at 12:19, Yury Norov <ynorov@nvidia.com> wrote:
> >
> > This is what Linus said when added x86 implementation for copy_from_user()
> > in c512c69187197:
>
> Note that some things have happily changed in the six+ years since...
>
> > That's partly because we have no current users of it, but also partly
> > because the copy_from_user() case is slightly different and cannot
> > efficiently be implemented in terms of a unsafe_get_user() loop (because
> > gcc can't do asm goto with outputs).
>
> now everybody can do asm goto with outputs.
>
> Yes, it's disabled on older versions, so it's not *always* available,
> but all modern versions do it. And if you care about performance, you
> won't be using an old compiler.
The minimal GCC version is 8.1, and asm goto with outputs is supported
since GCC-11. That would brake the build, if we just switch to using it
without "CC_IS_GCC && (GCC_VERSION >= 110100)" guard.
Is it worth to maintain 2 version of the function? I don't know...
Thanks,
Yury
^ permalink raw reply
* Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: LB F @ 2026-04-27 22:25 UTC (permalink / raw)
To: Bitterblue Smith
Cc: Ping-Ke Shih, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqSAr9kgFQw5=fht1N4Tn3JEZwro8f+JveDGMU3VVYNvzg@mail.gmail.com>
Hi Bitterblue,
While looking through the driver code and my recent logs, I tried to
do a bit of amateur analysis. I noticed a small detail in the RX
validation path that I wanted to share, just as some food for thought
for the future.
In `rx.c:rtw_rx_query_rx_desc()`, if `pkt_stat->phy_status` is set,
the code calls `rtwdev->chip->ops->query_phy_status(...)` (which maps
to `rtw8821c.c:query_phy_status()` for my chip).
I saw that if the PHY status page is invalid (like the page 10 in my
previous log at 02:59), `query_phy_status()` prints the "unused phy
status page" warning and returns early. However, because it returns
`void`, it seems the caller (`rtw_rx_query_rx_desc`) just continues,
calls `rtw_rx_fill_rx_status`, and returns `0` (success).
To my untrained eye, it looks like this allows a frame with an invalid
PHY status page to still get passed up to mac80211.
I was wondering if it might make sense in the future to change the
`query_phy_status` callback to return an `int` (like `-EINVAL`), so
`rtw_rx_query_rx_desc` could drop these malformed frames before they
reach mac80211.
Of course, I might be completely misunderstanding the architecture
here! I also realize this would mean touching the `ops` struct for all
chipsets, which is a big change. Please treat this just as a humble
observation from a user. I leave it entirely to professionals like you
and Ping-Ke Shih to decide if something like this is actually needed
or correct.
As I mentioned before, the current patches are already doing a
fantastic job preventing the system freezes, and the laptop works
great.
Best regards,
Oleksandr Havrylov
^ permalink raw reply
* Re: [RFC PATCH v1 7/9] x86: Add unsafe_copy_from_user()
From: Linus Torvalds @ 2026-04-27 21:52 UTC (permalink / raw)
To: Yury Norov
Cc: Christophe Leroy (CS GROUP), Andrew Morton, David Laight,
Thomas Gleixner, linux-alpha, Yury Norov, linux-kernel,
linux-snps-arc, linux-arm-kernel, linux-mips, linuxppc-dev, kvm,
linux-riscv, linux-s390, sparclinux, linux-um, dmaengine,
linux-efi, linux-fsi, amd-gfx, dri-devel, intel-gfx, linux-wpan,
netdev, linux-wireless, linux-spi, linux-media, linux-staging,
linux-serial, linux-usb, xen-devel, linux-fsdevel, ocfs2-devel,
bpf, kasan-dev, linux-mm, linux-x25, rust-for-linux, linux-sound,
sound-open-firmware, linux-csky, linux-hexagon, loongarch,
linux-m68k, linux-openrisc, linux-parisc, linux-sh, linux-arch
In-Reply-To: <ae-2yLWSGnfeTvh1@yury>
On Mon, 27 Apr 2026 at 12:19, Yury Norov <ynorov@nvidia.com> wrote:
>
> This is what Linus said when added x86 implementation for copy_from_user()
> in c512c69187197:
Note that some things have happily changed in the six+ years since...
> That's partly because we have no current users of it, but also partly
> because the copy_from_user() case is slightly different and cannot
> efficiently be implemented in terms of a unsafe_get_user() loop (because
> gcc can't do asm goto with outputs).
now everybody can do asm goto with outputs.
Yes, it's disabled on older versions, so it's not *always* available,
but all modern versions do it. And if you care about performance, you
won't be using an old compiler.
Linus
^ permalink raw reply
* Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: LB F @ 2026-04-27 21:48 UTC (permalink / raw)
To: Bitterblue Smith
Cc: Ping-Ke Shih, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4f40d96c-4cd5-4e01-846b-745e346b6744@gmail.com>
> Will you use the Bluetooth headphones again?
Yes, the Bluetooth headphones (Soundcore Q10i) are connected most
of the time. I regularly stream YouTube audio/video through them
during normal use. So BT coexistence was active during all prior
crash events and during the single "unused phy status page" event
I reported earlier (at 02:59).
In today's stress tests I also specifically tested BT coexistence:
I played audio over the BT headphones while simultaneously running
heavy Wi-Fi downloads, power_save toggling, and Wi-Fi scanning.
No anomalies were triggered.
Best regards,
Oleksandr Havrylov
^ permalink raw reply
* Re: [RFC PATCH v1 5/9] uaccess: Switch to copy_{to/from}_user_partial() when relevant
From: Linus Torvalds @ 2026-04-27 21:39 UTC (permalink / raw)
To: David Laight
Cc: Christophe Leroy (CS GROUP), Yury Norov, Andrew Morton,
Thomas Gleixner, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-mips, linuxppc-dev, kvm, linux-riscv,
linux-s390, sparclinux, linux-um, dmaengine, linux-efi, linux-fsi,
amd-gfx, dri-devel, intel-gfx, linux-wpan, netdev, linux-wireless,
linux-spi, linux-media, linux-staging, linux-serial, linux-usb,
xen-devel, linux-fsdevel, ocfs2-devel, bpf, kasan-dev, linux-mm,
linux-x25, rust-for-linux, linux-sound, sound-open-firmware,
linux-csky, linux-hexagon, loongarch, linux-m68k, linux-openrisc,
linux-parisc, linux-sh, linux-arch
In-Reply-To: <20260427222914.1cb2dd3b@pumpkin>
On Mon, 27 Apr 2026 at 14:29, David Laight <david.laight.linux@gmail.com> wrote:
>
> I think there is a slight difference in that the normal copy_to_user()
> will determine the exact offset of the error by retrying with byte copies.
I have this dim memory that we decided that you can't reply on byte
exactness anyway, because not all architectures gave that guarantee
for the user copies.
But that thing came up many years ago, I might mis-remember.
Linus
^ permalink raw reply
* [PATCH v2 9/9] ptp: switch to using FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-27 21:41 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Jonathan Cameron,
David Lechner, Johannes Berg, David Laight, Nuno Sá,
Andy Shevchenko, Ping-Ke Shih, Richard Cochran, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexandre Belloni, Yury Norov, Rasmus Villemoes, Hans de Goede,
Linus Walleij, Sakari Ailus, Salah Triki, Achim Gratz,
Ben Collins, x86, linux-kernel, linux-iio, linux-wireless, netdev,
linux-rtc
Cc: Yury Norov
In-Reply-To: <20260427214127.406067-1-ynorov@nvidia.com>
Switch from sign_extend32(FIELD_GET()) to the dedicated
FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
---
drivers/ptp/ptp_fc3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ptp/ptp_fc3.c b/drivers/ptp/ptp_fc3.c
index 70002500170e..f0e000428a3f 100644
--- a/drivers/ptp/ptp_fc3.c
+++ b/drivers/ptp/ptp_fc3.c
@@ -55,8 +55,8 @@ static s64 tdc_meas2offset(struct idtfc3 *idtfc3, u64 meas_read)
{
s64 coarse, fine;
- fine = sign_extend64(FIELD_GET(FINE_MEAS_MASK, meas_read), 12);
- coarse = sign_extend64(FIELD_GET(COARSE_MEAS_MASK, meas_read), (39 - 13));
+ fine = FIELD_GET_SIGNED(FINE_MEAS_MASK, meas_read);
+ coarse = FIELD_GET_SIGNED(COARSE_MEAS_MASK, meas_read);
fine = div64_s64(fine * NSEC_PER_SEC, idtfc3->tdc_apll_freq * 62LL);
coarse = div64_s64(coarse * NSEC_PER_SEC, idtfc3->time_ref_freq);
--
2.51.0
^ permalink raw reply related
* [PATCH v2 8/9] rtc: rv3032: switch to using FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-27 21:41 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Jonathan Cameron,
David Lechner, Johannes Berg, David Laight, Nuno Sá,
Andy Shevchenko, Ping-Ke Shih, Richard Cochran, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexandre Belloni, Yury Norov, Rasmus Villemoes, Hans de Goede,
Linus Walleij, Sakari Ailus, Salah Triki, Achim Gratz,
Ben Collins, x86, linux-kernel, linux-iio, linux-wireless, netdev,
linux-rtc
Cc: Yury Norov
In-Reply-To: <20260427214127.406067-1-ynorov@nvidia.com>
Switch from sign_extend32(FIELD_GET()) to the dedicated
FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
---
drivers/rtc/rtc-rv3032.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rv3032.c b/drivers/rtc/rtc-rv3032.c
index 6c09da7738e1..6bafdec637ae 100644
--- a/drivers/rtc/rtc-rv3032.c
+++ b/drivers/rtc/rtc-rv3032.c
@@ -376,7 +376,7 @@ static int rv3032_read_offset(struct device *dev, long *offset)
if (ret < 0)
return ret;
- steps = sign_extend32(FIELD_GET(RV3032_OFFSET_MSK, value), 5);
+ steps = FIELD_GET_SIGNED(RV3032_OFFSET_MSK, value);
*offset = DIV_ROUND_CLOSEST(steps * OFFSET_STEP_PPT, 1000);
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox