From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: "Rafał Miłecki" <zajec5@gmail.com>, "Kalle Valo" <kvalo@codeaurora.org>
Cc: "Franky Lin" <franky.lin@broadcom.com>,
"Hante Meuleman" <hante.meuleman@broadcom.com>,
"Chi-Hsien Lin" <chi-hsien.lin@cypress.com>,
"Wright Feng" <wright.feng@cypress.com>,
"Pieter-Paul Giesberts" <pieter-paul.giesberts@broadcom.com>,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com,
brcm80211-dev-list@cypress.com,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH] brcmfmac: add debugfs entry for reading firmware capabilities
Date: Sun, 13 May 2018 20:59:28 +0200 [thread overview]
Message-ID: <5AF88B10.2040504@broadcom.com> (raw)
In-Reply-To: <20180511101526.10734-1-zajec5@gmail.com>
On 5/11/2018 12:15 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This allows reading all capabilities as reported by a firmware. They are
> printed using native (raw) names, just like developers like it the most.
> It's how firmware reports support for various features, e.g. supported
> modes, supported standards, power saving details, max BSS-es.
>
> Access to all that info is useful for trying new firmwares, comparing
> them and debugging features AKA bugs.
What are you implying :-p ? Some comments below.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 36 ++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> index 876731c57bf5..782121cb9399 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> @@ -165,6 +165,41 @@ static void brcmf_feat_firmware_capabilities(struct brcmf_if *ifp)
> }
> }
>
> +/**
> + * brcmf_cap_read() - expose firmware capabilities to debugfs.
Please stick to naming convention brcmf_<module>_foo(), ie.
brcmf_feat_cap_read().
> + *
> + * @seq: sequence for debugfs entry.
> + * @data: raw data pointer.
> + */
> +static int brcmf_cap_read(struct seq_file *seq, void *data)
> +{
> + struct brcmf_bus *bus_if = dev_get_drvdata(seq->private);
> + struct brcmf_if *ifp = brcmf_get_ifp(bus_if->drvr, 0);
> + char caps[MAX_CAPS_BUFFER_SIZE + 1] = { };
> + char *tmp;
> + int err;
> +
> + err = brcmf_fil_iovar_data_get(ifp, "cap", caps, sizeof(caps));
> + if (err) {
> + brcmf_err("could not get firmware cap (%d)\n", err);
> + return err;
> + }
> +
> + /* Put every capability in a new line */
> + for (tmp = caps; *tmp; tmp++) {
> + if (*tmp == ' ')
> + *tmp = '\n';
> + }
> +
> + /* Usually there is a space at the end of capabilities string */
> + seq_printf(seq, "%s", caps);
> + /* So make sure we don't print two line breaks */
> + if (tmp > caps && *(tmp - 1) != '\n')
> + seq_printf(seq, "\n");
> +
> + return 0;
> +}
> +
> void brcmf_feat_attach(struct brcmf_pub *drvr)
> {
> struct brcmf_if *ifp = brcmf_get_ifp(drvr, 0);
> @@ -233,6 +268,7 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
> void brcmf_feat_debugfs_create(struct brcmf_pub *drvr)
> {
> brcmf_debugfs_add_entry(drvr, "features", brcmf_feat_debugfs_read);
> + brcmf_debugfs_add_entry(drvr, "cap", brcmf_cap_read);
Prefer to name the debugfs entry "fwcap".
next prev parent reply other threads:[~2018-05-13 18:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 10:15 [PATCH] brcmfmac: add debugfs entry for reading firmware capabilities Rafał Miłecki
2018-05-13 18:59 ` Arend van Spriel [this message]
2018-05-14 5:11 ` Rafał Miłecki
2018-05-14 7:24 ` Arend van Spriel
2018-05-14 6:48 ` [PATCH V2] " Rafał Miłecki
2018-05-23 8:01 ` [V2] " Kalle Valo
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=5AF88B10.2040504@broadcom.com \
--to=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211-dev-list@cypress.com \
--cc=chi-hsien.lin@cypress.com \
--cc=franky.lin@broadcom.com \
--cc=hante.meuleman@broadcom.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pieter-paul.giesberts@broadcom.com \
--cc=rafal@milecki.pl \
--cc=wright.feng@cypress.com \
--cc=zajec5@gmail.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 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.