[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff2232c8-fdf2-0a34-783b-5a5c8596f272@marcan.st>
Date: Tue, 1 Feb 2022 01:28:57 +0900
From: Hector Martin <marcan@...can.st>
To: Arend van Spriel <arend.vanspriel@...adcom.com>,
Kalle Valo <kvalo@...eaurora.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Arend van Spriel <aspriel@...il.com>,
Franky Lin <franky.lin@...adcom.com>,
Hante Meuleman <hante.meuleman@...adcom.com>,
Wright Feng <wright.feng@...ineon.com>,
Dmitry Osipenko <digetx@...il.com>
Cc: Sven Peter <sven@...npeter.dev>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Mark Kettenis <kettenis@...nbsd.org>,
Rafał Miłecki <zajec5@...il.com>,
Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
Linus Walleij <linus.walleij@...aro.org>,
Hans de Goede <hdegoede@...hat.com>,
"John W. Linville" <linville@...driver.com>,
"brian m. carlson" <sandals@...stytoothpaste.net>,
Andy Shevchenko <andy.shevchenko@...il.com>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com,
SHA-cyfmac-dev-list@...ineon.com
Subject: Re: [PATCH v2 33/35] brcmfmac: common: Add support for downloading
TxCap blobs
On 21/01/2022 16.36, Arend van Spriel wrote:
> On 1/4/2022 8:26 AM, Hector Martin wrote:
>> The TxCap blobs are additional data blobs used on Apple devices, and
>> are uploaded analogously to CLM blobs. Add core support for doing this.
>
> Reviewed-by: Arend van Spriel <arend.vanspriel@...adcom.com>
>> Acked-by: Linus Walleij <linus.walleij@...aro.org>
>> Signed-off-by: Hector Martin <marcan@...can.st>
>> ---
>> .../broadcom/brcm80211/brcmfmac/bus.h | 1 +
>> .../broadcom/brcm80211/brcmfmac/common.c | 97 +++++++++++++------
>> 2 files changed, 71 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
>> index b13af8f631f3..f4bd98da9761 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
>> @@ -39,6 +39,7 @@ enum brcmf_bus_protocol_type {
>> /* Firmware blobs that may be available */
>> enum brcmf_blob_type {
>> BRCMF_BLOB_CLM,
>> + BRCMF_BLOB_TXCAP,
>> };
>>
>> struct brcmf_mp_device;
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> index c84c48e49fde..d65308c3f070 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
>
> [...]
>
>> @@ -165,20 +157,64 @@ static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
>> } while ((datalen > 0) && (err == 0));
>>
>
> [...]
>
>> +static int brcmf_c_process_txcap_blob(struct brcmf_if *ifp)
>> +{
>> + struct brcmf_pub *drvr = ifp->drvr;
>> + struct brcmf_bus *bus = drvr->bus_if;
>> + const struct firmware *fw = NULL;
>> + s32 err;
>> +
>> + brcmf_dbg(TRACE, "Enter\n");
>> +
>> + err = brcmf_bus_get_blob(bus, &fw, BRCMF_BLOB_TXCAP);
>> + if (err || !fw) {
>> + brcmf_info("no txcap_blob available (err=%d)\n", err);
>> + return 0;
>> + }
>> +
>> + brcmf_info("TxCap blob found, loading\n");
>> + err = brcmf_c_download_blob(ifp, fw->data, fw->size,
>> + "txcapload", "txcapload_status");
>
> Although unlikely that we end up here with a firmware that does not
> support this command it is not impossible. Should we handle that here or
> introduce a feature flag for txcap loading?
Hmm, like trying to read txcapload_status to set the feature flag?
Honestly though, if we end up here on an unsupported firmware that
sounds like a firmware loading error, since if we have a TxCap blob for
a given board we better have a firmware that supports it. So it doesn't
feel too wrong to just error out entirely so the user knows something is
horribly wrong, instead of trying to use what is probably the wrong
firmware.
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists