lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ