mirror of
https://github.com/torvalds/linux.git
synced 2026-07-31 03:27:03 +02:00
Linux kernel source tree
acc152f9be
When two split-phy devices that support overlapping frequency ranges within the same band are grouped into an ath12k hardware (HW) setup, they share a common wiphy instance. Consequently, the channel list (wiphy->bands[]) becomes unified across all associated radios (ar). For reference, the devices are: 2.4 GHz + 5 GHz Low Band 5 GHz High Band + 6 GHz The first radio probed within the 5 GHz range (say 5 GHz Low Band) updates its sband reference (&ar->mac.sbands[NL80211_BAND_5GHZ]) within wiphy->bands[]. However, when the second 5 GHz radio (5 GHz High Band) is probed, it replaces the existing wiphy->bands[] entry with its own sub-band reference. As a result, wiphy->bands[] always reflects the channel list from the most recently probed radio in that band, restricting supported channels to those within its specific range for upper-layer. Fix this by updating the wiphy->bands[] to just enable the channels of current radio when there exist a radio which already has set it. This will make sure wiphy->bands[] holds reference of first radio which got probed in 5 GHz band and subsequent radio just updates the channel list in the same address space. Since same sband memory space is shared between radios of a band, while determining the allowed frequency range of radio, its frequency limits (ar->freq_range.start_freq, end_freq) should be used. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250522111514.3735107-1-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> |
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| rust | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .clippy.toml | ||
| .cocciconfig | ||
| .editorconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .pylintrc | ||
| .rustfmt.toml | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the reStructuredText markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.