aboutsummaryrefslogtreecommitdiffstats
path: root/package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch
diff options
context:
space:
mode:
authorRafał Miłecki <rafal@milecki.pl>2019-01-08 08:27:26 +0100
committerRafał Miłecki <rafal@milecki.pl>2019-01-08 09:17:11 +0100
commitadc8b374e3818a3d71dde22de6d2b8a72ccaf540 (patch)
treecc398f6758950175e860accdf15781ccf56dae18 /package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch
parentdf57d71a1a7147091b18d921d9edf7459aadacc1 (diff)
downloadupstream-adc8b374e3818a3d71dde22de6d2b8a72ccaf540.tar.gz
upstream-adc8b374e3818a3d71dde22de6d2b8a72ccaf540.tar.bz2
upstream-adc8b374e3818a3d71dde22de6d2b8a72ccaf540.zip
mac80211: brcmfmac: backport fixes from the 5.0-rc1
This fixes: 1) Getting STA info with newer firmwares 2) Getting DMI / UEFI / OF data 3) Possible memory corruption in firmware loading code Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Diffstat (limited to 'package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch')
-rw-r--r--package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch39
1 files changed, 39 insertions, 0 deletions
diff --git a/package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch b/package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch
new file mode 100644
index 0000000000..01621561c1
--- /dev/null
+++ b/package/kernel/mac80211/patches/brcm/326-v5.0-brcmfmac-Call-brcmf_dmi_probe-before-brcmf_of_probe.patch
@@ -0,0 +1,39 @@
+From 554da3868eb1d7174710c18b4ddd6ff01f6d612c Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 23 Nov 2018 10:11:48 +0100
+Subject: [PATCH] brcmfmac: Call brcmf_dmi_probe before brcmf_of_probe
+
+ARM systems with UEFI may have both devicetree (of) and DMI data in this
+case we end up setting brcmf_mp_device.board_type twice.
+
+In this case we should prefer the devicetree data, because:
+1) The devicerree data is more reliable
+2) Some ARM systems (e.g. the Raspberry Pi 3 models) support both UEFI and
+ classic uboot booting, the devicetree data is always there, so using it
+ makes sure we ask for the same nvram file independent of how we booted.
+
+This commit moves the brcmf_dmi_probe call to before the brcmf_of_probe
+call, so that the latter can override the value of the first if both are
+set.
+
+Fixes: bd1e82bb420a ("brcmfmac: Set board_type from DMI on x86 based ...")
+Cc: Peter Robinson <pbrobinson@gmail.com>
+Tested-and-reported-by: Peter Robinson <pbrobinson@gmail.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+@@ -449,8 +449,8 @@ struct brcmf_mp_device *brcmf_get_module
+ }
+ if (!found) {
+ /* No platform data for this device, try OF and DMI data */
+- brcmf_of_probe(dev, bus_type, settings);
+ brcmf_dmi_probe(settings, chip, chiprev);
++ brcmf_of_probe(dev, bus_type, settings);
+ }
+ return settings;
+ }