* Re: net: wireless: ralink: RT2X00: regression, hostapd do not work anymore on 6.18.33 (work on 6.18.26)
From: Stanislaw Gruszka @ 2026-06-01 16:17 UTC (permalink / raw)
To: Corentin Labbe; +Cc: linux-wireless, linux-kernel
In-Reply-To: <ahxBexU0n_yb__EV@Red>
Hi,
On Sun, May 31, 2026 at 04:11:07PM +0200, Corentin Labbe wrote:
> Hello
>
> I have an hostapd setup with a
> 01:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe
>
> The setup work fine on 6.18.26-gentoo
> It breaks on 6.18.33-gentoo
>
> I found an hint in dmesg:
> On 6.18.26-gentoo I see:
> May 31 15:48:45 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0003 detected
>
> On 6.18.33-gentoo I see:
> May 31 15:22:57 trash01 kernel: ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0006 detected
>
> The RF chipset seems badly detected.
I do not see any rt2x00 related changes between upstream v6.18.26
and v6.18.33. Assuming gentoo does not provide own extra patches,
seems the issue be in some other subsystem, maybe PCI.
Then the best way get solution to the problem would be to find
offensive commit using git bisection:
https://docs.kernel.org/admin-guide/bug-bisect.html
You can also try if by a chance bug is not yet fixed in just
released v6.18.34
Regards
Stanislaw
^ permalink raw reply
* net-next 32-bit clang build error in net/netfilter/nf_synproxy_core.o
From: Jeff Johnson @ 2026-06-01 16:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <178001352190.1565998.2039430206651171575.git-patchwork-notify@kernel.org>
On 5/28/2026 5:12 PM, patchwork-bot+netdevbpf@kernel.org wrote:
> Hello:
>
> This pull request was applied to netdev/net-next.git (main)
> by Jakub Kicinski <kuba@kernel.org>:
>
> On Thu, 28 May 2026 14:37:26 +0200 you wrote:
>> Hi,
>>
>> Here's a new set of changes, mostly ath and iwlwifi
>> drivers this time.
>>
>> I have a few more things pending, and I expect a few
>> more drivers will have pull requests later too.
>>
>> [...]
>
> Here is the summary with links:
> - [GIT,PULL] wireless-next-2026-05-28
> https://git.kernel.org/netdev/net-next/c/e7d6bd24e883
>
> You are awesome, thank you!
wireless-next/main has fast-forwarded to e7d6bd24e883 and I'm in the process
of also fast-forwarding ath/ath-next, but I'm seeing a build failure:
In file included from ../net/netfilter/nf_synproxy_core.c:7:
In file included from ../include/linux/skbuff.h:26:
In file included from ../include/net/checksum.h:21:
In file included from ../arch/x86/include/asm/checksum.h:9:
../arch/x86/include/asm/checksum_32.h:149:6: error: inline assembly requires more registers than available
149 | asm("addl 0(%1), %0 ;\n"
| ^
1 error generated.
make[5]: *** [../scripts/Makefile.build:289: net/netfilter/nf_synproxy_core.o] Error 1
This is with "ARCH=i386 LLVM=llvm-19.1.7-x86_64/bin/"
I use a config made via: make $allmodconfig
A lore search doesn't show any recent instances of this issue.
Rebuilding from scratch shows the same issue.
Any thoughts?
^ permalink raw reply
* Re: [PATCH ath-next 0/2] wifi: ath11k: dp rx sanity checks for invalid length in error paths
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: jjohnson, Miaoqing Pan; +Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <20260512022351.2033155-1-miaoqing.pan@oss.qualcomm.com>
On Tue, 12 May 2026 10:23:49 +0800, Miaoqing Pan wrote:
> This patch series adds two defensive sanity checks in ath11k DP RX
> handling to prevent invalid memory access when hardware/descriptor
> contents are unexpected, especially in WBM error scenarios.
>
>
Applied, thanks!
[1/2] wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
commit: 6b471e9aefee9ed73278eb1141e0d8530a56fae9
[2/2] wifi: ath11k: add MSDU length validation for TKIP MIC error
commit: 4d8af936b4fe377f3d7700540f301d8e45e8759b
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCHv3 ath-next] wifi: ath11k: use kzalloc_flex
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: linux-wireless, Rosen Penev
Cc: Jeff Johnson, Kees Cook, Gustavo A. R. Silva, ath11k,
linux-kernel, linux-hardening
In-Reply-To: <20260428205017.26288-1-rosenp@gmail.com>
On Tue, 28 Apr 2026 13:50:17 -0700, 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.
>
>
> [...]
Applied, thanks!
[1/1] wifi: ath11k: use kzalloc_flex
commit: c7427f297ddb01f593217c21b2416f1093b80194
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath11k: raise max vdevs to 4 on hardware with P2P and dual-station support
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: Wei Zhang; +Cc: ath11k, linux-wireless, linux-kernel
In-Reply-To: <20260525020711.2590815-1-wei.zhang@oss.qualcomm.com>
On Sun, 24 May 2026 19:07:11 -0700, Wei Zhang wrote:
> When P2P support is enabled, wpa_supplicant creates a p2p-device
> interface by default, which implicitly consumes one vdev. On systems
> managed by NetworkManager, this interface cannot be reliably disabled,
> leaving only two usable interfaces for user configurations.
>
> Increase num_vdevs to four for QCA6390 hw2.0, WCN6855 hw2.0/hw2.1,
> QCA2066 hw2.1, and QCA6698AQ hw2.1 to account for the implicit
> p2p-device and enable common concurrency scenarios such as AP + AP + STA.
>
> [...]
Applied, thanks!
[1/1] wifi: ath11k: raise max vdevs to 4 on hardware with P2P and dual-station support
commit: 209887467581116a93490e6122b87b6fe0787627
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3] wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: ath12k, linux-wireless, kwan1996
In-Reply-To: <20260507015336.14636-1-laicheehou9@gmail.com>
On Thu, 07 May 2026 09:53:35 +0800, kwan1996 wrote:
> In monitor mode, the driver incorrectly assigns the legacy rate
> to the rate_idx field of the radiotap header for HT/VHT/HE/EHT
> frames, ignoring the actual MCS value parsed from the hardware.
>
> This causes packet analyzers (like Wireshark) to display incorrect
> MCS values (e.g., legacy base rates instead of the true MCS).
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: fix incorrect HT/VHT/HE/EHT MCS reporting in monitor mode
commit: 10085a654a4c2331d5f0cdc20bfc839a49fbb886
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: jjohnson, Miaoqing Pan; +Cc: ath12k, linux-wireless, linux-kernel
In-Reply-To: <20260512021108.2031651-1-miaoqing.pan@oss.qualcomm.com>
On Tue, 12 May 2026 10:11:08 +0800, Miaoqing Pan wrote:
> In ath12k_wifi7_dp_rx_h_verify_tkip_mic(), the call to
> ath12k_dp_rx_check_nwifi_hdr_len_valid() may return false when the
> NWIFI header length is invalid, causing the function to abort early with
> -EINVAL.
>
> When this happens, the error propagates to
> ath12k_wifi7_dp_rx_h_defrag(), which clears first_frag by setting it
> to NULL. As a result, the corresponding MSDU is no longer referenced
> by the defragmentation path and is never freed.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()
commit: 98d4f92ab6a1af2ea2ab590d7e2801b203110981
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/2] wifi: ath12k: fix NULL deref when MLO link activation fails
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: Wei Zhang; +Cc: ath12k, linux-wireless, linux-kernel
In-Reply-To: <20260512044906.1735821-1-wei.zhang@oss.qualcomm.com>
On Mon, 11 May 2026 21:49:03 -0700, Wei Zhang wrote:
> ath12k_mac_op_change_sta_links() adds a link to ahsta->links_map
> before verifying that the link's vdev is ready, allowing broken links
> to be processed by subsequent operations and causing NULL dereferences.
>
> Patch 1 fixes three error path inconsistencies in ath12k_mac_vdev_create()
> that leave arvif state or vdev resources inconsistent: a direct return on
> wmi_vdev_create failure bypasses err: which clears arvif->ar; and both
> failure paths in err_peer_del skip the DP peer cleanup and vdev rollback.
>
> [...]
Applied, thanks!
[1/2] wifi: ath12k: fix inconsistent arvif state in vdev_create error paths
commit: c972636efc63f0f43d725b59805dd1ae5bc4b31e
[2/2] wifi: ath12k: fix NULL deref in change_sta_links for unready link
commit: 47809a7c8348bc4a332ccc26a37c7145a5f609f8
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: add hardware parameters for maximum supported clients
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: ath12k, Aaradhana Sahu; +Cc: linux-wireless
In-Reply-To: <20260515030909.3312511-1-aaradhana.sahu@oss.qualcomm.com>
On Fri, 15 May 2026 08:39:09 +0530, Aaradhana Sahu wrote:
> Currently, the driver uses memory profile parameters to determine the
> maximum number of supported clients, with a default limit of 512 for
> single-radio and 128 for DBS and DBS+SBS configurations. However,
> some devices have lower hardware limits depending on the radio
> configuration. Exceeding these hardware-specific limits can lead to
> firmware crashes.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: add hardware parameters for maximum supported clients
commit: 05337d0b9c5a7ab3b60473490705ebe90d5316aa
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: Prevent incorrect vif chanctx switch when handling multi-radio contexts
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: ath12k, Maharaja Kennadyrajan; +Cc: linux-wireless, Aditya Kumar Singh
In-Reply-To: <20260522091828.3199584-1-maharaja.kennadyrajan@oss.qualcomm.com>
On Fri, 22 May 2026 14:48:28 +0530, Maharaja Kennadyrajan wrote:
> When multiple links switch channel contexts around the same time, mac80211
> may complete CSA for several links together and invoke
> ath12k_mac_op_switch_vif_chanctx() with an array of vifs spanning more than
> one underlying radio in a single-wiphy configuration.
>
> The driver currently assumes that all entries in the vifs array belong to the
> same radio and derives the radio context from the first element. On multi-radio
> hardware, this can lead to incorrect vdev selection/updates and may corrupt
> driver state when the number of vifs exceeds what a single radio supports.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Prevent incorrect vif chanctx switch when handling multi-radio contexts
commit: 675aa75bfc29fb18c6e4d58904a91c1d37228217
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/6] wifi: ath12k: Add driver support for WDS mode
From: Jeff Johnson @ 2026-06-01 17:00 UTC (permalink / raw)
To: ath12k, Tamizh Chelvam Raja; +Cc: linux-wireless
In-Reply-To: <20260525110942.2890212-1-tamizh.raja@oss.qualcomm.com>
On Mon, 25 May 2026 16:39:36 +0530, Tamizh Chelvam Raja wrote:
> This patch series introduces support for WDS in the driver by adding
> below changes
>
> Handling of 4-address frame formats required for WDS operation.
> Proper setting of peer 4-address WMI param to ensure correct transmission
> and reception of multicast and unicast frames in WDS mode.
> Conversion of eth offload Rx frame to 802.11 frame for mac80211 to
> detect 4address frame and initiate AP_VLAN creation.
>
> [...]
Applied, thanks!
[1/6] wifi: ath12k: Set WDS vdev parameter for 4-address station interface
commit: e1125b0ab6fdda21dde19f7be631a477d14b684c
[2/6] wifi: ath12k: Add support for 4-address mode
commit: 2f57f737dbf3005951a045eb9d1daaff0095f6c1
[3/6] wifi: ath12k: Add 4-address mode support for eth offload
commit: 729cad3c3c9e09ca9900744fe2a02b25e23cdab5
[4/6] wifi: ath12k: Add support for 4-address NULL frame handling
commit: 6d0572f61539c5d4e2971139e7b501e37b7632d6
[5/6] wifi: ath12k: Add support for 4-address frame notification
commit: f818260ac66b2971a2a587ea08b171b135a2c1e6
[6/6] wifi: ath12k: Handle 4-address EAPOL frames from WBM error path
commit: 565257a857690244211d85593b2cd490ce86783a
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: avoid setting 320MHZ support on non 6GHz band
From: Nicolas Escande @ 2026-06-01 17:08 UTC (permalink / raw)
To: Rameshkumar Sundaram, Nicolas Escande, ath12k; +Cc: linux-wireless
In-Reply-To: <a4ee39fd-f1d6-4b84-832c-c4eb0166476d@oss.qualcomm.com>
On Thu May 28, 2026 at 9:56 AM CEST, Rameshkumar Sundaram wrote:
> On 1/23/2026 8:12 PM, Nicolas Escande wrote:
>> On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
>> realated features on the 5GHz band while it should not:
>>
>> Wiphy phy1
>> [...]
>> Band 2:
>> [...]
>> EHT Iftypes: managed
>> [...]
>> EHT PHY Capabilities: (0xe2ffdbe018778000):
>> 320MHz in 6GHz Supported
>> [...]
>> Beamformee SS (320MHz): 7
>> [...]
>> Number Of Sounding Dimensions (320MHz): 3
>> [...]
>> EHT MCS/NSS: (0x22222222222222222200000000):
>>
>> This is also reflected in the beacons sent by a mesh interface started on
>> that band. They erroneously advertise 320MHZ support too.
>>
>> This should not happen as the spec at section 9.4.2.323.3 says we should
>> not set the 320MHz related fields when not operating on a 6GHz band.
>> For example it says about Bit 0 "Support For 320 MHz In 6 GHz"
>>
>> "Reserved if the EHT Capabilities element is indicating capabilities for
>> the 2.4 GHz or 5 GHz bands."
>>
>> Fix this by clearing the related bits when converting from WMI eht phy
>> capabilities to mac80211 phy capabilities, for bands other than 6GHz.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
>> ---
>> drivers/net/wireless/ath/ath12k/wmi.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
>> index 84c29e4896a4..14947fdb9813 100644
>> --- a/drivers/net/wireless/ath/ath12k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
>> @@ -4888,6 +4888,7 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
>> __le32 cap_info_internal)
>> {
>> struct ath12k_band_cap *cap_band = &pdev->cap.band[band];
>> + u8 *phy_cap = (u8 *)&cap_band->eht_cap_phy_info[0];
>> u32 support_320mhz;
>> u8 i;
>>
>> @@ -4901,8 +4902,14 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
>> for (i = 0; i < WMI_MAX_EHTCAP_PHY_SIZE; i++)
>> cap_band->eht_cap_phy_info[i] = le32_to_cpu(cap_phy_info[i]);
>>
>> - if (band == NL80211_BAND_6GHZ)
>> + if (band == NL80211_BAND_6GHZ) {
>> cap_band->eht_cap_phy_info[0] |= support_320mhz;
>> + } else {
>> + phy_cap[0] &= ~IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
>> + phy_cap[1] &= ~IEEE80211_EHT_PHY_CAP1_BEAMFORMEE_SS_320MHZ_MASK;
>> + phy_cap[2] &= ~IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK;
>
> This field is split across PHY capability byte 2 and byte 3, so should
> IEEE80211_EHT_PHY_CAP3_SOUNDING_DIM_320MHZ_MASK be cleared as well ?
Indeed
>
>
>> + phy_cap[6] &= ~IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ;
>> + }
>>
>> cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
>> cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);
>
>
> Since you said "On a split phy qcn9274 (2.4GHz + 5GHz low)" i wonder how
> firmware set 6GHz capability bits in this case. That said, the approach
I suspect that the firmware sets the same features for mode 'a', regardless of
the actual frequency range supported by the device. I've also seen this on a
5G + 6G split device too.
> looks fine to me, although I would prefer to clear the remaining related
> bits as well:
>
> IEEE80211_EHT_PHY_CAP3_SOUNDING_DIM_320MHZ_MASK
> IEEE80211_EHT_PHY_CAP6_MCS15_SUPP_320MHZ
> IEEE80211_EHT_PHY_CAP6_EHT_DUP_6GHZ_SUPP
> IEEE80211_EHT_PHY_CAP7_NON_OFDMA_UL_MU_MIMO_320MHZ
> IEEE80211_EHT_PHY_CAP7_MU_BEAMFORMER_320MHZ
Yes, I cleared the ones I used in my middleware but I really don't mind
clearing all the 6GHz/320MHz related bits I can find.
Thanks for the review, I'll spin a v2
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add()
From: Roy Luo @ 2026-06-01 18:14 UTC (permalink / raw)
To: lorenzo@kernel.org
Cc: Ryder Lee, Shayne Chen (陳軒丞), nbd@nbd.name,
Roy-CH Luo, Chui-hao Chiu (邱垂浩),
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, Sean Wang,
Bo Jiao (焦波), linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ah0fGek5y8Nha0kd@lore-rh-laptop>
> > I mean the link_id is only corresponds to one specific flags bit of
> > mac80211_tx_control_flags. But there are other bits that aren't
> > handled. Wouldn't u32 flags make it more cleaner?
>
> Yes, I got your point, but my concern is if we need to sync link_id between
> mt7996_tx_prepare_skb() and mt7996_mac_write_txwi(). If so, I guess it is
> much better to pass link_id explicitly to mt7996_mac_write_txwi() since it
> does not just depended on mac80211_tx_control_flags and I think we should
> not duplicate the logic in mt7996_mac_write_txwi(). Got my point?
> If in the future (not required now) we need to pass mac80211_tx_control_flags
> to mt7996_mac_write_txwi(), we will do it easily.
>
> Regards,
> Lorenzo
>
> >
> > Ryder
> >
> >
Lorenzo,
I got your point and IIUC the problem being addressed in this patch is that
the link id assignment has unnecessary duplicated logic across different
places. However, the commit tile "fix reading zeroed info->control.flags"
seems a bit misleading to me - this patch does not fully address the problem
where the info->control.flags is cleared by memset in tx path when its
value might still be referenced, the field is still zeroed after
mt76_tx_status_skb_add() and whoever reads it afterward would get
incorrect value. With this patch, we avoid using the incorrect value for
link id, but the root cause remains.
The issue that Ryder tries to address in
https://lore.kernel.org/all/5ecac6a9b7d29526e8438dea105b58f5487c93aa.1778521232.git.ryder.lee@mediatek.com/
concerns the overlapping use of info->control and info->status in tx path,
and it remains valid even with this link id fix applied. We have to be
cautious when dealing with info->control in mt7996 tx path until the issue
is fully resolved.
Regards,
Roy
^ permalink raw reply
* Re: net-next 32-bit clang build error in net/netfilter/nf_synproxy_core.o
From: Florian Westphal @ 2026-06-01 19:14 UTC (permalink / raw)
To: Jeff Johnson; +Cc: Johannes Berg, netdev, linux-wireless
In-Reply-To: <a28df759-d0e9-41c0-97c7-5f89a18d54e2@oss.qualcomm.com>
Jeff Johnson <jeff.johnson@oss.qualcomm.com> wrote:
> wireless-next/main has fast-forwarded to e7d6bd24e883 and I'm in the process
> of also fast-forwarding ath/ath-next, but I'm seeing a build failure:
>
> In file included from ../net/netfilter/nf_synproxy_core.c:7:
> In file included from ../include/linux/skbuff.h:26:
> In file included from ../include/net/checksum.h:21:
> In file included from ../arch/x86/include/asm/checksum.h:9:
> ../arch/x86/include/asm/checksum_32.h:149:6: error: inline assembly requires more registers than available
> 149 | asm("addl 0(%1), %0 ;\n"
> | ^
> 1 error generated.
> make[5]: *** [../scripts/Makefile.build:289: net/netfilter/nf_synproxy_core.o] Error 1
>
> This is with "ARCH=i386 LLVM=llvm-19.1.7-x86_64/bin/"
>
> I use a config made via: make $allmodconfig
>
> A lore search doesn't show any recent instances of this issue.
>
> Rebuilding from scratch shows the same issue.
>
> Any thoughts?
Happens since 403cec8ab6d0 ("netfilter: add option for GCOV
profiling"). 'allmodconfig' sets CONFIG_GCOV_PROFILE_NETFILTER=y
Same problem after revert or plain 7.0 when I set CONFIG_GCOV_PROFILE_ALL=y
(which depends on !COMPILE_TEST so its off for 'make allmodconfig').
^ permalink raw reply
* [PATCH] wifi: mt76: transform aspm_conf for pci_disable_link_state
From: Jiajia Liu @ 2026-06-02 5:43 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Jiajia Liu
From: Jiajia Liu <liujiajia@kylinos.cn>
commit b478e162f227 ("PCI/ASPM: Consolidate link state defines") changed
PCIE_LINK_STATE_L0S (1) to (BIT(0) | BIT(1)). PCI_EXP_LNKCTL_ASPM_L0S (1)
and PCI_EXP_LNKCTL_ASPM_L1 (2) are no longer matched with
PCIE_LINK_STATE_L0S (3) and PCIE_LINK_STATE_L1 (4).
On the platform enabling ASPM L0s and L1, mt76_pci_disable_aspm is not able
to disable L1. Fix this by transforming aspm_conf to pcie link state.
Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
---
drivers/net/wireless/mediatek/mt76/pci.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/pci.c b/drivers/net/wireless/mediatek/mt76/pci.c
index 833923ab2483..11fe62aa8113 100644
--- a/drivers/net/wireless/mediatek/mt76/pci.c
+++ b/drivers/net/wireless/mediatek/mt76/pci.c
@@ -30,8 +30,14 @@ void mt76_pci_disable_aspm(struct pci_dev *pdev)
if (IS_ENABLED(CONFIG_PCIEASPM)) {
int err;
+ int state = 0;
- err = pci_disable_link_state(pdev, aspm_conf);
+ if (aspm_conf & PCI_EXP_LNKCTL_ASPM_L0S)
+ state |= PCIE_LINK_STATE_L0S;
+ if (aspm_conf & PCI_EXP_LNKCTL_ASPM_L1)
+ state |= PCIE_LINK_STATE_L1;
+
+ err = pci_disable_link_state(pdev, state);
if (!err)
return;
}
--
2.53.0
^ permalink raw reply related
* [PATCH wireless-next] wifi: mac80211: basic S1G rx rate reporting support
From: Lachlan Hodges @ 2026-06-02 6:22 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, arien.judge, Lachlan Hodges
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>
---
include/net/mac80211.h | 1 +
net/mac80211/rx.c | 8 ++++++++
net/mac80211/sta_info.c | 7 +++++++
net/mac80211/sta_info.h | 11 ++++++++++-
4 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4fb579805e0f..7dd558f4025b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1704,6 +1704,7 @@ enum mac80211_rx_encoding {
RX_ENC_HE,
RX_ENC_EHT,
RX_ENC_UHR,
+ RX_ENC_S1G,
};
/**
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index ef6086b183f7..91b4f6cbfce8 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -5621,6 +5621,14 @@ void ieee80211_rx_list(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta,
status->rate_idx, status->nss))
goto drop;
break;
+ case RX_ENC_S1G:
+ if (WARN_ONCE(status->rate_idx > 12 ||
+ !status->nss ||
+ status->nss > 4,
+ "Rate marked as an S1G rate but data is invalid: MCS: %d, NSS: %d\n",
+ status->rate_idx, status->nss))
+ goto drop;
+ break;
default:
WARN_ON_ONCE(1);
fallthrough;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 0ea37016cd4f..9adda77f2679 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2605,6 +2605,13 @@ static void sta_stats_decode_rate(struct ieee80211_local *local, u32 rate,
if (STA_STATS_GET(UHR_IM, rate))
rinfo->flags |= RATE_INFO_FLAGS_UHR_IM;
break;
+ case STA_STATS_RATE_TYPE_S1G:
+ rinfo->flags = RATE_INFO_FLAGS_S1G_MCS;
+ rinfo->mcs = STA_STATS_GET(S1G_MCS, rate);
+ rinfo->nss = STA_STATS_GET(S1G_NSS, rate);
+ if (STA_STATS_GET(SGI, rate))
+ rinfo->flags |= RATE_INFO_FLAGS_SHORT_GI;
+ break;
}
}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 39608a0abbb5..e1837e986837 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -1042,7 +1042,7 @@ enum sta_stats_type {
#define STA_STATS_FIELD_VHT_MCS 0x0000F000
#define STA_STATS_FIELD_VHT_NSS 0x000F0000
-/* HT & VHT */
+/* HT, VHT & S1G */
#define STA_STATS_FIELD_SGI 0x00100000
/* STA_STATS_RATE_TYPE_HE */
@@ -1066,6 +1066,9 @@ enum sta_stats_type {
#define STA_STATS_FIELD_UHR_ELR 0x08000000
#define STA_STATS_FIELD_UHR_IM 0x10000000
+/* STA_STATS_RATE_TYPE_S1G */
+#define STA_STATS_FIELD_S1G_MCS 0x0000F000
+#define STA_STATS_FIELD_S1G_NSS 0x000F0000
#define STA_STATS_FIELD(_n, _v) FIELD_PREP(STA_STATS_FIELD_ ## _n, _v)
#define STA_STATS_GET(_n, _v) FIELD_GET(STA_STATS_FIELD_ ## _n, _v)
@@ -1081,6 +1084,7 @@ static inline u32 sta_stats_encode_rate(struct ieee80211_rx_status *s)
switch (s->encoding) {
case RX_ENC_HT:
case RX_ENC_VHT:
+ case RX_ENC_S1G:
if (s->enc_flags & RX_ENC_FLAG_SHORT_GI)
r |= STA_STATS_FIELD(SGI, 1);
break;
@@ -1127,6 +1131,11 @@ static inline u32 sta_stats_encode_rate(struct ieee80211_rx_status *s)
r |= STA_STATS_FIELD(UHR_ELR, s->uhr.elr);
r |= STA_STATS_FIELD(UHR_IM, s->uhr.im);
break;
+ case RX_ENC_S1G:
+ r |= STA_STATS_FIELD(TYPE, STA_STATS_RATE_TYPE_S1G);
+ r |= STA_STATS_FIELD(S1G_NSS, s->nss);
+ r |= STA_STATS_FIELD(S1G_MCS, s->rate_idx);
+ break;
default:
WARN_ON(1);
return STA_STATS_RATE_INVALID;
--
2.43.0
^ permalink raw reply related
* [PATCH] iw: station: print S1G MCS/NSS values
From: Lachlan Hodges @ 2026-06-02 6:24 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, arien.judge, Lachlan Hodges
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
---
station.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/station.c b/station.c
index 0f992d5b9134..6a143ac22cfb 100644
--- a/station.c
+++ b/station.c
@@ -231,6 +231,9 @@ void parse_bitrate(struct nlattr *bitrate_attr, char *buf, int buflen)
if (rinfo[NL80211_RATE_INFO_VHT_MCS])
pos += snprintf(pos, buflen - (pos - buf),
" VHT-MCS %d", nla_get_u8(rinfo[NL80211_RATE_INFO_VHT_MCS]));
+ if (rinfo[NL80211_RATE_INFO_S1G_MCS])
+ pos += snprintf(pos, buflen - (pos - buf),
+ " S1G-MCS %d", nla_get_u8(rinfo[NL80211_RATE_INFO_S1G_MCS]));
if (rinfo[NL80211_RATE_INFO_40_MHZ_WIDTH])
pos += snprintf(pos, buflen - (pos - buf), " 40MHz");
if (rinfo[NL80211_RATE_INFO_80_MHZ_WIDTH])
@@ -256,6 +259,9 @@ void parse_bitrate(struct nlattr *bitrate_attr, char *buf, int buflen)
if (rinfo[NL80211_RATE_INFO_VHT_NSS])
pos += snprintf(pos, buflen - (pos - buf),
" VHT-NSS %d", nla_get_u8(rinfo[NL80211_RATE_INFO_VHT_NSS]));
+ if (rinfo[NL80211_RATE_INFO_S1G_NSS])
+ pos += snprintf(pos, buflen - (pos - buf),
+ " S1G-NSS %d", nla_get_u8(rinfo[NL80211_RATE_INFO_S1G_NSS]));
if (rinfo[NL80211_RATE_INFO_HE_MCS])
pos += snprintf(pos, buflen - (pos - buf),
" HE-MCS %d", nla_get_u8(rinfo[NL80211_RATE_INFO_HE_MCS]));
--
2.43.0
^ permalink raw reply related
* Re: [PATCH wireless-next] wifi: mac80211: basic S1G rx rate reporting support
From: Lachlan Hodges @ 2026-06-02 6:32 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, arien.judge
In-Reply-To: <20260602062224.1792985-1-lachlan.hodges@morsemicro.com>
On Tue, Jun 02, 2026 at 04:22:24PM +1000, Lachlan Hodges wrote:
> 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):
Johannes, there are obviously some driver changes associated with
this - I'm not sure if you prefer these to be included in the v3
since I have to fix some things anyway or scope v3 just to review/bot
fixes and then send a subsequent pull request once it is in tree. I do
not really mind.
lachlan
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mac80211: basic S1G rx rate reporting support
From: Johannes Berg @ 2026-06-02 6:37 UTC (permalink / raw)
To: Lachlan Hodges; +Cc: linux-wireless, arien.judge
In-Reply-To: <2enlvwdxco5ezmpfosvvp3frreharqiiuspf67veztsmjwfcbd@rk3ej7yh4wow>
On Tue, 2026-06-02 at 16:32 +1000, Lachlan Hodges wrote:
> On Tue, Jun 02, 2026 at 04:22:24PM +1000, Lachlan Hodges wrote:
> > 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):
>
> Johannes, there are obviously some driver changes associated with
> this - I'm not sure if you prefer these to be included in the v3
> since I have to fix some things anyway or scope v3 just to review/bot
> fixes and then send a subsequent pull request once it is in tree. I do
> not really mind.
Unfortunately, given demands on my time, I don't think I'll be able to
merge the driver for 7.2 since that'd have to happen in the next week or
so. I think it's fair to just include them in v3, ideally once this
patch lands, maybe I'll get a chance to restore the build bot too.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mac80211: basic S1G rx rate reporting support
From: Lachlan Hodges @ 2026-06-02 6:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, arien.judge
In-Reply-To: <d6e543046d8b2ba7e681c137a23a55a21f4d19e0.camel@sipsolutions.net>
On Tue, Jun 02, 2026 at 08:37:48AM +0200, Johannes Berg wrote:
> On Tue, 2026-06-02 at 16:32 +1000, Lachlan Hodges wrote:
> > On Tue, Jun 02, 2026 at 04:22:24PM +1000, Lachlan Hodges wrote:
> > > 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):
> >
> > Johannes, there are obviously some driver changes associated with
> > this - I'm not sure if you prefer these to be included in the v3
> > since I have to fix some things anyway or scope v3 just to review/bot
> > fixes and then send a subsequent pull request once it is in tree. I do
> > not really mind.
>
> Unfortunately, given demands on my time, I don't think I'll be able to
> merge the driver for 7.2 since that'd have to happen in the next week or
> so. I think it's fair to just include them in v3, ideally once this
> patch lands, maybe I'll get a chance to restore the build bot too.
That's not a problem at all and sounds good. I know the NXP driver is
also under review on top of everything else... ^.^
lachlan
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add()
From: lorenzo @ 2026-06-02 6:43 UTC (permalink / raw)
To: Roy Luo
Cc: Ryder Lee, Shayne Chen (陳軒丞), nbd@nbd.name,
Roy-CH Luo, Chui-hao Chiu (邱垂浩),
AngeloGioacchino Del Regno, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, Sean Wang,
Bo Jiao (焦波), linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAHoxoj+N3AtJgFD8vGP+uDpj6anKMgPBtZGejLDgAz0ZyisSHg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
On Jun 01, Roy Luo wrote:
> > > I mean the link_id is only corresponds to one specific flags bit of
> > > mac80211_tx_control_flags. But there are other bits that aren't
> > > handled. Wouldn't u32 flags make it more cleaner?
> >
> > Yes, I got your point, but my concern is if we need to sync link_id between
> > mt7996_tx_prepare_skb() and mt7996_mac_write_txwi(). If so, I guess it is
> > much better to pass link_id explicitly to mt7996_mac_write_txwi() since it
> > does not just depended on mac80211_tx_control_flags and I think we should
> > not duplicate the logic in mt7996_mac_write_txwi(). Got my point?
> > If in the future (not required now) we need to pass mac80211_tx_control_flags
> > to mt7996_mac_write_txwi(), we will do it easily.
> >
> > Regards,
> > Lorenzo
> >
> > >
> > > Ryder
> > >
> > >
>
> Lorenzo,
Hi Roy,
>
> I got your point and IIUC the problem being addressed in this patch is that
> the link id assignment has unnecessary duplicated logic across different
> places. However, the commit tile "fix reading zeroed info->control.flags"
> seems a bit misleading to me - this patch does not fully address the problem
> where the info->control.flags is cleared by memset in tx path when its
> value might still be referenced, the field is still zeroed after
> mt76_tx_status_skb_add() and whoever reads it afterward would get
> incorrect value. With this patch, we avoid using the incorrect value for
> link id, but the root cause remains.
This patch is actually fixing both of the issues since now do not have any
leftover access to info->control.flags after running mt76_tx_status_skb_add()
in the mt7996 tx path and it is not required (according to the current mt7996
codebase) to pass the flags cached value to mt7996_mac_write_txwi(). However,
if in the future this will be necessary, I am completely fine with that.
Regards,
Lorenzo
>
> The issue that Ryder tries to address in
> https://lore.kernel.org/all/5ecac6a9b7d29526e8438dea105b58f5487c93aa.1778521232.git.ryder.lee@mediatek.com/
> concerns the overlapping use of info->control and info->status in tx path,
> and it remains valid even with this link id fix applied. We have to be
> cautious when dealing with info->control in mt7996 tx path until the issue
> is fully resolved.
>
> Regards,
> Roy
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] wifi: ath11k: enable support for WCN6851
From: Bartosz Golaszewski @ 2026-06-02 7:53 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
In-Reply-To: <20260601-sm8350-wifi-v1-2-242917d88031@oss.qualcomm.com>
On Mon, 1 Jun 2026 11:46:50 +0200, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> said:
> The WCN6851, found e.g. on SM8350 platforms, is an earlier version of
> WCN6855 platform. It identifies itself as hw1.1. Copy WCN6855 hw 2.0
> configuration to support hw1.1 version.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 3/7] regulator: dt-bindings: qcom,qca6390-pmu: document WCN6851
From: Bartosz Golaszewski @ 2026-06-02 7:54 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
In-Reply-To: <20260601-sm8350-wifi-v1-3-242917d88031@oss.qualcomm.com>
On Mon, 1 Jun 2026 11:46:51 +0200, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> said:
> WCN6851 is an earlier version of WCN6855 WiFi/BT chip, compatible with
> it. Add a device-specific compat string with the fallback to WCN6855
> one.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
> index 105174df7df2..3d3c6fa7ecbc 100644
> --- a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
> +++ b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
> @@ -21,6 +21,10 @@ properties:
> - enum:
> - qcom,wcn6755-pmu
> - const: qcom,wcn6750-pmu
> + - items:
> + - enum:
> + - qcom,wcn6851-pmu
> + - const: qcom,wcn6855-pmu
>
> - enum:
> - qcom,qca6390-pmu
>
> --
> 2.47.3
>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: bluetooth: qcom,wcn6855-bt: document WCN6851
From: Bartosz Golaszewski @ 2026-06-02 7:56 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pci, linux-kernel, linux-wireless, ath11k, devicetree,
Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <20260601-sm8350-wifi-v1-4-242917d88031@oss.qualcomm.com>
On Mon, 1 Jun 2026 11:46:52 +0200, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> said:
> WCN6851 is an earlier version of WCN6855 WiFi/BT chip, compatible with
> it. Add a device-specific compat string with the fallback to WCN6855
> one.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/bluetooth/qcom,wcn6855-bt.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6855-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6855-bt.yaml
> index 0beda26ae8bb..ec766f40a042 100644
> --- a/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6855-bt.yaml
> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6855-bt.yaml
> @@ -13,8 +13,12 @@ maintainers:
>
> properties:
> compatible:
> - enum:
> - - qcom,wcn6855-bt
> + oneOf:
> + - items:
> + - const: qcom,wcn6851-bt
> + - const: qcom,wcn6855-bt
> + - enum:
> + - qcom,wcn6855-bt
>
> enable-gpios:
> maxItems: 1
>
> --
> 2.47.3
>
>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 5/7] arm64: dts: qcom: sm8350: expand UART18 to 4 pins config
From: Bartosz Golaszewski @ 2026-06-02 7:58 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-arm-msm, linux-pci, linux-kernel, linux-wireless, ath11k,
devicetree, Bartosz Golaszewski, linux-bluetooth,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio
In-Reply-To: <20260601-sm8350-wifi-v1-5-242917d88031@oss.qualcomm.com>
On Mon, 1 Jun 2026 11:46:53 +0200, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> said:
> On SM8350 platforms the primary use of UART18 is a 4-pin UART (targeting
> Bluetooth or other similar applications). Add all 4 pins to the default
> pinctrl entry for the UART.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index c830953156ec..eb2a795d8edb 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> @@ -3309,7 +3309,7 @@ qup_uart6_default: qup-uart6-default-state {
> };
>
> qup_uart18_default: qup-uart18-default-state {
> - pins = "gpio68", "gpio69";
> + pins = "gpio68", "gpio69", "gpio70", "gpio71";
> function = "qup18";
> drive-strength = <2>;
> bias-disable;
>
> --
> 2.47.3
>
>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
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