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
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 <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
---
.../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
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 <[email protected]>
---
.../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
Hi Arend,
On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <[email protected]> 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 <[email protected]>
> Signed-off-by: Hector Martin <[email protected]>
Beyond that, it all seems pretty sensible.
Reviewed-by: Julian Calaby <[email protected]>
> ---
> .../broadcom/brcm80211/brcmfmac/pcie.c | 32 +++++++++++++++++++
> 1 file changed, 32 insertions(+)
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
Hi Hector,
On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <[email protected]> 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 <[email protected]>
Makes sense to me.
Reviewed-by: Julian Calaby <[email protected]>
> ---
> .../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: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
On 14/02/2023 18.00, Julian Calaby wrote:
> Hi Arend,
>
> On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <[email protected]> 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
Hi Hector,
On Tue, Feb 14, 2023 at 8:08 PM Hector Martin <[email protected]> wrote:
>
> On 14/02/2023 18.00, Julian Calaby wrote:
> > Hi Arend,
> >
> > On Tue, Feb 14, 2023 at 7:04 PM Hector Martin <[email protected]> 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: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
On Tue, Feb 14, 2023 at 9:01 AM Hector Martin <[email protected]> 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 <[email protected]>
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 <[email protected]>
Yours,
Linus Walleij
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/[email protected]/T/#t (BCM4355/4364/4377 support & identification fixes)
https://lore.kernel.org/asahi/[email protected]/T/#t (Apple T2 platform support)
https://lore.kernel.org/asahi/[email protected]/T/#t (BCM4387 / Apple M1 platform support)
https://lore.kernel.org/asahi/[email protected]/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 <[email protected]> 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
>
>
> On 23-Feb-2023, at 8:31 PM, Aditya Garg <[email protected]> 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/[email protected]/T/#t (BCM4355/4364/4377 support & identification fixes)
>
> https://lore.kernel.org/asahi/[email protected]/T/#t (Apple T2 platform support)
>
> https://lore.kernel.org/asahi/[email protected]/T/#t (BCM4387 / Apple M1 platform support)
>
> https://lore.kernel.org/asahi/[email protected]/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 <[email protected]> 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
>>
>>
>
>
> 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
Aditya Garg <[email protected]> writes:
> On 23-Feb-2023, at 8:31 PM, Aditya Garg <[email protected]> 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/[email protected]/T/#t
> (BCM4355/4364/4377 support & identification fixes)
>
> https://lore.kernel.org/asahi/[email protected]/T/#t (Apple T2
> platform support)
>
> https://lore.kernel.org/asahi/[email protected]/T/#t (BCM4387
> / Apple M1 platform support)
>
> https://lore.kernel.org/asahi/[email protected]/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
> On 24-Feb-2023, at 6:42 PM, Kalle Valo <[email protected]> wrote:
>
> Aditya Garg <[email protected]> writes:
>
>> On 23-Feb-2023, at 8:31 PM, Aditya Garg <[email protected]> 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/[email protected]/T/#t
>> (BCM4355/4364/4377 support & identification fixes)
>>
>> https://lore.kernel.org/asahi/[email protected]/T/#t (Apple T2
>> platform support)
>>
>> https://lore.kernel.org/asahi/[email protected]/T/#t (BCM4387
>> / Apple M1 platform support)
>>
>> https://lore.kernel.org/asahi/[email protected]/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
Hector Martin <[email protected]> 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 <[email protected]>
> Reviewed-by: Julian Calaby <[email protected]>
> Acked-by: Linus Walleij <[email protected]>
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/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches