linux-stable.git/drivers/pci, branch v5.14.2

PCI/MSI: Skip masking MSI-X on Xen PV

2021-08-26T22:27:15+00:00

When running as Xen PV guest, masking MSI-X is a responsibility of the
hypervisor. The guest has no write access to the relevant BAR at all - when
it tries to, it results in a crash like this:

    BUG: unable to handle page fault for address: ffffc9004069100c
    #PF: supervisor write access in kernel mode
    #PF: error_code(0x0003) - permissions violation
    RIP: e030:__pci_enable_msix_range.part.0+0x26b/0x5f0
     e1000e_set_interrupt_capability+0xbf/0xd0 [e1000e]
     e1000_probe+0x41f/0xdb0 [e1000e]
     local_pci_probe+0x42/0x80
    (...)

The recently introduced function msix_mask_all() does not check the global
variable pci_msi_ignore_mask which is set by XEN PV to bypass the masking
of MSI[-X] interrupts.

Add the check to make this function XEN PV compatible.

Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries")
Signed-off-by: Marek Marczykowski-Górecki 
Signed-off-by: Thomas Gleixner 
Acked-by: Bjorn Helgaas 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210826170342.135172-1-marmarek@invisiblethingslab.com

Merge tag 'pci-v5.14-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2021-08-20T19:51:37+00:00

Pull PCI fixes from Bjorn Helgaas:

 - Add Rahul Tanwar as Intel LGM Gateway PCIe maintainer (Rahul Tanwar)

 - Add Jim Quinlan et al as Broadcom STB PCIe maintainers (Jim Quinlan)

 - Increase D3hot-to-D0 delay for AMD Renoir/Cezanne XHCI (Marcin
   Bachry)

 - Correct iomem_get_mapping() usage for legacy_mem sysfs (Krzysztof
   Wilczyński)

* tag 'pci-v5.14-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI/sysfs: Use correct variable for the legacy_mem sysfs object
  PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI
  MAINTAINERS: Add Jim Quinlan et al as Broadcom STB PCIe maintainers
  MAINTAINERS: Add Rahul Tanwar as Intel LGM Gateway PCIe maintainer

Merge tag 'soc-fixes-5.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2021-08-19T22:32:58+00:00

Pull ARM SoC fixes from Arnd Bergmann:
 "Not much to see here. Half the fixes this time are for Qualcomm dts
  files, fixing small mistakes on certain machines. The other fixes are:

   - A 5.13 regression fix for freescale QE interrupt controller\

   - A fix for TI OMAP gpt12 timer error handling

   - A randconfig build regression fix for ixp4xx

   - Another defconfig fix following the CONFIG_FB dependency rework"

* tag 'soc-fixes-5.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  soc: fsl: qe: fix static checker warning
  ARM: ixp4xx: fix building both pci drivers
  ARM: configs: Update the nhk8815_defconfig
  bus: ti-sysc: Fix error handling for sysc_check_active_timer()
  soc: fsl: qe: convert QE interrupt controller to platform_device
  arm64: dts: qcom: sdm845-oneplus: fix reserved-mem
  arm64: dts: qcom: msm8994-angler: Disable cont_splash_mem
  arm64: dts: qcom: sc7280: Fixup cpufreq domain info for cpu7
  arm64: dts: qcom: msm8992-bullhead: Fix cont_splash_mem mapping
  arm64: dts: qcom: msm8992-bullhead: Remove PSCI
  arm64: dts: qcom: c630: fix correct powerdown pin for WSA881x

PCI/sysfs: Use correct variable for the legacy_mem sysfs object

2021-08-19T15:21:53+00:00

Two legacy PCI sysfs objects "legacy_io" and "legacy_mem" were updated
to use an unified address space in the commit 636b21b50152 ("PCI: Revoke
mappings like devmem").  This allows for revocations to be managed from
a single place when drivers want to take over and mmap() a /dev/mem
range.

Following the update, both of the sysfs objects should leverage the
iomem_get_mapping() function to get an appropriate address range, but
only the "legacy_io" has been correctly updated - the second attribute
seems to be using a wrong variable to pass the iomem_get_mapping()
function to.

Thus, correct the variable name used so that the "legacy_mem" sysfs
object would also correctly call the iomem_get_mapping() function.

Fixes: 636b21b50152 ("PCI: Revoke mappings like devmem")
Link: https://lore.kernel.org/r/20210812132144.791268-1-kw@linux.com
Signed-off-by: Krzysztof Wilczyński 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Daniel Vetter

PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI

2021-08-19T15:21:53+00:00

The Renoir XHCI controller apparently doesn't resume reliably with the
standard D3hot-to-D0 delay.  Increase it to 20ms.

[Alex: I talked to the AMD USB hardware team and the AMD Windows team and
they are not aware of any HW errata or specific issues.  The HW works fine
in Windows.  I was told Windows uses a rather generous default delay of
100ms for PCI state transitions.]

Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.com
Signed-off-by: Marcin Bachry 
Signed-off-by: Alex Deucher 
Signed-off-by: Bjorn Helgaas 
Cc: stable@vger.kernel.org
Cc: Mario Limonciello 
Cc: Prike Liang 
Cc: Shyam Sundar S K

ARM: ixp4xx: fix building both pci drivers

2021-08-12T21:10:09+00:00

When both the old and the new PCI drivers are enabled
in the same kernel, there are a couple of namespace
conflicts that cause a build failure:

drivers/pci/controller/pci-ixp4xx.c:38: error: "IXP4XX_PCI_CSR" redefined [-Werror]
   38 | #define IXP4XX_PCI_CSR                  0x1c
      |
In file included from arch/arm/mach-ixp4xx/include/mach/hardware.h:23,
                 from arch/arm/mach-ixp4xx/include/mach/io.h:15,
                 from arch/arm/include/asm/io.h:198,
                 from include/linux/io.h:13,
                 from drivers/pci/controller/pci-ixp4xx.c:20:
arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:221: note: this is the location of the previous definition
  221 | #define IXP4XX_PCI_CSR(x) ((volatile u32 *)(IXP4XX_PCI_CFG_BASE_VIRT+(x)))
      |
drivers/pci/controller/pci-ixp4xx.c:148:12: error: 'ixp4xx_pci_read' redeclared as different kind of symbol
  148 | static int ixp4xx_pci_read(struct ixp4xx_pci *p, u32 addr, u32 cmd, u32 *data)
      |            ^~~~~~~~~~~~~~~

Rename both the ixp4xx_pci_read/ixp4xx_pci_write functions and the
IXP4XX_PCI_CSR macro. In each case, I went with the version that
has fewer callers to keep the change small.

Fixes: f7821b493458 ("PCI: ixp4xx: Add a new driver for IXP4xx")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Linus Walleij 
Acked-by: Lorenzo Pieralisi 
Cc: soc@kernel.org
Link: https://lore.kernel.org/r/20210721151546.2325937-1-arnd@kernel.org'
Signed-off-by: Arnd Bergmann

PCI/MSI: Protect msi_desc::masked for multi-MSI

2021-08-10T08:59:20+00:00

Multi-MSI uses a single MSI descriptor and there is a single mask register
when the device supports per vector masking. To avoid reading back the mask
register the value is cached in the MSI descriptor and updates are done by
clearing and setting bits in the cache and writing it to the device.

But nothing protects msi_desc::masked and the mask register from being
modified concurrently on two different CPUs for two different Linux
interrupts which belong to the same multi-MSI descriptor.

Add a lock to struct device and protect any operation on the mask and the
mask register with it.

This makes the update of msi_desc::masked unconditional, but there is no
place which requires a modification of the hardware register without
updating the masked cache.

msi_mask_irq() is now an empty wrapper which will be cleaned up in follow
up changes.

The problem goes way back to the initial support of multi-MSI, but picking
the commit which introduced the mask cache is a valid cut off point
(2.6.30).

Fixes: f2440d9acbe8 ("PCI MSI: Refactor interrupt masking code")
Signed-off-by: Thomas Gleixner 
Tested-by: Marc Zyngier 
Reviewed-by: Marc Zyngier 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.726833414@linutronix.de

PCI/MSI: Use msi_mask_irq() in pci_msi_shutdown()

2021-08-10T08:59:20+00:00

No point in using the raw write function from shutdown. Preparatory change
to introduce proper serialization for the msi_desc::masked cache.

Signed-off-by: Thomas Gleixner 
Tested-by: Marc Zyngier 
Reviewed-by: Marc Zyngier 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.674391354@linutronix.de

PCI/MSI: Correct misleading comments

2021-08-10T08:59:20+00:00

The comments about preserving the cached state in pci_msi[x]_shutdown() are
misleading as the MSI descriptors are freed right after those functions
return. So there is nothing to restore. Preparatory change.

Signed-off-by: Thomas Gleixner 
Tested-by: Marc Zyngier 
Reviewed-by: Marc Zyngier 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.621609423@linutronix.de

PCI/MSI: Do not set invalid bits in MSI mask

2021-08-10T08:59:20+00:00

msi_mask_irq() takes a mask and a flags argument. The mask argument is used
to mask out bits from the cached mask and the flags argument to set bits.

Some places invoke it with a flags argument which sets bits which are not
used by the device, i.e. when the device supports up to 8 vectors a full
unmask in some places sets the mask to 0xFFFFFF00. While devices probably
do not care, it's still bad practice.

Fixes: 7ba1930db02f ("PCI MSI: Unmask MSI if setup failed")
Signed-off-by: Thomas Gleixner 
Tested-by: Marc Zyngier 
Reviewed-by: Marc Zyngier 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210729222542.568173099@linutronix.de