Re: [PATCH v4] PCI: Add PCI_DEVICE_DATA() macro to fully describe device ID entry

2018-08-14 Thread Bjorn Helgaas 
On Sun, Jul 29, 2018 at 04:16:56PM +0300, Andy Shevchenko wrote:
> There are a lot of examples in the kernel where PCI_VDEVICE() is used and 
> still
> looks not so convenient due to additional driver_data field attached.
> 
> Introduce PCI_DEVICE_DATA() macro to fully describe device ID entry in 
> shortest
> possible form. For example,
> 
>   before:
> 
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD),
>   (kernel_ulong_t) _pci_mrfld_properties, },
> 
>   after:
> 
> { PCI_DEVICE_DATA(INTEL, MRFLD, _pci_mrfld_properties) },
> 
> Drivers can be converted later on in independent way.
> 
> While here, remove the unused macro with the same name
> from Ralink wireless driver.
> 
> Signed-off-by: Andy Shevchenko 

Applied with Kalle's ack to pci/misc for v4.19, thanks!

> ---
> 
> - Add vend to the device (Bjorn)
> 
> Bjorn, this also looks good.
> 
>  drivers/net/wireless/ralink/rt2x00/rt2x00pci.h |  6 --
>  include/linux/pci.h| 15 +++
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h 
> b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
> index bc0ca5f58f38..283e2e607bba 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.h
> @@ -27,12 +27,6 @@
>  #include 
>  #include 
>  
> -/*
> - * This variable should be used with the
> - * pci_driver structure initialization.
> - */
> -#define PCI_DEVICE_DATA(__ops)   .driver_data = (kernel_ulong_t)(__ops)
> -
>  /*
>   * PCI driver handlers.
>   */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d0961aefdbae..fe060114a647 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -825,6 +825,21 @@ struct pci_driver {
>   .vendor = PCI_VENDOR_ID_##vend, .device = (dev), \
>   .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0
>  
> +/**
> + * PCI_DEVICE_DATA - macro used to describe a specific PCI device in very 
> short form
> + * @vend: the vendor name (without PCI_VENDOR_ID_ prefix)
> + * @dev: the device name (without PCI_DEVICE_ID__ prefix)
> + * @data: the driver data to be filled
> + *
> + * This macro is used to create a struct pci_device_id that matches a
> + * specific PCI device.  The subvendor, and subdevice fields will be set
> + * to PCI_ANY_ID.
> + */
> +#define PCI_DEVICE_DATA(vend, dev, data) \
> + .vendor = PCI_VENDOR_ID_##vend, .device = PCI_DEVICE_ID_##vend##_##dev, 
> \
> + .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0, \
> + .driver_data = (kernel_ulong_t)(data)
> +
>  enum {
>   PCI_REASSIGN_ALL_RSRC   = 0x0001,   /* Ignore firmware setup */
>   PCI_REASSIGN_ALL_BUS= 0x0002,   /* Reassign all bus numbers */
> -- 
> 2.18.0
>

Re: [PATCH v3] PCI: Add PCI_DEVICE_DATA() macro to fully describe device ID entry

2018-07-27 Thread Bjorn Helgaas 
On Fri, Jul 27, 2018 at 11:49:44PM +0300, Andy Shevchenko wrote:
> There are a lot of examples in the kernel where PCI_VDEVICE() is used and 
> still
> looks not so convenient due to additional driver_data field attached.
> 
> Introduce PCI_DEVICE_DATA() macro to fully describe device ID entry in 
> shortest
> possible form. For example,
> 
>   before:
> 
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD),
>   (kernel_ulong_t) _pci_mrfld_properties, },
> 
>   after:
> 
> { PCI_DEVICE_DATA(INTEL, INTEL_MRFLD, _pci_mrfld_properties) },

Most device IDs include the vendor ID; did you consider pasting the
vendor ID string into the device ID, so you would end up with this?

{ PCI_DEVICE_DATA(INTEL, MRFLD, _pci_mrfld_properties) },

I don't absolutely love either PCI_VDEVICE or PCI_DEVICE_DATA because
grep doesn't work as well to find uses of the symbol, but the existing
2300 uses of PCI_VDEVICE are telling me pretty loudly to just get over
it :)

Bjorn

Re: [PATCH v1 0/4] PCI: Remove unnecessary includes of

2018-07-25 Thread Bjorn Helgaas 
On Wed, Jul 25, 2018 at 01:33:23PM -0700, Sinan Kaya wrote:
> On 7/25/2018 12:52 PM, Bjorn Helgaas wrote:
> > emove includes of  from files that don't need
> > it.  I'll apply all these via the PCI tree unless there's objection.
> > 
> > ---
> > 
> > Bjorn Helgaas (4):
> >igb: Remove unnecessary include of 
> >ath9k: Remove unnecessary include of 
> >iwlwifi: Remove unnecessary include of 
> >PCI: Remove unnecessary include of 
> 
> Thanks.
> 
> Reviewed-by: Sinan Kaya 
> 
> Is it possible to kill that file altogether? I haven't looked who is
> using outside of pci directory.

Thanks for taking a look!

It's possible we could remove it altogether; there's very little in
it, and in most cases the only reason drivers include it is to disable
certain ASPM link states to work around hardware defects.  It might
make sense to just move that interface into .

[PATCH v1 3/4] iwlwifi: Remove unnecessary include of

2018-07-25 Thread Bjorn Helgaas 
From: Bjorn Helgaas 

This part of the iwlwifi driver doesn't need anything provided by
pci-aspm.h, so remove the unnecessary include of it.

Signed-off-by: Bjorn Helgaas 
---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 38234bda9017..d6c55e111fda 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -72,7 +72,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "fw/acpi.h"

[PATCH v1 4/4] PCI: Remove unnecessary include of

2018-07-25 Thread Bjorn Helgaas 
From: Bjorn Helgaas 

Several PCI core files include pci-aspm.h even though they don't need
anything provided by that file.  Remove the unnecessary includes of it.

Signed-off-by: Bjorn Helgaas 
---
 drivers/pci/pci-sysfs.c |1 -
 drivers/pci/pci.c   |1 -
 drivers/pci/probe.c |1 -
 drivers/pci/remove.c|1 -
 4 files changed, 4 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 0c4653c1d2ce..91337faae60d 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f5c6ab14fb31..7c2f0e682fc0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac876e32de4b..1ed2852dee21 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 6f072eae4f7a..01ec7fcb5634 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -1,7 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
-#include 
 #include "pci.h"
 
 static void pci_free_resources(struct pci_dev *dev)

[PATCH v1 1/4] igb: Remove unnecessary include of

2018-07-25 Thread Bjorn Helgaas 
From: Bjorn Helgaas 

The igb driver doesn't need anything provided by pci-aspm.h, so remove
the unnecessary include of it.

Signed-off-by: Bjorn Helgaas 
---
 drivers/net/ethernet/intel/igb/igb_main.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c 
b/drivers/net/ethernet/intel/igb/igb_main.c
index f707709969ac..c77fda05f683 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include

[PATCH v1 2/4] ath9k: Remove unnecessary include of

2018-07-25 Thread Bjorn Helgaas 
From: Bjorn Helgaas 

The ath9k driver doesn't need anything provided by pci-aspm.h, so remove
the unnecessary include of it.

Signed-off-by: Bjorn Helgaas 
---
 drivers/net/wireless/ath/ath9k/pci.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/pci.c 
b/drivers/net/wireless/ath/ath9k/pci.c
index 645f0fbd9179..92b2dd396436 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -18,7 +18,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include "ath9k.h"

[PATCH v1 0/4] PCI: Remove unnecessary includes of

2018-07-25 Thread Bjorn Helgaas 
Remove includes of  from files that don't need
it.  I'll apply all these via the PCI tree unless there's objection.

---

Bjorn Helgaas (4):
  igb: Remove unnecessary include of 
  ath9k: Remove unnecessary include of 
  iwlwifi: Remove unnecessary include of 
  PCI: Remove unnecessary include of 


 drivers/net/ethernet/intel/igb/igb_main.c |1 -
 drivers/net/wireless/ath/ath9k/pci.c  |1 -
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c |1 -
 drivers/pci/pci-sysfs.c   |1 -
 drivers/pci/pci.c |1 -
 drivers/pci/probe.c   |1 -
 drivers/pci/remove.c  |1 -
 7 files changed, 7 deletions(-)

Re: [PATCH v3 2/2] drivers: remove force dma flag from buses

2018-04-10 Thread Bjorn Helgaas 
On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if implicit DMA
> configuration is required even when it is not described by the
> firmware.
> 
> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>

Acked-by: Bjorn Helgaas <bhelg...@google.com>  # PCI parts

> ---
> Changes in v2:
>   - This is a new change suggested by Robin and Christoph
> and is added to the series.
> 
> Changes in v3:
>   - Rebase and changes corresponding to the changes in patch 1/2
> 
>  drivers/amba/bus.c| 1 -
>  drivers/base/platform.c   | 3 +--
>  drivers/bcma/main.c   | 2 +-
>  drivers/dma/qcom/hidma_mgmt.c | 2 +-
>  drivers/gpu/host1x/bus.c  | 5 ++---
>  drivers/of/device.c   | 6 --
>  drivers/of/of_reserved_mem.c  | 2 +-
>  drivers/pci/pci-driver.c  | 3 +--
>  include/linux/device.h| 4 
>  include/linux/of_device.h | 8 ++--
>  10 files changed, 17 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 867dc2b..abe73c4 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
>   .uevent = amba_uevent,
>   .dma_configure  = platform_dma_configure,
>   .pm = _pm,
> - .force_dma  = true,
>  };
>  
>  static int __init amba_init(void)
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 72fdbf6..cfbc569 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
>   int ret = 0;
>  
>   if (dev->of_node) {
> - ret = of_dma_configure(dev, dev->of_node);
> + ret = of_dma_configure(dev, dev->of_node, true);
>   } else if (has_acpi_companion(dev)) {
>   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
>   if (attr != DEV_DMA_NOT_SUPPORTED)
> @@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
>   .uevent = platform_uevent,
>   .dma_configure  = platform_dma_configure,
>   .pm = _dev_pm_ops,
> - .force_dma  = true,
>  };
>  EXPORT_SYMBOL_GPL(platform_bus_type);
>  
> diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> index e6986c7..fc1f4ac 100644
> --- a/drivers/bcma/main.c
> +++ b/drivers/bcma/main.c
> @@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
>  
>   core->irq = bcma_of_get_irq(parent, core, 0);
>  
> - of_dma_configure(>dev, node);
> + of_dma_configure(>dev, node, false);
>  }
>  
>  unsigned int bcma_core_irq(struct bcma_device *core, int num)
> diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
> index 000c7019..d64edeb 100644
> --- a/drivers/dma/qcom/hidma_mgmt.c
> +++ b/drivers/dma/qcom/hidma_mgmt.c
> @@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
> device_node *np)
>   }
>   of_node_get(child);
>   new_pdev->dev.of_node = child;
> - of_dma_configure(_pdev->dev, child);
> + of_dma_configure(_pdev->dev, child, true);
>   /*
>* It is assumed that calling of_msi_configure is safe on
>* platforms with or without MSI support.
> diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
> index a9ec99d..b39c1e9 100644
> --- a/drivers/gpu/host1x/bus.c
> +++ b/drivers/gpu/host1x/bus.c
> @@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
> device_driver *drv)
>  static int host1x_dma_configure(struct device *dev)
>  {
>   if (dev->of_node)
> - return of_dma_configure(dev, dev->of_node);
> + return of_dma_configure(dev, dev->of_node, true);
>   return 0;
>  }
>  
> @@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
>   .match = host1x_device_match,
>   .dma_configure  = host1x_dma_configure,
>   .pm = _device_pm_ops,
> - .force_dma = true,
>  };
>  
>  static void __host1x_device_del(struct host1x_device *device)
> @@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
>   device->dev.bus = _bus_type;
>   device->dev.parent = host1x->dev;
>  
> - of_dma_configure(>dev, host1x->dev->of_node);
> + of_dma_configure(>dev, host1x->d

Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

2018-04-10 Thread Bjorn Helgaas 
On Fri, Mar 30, 2018 at 01:24:44PM +0530, Nipun Gupta wrote:
> It is bus specific aspect to map a given device on the bus and
> relevant firmware description of its DMA configuration.
> So, this change introduces 'dma_configure' as bus callback
> giving flexibility to busses for implementing its own dma
> configuration function.
> 
> The change eases the addition of new busses w.r.t. adding the dma
> configuration functionality.
> 
> This patch also updates the PCI, Platform, ACPI and host1x bus to
> use new introduced callbacks.

s/dma/DMA/ consistently above.

> Suggested-by: Christoph Hellwig <h...@lst.de>
> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Acked-by: Bjorn Helgaas <bhelg...@google.com>  # PCI parts

I assume you'll merge this via some non-PCI tree.  Let me know if you
need anything else from me.

> ---
>  - The patches are based on the comments on:
>https://patchwork.kernel.org/patch/10259087/
> 
> Changes in v2:
>   - Do not have dma_deconfigure callback
>   - Have '/dma_common_configure/' API to provide a common DMA
> configuration which can be used by busses if it suits them.
>   - Platform and ACPI bus to use '/dma_common_configure/' in
> '/dma_configure/' callback.
>   - Updated commit message
>   - Updated pci_dma_configure API with changes suggested by Robin
> 
> Changes in v3
>   - Move dma_common_configure() within platform_dma_configure() and
> reuse platofrm_dma_configure() for AMBA bus too
>   - Declare 'attr' in pci_dma_configure() inside the else statement
> where it is used.
> 
>  drivers/amba/bus.c  |  4 
>  drivers/base/dma-mapping.c  | 31 ---
>  drivers/base/platform.c | 17 +
>  drivers/gpu/host1x/bus.c|  8 
>  drivers/pci/pci-driver.c| 32 
>  include/linux/device.h  |  4 
>  include/linux/platform_device.h |  2 ++
>  7 files changed, 71 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 594c228..867dc2b 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
>  /*
>   * Primecells are part of the Advanced Microcontroller Bus Architecture,
>   * so we call the bus "amba".
> + * DMA configuration for platform and AMBA bus is same. So here we reuse
> + * platform's DMA config routine.
>   */
>  struct bus_type amba_bustype = {
>   .name   = "amba",
>   .dev_groups = amba_dev_groups,
>   .match  = amba_match,
>   .uevent = amba_uevent,
> + .dma_configure  = platform_dma_configure,
>   .pm = _pm,
>   .force_dma  = true,
>  };
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index 3b11835..fdc1502 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -331,36 +331,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
> unsigned long vm_flags)
>  #endif
>  
>  /*
> - * Common configuration to enable DMA API use for a device
> + * enables DMA API use for a device
>   */
> -#include 
> -
>  int dma_configure(struct device *dev)
>  {
> - struct device *bridge = NULL, *dma_dev = dev;
> - enum dev_dma_attr attr;
> - int ret = 0;
> -
> - if (dev_is_pci(dev)) {
> - bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> - dma_dev = bridge;
> - if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
> - dma_dev->parent->of_node)
> - dma_dev = dma_dev->parent;
> - }
> -
> - if (dma_dev->of_node) {
> - ret = of_dma_configure(dev, dma_dev->of_node);
> - } else if (has_acpi_companion(dma_dev)) {
> - attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
> - if (attr != DEV_DMA_NOT_SUPPORTED)
> - ret = acpi_dma_configure(dev, attr);
> - }
> -
> - if (bridge)
> - pci_put_host_bridge_device(bridge);
> -
> - return ret;
> + if (dev->bus->dma_configure)
> + return dev->bus->dma_configure(dev);
> + return 0;
>  }
>  
>  void dma_deconfigure(struct device *dev)
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index f1bf7b3..72fdbf6 100644
> --- a/drivers/bas

Re: [PATCH v3 1/2] pci: Add vendor id of Ubiquiti Networks

2018-01-29 Thread Bjorn Helgaas 
On Thu, Jan 25, 2018 at 12:13:39PM +0100, Tobias Schramm wrote:
> Signed-off-by: Tobias Schramm <toblemi...@gmail.com>

Acked-by: Bjorn Helgaas <bhelg...@google.com>

I see Kalle has already applied this, but if it's updated for any reason,
please add my ack and change the subject to:

  PCI: Add Ubiquiti Networks vendor ID

i.e., match the style of previous changes.

> ---
>  include/linux/pci_ids.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index ab20dc5db423..35871adfdc86 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -149,6 +149,8 @@
>  #define PCI_VENDOR_ID_DYNALINK   0x0675
>  #define PCI_DEVICE_ID_DYNALINK_IS64PH0x1702
>  
> +#define PCI_VENDOR_ID_UBIQUITI   0x0777
> +
>  #define PCI_VENDOR_ID_BERKOM 0x0871
>  #define PCI_DEVICE_ID_BERKOM_A1T 0xffa1
>  #define PCI_DEVICE_ID_BERKOM_T_CONCEPT   0xffa2
> -- 
> 2.16.0
>

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

2017-10-03 Thread Bjorn Helgaas 
On Tue, Oct 03, 2017 at 11:07:58PM +0200, Thomas Gleixner wrote:
> On Mon, 2 Oct 2017, Thomas Gleixner wrote:
> > On Mon, 2 Oct 2017, Thomas Gleixner wrote:
> > > On Mon, 2 Oct 2017, Daniel Drake wrote:
> > >   2) The affinity setting of straight MSI interrupts (w/o remapping) on 
> > > x86
> > >  requires to make the affinity change from the interrupt context of 
> > > the
> > >  current active vector in order not to lose interrupts or worst case
> > >  getting into a stale state.
> > > 
> > >  That works for single vectors, but trying to move all vectors in one
> > >  go is more or less impossible, as there is no reliable way to
> > >  determine that none of the other vectors is on flight.
> > > 
> > >  There might be some 'workarounds' for that, but I rather avoid that
> > >  unless we get an official documented one from Intel/AMD.
> > 
> > Thinking more about it. That might be actually a non issue for MSI, but we
> > have that modus operandi in the current code and we need to address that
> > first before even thinking about multi MSI support.
> 
> But even if its possible, it's very debatable whether it's worth the effort
> when this driver just can use the legacy INTx.and be done with it.

Daniel said "Legacy interrupts do not work on that module, so MSI
support is required," so I assume he means INTx doesn't work.  Maybe
the driver could poll?  I don't know how much slower that would be,
but at least it would penalize the broken device, not everybody.

Bjorn

Re: iwlwifi firmware load broken in current -git

2017-09-15 Thread Bjorn Helgaas 
On Fri, Sep 15, 2017 at 01:55:57PM -0600, Jens Axboe wrote:
> On 09/15/2017 01:51 PM, Luca Coelho wrote:
> > On Fri, 2017-09-15 at 13:48 -0600, Jens Axboe wrote:
> >> On 09/15/2017 01:38 PM, Linus Torvalds wrote:
> >>> On Fri, Sep 15, 2017 at 12:32 PM, Jens Axboe  wrote:
> >
> > In any case, your patch introduces a regression on systems. Please get
> > it reverted now, and then you can come up with a new approach to fix the
> > double enable of the upstream bridge.
> 
>  Who's sending in the revert? I can certainly do it if no one else does,
>  but it needs to be done.
> 
>  I'm not seeing any patches coming out of Srinath to fix up the
>  situation, so we should revert the broken patch until a better solution
>  exists.
> >>>
> >>> Hmm. I don't have the history here (apparently it never made lkml, for
> >>> example), so I don't even know which commit you're talking about.
> >>>
> >>> From some of the context it looks like commit 40f11adc7cd9 ("PCI:
> >>> Avoid race while enabling upstream bridges"), is that correct?
> >>
> >> Yes, Luca says that Bjorn already sent in the revert request, I just
> >> didn't see it since I wasn't CC'ed on it. So looks like we're all
> >> good, provided that makes it into -rc1. 40f11adc7cd9 is the broken
> >> commit.
> > 
> > Strange... AFAICT you *were* CCed on it.  And so was everyone else in
> > the original thread (+LKML)...
> 
> Hmm, never showed up here. Very odd!

Sorry, I think this is probably because I'm an idiot and sent it from
an @google.com account and it got rejected because the DMARC check
failed.

Bjorn

[GIT PULL] PCI fixes for v4.14

2017-09-15 Thread Bjorn Helgaas 
PCI fix:

  - revert an attempt to fix a race while enabling upstream bridges because
it broke iwlwifi firmware loading


The following changes since commit 711aab1dbb324d321e3d84368a435a78908c7bce:

  vfs: constify path argument to kernel_read_file_from_path (2017-09-14 
20:18:45 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.14-fixes-1

for you to fetch changes up to 0f50a49e3008597abed0fff052d487f77db89093:

  Revert "PCI: Avoid race while enabling upstream bridges" (2017-09-15 01:33:51 
-0500)


pci-v4.14-fixes-1

--------
Bjorn Helgaas (1):
  Revert "PCI: Avoid race while enabling upstream bridges"

 drivers/pci/pci.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

[PATCH] Revert "PCI: Avoid race while enabling upstream bridges"

2017-09-15 Thread Bjorn Helgaas 
This reverts commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9.

Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon,
gen4:

  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed 
with error -2
  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed 
with error -2
  iwlwifi :04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed 
with error -2
  iwlwifi :04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
  iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
  ...
  iwlwifi :04:00.0: Failed to load firmware chunk!
  iwlwifi :04:00.0: Could not load the [0] uCode section
  iwlwifi :04:00.0: Failed to start INIT ucode: -110
  iwlwifi :04:00.0: Failed to run INIT ucode: -110

He bisected it to 40f11adc7cd9 ("PCI: Avoid race while enabling upstream
bridges").  Revert that commit to fix the regression.

Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6...@kernel.dk
Fixes: 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges")
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
CC: Srinath Mannam <srinath.man...@broadcom.com>
CC: Jens Axboe <ax...@kernel.dk>
CC: Luca Coelho <l...@coelho.fi>
CC: Johannes Berg <johan...@sipsolutions.net>
CC: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
---
 drivers/pci/pci.c |   13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b0002daa50f3..6078dfc11b11 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -52,7 +52,6 @@ static void pci_pme_list_scan(struct work_struct *work);
 static LIST_HEAD(pci_pme_list);
 static DEFINE_MUTEX(pci_pme_list_mutex);
 static DECLARE_DELAYED_WORK(pci_pme_work, pci_pme_list_scan);
-static DEFINE_MUTEX(pci_bridge_mutex);
 
 struct pci_pme_device {
struct list_head list;
@@ -1351,16 +1350,10 @@ static void pci_enable_bridge(struct pci_dev *dev)
if (bridge)
pci_enable_bridge(bridge);
 
-   /*
-* Hold pci_bridge_mutex to prevent a race when enabling two
-* devices below the bridge simultaneously.  The race may cause a
-* PCI_COMMAND_MEMORY update to be lost (see changelog).
-*/
-   mutex_lock(_bridge_mutex);
if (pci_is_enabled(dev)) {
if (!dev->is_busmaster)
pci_set_master(dev);
-   goto end;
+   return;
}
 
retval = pci_enable_device(dev);
@@ -1368,8 +1361,6 @@ static void pci_enable_bridge(struct pci_dev *dev)
dev_err(>dev, "Error enabling bridge (%d), continuing\n",
retval);
pci_set_master(dev);
-end:
-   mutex_unlock(_bridge_mutex);
 }
 
 static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
@@ -1394,7 +1385,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, 
unsigned long flags)
return 0;   /* already enabled */
 
bridge = pci_upstream_bridge(dev);
-   if (bridge && !pci_is_enabled(bridge))
+   if (bridge)
pci_enable_bridge(bridge);
 
/* only skip sriov related */

Re: iwlwifi firmware load broken in current -git

2017-09-14 Thread Bjorn Helgaas 
[+cc linux-pci]

On Thu, Sep 14, 2017 at 12:00 PM, Jens Axboe  wrote:
> On 09/12/2017 02:04 PM, Johannes Berg wrote:
>> On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
>>
>>> CC'ing the guilty part and Bjorn. I'm assuming it's the
>>> pci_is_enabled() check, since the rest of the patch shouldn't have
>>> functional changes.
>>
>> and pci_enable_bridge() already checks if it's already enabled, but
>> still enables mastering in that case if it isn't:
>>
>> static void pci_enable_bridge(struct pci_dev *dev)
>> {
>> [...]
>> if (pci_is_enabled(dev)) {
>> if (!dev->is_busmaster)
>> pci_set_master(dev);
>> return;
>> }
>>
>> so I guess due to the new check we end up with mastering disabled, and
>> thus the firmware can't load since that's a DMA thing?
>
> Bjorn/Srinath, any input here? This is a regression that prevents wifi
> from working on a pretty standard laptop. It'd suck to have this be in
> -rc1. Seems like the trivial fix would be:
>
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b0002daa50f3..ffbe11dbdd61 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1394,7 +1394,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, 
> unsigned long flags)
> return 0;   /* already enabled */
>
> bridge = pci_upstream_bridge(dev);
> -   if (bridge && !pci_is_enabled(bridge))
> +   if (bridge)
> pci_enable_bridge(bridge);
>
> /* only skip sriov related */
>
>

Looks like a reasonable fix.  I assume it works for you?  I don't have
a way to test it, so if you can verify that it works and supply a
Signed-off-by, I can merge it.

Bjorn

Re: linux <=4.9.5, 4.10-rc7 ok, 4.9.6 - 4.9.8 nok with realtek wlan, atom

2017-02-09 Thread Bjorn Helgaas 
[+cc rtl8192ce folks in case they've seen this]

On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:
> hi,
> 
> not technical expert enough, i just wanted to give a short user
> feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
> kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
> well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
> hotspot is possible then drops, or connecting to wlan fails
> alltogether.

Thanks very much for your report, and sorry for the inconvenience.

v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.

But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
need to figure out why and make sure we fix the v4.9 stable series.

I can't tell yet whether this is PCI-related or not.  If it is,
4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
appeared in v4.9.6, and there is a known issue with that.  The issue
should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
the first thing to do would be to test v4.9.9.

If it's not fixed in v4.9.9, can you share the complete dmesg log
(output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
known working version) and v4.9.6 (first known broken version)?  On
v4.9.6, collect the dmesg output after the failure occurs.

> 24: PCI 300.0: 0282 WLAN controller
>   [Created at pci.366]
>   Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
>   Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
>   Revision: 0x01
>   Driver: "rtl8192ce"
>   Driver Modules: "rtl8192ce"
>   Device File: wlp3s0
>   Features: WLAN

Re: ATH9 driver issues on ARM64

2016-12-12 Thread Bjorn Helgaas 
On Sat, Dec 10, 2016 at 02:40:48PM +, Bharat Kumar Gogada wrote:
> Hi,
> 
> After taking some more lecroy traces, we see that after 2nd ASSERT from EP on 
> ARM64 we see continuous data movement of 32 dwords or 12 dwords and never 
> sign of DEASSERT.
> Comparatively on working traces (x86) after 2nd assert there are only BAR 
> register reads and writes and then DEASSERT, for almost most of the 
> interrupts and we haven't seen 12 or 32 dwords data movement on this trace.
> 
> I did not work on EP wifi/network drivers, any help why EP needs those many 
> number of data at scan time ?

The device doesn't know whether it's in an x86 or an arm64 system.  If
it works differently, it must be because the PCI core or the driver is
programming the device differently.

You should be able to match up Memory transactions from the host in
the trace with things the driver does.  For example, if you see an
Assert_INTx message from the device, you should eventually see a
Memory Read from the host to get the ISR, i.e., some read done in the
bowels of ath9k_hw_getisr().

I don't know how the ath9k device works, but there must be some Memory
Read or Write done by the driver that tells the device "we've handled
this interrupt".  The device should then send a Deassert_INTx; of
course, if the device still requires service, e.g., because it has
received more packets, it might leave the INTx asserted.

I doubt you'd see exactly the same traces on x86 and arm64 because
they aren't seeing the same network packets and the driver is
executing at different rates.  But you should at least be able to
identify interrupt assertion and the actions of the driver's interrupt
service routine.

> > Hello there,
> > 
> > as this is a thread about ath9k and ARM64, i'm not sure if i should answer 
> > here
> > or not, but i have similar "stalls" with ath9k on x86_64 (starting with 
> > 4.9rc), stack
> > trace is posted down below where the original ARM64 stall traces are.
> > 
> > Greetings,
> > 
> > Tobias
> > 
> > 
> > On 08.12.2016 18:36, Kalle Valo wrote:
> > > Bharat Kumar Gogada  writes:
> > >
> > >>   > [+cc Kalle, ath9k list]
> > > Thanks, but please also CC linux-wireless. Full thread below for the
> > > folks there.
> > >
> > >>> On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada wrote:
> >  Hi,
> > 
> >  Did anyone test Atheros ATH9
> >  driver(drivers/net/wireless/ath/ath9k/)
> >  on ARM64.  The end point is TP link wifi card with which supports
> >  only legacy interrupts.
> > >>> If it works on other arches and the arm64 PCI enumeration works, my
> > >>> first guess would be an INTx issue, e.g., maybe the driver is
> > >>> waiting for an interrupt that never arrives.
> > >> We are not sure for now.
> >  We are trying to test it on ARM64 with
> >  (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> > 
> >  EP is getting enumerated and able to link up.
> > 
> >  But when we start scan system gets hanged.
> > >>> When you say the system hangs when you start a scan, I assume you
> > >>> mean a wifi scan, not the PCI enumeration.  A problem with a wifi
> > >>> scan might cause a *process* to hang, but it shouldn't hang the
> > >>> entire system.
> > >>>
> > >> Yes wifi scan.
> >  When we took trace we see that after we start scan assert message
> >  is sent but there is no de assert from end point.
> > >>> Are you talking about a trace from a PCIe analyzer?  Do you see an
> > >>> Assert_INTx PCIe message on the link?
> > >>>
> > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening
> > when we do interface link up.
> > >> When we have less debug prints in Atheros driver, and do wifi scan we
> > >> see Assert_INTx but never Deassert_INTx,
> >  What might cause end point not sending de assert ?
> > >>> If the endpoint doesn't send a Deassert_INTx message, I expect that
> > >>> would mean the driver didn't service the interrupt and remove the
> > >>> condition that caused the device to assert the interrupt in the
> > >>> first place.
> > >>>
> > >>> If the driver didn't receive the interrupt, it couldn't service it,
> > >>> of course.  You could add a printk in the ath9k interrupt service
> > >>> routine to see if you ever get there.
> > >>>
> > >> The interrupt behavior is changing w.r.t amount of debug prints we
> > >> add. (I kept many prints to aid debug) root@Xilinx-ZCU102-2016_3:~# iw 
> > >> dev
> > wlan0 scan
> > >> [   83.064675] ath9k: ath9k_iowrite32 ff800a400024
> > >> [   83.069486] ath9k: ath9k_ioread32 ff800a400024
> > >> [   83.074257] ath9k_hw_kill_interrupts   793
> > >> [   83.078260] ath9k: ath9k_iowrite32 ff800a400024
> > >> [   83.083107] ath9k: ath9k_ioread32 ff800a400024
> > >> [   83.087882] ath9k_hw_kill_interrupts   793
> > >> [   83.095450] ath9k_hw_enable_interrupts 821
> > >> [   83.099557] ath9k_hw_enable_interrupts 825
> > >> [   83.103721]

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

2016-06-09 Thread Bjorn Helgaas 
On Sun, May 29, 2016 at 01:35:28AM +0200, Lukas Wunner wrote:
> 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.
> ...

> 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

I think I saw mail about this being applied via the x86 tree.  Let me
know if I need to do anything more here.
--
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

2016-04-06 Thread Bjorn Helgaas 
On Tue, Apr 05, 2016 at 09:49:45PM +0200, Michael Büsch wrote:
> On Tue, 5 Apr 2016 14:40:15 -0500
> Bjorn Helgaas <helg...@kernel.org> wrote:
> 
> > [+cc Matthew]
> > 
> > Hi Lukas,
> > 
> > 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_iounma

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

2016-04-05 Thread Bjorn Helgaas 
[+cc Matthew]

Hi Lukas,

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  [MacBookPro9,1]
> Signed-off-by: Lukas Wunner 
> ---
>  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 generic way?

I'm a little bit hesitant to put a quirk like this in Linux because
it's only a 90% solution.  If the only problem is the interrupts, it's
probably OK since a few extra interrupts doesn't hurt anything.  But
if there is also DMA that might corrupt something, a 90% solution just
makes it harder to debug for the remaining 10%.

> +}
> +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_DEFAULT0xFFF
>  
>  #define BCMA_MAX_NR_CORES16
> +#define