From: Kalle Valo <kvalo@codeaurora.org>
To: Rakesh Pillai <pillair@codeaurora.org>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
ath10k@lists.infradead.org
Subject: Re: [PATCH] ath10k: Use bdf calibration variant for snoc targets
Date: Wed, 02 Sep 2020 11:47:16 +0300 [thread overview]
Message-ID: <87y2ls4lbf.fsf@codeaurora.org> (raw)
In-Reply-To: <1593193990-30366-1-git-send-email-pillair@codeaurora.org> (Rakesh Pillai's message of "Fri, 26 Jun 2020 23:23:10 +0530")
Rakesh Pillai <pillair@codeaurora.org> writes:
> Board Data File (BDF) is loaded upon driver boot-up procedure.
> The right board data file is identified using bus and qmi-board-id.
>
> The problem, however, can occur when the (default) board data
> file cannot fulfill with the vendor requirements and it is
> necessary to use a different board data file.
>
> Add the support to get the variant field from DTSI and
> use tht information to load the vendor specific BDF.
>
> The device tree requires addition strings to define the variant name
>
> wifi@a000000 {
> status = "okay";
> qcom,ath10k-calibration-variant = "xyz-v2";
> };
>
> wifi@a800000 {
> status = "okay";
> qcom,ath10k-calibration-variant = "xyz-v1";
> };
>
> This would create the boarddata identifiers for the board-2.bin search
>
> * bus=snoc,qmi-board-id=16,qmi-chip-id=0,variant=xyz-v1
> * bus=snoc,qmi-board-id=17,qmi-chip-id=0,variant=xyz-v2
You mention nothing about qmi-chip-id in the commit log. Please document
what it is and also give some examples what kind of values there can be.
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -576,6 +576,8 @@ static int ath10k_qmi_cap_send_sync_msg(struct ath10k_qmi *qmi)
> if (resp->chip_info_valid) {
> qmi->chip_info.chip_id = resp->chip_info.chip_id;
> qmi->chip_info.chip_family = resp->chip_info.chip_family;
> + } else {
> + qmi->chip_info.chip_id = 0xFF;
> }
So you hard code chip_id to 0xff if it's not valid. Is it 100%
guaranteed that there never will be a chip id with 0xff?
>
> if (resp->board_info_valid)
> @@ -817,12 +819,18 @@ static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
> static int ath10k_qmi_fetch_board_file(struct ath10k_qmi *qmi)
> {
> struct ath10k *ar = qmi->ar;
> + int ret;
>
> ar->hif.bus = ATH10K_BUS_SNOC;
> ar->id.qmi_ids_valid = true;
> ar->id.qmi_board_id = qmi->board_info.board_id;
> + ar->id.qmi_chip_id = qmi->chip_info.chip_id;
To me a safer, and cleaner, option would be to have
ar->id.qmi_chip_id_valid, and only add qmi-chip-id=%x to the board id if
qmi_chip_id_valid is true. That way there's not this magic 0xff value
hardcoded anywhere.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Rakesh Pillai <pillair@codeaurora.org>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath10k: Use bdf calibration variant for snoc targets
Date: Wed, 02 Sep 2020 11:47:16 +0300 [thread overview]
Message-ID: <87y2ls4lbf.fsf@codeaurora.org> (raw)
In-Reply-To: <1593193990-30366-1-git-send-email-pillair@codeaurora.org> (Rakesh Pillai's message of "Fri, 26 Jun 2020 23:23:10 +0530")
Rakesh Pillai <pillair@codeaurora.org> writes:
> Board Data File (BDF) is loaded upon driver boot-up procedure.
> The right board data file is identified using bus and qmi-board-id.
>
> The problem, however, can occur when the (default) board data
> file cannot fulfill with the vendor requirements and it is
> necessary to use a different board data file.
>
> Add the support to get the variant field from DTSI and
> use tht information to load the vendor specific BDF.
>
> The device tree requires addition strings to define the variant name
>
> wifi@a000000 {
> status = "okay";
> qcom,ath10k-calibration-variant = "xyz-v2";
> };
>
> wifi@a800000 {
> status = "okay";
> qcom,ath10k-calibration-variant = "xyz-v1";
> };
>
> This would create the boarddata identifiers for the board-2.bin search
>
> * bus=snoc,qmi-board-id=16,qmi-chip-id=0,variant=xyz-v1
> * bus=snoc,qmi-board-id=17,qmi-chip-id=0,variant=xyz-v2
You mention nothing about qmi-chip-id in the commit log. Please document
what it is and also give some examples what kind of values there can be.
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -576,6 +576,8 @@ static int ath10k_qmi_cap_send_sync_msg(struct ath10k_qmi *qmi)
> if (resp->chip_info_valid) {
> qmi->chip_info.chip_id = resp->chip_info.chip_id;
> qmi->chip_info.chip_family = resp->chip_info.chip_family;
> + } else {
> + qmi->chip_info.chip_id = 0xFF;
> }
So you hard code chip_id to 0xff if it's not valid. Is it 100%
guaranteed that there never will be a chip id with 0xff?
>
> if (resp->board_info_valid)
> @@ -817,12 +819,18 @@ static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
> static int ath10k_qmi_fetch_board_file(struct ath10k_qmi *qmi)
> {
> struct ath10k *ar = qmi->ar;
> + int ret;
>
> ar->hif.bus = ATH10K_BUS_SNOC;
> ar->id.qmi_ids_valid = true;
> ar->id.qmi_board_id = qmi->board_info.board_id;
> + ar->id.qmi_chip_id = qmi->chip_info.chip_id;
To me a safer, and cleaner, option would be to have
ar->id.qmi_chip_id_valid, and only add qmi-chip-id=%x to the board id if
qmi_chip_id_valid is true. That way there's not this magic 0xff value
hardcoded anywhere.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2020-09-02 8:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 17:53 [PATCH] ath10k: Use bdf calibration variant for snoc targets Rakesh Pillai
2020-06-26 17:53 ` Rakesh Pillai
2020-09-02 8:47 ` Kalle Valo [this message]
2020-09-02 8:47 ` Kalle Valo
2020-09-04 16:40 ` Rakesh Pillai
2020-09-07 16:17 ` Kalle Valo
2020-09-07 16:17 ` Kalle Valo
[not found] ` <87k0x51rz3.fsf@codeaurora.org>
2020-09-10 13:11 ` Rakesh Pillai
2020-09-10 13:11 ` Rakesh Pillai
2020-09-04 16:40 ` Rakesh Pillai
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=87y2ls4lbf.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pillair@codeaurora.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.