From: Kalle Valo <kvalo@kernel.org>
To: Abhishek Kumar <kuabhs@chromium.org>
Cc: netdev@vger.kernel.org, dianders@chromium.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
ath10k@lists.infradead.org,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH v3] ath10k: improve BDF search fallback strategy
Date: Wed, 11 May 2022 16:34:26 +0300 [thread overview]
Message-ID: <878rr86vml.fsf@kernel.org> (raw)
In-Reply-To: <20220509022618.v3.1.Ibfd52b9f0890fffe87f276fa84deaf6f1fb0055c@changeid> (Abhishek Kumar's message of "Mon, 9 May 2022 02:26:36 +0000")
Abhishek Kumar <kuabhs@chromium.org> writes:
> 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_XXXX
> 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_XXXX
> bus=snoc,qmi-board-id=67,qmi-chip-id=320
> bus=snoc,qmi-board-id=67
> bus=snoc
> <No BDF found>
>
> Tested-on: WCN3990/hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
> Signed-off-by: Abhishek Kumar <kuabhs@chromium.org>
> ---
>
> 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)
"static int" as you use error values. Strange that the compiler doesn't
warn about that.
> +{
> + /* 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);
> + return 0;
> + }
> + return -ENODATA;
I would invert the check:
if (!last_field)
return -ENODATA;
/* Drop the last BDF element */
last_field[0] = '\0';
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot reduced boardname %s\n",
boardname);
return 0;
Also I changed the style used in the debug message.
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle#debug_messages
> 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);
"boot 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) {
> ath10k_err(ar,
> "failed to fetch board data for %s from %s/%s\n",
> - boardname, ar->hw_params.fw.dir, filename);
> + temp_boardname, ar->hw_params.fw.dir, filename);
> ret = -ENODATA;
> }
This is hard to read, what about the loop below? Though I'm sure I
missed some corner case but I hope you get the idea. It's always good to
have a limit for the loops to avoid looping forever.
for (i = 0; i < 20; i++) {
/* attempt to find boardname in the IE list */
ret = ath10k_core_search_bd(ar, temp_boardname, data, len);
if (ret != -ENOENT)
/* found it or something was wrong */
break;
/* 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.
*/
ret = ath10k_create_reduced_boardname(ar, temp_boardname);
if (ret) {
ath10k_err(ar,
"failed to fetch board data for %s from %s/%s\n",
temp_boardname, ar->hw_params.fw.dir, filename);
ret = -ENODATA;
break;
}
};
if (ret)
goto err;
return 0;
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
prev parent reply other threads:[~2022-05-11 13:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 2:26 [PATCH v3] ath10k: improve BDF search fallback strategy Abhishek Kumar
2022-05-09 17:22 ` Jeff Johnson
[not found] ` <CAB5ih=O325ndrYqLWwug01tSmketLDrsJgtX5DvR38Om6T8ZCQ@mail.gmail.com>
2022-05-10 2:17 ` Abhishek Kumar
2022-05-10 15:41 ` Kalle Valo
2022-05-10 15:46 ` Kalle Valo
2022-05-11 13:34 ` Kalle Valo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rr86vml.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath10k@lists.infradead.org \
--cc=davem@davemloft.net \
--cc=dianders@chromium.org \
--cc=edumazet@google.com \
--cc=kuabhs@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).