Re: BCM4331 reset leads to wl lockup

[Lukas Wunner]

[cc += Eric Dumazet]

On Sun, May 29, 2016 at 08:55:01PM +0200, Arend van Spriel wrote:
> On 29-05-16 13:02, Lukas Wunner wrote:
> > On Thu, May 26, 2016 at 02:42:46PM +0200, Michael Büsch wrote:
> >> On Thu, 26 May 2016 14:12:10 +0200 Lukas Wunner <lu...@wunner.de> wrote:
> >>> + mmio = early_ioremap(addr, BCM4331_MMIO_SIZE);
> >>> + if (!mmio) {
> >>> + pr_err("Cannot iomap Apple AirPort card\n");
> >>> + return;
> >>> + }
> >>> + pr_info("Resetting Apple AirPort card\n");
> >>> + iowrite32(BCMA_RESET_CTL_RESET,
> >>> +   mmio + (1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL);
> >>> + early_iounmap(mmio, BCM4331_MMIO_SIZE);
> >>
> >> Just writing that bit is not the correct reset procedure.
> >> So it might cause problems depending on how wl does the core reset
> >> later.
> >>
> >> Please try this:
> >> - wait for BCMA_RESET_ST to be 0
> >> - set reset bit
> >> - flush
> >> - wait 1us
> >> - reset reset bit
> >> - flush
> >> - wait 10us
> >>
> >> See bcma_core_disable()
> > 
> > It turned out that the lockups are triggered by bec3cfdca36b
> > ("net: skb_segment() provides list head and tail") in Linux 3.18
> > and that Eric Dumazet has kindly provided a fix for broadcom-sta:
> > https://bugs.gentoo.org/show_bug.cgi?id=523326#c24
> > https://523326.bugs.gentoo.org/attachment.cgi?id=393374
> 
> Looked at the patch and it provides little context. So before diving in
> the code would you know if the patched broadcom-sta driver works for
> kernels before 3.18?

I'm not familiar with the broadcom-sta code but I'm inclined to say yes.

The function modified by the patch, wl_start(), contains an if/else
statement, the if-branch puts a packet to be transmitted on a work
queue and the else-branch transmits it straight away. Apparently
skb->prev isn't initialized to NULL for the else-branch which wasn't
an issue until bec3cfdca36b. That's my superficial understanding of
that code, I'm sure you have access to the full source and revision
history and can make more sense of it than I do.

Best regards,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BCM4331 reset leads to wl lockup

[Lukas Wunner]

On Thu, May 26, 2016 at 02:42:46PM +0200, Michael Büsch wrote:
> On Thu, 26 May 2016 14:12:10 +0200 Lukas Wunner <lu...@wunner.de> wrote:
> > +   mmio = early_ioremap(addr, BCM4331_MMIO_SIZE);
> > +   if (!mmio) {
> > +   pr_err("Cannot iomap Apple AirPort card\n");
> > +   return;
> > +   }
> > +   pr_info("Resetting Apple AirPort card\n");
> > +   iowrite32(BCMA_RESET_CTL_RESET,
> > + mmio + (1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL);
> > +   early_iounmap(mmio, BCM4331_MMIO_SIZE);
> 
> Just writing that bit is not the correct reset procedure.
> So it might cause problems depending on how wl does the core reset
> later.
> 
> Please try this:
> - wait for BCMA_RESET_ST to be 0
> - set reset bit
> - flush
> - wait 1us
> - reset reset bit
> - flush
> - wait 10us
> 
> See bcma_core_disable()

It turned out that the lockups are triggered by bec3cfdca36b
("net: skb_segment() provides list head and tail") in Linux 3.18
and that Eric Duzamet has kindly provided a fix for broadcom-sta:
https://bugs.gentoo.org/show_bug.cgi?id=523326#c24
https://523326.bugs.gentoo.org/attachment.cgi?id=393374

@Broadcom: Please consider releasing a new driver version which
incorporates that patch. The latest version 6.30.223.271 of your
driver is still missing it even though the issue has existed for
almost 18 months now.

Nevertheless I amended my patch to follow the reset procedure you
specified above, just to cover all bases. Thanks Michael.

Best regards,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] x86: Add early quirk to reset Apple AirPort card

[Lukas Wunner]

2  15" [Root Port 00:1c.1 = 8086:1e12]
MacBookPro10,2  2012  13" [Root Port 00:1c.1 = 8086:1e12]

For posterity, spurious interrupts caused by the Broadcom 4331 wireless
card resulted in splats like this (stacktrace omitted):
irq 17: nobody cared (try booting with the "irqpoll" option)
handlers:
[] pcie_isr
[] sdhci_irq [sdhci] threaded [] 
sdhci_thread_irq [sdhci]
[] azx_interrupt [snd_hda_codec]
Disabling IRQ #17

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732
Cc: Chris Milsted <cmils...@redhat.com>
Cc: Matthew Garrett <mj...@srcf.ucam.org>
Cc: Andi Kleen <a...@linux.intel.com>
Cc: Michael Buesch <m...@bues.ch>
Cc: Bjorn Helgaas <bhelg...@google.com>
Cc: Matt Fleming <m...@codeblueprint.co.uk>
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
Tested-by: Konstantin Simanov <k.sima...@stlk.ru># [MacBookPro8,1]
Tested-by: Lukas Wunner <lu...@wunner.de># [MacBookPro9,1]
Tested-by: Bryan Paradis <bryan.para...@gmail.com>   # [MacBookPro9,2]
Tested-by: Andrew Worsley <amwors...@gmail.com>      # [MacBookPro10,1]
Tested-by: Chris Bainbridge <chris.bainbri...@gmail.com> # [MacBookPro10,2]
Signed-off-by: Lukas Wunner <lu...@wunner.de>
Acked-by: Rafał Miłecki <zaj...@gmail.com>
---
 arch/x86/kernel/early-quirks.c | 98 --
 drivers/bcma/bcma_private.h|  2 -
 include/linux/bcma/bcma.h  |  1 +
 3 files changed, 86 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bca14c8..2d44f28 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -11,7 +11,11 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void __init fix_hypertransport_config(int num, int slot, int func)
 {
@@ -76,6 +81,13 @@ static void __init nvidia_bugs(int num, int slot, int func)
 #ifdef CONFIG_ACPI
 #ifdef CONFIG_X86_IO_APIC
/*
+* Only applies to Nvidia root ports (bus 0) and not to
+* Nvidia graphics cards with PCI ports on secondary buses.
+*/
+   if (num)
+   return;
+
+   /*
 * All timer overrides on Nvidia are
 * wrong unless HPET is enabled.
 * Unfortunately that's not true on many Asus boards.
@@ -590,6 +602,57 @@ static void __init force_disable_hpet(int num, int slot, 
int func)
 #endif
 }
 
+#define BCM4331_MMIO_SIZE  16384
+#define BCM4331_PM_CAP 0x40
+#define bcma_aread32(reg)  ioread32(mmio + 1 * BCMA_CORE_SIZE + reg)
+#define bcma_awrite32(reg, val)iowrite32(val, mmio + 1 * 
BCMA_CORE_SIZE + reg)
+
+static void __init apple_airport_reset(int bus, int slot, int func)
+{
+   void __iomem *mmio;
+   u16 pmcsr;
+   u64 addr;
+   int i;
+
+   if (!dmi_match(DMI_SYS_VENDOR, "Apple Inc."))
+   return;
+
+   /* Card may have been put into PCI_D3hot by grub quirk */
+   pmcsr = read_pci_config_16(bus, slot, func,
+  BCM4331_PM_CAP + PCI_PM_CTRL);
+   if ((pmcsr & PCI_PM_CTRL_STATE_MASK) != PCI_D0) {
+   pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
+   write_pci_config_16(bus, slot, func,
+   BCM4331_PM_CAP + PCI_PM_CTRL, pmcsr);
+   mdelay(10);
+   pmcsr = read_pci_config_16(bus, slot, func,
+  BCM4331_PM_CAP + PCI_PM_CTRL);
+   if ((pmcsr & PCI_PM_CTRL_STATE_MASK) != PCI_D0) {
+   pr_err("Cannot power up Apple AirPort card\n");
+   return;
+   }
+   }
+
+   addr  =  read_pci_config(bus, slot, func, PCI_BASE_ADDRESS_0);
+   addr |= (u64)read_pci_config(bus, slot, func, PCI_BASE_ADDRESS_1) << 32;
+   addr &= PCI_BASE_ADDRESS_MEM_MASK;
+   mmio = early_ioremap(addr, BCM4331_MMIO_SIZE);
+   if (!mmio) {
+   pr_err("Cannot iomap Apple AirPort card\n");
+   return;
+   }
+
+   pr_info("Resetting Apple AirPort card\n");
+   for (i = 0; bcma_aread32(BCMA_RESET_ST) && i < 30; i++)
+   udelay(10);
+   bcma_awrite32(BCMA_RESET_CTL, BCMA_RESE

BCM4331 reset leads to wl lockup

[Lukas Wunner]

Dear Broadcom support,

on Macs equipped with a BCM4331, a reset of the wireless core is needed
early in the boot process to prevent spurious IRQs and memory corruption.
This is achieved by the below patch.

Unfortunately the patch seems to cause a lockup with wl depending on the
amount of traffic transmitted: A user has reported that when sending only
pings, everything works fine. However a larger amount of traffic such as
opening a website in a browser causes the system to lock up.

The issue only occurs with wl, not the open source b43 driver. All the
patch does is set the reset bit ((1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL)
in the wireless core's mmio space.

Please advise how the patch should be amended to avoid the lockups.

Thanks,

Lukas

-- >8 --
>From 37ddc5de665e155df1ceee475d851a21f16c4aba Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lu...@wunner.de>
Date: Mon, 23 May 2016 19:05:00 +0200
Subject: [PATCH] x86: Add early quirk to reset Apple AirPort card
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from osrecovery.apple.com. Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The card continues to assert its IRQ
line, causing spurious interrupts if the IRQ is shared. It also corrupts
memory by DMAing received packets, allowing for remote code execution
over the air. This only stops when a driver is loaded for the wireless
card, which may be never if the driver is not installed or blacklisted.

The issue seems to be constrained to the Broadcom 4331. Chris Milsted
has verified that the newer Broadcom 4360 built into the MacBookPro11,3
(2013/2014) does not exhibit this behaviour. The chances that Apple will
ever supply a firmware fix for the older machines appear to be zero.

The solution is to reset the card on boot by writing to a reset bit in
its mmio space. This must be done as an early quirk and not as a plain
vanilla PCI quirk to successfully combat memory corruption by DMAed
packets: Matthew Garrett found out in 2012 that the packets are written
to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
This type of memory is made available to the page allocator by
efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
subsys initcall level. In-between a time window would be open for memory
corruption. Random crashes occurring in this time window and attributed
to DMAed packets have indeed been observed in the wild by Chris
Bainbridge.

When Matthew Garrett analyzed the memory corruption issue in 2012, he
sought to fix it with a grub quirk which transitions the card to D3hot:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56

This approach does not help users with other bootloaders and while it
may prevent DMAed packets, it does not cure the spurious interrupts
emanating from the card. Unfortunately the card's mmio space is
inaccessible in D3hot, so to reset it, we have to undo the effect of
Matthew's grub patch and transition the card back to D0.

Since commit 8659c406ade3 ("x86: only scan the root bus in early PCI
quirks"), early quirks can only be applied to devices on the root bus.
However the Broadcom 4331 card is located on a secondary bus behind a
PCIe root port. The present commit therefore reintroduces scanning of
secondary buses. The primary motivation of 8659c406ade3 was to prevent
application of the nvidia_bugs() quirk on secondary buses. Amend the
quirk to open code this requirement.

A secondary motivation was to speed up PCI scanning. The algorithm used
prior to 8659c406ade3 was particularly time consuming because it scanned
buses 0 to 31 brute force. The recursive algorithm used by the present
commit only scans buses that are actually reachable from the root bus
and should thus be a bit faster. If this algorithm is found to
significantly impact boot time, it would be possible to limit its
recursion depth: The Apple AirPort quirk applies at depth 1, all others
at depth 0, so the bus need not be scanned deeper than that for now. An
alternative approach would be to continue scanning only the root bus,
and apply the AirPort quirk to the root ports 8086:1c12, 8086:1e12 and
8086:1e16. Apple always positioned the Broadcom 4331 behind one of these
three ports (see model list below). The quirk would then check presence
of the Broadcom 4331 in slot 0 below the root port and do its deed.

Note that the quirk takes a few shortcuts to reduce the amount of code:
The size of BAR 0 and the location of the PM capability is identical
on all affected machines and therefore hardcoded. Only the address of
BAR 0 differs between models. Also, it is assumed that the BCMA core
currently mapped is the 802.11 core. The EFI driver seems to always take
care of this.

Michael BÃŒsch, 

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi Andrew,

On Sun, Apr 24, 2016 at 07:04:23PM +0200, Lukas Wunner wrote:
> On Thu, Apr 14, 2016 at 06:42:50AM +1000, Andrew Worsley wrote:
> > The only time I am getting the IRQ 17 nobody cared message is on
> > suspend / resume. A fresh boot always had below the 100k interrupt
> > threshold level.
> > 
> > I tried your new patch and the number is even lower < 30,000 over two boots.
> 
> Hm, that's still way too much. You should have < 100 interrupts on IRQ 17
> on *every* boot, anything else isn't satisfactory.

The reason why my previous patches didn't work on your machine is
because you're using grub, and grub contains a patch by Matthew
Garrett which puts the wireless card into power state D3hot. The
card's mmio space isn't accessible in D3hot. Included below is a
new patch which transitions the card to D0 before resetting it.
Please let me know if this fixes the issue for you.

@Chris Bainbridge: Please test this as well, this is no longer a
plain vanilla PCI quirk but an early quirk, it should prevent any
kind of memory corruption by DMAed packets.

Best regards,

Lukas

-- >8 --
Subject: [PATCH] x86: Add early quirk to reset Apple AirPort card
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from osrecovery.apple.com. Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The card continues to assert its
IRQ, causing spurious interrupts if the IRQ is shared. It also
corrupts memory by DMAing received packets.

The issue seems to be constrained to the Broadcom 4331. Chris Milsted
has verified that the newer Broadcom 4360 built into the MacBookPro11,3
(2013/2014) does not exhibit this behaviour. The chances that Apple will
ever supply a firmware fix for the older machines appear to be zero.

The solution is to reset the card on boot by writing to a reset bit in
its mmio space. This must be done as an early quirk and not as a plain
vanilla PCI quirk to prevent memory corruption by DMAed packets:
Matthew Garrett found out in 2012 that the packets are written to
EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
This type of memory is made available to the page allocator by
efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
subsys initcall level. In-between a time window would be open for memory
corruption. Random crashes occuring in this time window and attributed
to DMAed packets have indeed been observed in the wild by Chris
Bainbridge.

When Matthew Garrett analyzed the memory corruption issue in 2012, he
sought to fix it with a grub quirk which transitions the card to D3hot:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56

While this may prevent DMAed packets, it does not cure the spurious
interrupts emanating from the card. Unfortunately the card's mmio space
is inaccessible during D3hot, so to reset it, we have to undo the effect
of Matthew's patch and transition the card back to D0 if the system was
booted with grub.

Since commit 8659c406ade3 ("x86: only scan the root bus in early PCI
quirks"), early quirks can only be applied to devices on the root bus.
However the Broadcom 4331 card is located on a secondary bus behind a
PCIe root port. This commit therefore reintroduces scanning of secondary
buses. The primary motivation of 8659c406ade3 was to prevent application
of the nvidia_bugs() quirk on secondary buses. Amend the quirk to open
code this requirement.

A secondary motivation was to speed up PCI scanning. The algorithm used
prior to 8659c406ade3 was particularly time consuming because it scanned
buses 0 to 31 brute force. The recursive algorithm used by this commit
only scans buses that are actually reachable from the root bus and
should thus be a bit faster. If this algorithm is found to significantly
impact boot time, it would be possible to limit its recursion depth:
The Apple AirPort quirk applies at depth 1, all others at depth 0,
so the bus need not be scanned deeper than that for now. An alternative
approach would be to continue scanning only the root bus, and apply the
AirPort quirk to the root ports 8086:1c12, 8086:1e12 and 8086:1e16.
Apple always positioned the Broadcom 4331 behind one of these three
ports (see model list below). The quirk would then check presence of the
Broadcom 4331 in slot 0 below the root port and do its deed.

Note that the quirk takes a few shortcuts to reduce the amount of code:
The size of BAR 0 and the location of the PM capability is identical
on all affected machines and therefore hardcoded. Only the address of
BAR 0 differs between models. Also, it is assumed that the BCMA core
currently mapped is the 802.11 core. The EFI driver seems to always take
care of this.

Michael BÃŒsch an

[PATCH] mwifiex: Drop unnecessary include pcieport_if.h

[Lukas Wunner]

This header file is only needed for drivers binding to a PCI bridge
device allocated by drivers/pci/pcie/portdrv_core.c. The mwifiex driver
doesn't do that nor use any symbols defined in pcieport_if.h.

Cc: Amitkumar Karwar <akar...@marvell.com>
Cc: Nishant Sarmukadam <nisha...@marvell.com>
Signed-off-by: Lukas Wunner <lu...@wunner.de>
---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 6fc2873..1ccd5ad 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -23,7 +23,6 @@
 #define_MWIFIEX_PCIE_H
 
 #include
-#include
 #include
 
 #include"main.h"
-- 
2.8.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi Andrew,

On Thu, Apr 14, 2016 at 06:42:50AM +1000, Andrew Worsley wrote:
> The only time I am getting the IRQ 17 nobody cared message is on
> suspend / resume. A fresh boot always had below the 100k interrupt
> threshold level.
> 
> I tried your new patch and the number is even lower < 30,000 over two boots.

Hm, that's still way too much. You should have < 100 interrupts on IRQ 17
on *every* boot, anything else isn't satisfactory. I'm working on a patch
that runs before EFI ExitBootServices() but will need a little longer to
find an optimal solution.


> Have you any insights on fixing suspend to disk  / resume paths which
> presumably face the same issue of being passed live hardware on boot
> up?

Suspend to disk involves two kernels, the boot kernel and the image kernel.
Perhaps these two are not the same on your machine and you've only compiled
the patch into one of them?

Best regards,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi,

On Sat, Apr 09, 2016 at 01:00:55PM +0100, Matt Fleming wrote:
> On Wed, 06 Apr, at 11:30:29PM, Lukas Wunner wrote:
> > (2) Find out exactly which EFI boot services area is used for DMA and
> > amend arch/x86/platform/efi/quirks.c:efi_apply_memmap_quirks() to
> > assign that area a different type if dmi_match(DMI_SYS_VENDOR,
> > "Apple Inc."). That way it's not freed by efi_free_boot_services().
> > Add a late_initcall which calls free_bootmem() for that area.
>  
> If it is possible to find out which boot services region is the
> problematic one, this would be the best solution. If there's any way
> to tie it into the PCI quirk, that would be even better so we don't
> need to maintain the blacklist in two places.

I've since cooked up an experimental patch which resets the Broadcom 4331
wireless card from arch/x86/kernel/early-quirks.c, and another which does
the same from arch/x86/boot/compressed/eboot.c. Both approaches stopped
the spurious interrupts for me and should also stop the DMA'ing.

In the latter case, the machine locked up immediately after resetting the
card. Suspecting that the EFI driver doesn't digest the reset well,
I tried kicking it off the card with DisconnectController() first.
This worked, although it returns EFI_NOT_FOUND, which is strange as that
error isn't defined for DisconnectController() per the spec.

I then tested if DisconnectController() alone is already sufficient
(i.e. without resetting the card by writing to its mmio).
Guess what, it is. So the EFI driver seems to leave the card in a
sane state if it's unloaded.

I then realized that the Simple Network protocol is supported for both
the wireless card as well as the Ethernet card built into my MacBook Pro.
What I'll try next is to iterate over all handles that support that
protocol and just Stop() the interface if it's been brought up by EFI.

Perhaps OS X supports some kind of connection handover from EFI.
That would explain why they leave the card enabled.

Best regards,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi Andrew,

thank you for the extensive testing.

On Sun, Apr 10, 2016 at 08:09:29PM +1000, Andrew Worsley wrote:
> Further testing Broadcom 4331 reset quirk to prevent IRQ storm patch
> testing reveals that:
>   1. quirk is run on initial boot up and this time appears to have
> vastly reduced the interrupts (only 81 this time):
> cat /proc/interrupts| grep 17
>  17: 81  0  0  0  0  0
>  0  0   IO-APIC-fasteoi   snd_hda_intel

Something in the ballpark of 81 interrupt requests is fine.

The kernel will print the error message about spurious interrupts and
switch to polling at 10 requests. But even 2 is way too much.
This just means that b43 loaded quickly enough to stop the interrupts
before the kernel limit of 10 was reached, but the wireless card
wasn't reset early on as it should have been.

It looks like the patch didn't work at all on your machine for some
reason. Do you see a message "cannot iomap device, IRQ storm ahead"
in dmesg?

Included below is a slightly different patch which is based on the
3.16.7-ckt tree (so it should apply cleanly to your kernel version).
This version prints a message when the wireless card is reset. Please
verify that you see the message "b43 quirk: resetting controller" in
dmesg with this patch. This version of the patch also resets the card
a bit earlier in the boot process than the previous version did.
Please let me know if this improves the situation on your machine.

You might also want to try a newer kernel version, 3.16 is very old
and I'm not sure if there have been any changes since which might
negatively impact proper functioning of the patch. There are also
official 4.4 kernels available for Jessie. Canonical ends support
for the 3.16.y-ckt series anyway this month.


> Presently I have a grub work around for black screen as described here:
>   
> http://askubuntu.com/questions/264247/proprietary-nvidia-drivers-with-efi-on-mac-to-prevent-overheating/613573#613573
> 
> which basically involves adding a grub scriptlet to enable PCI-E bus
> mastering on graphics cards:
> 
> In /etc/grub.d/01_enable_vga.conf:
> 
> setpci -s "00:01.0" 3e.b=8
> setpci -s "01:00.0" 04.b=7

I think you need to upgrade to a newer version of the Nvidia driver,
I have just verified that 352.63 will set the busmaster bit if it's
cleared.


> Can we do some similar magic setpci commands to disable 04:00.0
> which is my BCM4331

I think grub is also able to write to mmio space of a PCI device,
which is what's necessary to reset the wireless card, so theoretically
yes, but the right place to fix this is in the kernel since not
everyone is using grub.

Best regards,

Lukas

-- >8 --
Subject: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
on boot until they are reset, causing spurious interrupts if the IRQ is
shared. Apparently the EFI bootloader enables the device and does not
disable it before passing control to the OS. The bootloader contains a
driver for the wireless card which allows it to phone home to Cupertino.
This is used for Internet Recovery (download and install OS X images)
and probably also for Back to My Mac (remote access, RFC 6281) and to
discover stolen hardware.

The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
reader, HDA card on discrete GPU). As soon as an interrupt handler is
installed for one of these devices, the ensuing storm of spurious IRQs
causes the kernel to disable the IRQ and switch to polling. This lasts
until the b43 driver loads and resets the device.

Loading the b43 driver first is not always an option, in particular with
the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
installed early on because it is built in, unlike b43 which is usually
a module.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
Cc: <sta...@vger.kernel.org>
Tested-by: Lukas Wunner <lu...@wunner.de> [MacBookPro9,1]
Signed-off-by: Lukas Wunner <lu...@wunner.de>
Acked-by: Rafał Miłecki <zaj...@gmail.com>
---
 drivers/bcma/bcma_private.h |  2 --
 drivers/pci/quirks.c| 28 
 include/linux/bcma/bcma.h   |  1 +
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index 09b632a..7ded994 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -8,8 +8,6 @@
 #include 
 #include 
 
-#define BCMA_CORE_SIZE 0x1000
-
 #define bcma_err(bus, fmt, ...) \
pr_er

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi,

On Wed, Apr 06, 2016 at 05:17:24PM +0200, Michael Büsch wrote:
> On Wed, 6 Apr 2016 08:31:51 -0500 Bjorn Helgaas  wrote:
>
> > Even for interrupts, it's only a 90% solution because we do still get
> > a few interrupts before the quirk runs.  There may not be enough to
> > trigger the "IRQ nobody cared" check,
> 
> If no driver requested the shared interrupt yet, it should be disabled
> in the interrupt controller. So the interrupts do not reach the CPU.
> The interrupt storm (on the CPU) starts as soon as some driver
> that shares the interrupt with b43 requests and thus enables the
> interrupt. And that always happens after the PCI fixup. Thus this is
> safe.

Yes, that is correct. I only see 67 interrupts for IRQ 17 with the
PCI quirk compiled in, all of which seem to come from the initialization
of pciehp, mmc and the hda sound card (which share the IRQ with b43 on my
machine).

Thanks,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

[+cc Matt Fleming, linux-efi]

Hi Bjorn,

On Tue, Apr 05, 2016 at 02:40:15PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 29, 2016 at 08:20:30PM +0200, Lukas Wunner wrote:
> > Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> > on boot until they are reset, causing spurious interrupts if the IRQ is
> > shared. Apparently the EFI bootloader enables the device and does not
> > disable it before passing control to the OS. The bootloader contains a
> > driver for the wireless card which allows it to phone home to Cupertino.
> > This is used for Internet Recovery (download and install OS X images)
> > and probably also for Back to My Mac (remote access, RFC 6281) and to
> > discover stolen hardware.
> > 
> > The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
> > is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
> > reader, HDA card on discrete GPU). As soon as an interrupt handler is
> > installed for one of these devices, the ensuing storm of spurious IRQs
> > causes the kernel to disable the IRQ and switch to polling. This lasts
> > until the b43 driver loads and resets the device.
> > 
> > Loading the b43 driver first is not always an option, in particular with
> > the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
> > installed early on because it is built in, unlike b43 which is usually
> > a module.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
> > Tested-by: Lukas Wunner <lu...@wunner.de> [MacBookPro9,1]
> > Signed-off-by: Lukas Wunner <lu...@wunner.de>
> > ---
> >  drivers/bcma/bcma_private.h |  2 --
> >  drivers/pci/quirks.c| 27 +++
> >  include/linux/bcma/bcma.h   |  1 +
> >  3 files changed, 28 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
> > index eda0909..f642c42 100644
> > --- a/drivers/bcma/bcma_private.h
> > +++ b/drivers/bcma/bcma_private.h
> > @@ -8,8 +8,6 @@
> >  #include 
> >  #include 
> >  
> > -#define BCMA_CORE_SIZE 0x1000
> > -
> >  #define bcma_err(bus, fmt, ...) \
> > pr_err("bus%d: " fmt, (bus)->num, ##__VA_ARGS__)
> >  #define bcma_warn(bus, fmt, ...) \
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 8e67802..d4fb5ee 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -25,6 +25,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include/* isa_dma_bridge_buggy */
> >  #include "pci.h"
> >  
> > @@ -3282,6 +3284,31 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 
> > 0x156d,
> >quirk_apple_wait_for_thunderbolt);
> >  #endif
> >  
> > +/*
> > + * Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> > + * on boot until they are reset, causing spurious interrupts if the IRQ is
> > + * shared. Apparently the EFI bootloader enables the device to phone home
> > + * to Cupertino and does not disable it before passing control to the OS.
> > + */
> > +static void quirk_apple_b43_reset(struct pci_dev *dev)
> > +{
> > +   void __iomem *mmio;
> > +
> > +   if (!dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") || !dev->bus->self ||
> > +   pci_pcie_type(dev->bus->self) != PCI_EXP_TYPE_ROOT_PORT)
> > +   return;
> > +
> > +   mmio = pci_iomap(dev, 0, 0);
> > +   if (!mmio) {
> > +   pr_err("b43 quirk: Cannot iomap device, IRQ storm ahead\n");
> > +   return;
> > +   }
> > +   iowrite32(BCMA_RESET_CTL_RESET,
> > + mmio + (1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL);
> > +   pci_iounmap(dev, mmio);
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=111781 and
> https://mjg59.dreamwidth.org/11235.html describe a sort of similar
> issue, but with DMA.  An interrupt from the device is probably to
> signal a DMA completion, but these problem reports only mention the
> "IRQ nobody cared" issue; I don't see anything about memory
> corruption.
> 
> If this resets the device, I guess that should prevent future DMA as
> well as future interrupts.  Would pci_reset_function() do the same
> thing in a more ge

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi Andrew,

On Sat, Apr 02, 2016 at 10:40:41PM +1100, Andrew Worsley wrote:
> On 30 March 2016 at 04:41, Lukas Wunner <lu...@wunner.de> wrote:
> > Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> > on boot until they are reset, causing spurious interrupts if the IRQ is
> > shared. Apparently the EFI bootloader enables the device and does not
> > disable it before passing control to the OS. The bootloader contains a
> > driver for the wireless card which allows it to phone home to Cupertino.
> > This is used for Internet Recovery (download and install OS X images)
> > and probably also for Back to My Mac (remote access, RFC 6281) and to
> > discover stolen hardware.
> >
> > The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
> > is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
> > reader, HDA card on discrete GPU). As soon as an interrupt handler is
> > installed for one of these devices, the ensuing storm of spurious IRQs
> > causes the kernel to disable the IRQ and switch to polling. This lasts
> > until the b43 driver loads and resets the device.
> >
> > Loading the b43 driver first is not always an option, in particular with
> > the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
> > installed early on because it is built in, unlike b43 which is usually
> > a module.
> >
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
> 
> I do see an irq 17 problem on my macbook, but I thought grub is
> supposed to stop the boardcom wireless?
> 
> Investigating grub2 git://git.savannah.gnu.org/grub.git I see this
> patch  rev 9d34bb8 which says it disables Broadcom wireless hardware
> on Apples:

Thanks for the pointer to the grub2 commit, I wasn't aware of that.

The commit puts the wireless card in power state D3hot but that doesn't
stop it from sending interrupts. I have just tested that. So it's
perfectly plausible that you're still seeing spurious interrupts
despite using grub. Please test the patch I've posted, the spurious
interrupts should disappear. If you "cat /proc/interrupts", you should
then only see a few hundred interrupts on IRQ 17. Without the patch it
should be in the 10+ range.

Best regards,

Lukas

> 
> * commit 9d34bb8
> | Author: Matthew Garrett <m...@redhat.com>
> | Date:   Thu May 3 17:26:55 2012 +0200
> |
> |   Suspend broadcom cards in order to stop their DMA.
> |
> |   * grub-core/Makefile.am (KERNEL_HEADER_FILES): Add pci.h on x86 EFI.
> |   * grub-core/Makefile.core.def (kernel): Add pci.c on x86 EFI.
> |   (pci): Don't build on x86 EFI.
> |   * grub-core/bus/pci.c (grub_pci_find_capability): New function.
> |   * grub-core/kern/efi/mm.c (stop_broadcom) [__i386__ || __x86_64__]:
> |   New function.
> |   (grub_efi_finish_boot_services) [__i386__ || __x86_64__]: Call
> |   stop_broadcom if running on EFI.
> |   * include/grub/pci.h (GRUB_PCI_CLASS_NETWORK): New enum value.
> |   (GRUB_PCI_CAP_POWER_MANAGEMENT): Likewise.
> |   (GRUB_PCI_VENDOR_BROADCOM): Likewise.
> |   (grub_pci_find_capability): New proto.
> |
> |   Also-By: Vladimir Serbinenko <phco...@gmail.com>
> |
> | M ChangeLog
> | M grub-core/Makefile.am
> | M grub-core/Makefile.core.def
> | M grub-core/bus/pci.c
> | M grub-core/kern/efi/mm.c
> | M include/grub/pci.h
> 
> But I run debian grub2-common 2.02~beta2-22+deb8u1 which has this fix
> and I *still* get this irq issue
> 
> 
> [  608.242849] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
> with disabled ep 88008a19df48
> [  608.242851] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
> with disabled ep 88008a19df90
> [  608.254975] irq 17: nobody cared (try booting with the "irqpoll" option)
> [  608.254979] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C O
> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt20-1+deb8u4
> [  608.254981] Hardware name: Apple Inc.
> MacBookPro10,1/Mac-C3EC7CD22292981F, BIOS
> MBP101.88Z.00EE.B00.1205101839 05/10/2012
> [  608.254985]  88045a85bac4 8150dcff 88045a85ba00
> 810bd3ad
> [  608.254987]  88045a85ba00 0011 
> 810bd8d1
> [  608.254989]    0011
> 
> [  608.254990] Call Trace:
> [  608.254999][] ? dump_stack+0x41/0x51
> [  608.255006]  [] ? __r

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Hi Chris,

On Fri, Apr 01, 2016 at 12:13:46AM +0100, Chris Bainbridge wrote:
> On Tue, Mar 29, 2016 at 07:41:30PM +0200, Lukas Wunner wrote:
> > Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> > on boot until they are reset, causing spurious interrupts if the IRQ is
> > shared. Apparently the EFI bootloader enables the device and does not
> > disable it before passing control to the OS. The bootloader contains a
> > driver for the wireless card which allows it to phone home to Cupertino.
> > This is used for Internet Recovery (download and install OS X images)
> > and probably also for Back to My Mac (remote access, RFC 6281) and to
> > discover stolen hardware.
> > 
> > The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
> > is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
> > reader, HDA card on discrete GPU). As soon as an interrupt handler is
> > installed for one of these devices, the ensuing storm of spurious IRQs
> > causes the kernel to disable the IRQ and switch to polling. This lasts
> > until the b43 driver loads and resets the device.
> > 
> > Loading the b43 driver first is not always an option, in particular with
> > the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
> > installed early on because it is built in, unlike b43 which is usually
> > a module.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
> 
> Should also fix https://bugzilla.kernel.org/show_bug.cgi?id=111781 ?
> Given that this is a serious bug that can corrupt filesystems it would
> be good to see the fix in stable too.

I cannot reproduce this particular issue on my MBP9,1 even though it
is architecturally very similar to your MBP10,2. I tested it with
"iommu=force intel_iommu=on", blacklisted b43 and stressed the machine
a bit with kernel compiles. No issues.

Have you tested my patch? As Michael Büsch has pointed out correctly,
it should mitigate that issue but will not solve it completely.
You write in the bugzilla entry that you've seen the issue as early
as 0.7 seconds into the boot. That's not a very precise method to
measure boot progress but on my machine the card is reset around 1.2
seconds, so likely too late. It's possible to execute the PCI quirk
slightly earlier (in the header fixup section rather than the late
fixup section) but that wouldn't make a significant difference.

If you use the method described in Matthew Garrett's blog post,
i.e. boot with "memmap=0xc0$0x1568a0", does the issue go away?
If so, we could probably add a quirk in arch/x86/kernel/e820.c
to mark that particular area reserved, or generally mark all
EFI boot services areas as reserved on Macs. This memory could
then be marked usable again once the card has been reset.

As to why the issue doesn't occur on my machine, my guess is that
the wireless card only writes packets to memory if it is associated
with a base station. Do you have an open WLAN around? Try moving
out of its reach and test if the issue goes away. Alternatively,
did you enter Wifi credentials in OS X? If so it has saved the
credentials to EFI variables. To verify if it has, use this on OS X:

/usr/sbin/nvram 36C28AB5-6566-4C50-9EBD-CBB920F83843:current-network
/usr/sbin/nvram 36C28AB5-6566-4C50-9EBD-CBB920F83843:preferred-networks
/usr/sbin/nvram 36C28AB5-6566-4C50-9EBD-CBB920F83843:preferred-count

On Linux, invoke "mount -t efivarfs none /sys/firmware/efi/efivars"
and delete the variables (use chattr -i first if you're on Linux 4.5+).
Test if the issue goes away.

I have neither an open WLAN nearby nor Wifi credentials in my EFI
variables, so the wireless card cannot associate with a base station
in the pre-OS phase and that's probably the reason why the issue doesn't
occur on my machine.

Best regards,

Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
on boot until they are reset, causing spurious interrupts if the IRQ is
shared. Apparently the EFI bootloader enables the device and does not
disable it before passing control to the OS. The bootloader contains a
driver for the wireless card which allows it to phone home to Cupertino.
This is used for Internet Recovery (download and install OS X images)
and probably also for Back to My Mac (remote access, RFC 6281) and to
discover stolen hardware.

The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
reader, HDA card on discrete GPU). As soon as an interrupt handler is
installed for one of these devices, the ensuing storm of spurious IRQs
causes the kernel to disable the IRQ and switch to polling. This lasts
until the b43 driver loads and resets the device.

Loading the b43 driver first is not always an option, in particular with
the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
installed early on because it is built in, unlike b43 which is usually
a module.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
Tested-by: Lukas Wunner <lu...@wunner.de> [MacBookPro9,1]
Signed-off-by: Lukas Wunner <lu...@wunner.de>
---
 drivers/bcma/bcma_private.h |  2 --
 drivers/pci/quirks.c| 27 +++
 include/linux/bcma/bcma.h   |  1 +
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index eda0909..f642c42 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -8,8 +8,6 @@
 #include 
 #include 
 
-#define BCMA_CORE_SIZE 0x1000
-
 #define bcma_err(bus, fmt, ...) \
pr_err("bus%d: " fmt, (bus)->num, ##__VA_ARGS__)
 #define bcma_warn(bus, fmt, ...) \
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 8e67802..d4fb5ee 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include/* isa_dma_bridge_buggy */
 #include "pci.h"
 
@@ -3282,6 +3284,31 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 
0x156d,
   quirk_apple_wait_for_thunderbolt);
 #endif
 
+/*
+ * Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
+ * on boot until they are reset, causing spurious interrupts if the IRQ is
+ * shared. Apparently the EFI bootloader enables the device to phone home
+ * to Cupertino and does not disable it before passing control to the OS.
+ */
+static void quirk_apple_b43_reset(struct pci_dev *dev)
+{
+   void __iomem *mmio;
+
+   if (!dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") || !dev->bus->self ||
+   pci_pcie_type(dev->bus->self) != PCI_EXP_TYPE_ROOT_PORT)
+   return;
+
+   mmio = pci_iomap(dev, 0, 0);
+   if (!mmio) {
+   pr_err("b43 quirk: Cannot iomap device, IRQ storm ahead\n");
+   return;
+   }
+   iowrite32(BCMA_RESET_CTL_RESET,
+ mmio + (1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL);
+   pci_iounmap(dev, mmio);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, 0x4331, quirk_apple_b43_reset);
+
 static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
  struct pci_fixup *end)
 {
diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
index 0367c63..5c37b58 100644
--- a/include/linux/bcma/bcma.h
+++ b/include/linux/bcma/bcma.h
@@ -158,6 +158,7 @@ struct bcma_host_ops {
 #define BCMA_CORE_DEFAULT  0xFFF
 
 #define BCMA_MAX_NR_CORES  16
+#define BCMA_CORE_SIZE 0x1000
 
 /* Chip IDs of PCIe devices */
 #define BCMA_CHIP_ID_BCM4313   0x4313
-- 
2.8.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm

[Lukas Wunner]

Dear bcma maintainers,

I'm moving BCMA_CORE_SIZE from drivers/bcma/bcma_private.h to
include/linux/bcma/bcma.h in the patch included below to be
able to use it in drivers/pci/quirks.c.

If you are okay with this change and have no other objections then
please kindly ack the patch for merging via the pci tree.

If you object against this change then I could alternatively redefine
BCMA_CORE_SIZE in drivers/pci/quirks.c. Other pci quirks are redefining
constants there as well. However it's obviously nicer to have a single
definition in one place.

Thanks,

Lukas

On Tue, Mar 29, 2016 at 07:41:30PM +0200, Lukas Wunner wrote:
> Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> on boot until they are reset, causing spurious interrupts if the IRQ is
> shared. Apparently the EFI bootloader enables the device and does not
> disable it before passing control to the OS. The bootloader contains a
> driver for the wireless card which allows it to phone home to Cupertino.
> This is used for Internet Recovery (download and install OS X images)
> and probably also for Back to My Mac (remote access, RFC 6281) and to
> discover stolen hardware.
> 
> The issue is most pronounced on 2011 and 2012 MacBook Pros where the IRQ
> is shared with 3 other devices (Light Ridge Thunderbolt controller, SDXC
> reader, HDA card on discrete GPU). As soon as an interrupt handler is
> installed for one of these devices, the ensuing storm of spurious IRQs
> causes the kernel to disable the IRQ and switch to polling. This lasts
> until the b43 driver loads and resets the device.
> 
> Loading the b43 driver first is not always an option, in particular with
> the Light Ridge Thunderbolt controller: The PCI hotplug IRQ handler gets
> installed early on because it is built in, unlike b43 which is usually
> a module.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632
> Tested-by: Lukas Wunner <lu...@wunner.de> [MacBookPro9,1]
> Signed-off-by: Lukas Wunner <lu...@wunner.de>
> ---
>  drivers/bcma/bcma_private.h |  2 --
>  drivers/pci/quirks.c| 27 +++
>  include/linux/bcma/bcma.h   |  1 +
>  3 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
> index eda0909..f642c42 100644
> --- a/drivers/bcma/bcma_private.h
> +++ b/drivers/bcma/bcma_private.h
> @@ -8,8 +8,6 @@
>  #include 
>  #include 
>  
> -#define BCMA_CORE_SIZE   0x1000
> -
>  #define bcma_err(bus, fmt, ...) \
>   pr_err("bus%d: " fmt, (bus)->num, ##__VA_ARGS__)
>  #define bcma_warn(bus, fmt, ...) \
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 8e67802..d4fb5ee 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include  /* isa_dma_bridge_buggy */
>  #include "pci.h"
>  
> @@ -3282,6 +3284,31 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 
> 0x156d,
>  quirk_apple_wait_for_thunderbolt);
>  #endif
>  
> +/*
> + * Broadcom 4331 wireless cards built into Apple Macs unleash an IRQ storm
> + * on boot until they are reset, causing spurious interrupts if the IRQ is
> + * shared. Apparently the EFI bootloader enables the device to phone home
> + * to Cupertino and does not disable it before passing control to the OS.
> + */
> +static void quirk_apple_b43_reset(struct pci_dev *dev)
> +{
> + void __iomem *mmio;
> +
> + if (!dmi_match(DMI_BOARD_VENDOR, "Apple Inc.") || !dev->bus->self ||
> + pci_pcie_type(dev->bus->self) != PCI_EXP_TYPE_ROOT_PORT)
> + return;
> +
> + mmio = pci_iomap(dev, 0, 0);
> + if (!mmio) {
> + pr_err("b43 quirk: Cannot iomap device, IRQ storm ahead\n");
> + return;
> + }
> + iowrite32(BCMA_RESET_CTL_RESET,
> +   mmio + (1 * BCMA_CORE_SIZE) + BCMA_RESET_CTL);
> + pci_iounmap(dev, mmio);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM, 0x4331, 
> quirk_apple_b43_reset);
> +
>  static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> struct pci_fixup *end)
>  {
> diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
> index 0367c63..5c37b58 100644
> --- a/include/linux/bcma/bcma.h
> +++ b/include/linux/bcma/bcma.h
> @@ -158,6 +158,7 @@ struct bcma_host_ops {
>  #define BCMA_CORE_DEFAUL