From: Arend van Spriel <arend@broadcom.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>,
<linux-wireless@vger.kernel.org>,
Brett Rudley <brudley@broadcom.com>,
"Franky (Zhenhui) Lin" <frankyl@broadcom.com>,
Hante Meuleman <meuleman@broadcom.com>,
<brcm80211-dev-list@broadcom.com>
Subject: Re: [PATCH] brcmfmac: use direct data pointer in NVRAM parser struct
Date: Thu, 4 Jun 2015 17:02:38 +0200 [thread overview]
Message-ID: <5570688E.8060307@broadcom.com> (raw)
In-Reply-To: <1432813063-30922-1-git-send-email-zajec5@gmail.com>
On 05/28/15 13:37, Rafał Miłecki wrote:
> As we plan to add support for platform NVRAM we should store direct
> data pointer without the extra struct firmware layer. This will allow
> us to support other sources with the only requirement being u8 buffer.
>
> Signed-off-by: Rafał Miłecki<zajec5@gmail.com>
> Signed-off-by: Hante Meuleman<meuleman@broadcom.com>
> Signed-off-by: Arend van Spriel<arend@broadcom.com>
This look a bit contradictory. You mention below you written this from
'scratch' so it seems odd that it is signed off by me and Hante.
You may add:
Acked-by: Arend van Spriel <arend@broadcom.com>
> ---
> Tested on router with BCM43602-s using /lib/firmware/brcm/brcmfmac43602-pcie.txt
>
> I've written this patch from scratch, it's inspired by the dropped:
> [PATCH 6/6] brcmfmac: Add support for host platform NVRAM loading.
> ---
> drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 40 +++++++++++-----------
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
> index 7ae6461..b72df87 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
> @@ -43,7 +43,7 @@ enum nvram_parser_state {
> * struct nvram_parser - internal info for parser.
> *
> * @state: current parser state.
> - * @fwnv: input buffer being parsed.
> + * @data: input buffer being parsed.
So you are not adding the data_len to the structure, which means you
found it is not needed? Just checking as it is different from the
aforementioned patch.
Regards,
Arend
> * @nvram: output buffer with parse result.
> * @nvram_len: lenght of parse result.
> * @line: current line.
> @@ -55,7 +55,7 @@ enum nvram_parser_state {
> */
> struct nvram_parser {
> enum nvram_parser_state state;
> - const struct firmware *fwnv;
> + const u8 *data;
> u8 *nvram;
> u32 nvram_len;
> u32 line;
> @@ -91,7 +91,7 @@ static enum nvram_parser_state brcmf_nvram_handle_idle(struct nvram_parser *nvp)
> {
> char c;
>
> - c = nvp->fwnv->data[nvp->pos];
> + c = nvp->data[nvp->pos];
> if (c == '\n')
> return COMMENT;
> if (is_whitespace(c))
> @@ -115,16 +115,16 @@ static enum nvram_parser_state brcmf_nvram_handle_key(struct nvram_parser *nvp)
> enum nvram_parser_state st = nvp->state;
> char c;
>
> - c = nvp->fwnv->data[nvp->pos];
> + c = nvp->data[nvp->pos];
> if (c == '=') {
> /* ignore RAW1 by treating as comment */
> - if (strncmp(&nvp->fwnv->data[nvp->entry], "RAW1", 4) == 0)
> + if (strncmp(&nvp->data[nvp->entry], "RAW1", 4) == 0)
> st = COMMENT;
> else
> st = VALUE;
> - if (strncmp(&nvp->fwnv->data[nvp->entry], "devpath", 7) == 0)
> + if (strncmp(&nvp->data[nvp->entry], "devpath", 7) == 0)
> nvp->multi_dev_v1 = true;
> - if (strncmp(&nvp->fwnv->data[nvp->entry], "pcie/", 5) == 0)
> + if (strncmp(&nvp->data[nvp->entry], "pcie/", 5) == 0)
> nvp->multi_dev_v2 = true;
> } else if (!is_nvram_char(c) || c == ' ') {
> brcmf_dbg(INFO, "warning: ln=%d:col=%d: '=' expected, skip invalid key entry\n",
> @@ -145,11 +145,11 @@ brcmf_nvram_handle_value(struct nvram_parser *nvp)
> char *ekv;
> u32 cplen;
>
> - c = nvp->fwnv->data[nvp->pos];
> + c = nvp->data[nvp->pos];
> if (!is_nvram_char(c)) {
> /* key,value pair complete */
> - ekv = (u8 *)&nvp->fwnv->data[nvp->pos];
> - skv = (u8 *)&nvp->fwnv->data[nvp->entry];
> + ekv = (u8 *)&nvp->data[nvp->pos];
> + skv = (u8 *)&nvp->data[nvp->entry];
> cplen = ekv - skv;
> if (nvp->nvram_len + cplen + 1>= BRCMF_FW_MAX_NVRAM_SIZE)
> return END;
> @@ -170,7 +170,7 @@ brcmf_nvram_handle_comment(struct nvram_parser *nvp)
> {
> char *eoc, *sol;
>
> - sol = (char *)&nvp->fwnv->data[nvp->pos];
> + sol = (char *)&nvp->data[nvp->pos];
> eoc = strchr(sol, '\n');
> if (!eoc) {
> eoc = strchr(sol, '\0');
> @@ -201,17 +201,17 @@ static enum nvram_parser_state
> };
>
> static int brcmf_init_nvram_parser(struct nvram_parser *nvp,
> - const struct firmware *nv)
> + const u8 *data, size_t data_len)
> {
> size_t size;
>
> memset(nvp, 0, sizeof(*nvp));
> - nvp->fwnv = nv;
> + nvp->data = data;
> /* Limit size to MAX_NVRAM_SIZE, some files contain lot of comment */
> - if (nv->size> BRCMF_FW_MAX_NVRAM_SIZE)
> + if (data_len> BRCMF_FW_MAX_NVRAM_SIZE)
> size = BRCMF_FW_MAX_NVRAM_SIZE;
> else
> - size = nv->size;
> + size = data_len;
> /* Alloc for extra 0 byte + roundup by 4 + length field */
> size += 1 + 3 + sizeof(u32);
> nvp->nvram = kzalloc(size, GFP_KERNEL);
> @@ -356,18 +356,18 @@ fail:
> * and converts newlines to NULs. Shortens buffer as needed and pads with NULs.
> * End of buffer is completed with token identifying length of buffer.
> */
> -static void *brcmf_fw_nvram_strip(const struct firmware *nv, u32 *new_length,
> - u16 domain_nr, u16 bus_nr)
> +static void *brcmf_fw_nvram_strip(const u8 *data, size_t data_len,
> + u32 *new_length, u16 domain_nr, u16 bus_nr)
> {
> struct nvram_parser nvp;
> u32 pad;
> u32 token;
> __le32 token_le;
>
> - if (brcmf_init_nvram_parser(&nvp, nv)< 0)
> + if (brcmf_init_nvram_parser(&nvp, data, data_len)< 0)
> return NULL;
>
> - while (nvp.pos< nv->size) {
> + while (nvp.pos< data_len) {
> nvp.state = nv_parser_states[nvp.state](&nvp);
> if (nvp.state == END)
> break;
> @@ -426,7 +426,7 @@ static void brcmf_fw_request_nvram_done(const struct firmware *fw, void *ctx)
> goto fail;
>
> if (fw) {
> - nvram = brcmf_fw_nvram_strip(fw,&nvram_length,
> + nvram = brcmf_fw_nvram_strip(fw->data, fw->size,&nvram_length,
> fwctx->domain_nr, fwctx->bus_nr);
> release_firmware(fw);
> if (!nvram&& !(fwctx->flags& BRCMF_FW_REQ_NV_OPTIONAL))
next prev parent reply other threads:[~2015-06-04 15:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 11:37 [PATCH] brcmfmac: use direct data pointer in NVRAM parser struct Rafał Miłecki
2015-05-28 11:54 ` Arend van Spriel
2015-05-28 12:34 ` Rafał Miłecki
2015-05-28 21:24 ` Arend van Spriel
2015-05-29 5:20 ` Rafał Miłecki
2015-05-29 8:03 ` Arend van Spriel
2015-05-29 15:58 ` Rafał Miłecki
2015-06-03 12:12 ` Arend van Spriel
2015-06-04 14:23 ` Kalle Valo
2015-06-04 14:55 ` Arend van Spriel
2015-06-04 15:02 ` Arend van Spriel [this message]
2015-06-04 19:59 ` Rafał Miłecki
2015-06-04 20:11 ` [PATCH RESEND] " Rafał Miłecki
2015-06-08 11:31 ` 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=5570688E.8060307@broadcom.com \
--to=arend@broadcom.com \
--cc=brcm80211-dev-list@broadcom.com \
--cc=brudley@broadcom.com \
--cc=frankyl@broadcom.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=meuleman@broadcom.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 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).