Re: [PATCH v3] ath10k: improve BDF search fallback strategy
Replying again ...
Thanks for the review Jeff, I have replied below and will address
these comments in next iteration. I will wait for a day more to get
some more reviews and collectively make the change.
On Mon, May 9, 2022 at 10:22 AM Jeff Johnson wrote:
>
> On 5/8/2022 7:26 PM, Abhishek Kumar wrote:
> > Board data files wrapped inside board-2.bin files are
> > identified based on a combination of bus architecture,
> > chip-id, board-id or variants. Here is one such example
> > of a BDF entry in board-2.bin file:
> > bus=snoc,qmi-board-id=67,qmi-chip-id=320,variant=GO_
> > It is possible for few platforms none of the combinations
> > of bus,qmi-board,chip-id or variants match, e.g. if
> > board-id is not programmed and thus reads board-id=0xff,
> > there won't be any matching BDF to be found. In such
> > situations, the wlan will fail to enumerate.
> >
> > Currently, to search for BDF, there are two fallback
> > boardnames creates to search for BDFs in case the full BDF
> > is not found. It is still possible that even the fallback
> > boardnames do not match.
> >
> > As an improvement, search for BDF with full BDF combination
> > and perform the fallback searches by stripping down the last
> > elements until a BDF entry is found or none is found for all
> > possible BDF combinations.e.g.
> > Search for initial BDF first then followed by reduced BDF
> > names as follows:
> > bus=snoc,qmi-board-id=67,qmi-chip-id=320,variant=GO_
> > bus=snoc,qmi-board-id=67,qmi-chip-id=320
> > bus=snoc,qmi-board-id=67
> > bus=snoc
> >
> >
> > Tested-on: WCN3990/hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
> > Signed-off-by: Abhishek Kumar
> > ---
> >
> > Changes in v3:
> > - As discussed, instead of adding support for default BDF in DT, added
> > a method to drop the last elements from full BDF until a BDF is found.
> > - Previous patch was "ath10k: search for default BDF name provided in DT"
> >
> > drivers/net/wireless/ath/ath10k/core.c | 65 +-
> > 1 file changed, 32 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c
> > b/drivers/net/wireless/ath/ath10k/core.c
> > index 688177453b07..ebb0d2a02c28 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -1426,15 +1426,31 @@ static int ath10k_core_search_bd(struct ath10k *ar,
> > return ret;
> > }
> >
> > +static bool ath10k_create_reduced_boardname(struct ath10k *ar, char
> > *boardname)
> > +{
> > + /* Find last BDF element */
> > + char *last_field = strrchr(boardname, ',');
> > +
> > + if (last_field) {
> > + /* Drop the last BDF element */
> > + last_field[0] = '\0';
> > + ath10k_dbg(ar, ATH10K_DBG_BOOT,
> > +"boardname =%s\n", boardname);
>
> nit: strange spacing in the message. i'd expect consistent spacing on
> both side of "=", either one space on both sides or no space on both
> sides. also the use of "=" here is inconsistent with the use of ":" in
> a log later below
Ack, will fix this in the next iteration.
>
>
> > + return 0;
> > + }
> > + return -ENODATA;
> > +}
> > +
> > static int ath10k_core_fetch_board_data_api_n(struct ath10k *ar,
> > const char *boardname,
> > - const char *fallback_boardname1,
> > - const char *fallback_boardname2,
> > const char *filename)
> > {
> > - size_t len, magic_len;
> > + size_t len, magic_len, board_len;
> > const u8 *data;
> > int ret;
> > + char temp_boardname[100];
> > +
> > + board_len = 100 * sizeof(temp_boardname[0]);
> >
> > /* Skip if already fetched during board data download */
> > if (!ar->normal_mode_fw.board)
> > @@ -1474,20 +1490,24 @@ static int
> > ath10k_core_fetch_board_data_api_n(struct ath10k *ar,
> > data += magic_len;
> > len -= magic_len;
> >
> > - /* attempt to find boardname in the IE list */
> > - ret = ath10k_core_search_bd(ar, boardname, data, len);
> > + memcpy(temp_boardname, boardname, board_len);
> > + ath10k_dbg(ar, ATH10K_DBG_BOOT, "boardname :%s\n", boardname);
>
> nit: use of ":" inconsistent with use of "=" noted above.
> also expect space after ":, not before: "boardname: %s\n"
>
Ack, will remove the extra space.
>
>
> >
> > - /* if we didn't find it and have a fallback name, try that */
> > - if (ret == -ENOENT && fallback_boardname1)
> > - ret = ath10k_core_search_bd(ar, fallback_boardname1, data,
> > len);
> > +retry_search:
> > + /* attempt to find boardname in the IE list */
> > + ret = ath10k_core_search_bd(ar, temp_boardname, data, len);
> >
> > - if (ret == -ENOENT && fallback_boardname2)
> > - ret = ath10k_core_search_bd(ar, fallback_boardname2, data,
> > len)
Re: [PATCH] Revert "ath: add support for special 0x0 regulatory domain"
Hello Brian and Kalle, I'm experiencing an issue very similar to this. The regulatory domain settings wouldn't allow me to create an AP on 5ghz bands on kernels newer than 5.10 when using a WLE900VX (QCA9984) radio. I bisected the kernel and ultimately landed on the regression that Brian patched. I applied the patch and that resolved the issue from 5.4 up to 5.10. For versions later than that I encountered the same problem. I tried to bisect again but PCI is broken for the ARM board(s) I'm using in many of the RC's, I'm pretty new to all of this and it was just over my head. I saw Kalle pushed Brian's patch a few weeks ago, so I figured the politics behind how the regulatory domain should be addressed was decided at that point. I cherry picked Brian's patch onto 5.17 to test, the results are below. Can someone help me figure out what I can do to get 5ghz APs back? If there's any more information I can provide please let me know, I wanted to keep things on the shorter side. cale@cale:~/builds/upstream/linux$ git log --oneline 5c12efe9e783 (HEAD) Revert "ath: add support for special 0x0 regulatory domain" f443e374ae13 (tag: v5.17) Linux 5.17 #On my ARM64 board root@focal-ventana:~# uname -a Linux focal-ventana 5.17.0-1-g5c12efe9e783 #1 SMP Wed Apr 6 16:33:54 PDT 2022 armv7l armv7l armv7l GNU/Linux root@focal-ventana:~# ls /sys/class/net/ can0 eth0 lo sit0 wlp6s0 root@focal-ventana:~# iw phy phy0 info | grep " MHz \[" | grep -v "no IR\|disabled" * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) root@focal-ventana:~# iw reg get global country 00: DFS-UNSET (2402 - 2472 @ 40), (N/A, 20), (N/A) (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, NO-IR (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, NO-IR (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, NO-IR (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, NO-IR (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, NO-IR (5735 - 5835 @ 80), (N/A, 20), (N/A), NO-IR (57240 - 63720 @ 2160), (N/A, 0), (N/A) phy#0 country 99: DFS-UNSET (2402 - 2472 @ 40), (N/A, 20), (N/A) (5140 - 5360 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN (5715 - 5860 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN #dmesg |grep ath output [5.724215] ath10k_pci :06:00.0: enabling device (0140 -> 0142) [5.732439] ath10k_pci :06:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 [ 17.573591] ath10k_pci :06:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub : [ 17.573707] ath10k_pci :06:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 [ 17.575118] ath10k_pci :06:00.0: firmware ver 10.2.4-1.0-00047 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 35bd9258 [ 17.637397] ath10k_pci :06:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 18.849651] ath10k_pci :06:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 Best regards, Cale Collins Cale Collins Field Applications Engineer II Gateworks Corporation (805)781-2000 x37 3026 S. Higuera, San Luis Obispo, CA 93401 www.gateworks.com On Mon, Apr 25, 2022 at 11:55 AM Brian Norris wrote: > > Hi Patrick, > > On Sat, Apr 23, 2022 at 3:52 AM Patrick Steinhardt wrote: > > This revert is in fact causing problems on my machine. I have a QCA9984, > > which exports two network interfaces. While I was able to still use one > > of both NICs for 2.4GHz, I couldn't really use the other card to set up > > a 5GHz AP anymore because all frequencies were restricted. This has > > started with v5.17.1, to which this revert was backported. > > > > Reverting this patch again fixes the issue on my system. So it seems > > like there still are cards out there in the wild which have a value of > > 0x0 as their regulatory domain. > > > > Quoting from your other mail: > > > > > My understanding was that no QCA modules *should* be shipped with a > > > value of 0 in this field. The instance I'm aware of was more or less a > > > manufacturing error I think, and we got Qualcomm to patch it over in > > > software. > > > > This sounds like the issue should've already been fixed in firmware, > > right? > > See the original patch: > https://git.kernel.org/linus/2dc016599cfa9672a147528ca26d70c3654a5423 > > "Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029." > > That patch was only tested for QCA6174 SDIO, and the 6174 firmware has > since been updated. So none of that really applies to QCA9984. I > suppose your device was also not working before v5.6 either, and IIUC, > according to Qualcomm your hardware is a manufacturing error
Re: [PATCH v3] ath10k: improve BDF search fallback strategy
On 5/8/2022 7:26 PM, Abhishek Kumar wrote:
Board data files wrapped inside board-2.bin files are
identified based on a combination of bus architecture,
chip-id, board-id or variants. Here is one such example
of a BDF entry in board-2.bin file:
bus=snoc,qmi-board-id=67,qmi-chip-id=320,variant=GO_
It is possible for few platforms none of the combinations
of bus,qmi-board,chip-id or variants match, e.g. if
board-id is not programmed and thus reads board-id=0xff,
there won't be any matching BDF to be found. In such
situations, the wlan will fail to enumerate.
Currently, to search for BDF, there are two fallback
boardnames creates to search for BDFs in case the full BDF
is not found. It is still possible that even the fallback
boardnames do not match.
As an improvement, search for BDF with full BDF combination
and perform the fallback searches by stripping down the last
elements until a BDF entry is found or none is found for all
possible BDF combinations.e.g.
Search for initial BDF first then followed by reduced BDF
names as follows:
bus=snoc,qmi-board-id=67,qmi-chip-id=320,variant=GO_
bus=snoc,qmi-board-id=67,qmi-chip-id=320
bus=snoc,qmi-board-id=67
bus=snoc
Tested-on: WCN3990/hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
Signed-off-by: Abhishek Kumar
---
Changes in v3:
- As discussed, instead of adding support for default BDF in DT, added
a method to drop the last elements from full BDF until a BDF is found.
- Previous patch was "ath10k: search for default BDF name provided in DT"
drivers/net/wireless/ath/ath10k/core.c | 65 +-
1 file changed, 32 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 688177453b07..ebb0d2a02c28 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1426,15 +1426,31 @@ static int ath10k_core_search_bd(struct ath10k *ar,
return ret;
}
+static bool ath10k_create_reduced_boardname(struct ath10k *ar, char *boardname)
+{
+ /* Find last BDF element */
+ char *last_field = strrchr(boardname, ',');
+
+ if (last_field) {
+ /* Drop the last BDF element */
+ last_field[0] = '\0';
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "boardname =%s\n", boardname);
nit: strange spacing in the message. i'd expect consistent spacing on
both side of "=", either one space on both sides or no space on both
sides. also the use of "=" here is inconsistent with the use of ":" in
a log later below
+ return 0;
+ }
+ return -ENODATA;
+}
+
static int ath10k_core_fetch_board_data_api_n(struct ath10k *ar,
const char *boardname,
- const char *fallback_boardname1,
- const char *fallback_boardname2,
const char *filename)
{
- size_t len, magic_len;
+ size_t len, magic_len, board_len;
const u8 *data;
int ret;
+ char temp_boardname[100];
+
+ board_len = 100 * sizeof(temp_boardname[0]);
/* Skip if already fetched during board data download */
if (!ar->normal_mode_fw.board)
@@ -1474,20 +1490,24 @@ static int ath10k_core_fetch_board_data_api_n(struct
ath10k *ar,
data += magic_len;
len -= magic_len;
- /* attempt to find boardname in the IE list */
- ret = ath10k_core_search_bd(ar, boardname, data, len);
+ memcpy(temp_boardname, boardname, board_len);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT, "boardname :%s\n", boardname);
nit: use of ":" inconsistent with use of "=" noted above.
also expect space after ":, not before: "boardname: %s\n"
- /* if we didn't find it and have a fallback name, try that */
- if (ret == -ENOENT && fallback_boardname1)
- ret = ath10k_core_search_bd(ar, fallback_boardname1, data, len);
+retry_search:
+ /* attempt to find boardname in the IE list */
+ ret = ath10k_core_search_bd(ar, temp_boardname, data, len);
- if (ret == -ENOENT && fallback_boardname2)
- ret = ath10k_core_search_bd(ar, fallback_boardname2, data, len);
+ /* If the full BDF entry was not found then drop the last element and
+* recheck until a BDF is found or until all options are exhausted.
+*/
+ if (ret == -ENOENT)
+ if (!ath10k_create_reduced_boardname(ar, temp_boardname))
+ goto retry_search;
if (ret == -ENOENT) {
note that ath10k_create_reduced_boardname() returns -ENODATA when
truncation fails and hence you won't log this error when that occurs
ath10k_err(ar,
"failed to fetch board data for %s from %s/%s\n",
- boardname, ar->hw_params.fw.dir, filename);
+ t
