* [PATCH 0/2] Apple T2 platform support
@ 2023-02-14 8:00 Hector Martin
2023-02-14 8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Hector Martin @ 2023-02-14 8:00 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi,
linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list,
netdev, linux-kernel, Hector Martin
Hi all,
This short series adds the missing bits to support Apple T2 platforms.
There are two quirks: these devices have firmware that requires the
host to provide a blob of randomness as a seed (presumably because the
chipsets lack a proper RNG), and the module/antenna information that
is used for Apple firmware selection and comes from the Device Tree
on ARM64 systems (already upstream) needs to come from ACPI on these
instead.
Changes since the megaseries from a ~year ago: made the ACPI code bail
if there is no module-instance, so we don't try to get the antenna
info at all in that case (as suggested by Arend). Made the randomness
conditional on an Apple OTP being present, since it's not known to be
needed on non-Apple firmware.
Hector Martin (2):
brcmfmac: acpi: Add support for fetching Apple ACPI properties
brcmfmac: pcie: Provide a buffer of random bytes to the device
.../broadcom/brcm80211/brcmfmac/Makefile | 2 +
.../broadcom/brcm80211/brcmfmac/acpi.c | 51 +++++++++++++++++++
.../broadcom/brcm80211/brcmfmac/common.c | 1 +
.../broadcom/brcm80211/brcmfmac/common.h | 9 ++++
.../broadcom/brcm80211/brcmfmac/pcie.c | 32 ++++++++++++
5 files changed, 95 insertions(+)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c
--
2.35.1
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties 2023-02-14 8:00 [PATCH 0/2] Apple T2 platform support Hector Martin @ 2023-02-14 8:00 ` Hector Martin 2023-02-14 9:04 ` Julian Calaby ` (2 more replies) 2023-02-14 8:00 ` [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin 2023-02-23 15:01 ` [PATCH 0/2] Apple T2 platform support Aditya Garg 2 siblings, 3 replies; 14+ messages in thread From: Hector Martin @ 2023-02-14 8:00 UTC (permalink / raw) To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni Cc: Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel, Hector Martin On DT platforms, the module-instance and antenna-sku-info properties are passed in the DT. On ACPI platforms, module-instance is passed via the analogous Apple device property mechanism, while the antenna SKU info is instead obtained via an ACPI method that grabs it from non-volatile storage. Add support for this, to allow proper firmware selection on Apple platforms. Signed-off-by: Hector Martin <marcan@marcan.st> --- .../broadcom/brcm80211/brcmfmac/Makefile | 2 + .../broadcom/brcm80211/brcmfmac/acpi.c | 51 +++++++++++++++++++ .../broadcom/brcm80211/brcmfmac/common.c | 1 + .../broadcom/brcm80211/brcmfmac/common.h | 9 ++++ 4 files changed, 63 insertions(+) create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile index 0e996cf24f88..dc6d27a36faa 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile @@ -48,6 +48,8 @@ brcmfmac-$(CONFIG_OF) += \ of.o brcmfmac-$(CONFIG_DMI) += \ dmi.o +brcmfmac-$(CONFIG_ACPI) += \ + acpi.o ifeq ($(CONFIG_BRCMFMAC),m) obj-m += wcc/ diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c new file mode 100644 index 000000000000..c4a54861bfb4 --- /dev/null +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c @@ -0,0 +1,51 @@ +// SPDX-License-Identifier: ISC +/* + * Copyright The Asahi Linux Contributors + */ + +#include <linux/acpi.h> +#include "debug.h" +#include "core.h" +#include "common.h" + +void brcmf_acpi_probe(struct device *dev, enum brcmf_bus_type bus_type, + struct brcmf_mp_device *settings) +{ + acpi_status status; + const union acpi_object *o; + struct acpi_buffer buf = {ACPI_ALLOCATE_BUFFER, NULL}; + struct acpi_device *adev = ACPI_COMPANION(dev); + + if (!adev) + return; + + if (!ACPI_FAILURE(acpi_dev_get_property(adev, "module-instance", + ACPI_TYPE_STRING, &o))) { + brcmf_dbg(INFO, "ACPI module-instance=%s\n", o->string.pointer); + settings->board_type = devm_kasprintf(dev, GFP_KERNEL, + "apple,%s", + o->string.pointer); + } else { + brcmf_dbg(INFO, "No ACPI module-instance\n"); + return; + } + + status = acpi_evaluate_object(adev->handle, "RWCV", NULL, &buf); + o = buf.pointer; + if (!ACPI_FAILURE(status) && o && o->type == ACPI_TYPE_BUFFER && + o->buffer.length >= 2) { + char *antenna_sku = devm_kzalloc(dev, 3, GFP_KERNEL); + + if (antenna_sku) { + memcpy(antenna_sku, o->buffer.pointer, 2); + brcmf_dbg(INFO, "ACPI RWCV data=%*phN antenna-sku=%s\n", + (int)o->buffer.length, o->buffer.pointer, + antenna_sku); + settings->antenna_sku = antenna_sku; + } + + kfree(buf.pointer); + } else { + brcmf_dbg(INFO, "No ACPI antenna-sku\n"); + } +} diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index 4a309e5a5707..b977e50137bb 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -484,6 +484,7 @@ struct brcmf_mp_device *brcmf_get_module_param(struct device *dev, /* No platform data for this device, try OF and DMI data */ brcmf_dmi_probe(settings, chip, chiprev); brcmf_of_probe(dev, bus_type, settings); + brcmf_acpi_probe(dev, bus_type, settings); } return settings; } diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h index aa25abffcc7d..7167fd4f8c63 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h @@ -77,6 +77,15 @@ static inline void brcmf_dmi_probe(struct brcmf_mp_device *settings, u32 chip, u32 chiprev) {} #endif +#ifdef CONFIG_ACPI +void brcmf_acpi_probe(struct device *dev, enum brcmf_bus_type bus_type, + struct brcmf_mp_device *settings); +#else +static inline void brcmf_acpi_probe(struct device *dev, + enum brcmf_bus_type bus_type, + struct brcmf_mp_device *settings) {} +#endif + u8 brcmf_map_prio_to_prec(void *cfg, u8 prio); u8 brcmf_map_prio_to_aci(void *cfg, u8 prio); -- 2.35.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties 2023-02-14 8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin @ 2023-02-14 9:04 ` Julian Calaby 2023-02-15 10:13 ` Linus Walleij 2023-02-27 10:41 ` [1/2] wifi: " Kalle Valo 2 siblings, 0 replies; 14+ messages in thread From: Julian Calaby @ 2023-02-14 9:04 UTC (permalink / raw) To: Hector Martin Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel Hi Hector, On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <marcan@marcan.st> wrote: > > On DT platforms, the module-instance and antenna-sku-info properties > are passed in the DT. On ACPI platforms, module-instance is passed via > the analogous Apple device property mechanism, while the antenna SKU > info is instead obtained via an ACPI method that grabs it from > non-volatile storage. > > Add support for this, to allow proper firmware selection on Apple > platforms. > > Signed-off-by: Hector Martin <marcan@marcan.st> Makes sense to me. Reviewed-by: Julian Calaby <julian.calaby@gmail.com> > --- > .../broadcom/brcm80211/brcmfmac/Makefile | 2 + > .../broadcom/brcm80211/brcmfmac/acpi.c | 51 +++++++++++++++++++ > .../broadcom/brcm80211/brcmfmac/common.c | 1 + > .../broadcom/brcm80211/brcmfmac/common.h | 9 ++++ > 4 files changed, 63 insertions(+) > create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties 2023-02-14 8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin 2023-02-14 9:04 ` Julian Calaby @ 2023-02-15 10:13 ` Linus Walleij 2023-02-27 10:41 ` [1/2] wifi: " Kalle Valo 2 siblings, 0 replies; 14+ messages in thread From: Linus Walleij @ 2023-02-15 10:13 UTC (permalink / raw) To: Hector Martin Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel On Tue, Feb 14, 2023 at 9:01 AM Hector Martin <marcan@marcan.st> wrote: > On DT platforms, the module-instance and antenna-sku-info properties > are passed in the DT. On ACPI platforms, module-instance is passed via > the analogous Apple device property mechanism, while the antenna SKU > info is instead obtained via an ACPI method that grabs it from > non-volatile storage. > > Add support for this, to allow proper firmware selection on Apple > platforms. > > Signed-off-by: Hector Martin <marcan@marcan.st> It looks like a horrible Apple-ism but I don't know much about ACPI. The ACPI people are working on device properties to abstract away all device properties no matter if they come from ACPI, device tree or, ehm Apple-ACPI, but for now I think it is more important to get this hardware working upstream and we can think about refactoring this into device properties for the longer term. Acked-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [1/2] wifi: brcmfmac: acpi: Add support for fetching Apple ACPI properties 2023-02-14 8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin 2023-02-14 9:04 ` Julian Calaby 2023-02-15 10:13 ` Linus Walleij @ 2023-02-27 10:41 ` Kalle Valo 2 siblings, 0 replies; 14+ messages in thread From: Kalle Valo @ 2023-02-27 10:41 UTC (permalink / raw) To: Hector Martin Cc: Arend van Spriel, Franky Lin, Hante Meuleman, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel, Hector Martin Hector Martin <marcan@marcan.st> wrote: > On DT platforms, the module-instance and antenna-sku-info properties > are passed in the DT. On ACPI platforms, module-instance is passed via > the analogous Apple device property mechanism, while the antenna SKU > info is instead obtained via an ACPI method that grabs it from > non-volatile storage. > > Add support for this, to allow proper firmware selection on Apple > platforms. > > Signed-off-by: Hector Martin <marcan@marcan.st> > Reviewed-by: Julian Calaby <julian.calaby@gmail.com> > Acked-by: Linus Walleij <linus.walleij@linaro.org> 2 patches applied to wireless-next.git, thanks. 0f485805d008 wifi: brcmfmac: acpi: Add support for fetching Apple ACPI properties 91918ce88d9f wifi: brcmfmac: pcie: Provide a buffer of random bytes to the device -- https://patchwork.kernel.org/project/linux-wireless/patch/20230214080034.3828-2-marcan@marcan.st/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device 2023-02-14 8:00 [PATCH 0/2] Apple T2 platform support Hector Martin 2023-02-14 8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin @ 2023-02-14 8:00 ` Hector Martin 2023-02-14 9:00 ` Julian Calaby 2023-02-23 15:01 ` [PATCH 0/2] Apple T2 platform support Aditya Garg 2 siblings, 1 reply; 14+ messages in thread From: Hector Martin @ 2023-02-14 8:00 UTC (permalink / raw) To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni Cc: Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel, Hector Martin Newer Apple firmwares on chipsets without a hardware RNG require the host to provide a buffer of 256 random bytes to the device on initialization. This buffer is present immediately before NVRAM, suffixed by a footer containing a magic number and the buffer length. This won't affect chips/firmwares that do not use this feature, so do it unconditionally for all Apple platforms (those with an Apple OTP). Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> --- .../broadcom/brcm80211/brcmfmac/pcie.c | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c index f320b6ce8bff..a7b88ab609c2 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c @@ -15,6 +15,7 @@ #include <linux/sched/signal.h> #include <linux/kthread.h> #include <linux/io.h> +#include <linux/random.h> #include <asm/unaligned.h> #include <soc.h> @@ -1653,6 +1654,13 @@ brcmf_pcie_init_share_ram_info(struct brcmf_pciedev_info *devinfo, return 0; } +struct brcmf_random_seed_footer { + __le32 length; + __le32 magic; +}; + +#define BRCMF_RANDOM_SEED_MAGIC 0xfeedc0de +#define BRCMF_RANDOM_SEED_LENGTH 0x100 static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo, const struct firmware *fw, void *nvram, @@ -1689,6 +1697,30 @@ static int brcmf_pcie_download_fw_nvram(struct brcmf_pciedev_info *devinfo, nvram_len; memcpy_toio(devinfo->tcm + address, nvram, nvram_len); brcmf_fw_nvram_free(nvram); + + if (devinfo->otp.valid) { + size_t rand_len = BRCMF_RANDOM_SEED_LENGTH; + struct brcmf_random_seed_footer footer = { + .length = cpu_to_le32(rand_len), + .magic = cpu_to_le32(BRCMF_RANDOM_SEED_MAGIC), + }; + void *randbuf; + + /* Some Apple chips/firmwares expect a buffer of random + * data to be present before NVRAM + */ + brcmf_dbg(PCIE, "Download random seed\n"); + + address -= sizeof(footer); + memcpy_toio(devinfo->tcm + address, &footer, + sizeof(footer)); + + address -= rand_len; + randbuf = kzalloc(rand_len, GFP_KERNEL); + get_random_bytes(randbuf, rand_len); + memcpy_toio(devinfo->tcm + address, randbuf, rand_len); + kfree(randbuf); + } } else { brcmf_dbg(PCIE, "No matching NVRAM file found %s\n", devinfo->nvram_name); -- 2.35.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device 2023-02-14 8:00 ` [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin @ 2023-02-14 9:00 ` Julian Calaby 2023-02-14 9:08 ` Hector Martin 0 siblings, 1 reply; 14+ messages in thread From: Julian Calaby @ 2023-02-14 9:00 UTC (permalink / raw) To: Arend van Spriel Cc: Hector Martin, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel Hi Arend, On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <marcan@marcan.st> wrote: > > Newer Apple firmwares on chipsets without a hardware RNG require the > host to provide a buffer of 256 random bytes to the device on > initialization. This buffer is present immediately before NVRAM, > suffixed by a footer containing a magic number and the buffer length. > > This won't affect chips/firmwares that do not use this feature, so do it > unconditionally for all Apple platforms (those with an Apple OTP). Following on from the conversation a year ago, is there a way to detect chipsets that need these random bytes? While I'm sure Apple is doing their own special thing for special Apple reasons, it seems relatively sensible to omit a RNG on lower-cost chipsets, so would other chipsets need it? > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > Signed-off-by: Hector Martin <marcan@marcan.st> Beyond that, it all seems pretty sensible. Reviewed-by: Julian Calaby <julian.calaby@gmail.com> > --- > .../broadcom/brcm80211/brcmfmac/pcie.c | 32 +++++++++++++++++++ > 1 file changed, 32 insertions(+) Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device 2023-02-14 9:00 ` Julian Calaby @ 2023-02-14 9:08 ` Hector Martin 2023-02-14 9:11 ` Julian Calaby 0 siblings, 1 reply; 14+ messages in thread From: Hector Martin @ 2023-02-14 9:08 UTC (permalink / raw) To: Julian Calaby, Arend van Spriel Cc: Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel On 14/02/2023 18.00, Julian Calaby wrote: > Hi Arend, > > On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <marcan@marcan.st> wrote: >> >> Newer Apple firmwares on chipsets without a hardware RNG require the >> host to provide a buffer of 256 random bytes to the device on >> initialization. This buffer is present immediately before NVRAM, >> suffixed by a footer containing a magic number and the buffer length. >> >> This won't affect chips/firmwares that do not use this feature, so do it >> unconditionally for all Apple platforms (those with an Apple OTP). > > Following on from the conversation a year ago, is there a way to > detect chipsets that need these random bytes? While I'm sure Apple is > doing their own special thing for special Apple reasons, it seems > relatively sensible to omit a RNG on lower-cost chipsets, so would > other chipsets need it? I think we could include a list of chips known not to have the RNG (I think it's only the ones shipped on T2 machines). The main issue is I don't have access to those machines so it's hard for me to test exactly which ones need it. IIRC Apple's driver unconditionally provides the randomness. I could at least test the newer chips on AS platforms and figure out if they need it to exclude them... but then again, all I can do is test whether they work without the blob, but they might still want it (and simply become less secure without it). So I guess the answer is "maybe, I don't know, and it's kind of hard to know for sure"... the joys of reverse engineering hardware without vendor documentation. If you mean whether other chips with non-apple firmware can use this, I have no idea. That's probably something for Arend to answer. My gut feeling is Apple added this as part of a hardening mechanism and non-Apple firmware does not use it (and Broadcom then probably started shipping chips with a hardware RNG and firmware that uses it directly across all vendors), in which case the answer is no. - Hector ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device 2023-02-14 9:08 ` Hector Martin @ 2023-02-14 9:11 ` Julian Calaby 0 siblings, 0 replies; 14+ messages in thread From: Julian Calaby @ 2023-02-14 9:11 UTC (permalink / raw) To: Hector Martin Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel Hi Hector, On Tue, Feb 14, 2023 at 8:08 PM Hector Martin <marcan@marcan.st> wrote: > > On 14/02/2023 18.00, Julian Calaby wrote: > > Hi Arend, > > > > On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <marcan@marcan.st> wrote: > >> > >> Newer Apple firmwares on chipsets without a hardware RNG require the > >> host to provide a buffer of 256 random bytes to the device on > >> initialization. This buffer is present immediately before NVRAM, > >> suffixed by a footer containing a magic number and the buffer length. > >> > >> This won't affect chips/firmwares that do not use this feature, so do it > >> unconditionally for all Apple platforms (those with an Apple OTP). > > > > Following on from the conversation a year ago, is there a way to > > detect chipsets that need these random bytes? While I'm sure Apple is > > doing their own special thing for special Apple reasons, it seems > > relatively sensible to omit a RNG on lower-cost chipsets, so would > > other chipsets need it? > > I think we could include a list of chips known not to have the RNG (I > think it's only the ones shipped on T2 machines). The main issue is I > don't have access to those machines so it's hard for me to test exactly > which ones need it. IIRC Apple's driver unconditionally provides the > randomness. I could at least test the newer chips on AS platforms and > figure out if they need it to exclude them... but then again, all I can > do is test whether they work without the blob, but they might still want > it (and simply become less secure without it). > > So I guess the answer is "maybe, I don't know, and it's kind of hard to > know for sure"... the joys of reverse engineering hardware without > vendor documentation. > > If you mean whether other chips with non-apple firmware can use this, I > have no idea. That's probably something for Arend to answer. My gut > feeling is Apple added this as part of a hardening mechanism and > non-Apple firmware does not use it (and Broadcom then probably started > shipping chips with a hardware RNG and firmware that uses it directly > across all vendors), in which case the answer is no. Sorry, I should have been more clear, I wasn't expecting you to know, I was asking Arend if he knew. Thanks, -- Julian Calaby Email: julian.calaby@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/2] Apple T2 platform support 2023-02-14 8:00 [PATCH 0/2] Apple T2 platform support Hector Martin 2023-02-14 8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin 2023-02-14 8:00 ` [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin @ 2023-02-23 15:01 ` Aditya Garg 2023-02-23 15:04 ` Aditya Garg ` (2 more replies) 2 siblings, 3 replies; 14+ messages in thread From: Aditya Garg @ 2023-02-23 15:01 UTC (permalink / raw) To: Hector Martin Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel Hi Hector I’ve applied the following patchset (arranged in chronological order) to linux 6.2, and wifi seems to have broken on MacBookPro16,1 (brcmfmac4364b3) https://lore.kernel.org/asahi/20230212063813.27622-1-marcan@marcan.st/T/#t (BCM4355/4364/4377 support & identification fixes) https://lore.kernel.org/asahi/20230214080034.3828-1-marcan@marcan.st/T/#t (Apple T2 platform support) https://lore.kernel.org/asahi/20230214091651.10178-1-marcan@marcan.st/T/#t (BCM4387 / Apple M1 platform support) https://lore.kernel.org/asahi/b4489e24-e226-4f99-1322-cab6c1269f09@broadcom.com/T/#t (brcmfmac: cfg80211: Use WSEC to set SAE password) The logs show: Feb 23 20:08:57 MacBook kernel: usbcore: registered new interface driver brcmfmac Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: enabling device (0000 -> 0002) Feb 23 20:08:57 MacBook kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4364b3-pcie for chip BCM4364/4 Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.Apple Inc.-MacBookPro16,1.bin failed with error -2 Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.bin failed with error -2 Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_setup: Dongle setup failed I also tested the patchiest in the following link, and wifi mostly worked there (occasionally it complained about some pic error, I’ll save the logs next time I encounter that) : https://github.com/t2linux/linux-t2-patches/blob/main/8001-asahilinux-wifi-patchset.patch Thanks Aditya > On 14-Feb-2023, at 1:30 PM, Hector Martin <marcan@marcan.st> wrote: > > Hi all, > > This short series adds the missing bits to support Apple T2 platforms. > > There are two quirks: these devices have firmware that requires the > host to provide a blob of randomness as a seed (presumably because the > chipsets lack a proper RNG), and the module/antenna information that > is used for Apple firmware selection and comes from the Device Tree > on ARM64 systems (already upstream) needs to come from ACPI on these > instead. > > Changes since the megaseries from a ~year ago: made the ACPI code bail > if there is no module-instance, so we don't try to get the antenna > info at all in that case (as suggested by Arend). Made the randomness > conditional on an Apple OTP being present, since it's not known to be > needed on non-Apple firmware. > > Hector Martin (2): > brcmfmac: acpi: Add support for fetching Apple ACPI properties > brcmfmac: pcie: Provide a buffer of random bytes to the device > > .../broadcom/brcm80211/brcmfmac/Makefile | 2 + > .../broadcom/brcm80211/brcmfmac/acpi.c | 51 +++++++++++++++++++ > .../broadcom/brcm80211/brcmfmac/common.c | 1 + > .../broadcom/brcm80211/brcmfmac/common.h | 9 ++++ > .../broadcom/brcm80211/brcmfmac/pcie.c | 32 ++++++++++++ > 5 files changed, 95 insertions(+) > create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c > > -- > 2.35.1 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/2] Apple T2 platform support 2023-02-23 15:01 ` [PATCH 0/2] Apple T2 platform support Aditya Garg @ 2023-02-23 15:04 ` Aditya Garg [not found] ` <6588DEA1-673C-415E-A7AC-45CFBAA2B0F5@live.com> [not found] ` <BM1PR01MB09315D50C9380E9CB6471E9EB8A89@BM1PR01MB0931.INDPRD01.PROD.OUTLOOK.COM> 2 siblings, 0 replies; 14+ messages in thread From: Aditya Garg @ 2023-02-23 15:04 UTC (permalink / raw) To: Hector Martin Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel > On 23-Feb-2023, at 8:31 PM, Aditya Garg <gargaditya08@live.com> wrote: > > Hi Hector > > I’ve applied the following patchset (arranged in chronological order) to linux 6.2, > and wifi seems to have broken on MacBookPro16,1 (brcmfmac4364b3) > > https://lore.kernel.org/asahi/20230212063813.27622-1-marcan@marcan.st/T/#t (BCM4355/4364/4377 support & identification fixes) > > https://lore.kernel.org/asahi/20230214080034.3828-1-marcan@marcan.st/T/#t (Apple T2 platform support) > > https://lore.kernel.org/asahi/20230214091651.10178-1-marcan@marcan.st/T/#t (BCM4387 / Apple M1 platform support) > > https://lore.kernel.org/asahi/b4489e24-e226-4f99-1322-cab6c1269f09@broadcom.com/T/#t (brcmfmac: cfg80211: Use WSEC to set SAE password) > > > The logs show: > > Feb 23 20:08:57 MacBook kernel: usbcore: registered new interface driver brcmfmac > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: enabling device (0000 -> 0002) > Feb 23 20:08:57 MacBook kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4364b3-pcie for chip BCM4364/4 > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.Apple Inc.-MacBookPro16,1.bin failed with error -2 > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.bin failed with error -2 > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_setup: Dongle setup failed > > I also tested the patchiest in the following link, and wifi mostly worked there (occasionally it complained about some pic error, I’ll save the logs next time I encounter that) : > Sorry for the typos here (thanks to autocorrect) It says I also tested the *patchset* in the following link, and wifi mostly worked there (occasionally it complained about some *pci* error, I’ll save the logs next time I encounter that) : > > https://github.com/t2linux/linux-t2-patches/blob/main/8001-asahilinux-wifi-patchset.patch > > Thanks > Aditya > >> On 14-Feb-2023, at 1:30 PM, Hector Martin <marcan@marcan.st> wrote: >> >> Hi all, >> >> This short series adds the missing bits to support Apple T2 platforms. >> >> There are two quirks: these devices have firmware that requires the >> host to provide a blob of randomness as a seed (presumably because the >> chipsets lack a proper RNG), and the module/antenna information that >> is used for Apple firmware selection and comes from the Device Tree >> on ARM64 systems (already upstream) needs to come from ACPI on these >> instead. >> >> Changes since the megaseries from a ~year ago: made the ACPI code bail >> if there is no module-instance, so we don't try to get the antenna >> info at all in that case (as suggested by Arend). Made the randomness >> conditional on an Apple OTP being present, since it's not known to be >> needed on non-Apple firmware. >> >> Hector Martin (2): >> brcmfmac: acpi: Add support for fetching Apple ACPI properties >> brcmfmac: pcie: Provide a buffer of random bytes to the device >> >> .../broadcom/brcm80211/brcmfmac/Makefile | 2 + >> .../broadcom/brcm80211/brcmfmac/acpi.c | 51 +++++++++++++++++++ >> .../broadcom/brcm80211/brcmfmac/common.c | 1 + >> .../broadcom/brcm80211/brcmfmac/common.h | 9 ++++ >> .../broadcom/brcm80211/brcmfmac/pcie.c | 32 ++++++++++++ >> 5 files changed, 95 insertions(+) >> create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/acpi.c >> >> -- >> 2.35.1 >> >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <6588DEA1-673C-415E-A7AC-45CFBAA2B0F5@live.com>]
* Re: [PATCH 0/2] Apple T2 platform support [not found] ` <6588DEA1-673C-415E-A7AC-45CFBAA2B0F5@live.com> @ 2023-02-24 7:06 ` Aditya Garg 0 siblings, 0 replies; 14+ messages in thread From: Aditya Garg @ 2023-02-24 7:06 UTC (permalink / raw) To: Hector Martin Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, Asahi Linux, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, LKML, Orlando Chamberlain > > I also tested the *patchset* in the following link, and wifi mostly worked there (occasionally it complained about some *pci* error, I’ll save the logs next time I encounter that) : I got the logs as follows: Feb 24 12:04:50 MacBook kernel: usbcore: registered new interface driver brcmfmac Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: enabling device (0000 -> 0002) Feb 24 12:04:50 MacBook kernel: brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4364b3-pcie for chip BCM4364/4 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.apple,bali-HRPN-u-7.7-X3.bin failed with error -2 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.apple,bali-HRPN-u-7.7.bin failed with error -2 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.apple,bali-HRPN-u.bin failed with error -2 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.apple,bali-HRPN.bin failed with error -2 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for brcm/brcmfmac4364b3-pcie.apple,bali-X3.bin failed with error -2 Feb 24 12:04:50 MacBook kernel: brcmfmac_bca: brcmf_bca_attach: executing Feb 24 12:04:50 MacBook kernel: brcmfmac_bca: brcmf_bca_detach: executing Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_setup: Dongle setup failed Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 0000.853 EL: 30 3e84 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.853 Thread: wlan_thread(ID:0x54485244) run cnt:2 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.854 Thread: Stack:0029ff34 Start Addr:0029e000 End Addr:0029ffdf Size:8160 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.854 Thread: Entry func:0016f819 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.854 Thread: Timer:001ca70c Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.854 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: FWID 01-23419ed2 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: flags 78010007 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.854 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: TRAP 4(29fef8): pc 16e218, lr 16e205, sp 29ff50, cpsr 60000193, spsr 60000033 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.855 dfsr 80d, dfar 0 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.855 r0 1, r1 0, r2 160988, r3 0, r4 167f35, r5 1, r6 167f35 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.855 r7 0, r8 0, r9 0, r10 29e000, r11 80d, r12 0 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.855 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: sp+0 00280648 00019783 00000000 00167f35 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.856 sp+10 00280648 00168301 00236ec4 00000002 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.856 sp+4 00019783 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.856 sp+c 00167f35 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.856 sp+14 00168301 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.856 sp+2c 00019783 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.856 sp+34 0003910f Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.857 sp+44 0016f8e7 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.857 sp+4c 0003d1c5 Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.857 sp+60 0000c02b Feb 24 12:04:50 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_bus_console_read: CONSOLE: 000000.857 sp+6c 0003dfcd ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <BM1PR01MB09315D50C9380E9CB6471E9EB8A89@BM1PR01MB0931.INDPRD01.PROD.OUTLOOK.COM>]
* Re: [PATCH 0/2] Apple T2 platform support [not found] ` <BM1PR01MB09315D50C9380E9CB6471E9EB8A89@BM1PR01MB0931.INDPRD01.PROD.OUTLOOK.COM> @ 2023-02-24 13:11 ` Kalle Valo 2023-02-24 13:22 ` Aditya Garg 0 siblings, 1 reply; 14+ messages in thread From: Kalle Valo @ 2023-02-24 13:11 UTC (permalink / raw) To: Aditya Garg Cc: Hector Martin, Arend van Spriel, Franky Lin, Hante Meuleman, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel Aditya Garg <gargaditya08@live.com> writes: > On 23-Feb-2023, at 8:31 PM, Aditya Garg <gargaditya08@live.com> wrote: > > Hi Hector > > I’ve applied the following patchset (arranged in chronological order) to linux 6.2, > and wifi seems to have broken on MacBookPro16,1 (brcmfmac4364b3) > > https://lore.kernel.org/asahi/20230212063813.27622-1-marcan@marcan.st/T/#t > (BCM4355/4364/4377 support & identification fixes) > > https://lore.kernel.org/asahi/20230214080034.3828-1-marcan@marcan.st/T/#t (Apple T2 > platform support) > > https://lore.kernel.org/asahi/20230214091651.10178-1-marcan@marcan.st/T/#t (BCM4387 > / Apple M1 platform support) > > https://lore.kernel.org/asahi/b4489e24-e226-4f99-1322-cab6c1269f09@broadcom.com/T/#t > (brcmfmac: cfg80211: Use WSEC to set SAE password) > > The logs show: > > Feb 23 20:08:57 MacBook kernel: usbcore: registered new interface driver brcmfmac > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: enabling device (0000 -> 0002) > Feb 23 20:08:57 MacBook kernel: brcmfmac: brcmf_fw_alloc_request: using > brcm/brcmfmac4364b3-pcie for chip BCM4364/4 > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for > brcm/brcmfmac4364b3-pcie.Apple Inc.-MacBookPro16,1.bin failed with error -2 > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for > brcm/brcmfmac4364b3-pcie.bin failed with error -2 > Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_setup: Dongle setup > failed > > I also tested the patchiest in the following link, and wifi mostly worked there (occasionally it > complained about some pic error, I’ll save the logs next time I encounter that) : > > https://github.com/t2linux/linux-t2-patches/blob/main/8001-asahilinux-wifi-patchset.patch > > Thanks > Aditya > > I just noticed that the patch to ACPI was missing. Adding that fixed the issue. > > https://github.com/t2linux/linux-t2-patches/blob/main/8005-ACPI-property-Support-strings-in-Apple-_DSM-props.patch Please don't use HTML, our lists drop those. I'll reply in text/plain so that is info is archived. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/2] Apple T2 platform support 2023-02-24 13:11 ` Kalle Valo @ 2023-02-24 13:22 ` Aditya Garg 0 siblings, 0 replies; 14+ messages in thread From: Aditya Garg @ 2023-02-24 13:22 UTC (permalink / raw) To: Kalle Valo Cc: Hector Martin, Arend van Spriel, Franky Lin, Hante Meuleman, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Sven Peter, Alyssa Rosenzweig, Linus Walleij, asahi, linux-wireless, brcm80211-dev-list.pdl, SHA-cyfmac-dev-list, netdev, linux-kernel > On 24-Feb-2023, at 6:42 PM, Kalle Valo <kvalo@kernel.org> wrote: > > Aditya Garg <gargaditya08@live.com> writes: > >> On 23-Feb-2023, at 8:31 PM, Aditya Garg <gargaditya08@live.com> wrote: >> >> Hi Hector >> >> I’ve applied the following patchset (arranged in chronological order) to linux 6.2, >> and wifi seems to have broken on MacBookPro16,1 (brcmfmac4364b3) >> >> https://lore.kernel.org/asahi/20230212063813.27622-1-marcan@marcan.st/T/#t >> (BCM4355/4364/4377 support & identification fixes) >> >> https://lore.kernel.org/asahi/20230214080034.3828-1-marcan@marcan.st/T/#t (Apple T2 >> platform support) >> >> https://lore.kernel.org/asahi/20230214091651.10178-1-marcan@marcan.st/T/#t (BCM4387 >> / Apple M1 platform support) >> >> https://lore.kernel.org/asahi/b4489e24-e226-4f99-1322-cab6c1269f09@broadcom.com/T/#t >> (brcmfmac: cfg80211: Use WSEC to set SAE password) >> >> The logs show: >> >> Feb 23 20:08:57 MacBook kernel: usbcore: registered new interface driver brcmfmac >> Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: enabling device (0000 -> 0002) >> Feb 23 20:08:57 MacBook kernel: brcmfmac: brcmf_fw_alloc_request: using >> brcm/brcmfmac4364b3-pcie for chip BCM4364/4 >> Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for >> brcm/brcmfmac4364b3-pcie.Apple Inc.-MacBookPro16,1.bin failed with error -2 >> Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: Direct firmware load for >> brcm/brcmfmac4364b3-pcie.bin failed with error -2 >> Feb 23 20:08:57 MacBook kernel: brcmfmac 0000:05:00.0: brcmf_pcie_setup: Dongle setup >> failed >> >> I also tested the patchiest in the following link, and wifi mostly worked there (occasionally it >> complained about some pic error, I’ll save the logs next time I encounter that) : >> >> https://github.com/t2linux/linux-t2-patches/blob/main/8001-asahilinux-wifi-patchset.patch >> >> Thanks >> Aditya >> >> I just noticed that the patch to ACPI was missing. Adding that fixed the issue. >> >> https://github.com/t2linux/linux-t2-patches/blob/main/8005-ACPI-property-Support-strings-in-Apple-_DSM-props.patch > > Please don't use HTML, our lists drop those. I'll reply in text/plain so > that is info is archived. > Hi Sorry for that. I actually forgot to format that email as plain text. > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-02-27 10:41 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-14 8:00 [PATCH 0/2] Apple T2 platform support Hector Martin
2023-02-14 8:00 ` [PATCH 1/2] brcmfmac: acpi: Add support for fetching Apple ACPI properties Hector Martin
2023-02-14 9:04 ` Julian Calaby
2023-02-15 10:13 ` Linus Walleij
2023-02-27 10:41 ` [1/2] wifi: " Kalle Valo
2023-02-14 8:00 ` [PATCH 2/2] brcmfmac: pcie: Provide a buffer of random bytes to the device Hector Martin
2023-02-14 9:00 ` Julian Calaby
2023-02-14 9:08 ` Hector Martin
2023-02-14 9:11 ` Julian Calaby
2023-02-23 15:01 ` [PATCH 0/2] Apple T2 platform support Aditya Garg
2023-02-23 15:04 ` Aditya Garg
[not found] ` <6588DEA1-673C-415E-A7AC-45CFBAA2B0F5@live.com>
2023-02-24 7:06 ` Aditya Garg
[not found] ` <BM1PR01MB09315D50C9380E9CB6471E9EB8A89@BM1PR01MB0931.INDPRD01.PROD.OUTLOOK.COM>
2023-02-24 13:11 ` Kalle Valo
2023-02-24 13:22 ` Aditya Garg
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).