Age | Commit message (Collapse) | Author |
|
Kernel provides virtual IRQ number at teardown. Get hwirq number from
virtual IRQ and clear correct MSI set bit.
Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
|
|
The interrupt decode register is not being cleared if an invalid interrupt
arises. Clear the decode register in this case.
Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
|
|
When built with MSI support, the legacy domain reference was being
overwritten with MSI.
Create two separate domains for MSI and legacy interrupts.
Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
|
|
The current mask enables and allows only one MSI interrupt on each MSI
line. Enable all MSI interrupts, which will also support Endpoints with
multi-MSI support.
Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The current driver logs PCIe core errors. Add logging for individual core
events.
[bhelgaas: changelog]
Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
If clk_prepare_enable() fails, we must not call clk_disable_unprepare() in
the error path.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
devm_ioremap_resource() fails gracefully when given a NULL resource
pointer, so we don't need to check separately for failure from
platform_get_resource_byname(). Remove the redundant check.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Previously we used a PCI early fixup to initiate a link retrain on Altera
devices. But Altera PCIe IP can be configured as either a Root Port or an
Endpoint, and they might have same vendor ID, so the fixup would be run for
both.
We only want to initiate a link retrain for Altera Root Port devices, not
for Endpoints, so move the link retrain functionality from the fixup to
altera_pcie_host_init().
[bhelgaas: changelog]
Signed-off-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Previously we only allowed device 0 to be directly attached to the root
port. But SR-IOV devices may use non-zero device numbers for VFs.
Remove the restriction that only device 0 may be attached to a root port.
[bhelgaas: changelog]
Signed-off-by: Po Liu <po.liu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Previously we only allowed device 0 to be directly attached to the root
port. But SR-IOV devices may use non-zero device numbers for VFs.
Remove the restriction that only device 0 may be attached to a root port.
[bhelgaas: changelog]
Signed-off-by: Po Liu <po.liu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
|
|
Previously we only allowed device 0 to be directly attached to the root
port. But SR-IOV devices may use non-zero device numbers for VFs.
Remove the restriction that only device 0 may be attached to a root port.
[bhelgaas: changelog]
Signed-off-by: Po Liu <po.liu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ley Foon Tan <lftan@altera.com>
|
|
If pci_setup_device() returns failure, we must return failure from
pci_iov_add_virtfn(). If we ignore the failure and continue with an
uninitialized pci_dev for virtfn, we crash later when we try to use those
uninitialized parts.
Signed-off-by: Po Liu <po.liu@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
It is possible to provide information about which MSI controller to
use on a per-device basis for DT. This patch supply this with ACPI support.
Currently, IORT is the only one ACPI table which can provide such mapping.
In order to plug IORT into MSI infrastructure we are adding ACPI
equivalents for finding PCI device domain and its RID translation
(pci_msi_domain_get_msi_rid and pci_msi_domain_get_msi_rid calls).
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
Rename "detected" and "intr_loc" to "status" and "events" for clarity.
"status" is the value we read from the Slot Status register; "events" is
the set of hot-plug events we need to process. No functional change
intended.
Tested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Some PCI root bridges don't have a corresponding ACPI device.
This can be the case on some old platforms. Don't call acpi_ioapic_add()
on these bridges because they can't support ioapic hotplug.
Reported-and-tested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bhelgaas@google.com
Cc: helgaas@kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: rjw@rjwysocki.net
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/1473522046-31329-1-git-send-email-rui.y.wang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Commit:
ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
... enabled the PWRMU driver on platforms based on Intel Penwell, but
unfortunately this is not enough.
Add Intel Penwell ID to pci-mid.c driver as well. To avoid confusion in the
future add a comment to both drivers.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
Link: http://lkml.kernel.org/r/20160908103232.137587-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Merrifield2 is actually Moorefield.
Rename it accordingly and drop tail digit from Merrifield1.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160906184254.94440-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
The newly added quirk_cavium_sriov_rnm_link doesn't compile if
PCI_ATS is off. This patch adds a check for PCI_ATS.
Fixes: 21b5b8eebbae ("PCI: quirk fixup for cavium invalid sriov...")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
VMD root ports change all source ids to the VMD device ID. To find the
sender of the AER notification, we need to scan all child devices for the
AER sender, rather than relying on the source ID from the message.
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Allow root port buses to choose to skip source id matching when finding the
faulting device. Certain root port devices may return an incorrect source
ID and recommend to scan child device registers for AER notifications.
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI tegra host bridge driver adds the PCI IO resource retrieved from
firmware to the host bridge resource windows even if the
pci_remap_iospace() call fails; this is an actual bug in that the PCI host
bridge would consider the PCI IO resource valid (and possibly assign it to
downstream devices) even if the kernel was not able to map the PCI host
bridge memory address driving IO cycle to the CPU virtual address space (ie
pci_remap_iospace() failures).
Add the PCI host bridge driver pci_remap_iospace() failure path and do not
add the corresponding PCI host bridge PCI IO resources retrieved through
firmware when the pci_remap_iospace() function call fails, fixing the
issue.
Fixes: e6e9f471f5fe ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Thierry Reding <treding@nvidia.com>
|
|
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI common host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: 4e64dbe226e7 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
|
|
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI rcar host bridge driver does not remove the PCI IO resource from
the host bridge resource windows if the pci_remap_iospace() call fails;
this is an actual bug in that the PCI host bridge would consider the PCI IO
resource valid (and possibly assign it to downstream devices) even if the
kernel was not able to map the PCI host bridge memory address driving IO
cycle to the CPU virtual address space (ie pci_remap_iospace() failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: 5d2917d469fa ("PCI: rcar: Convert to DT resource parsing API")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Phil Edworthy <phil.edworthy@renesas.com>
CC: Simon Horman <horms+renesas@verge.net.au>
|
|
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI versatile host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: b7e78170efd4 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Rob Herring <robh@kernel.org>
|
|
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridges memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI designware host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: cbce7900598c ("PCI: designware: Make driver arch-agnostic")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Jingoo Han <jingoohan1@gmail.com>
CC: Pratyush Anand <pratyush.anand@gmail.com>
|
|
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped
IO, by reserving a chunk of virtual address space starting at PCI_IOBASE
and by mapping the PCI host bridge's memory address space driving PCI IO
cycles to it.
PCI host bridge drivers that enable downstream PCI IO cycles map the host
bridge memory address responding to PCI IO cycles to the fixed virtual
address space through the pci_remap_iospace() API.
This means that if the pci_remap_iospace() function fails, the
corresponding host bridge PCI IO resource must be considered invalid, in
that there is no way for the kernel to actually drive PCI IO transactions
if the memory addresses responding to PCI IO cycles cannot be mapped into
the CPU virtual address space.
The PCI aardvark host bridge driver does not remove the PCI IO resource
from the host bridge resource windows if the pci_remap_iospace() call
fails; this is an actual bug in that the PCI host bridge would consider the
PCI IO resource valid (and possibly assign it to downstream devices) even
if the kernel was not able to map the PCI host bridge memory address
driving IO cycle to the CPU virtual address space (ie pci_remap_iospace()
failures).
Fix the PCI host bridge driver pci_remap_iospace() failure path, by
destroying the PCI host bridge PCI IO resources retrieved through firmware
when the pci_remap_iospace() function call fails, therefore preventing the
kernel from adding the respective PCI IO resource to the list of PCI host
bridge valid resources, fixing the issue.
Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
'completion_status' is used in some places, e.g.,
hv_pci_protocol_negotiation(), so we should make sure it's initialized in
error case too, though the error is unlikely here.
[bhelgaas: fix changelog typo and nearby whitespace]
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: KY Srinivasan <kys@microsoft.com>
CC: Jake Oshins <jakeo@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
|
|
Handle vmbus_sendpacket() failure in hv_compose_msi_msg().
I happened to find this when reading the code. I didn't get a real issue
however.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: KY Srinivasan <kys@microsoft.com>
CC: Jake Oshins <jakeo@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
|
|
Remove the unused 'wrk' member in struct hv_pcibus_device.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: KY Srinivasan <kys@microsoft.com>
CC: Jake Oshins <jakeo@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
|
|
The 2 structs can use a zero-length array here, because dynamic memory of
the correct size is allocated in hv_pci_devices_present() and we don't need
this extra element.
No functional change.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: KY Srinivasan <kys@microsoft.com>
CC: Jake Oshins <jakeo@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
|
|
Use zero-length array in struct pci_packet and rename struct pci_message's
field "message_type" to "type". This makes the code more readable.
No functionality change.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: KY Srinivasan <kys@microsoft.com>
CC: Jake Oshins <jakeo@microsoft.com>
CC: Haiyang Zhang <haiyangz@microsoft.com>
CC: Vitaly Kuznetsov <vkuznets@redhat.com>
|
|
Add ARC as an arch that supports PCI_MSI_IRQ_DOMAIN and add generation of
msi.h in the ARC arch.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are a number of small driver fixes for 4.8-rc5.
The largest thing here is deleting an obsolete driver,
drivers/misc/bh1780gli.c, as the functionality of it was replaced by
an iio driver a while ago.
The other fixes are things that have been reported, or reverts of
broken stuff (the binder change). All of these changes have been in
linux-next for a while with no reported issues"
* tag 'char-misc-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
thunderbolt: Don't declare Falcon Ridge unsupported
thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.
thunderbolt: Fix resume quirk for Falcon Ridge 4C.
lkdtm: Mark lkdtm_rodata_do_nothing() notrace
mei: me: disable driver on SPT SPS firmware
Revert "android: binder: fix dangling pointer comparison"
drivers/iio/light/Kconfig: SENSORS_BH1780 cleanup
android: binder: fix dangling pointer comparison
misc: delete bh1780 driver
|
|
Add support for the Rockchip PCIe controller found on RK3399 SoC platform.
[bhelgaas: fold in Brian's rockchip_pcie_client_irq_handler() OR fix, other
fixes and cleanups from Guenter Roeck <linux@roeck-us.net> and me,
uninitialized variable fix from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
|
|
* pci/ptm:
PCI: Add PTM clock granularity information
PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints
PCI: Add Precision Time Measurement (PTM) support
|
|
Cavium cn88xx hardware presents an incorrect SR-IOV Function
Dependency Link, add a fixup quirk for the affected devices.
Acked-by: David Daney <david.daney@cavium.com>
Signed-off-by: Ananth Jasty <Ananth.Jasty@cavium.com>
Signed-off-by: Omer Khaliq <okhaliq@caviumnetworks.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
From: Xavier Gnata <xavier.gnata@gmail.com>
Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk
to support suspend/resume.
Tested against 4.7 master on a MacBook Air 11" 2015.
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The quirk 'quirk_apple_wait_for_thunderbolt' did not fire on Falcon
Ridge 4C controllers with subdevice/subvendor set to zero. This lead
to lost pci devices on system resume.
Older thunderbolt controllers (pre Falcon Ridge) used the same device id
for bridges and for the controller. On Apple hardware the subvendor- &
subdevice-ids were set for the controller, but not for bridges. So that
is what was used to differentiate between the two. Starting with Falcon
Ridge bridges and controllers received different device ids.
Additionally on some MacBookPro models (but not all) the
subvendor/subdevice was zeroed.
Starting with a42fb351c (thunderbolt: Allow loading of module on recent
Apple MacBooks with thunderbolt 2 controller) the thunderbolt driver
binds to all Falcon Ridge 4C controllers (irregardless of
subvendor/subdevice). The corresponding quirk was not updated.
This commit changes the quirk to check the device class instead of its
subvendor-/subdeviceids. This works for all generations of Thunderbolt
controllers.
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Ben Herrenschmidt:
"This was meant to be sent early last week, but I has a change pending
on one of the fixes and other things made me forget all about. Ugh.
We have some misc fixes for powerpc 4.8. Some trivial bits and some
regressions, and a trivial cleanup or two that I saw no point in
letting rot in patchwork"
* tag 'powerpc-4.8-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc: signals: Discard transaction state from signal frames
powerpc/powernv : Drop reference added by kset_find_obj()
powerpc/tm: do not use r13 for tabort_syscall
powerpc: move hmi.c to arch/powerpc/kvm/
powerpc: sysdev: cpm: fix gpio save_regs functions
powerpc/pseries: PACA save area fix for MCE vs MCE
powerpc/pseries: PACA save area fix for general exception vs MCE
powerpc/prom: Fix sub-processor option passed to ibm, client-architecture-support
powerpc, hotplug: Avoid to touch non-existent cpumasks.
powerpc: migrate exception table users off module.h and onto extable.h
powerpc/powernv/pci: fix iterator signedness
powerpc/pseries: use pci_host_bridge.release_fn() to kfree(phb)
cxl: use pcibios_free_controller_deferred() when removing vPHBs
powerpc: mpc8349emitx: Delete unnecessary assignment for the field "owner"
powerpc/512x: Delete unnecessary assignment for the field "owner"
drivers/macintosh: Delete owner assignment
powerpc: cputhreads: Add missing include file
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
"Resource management:
- Update "pci=resource_alignment" documentation (Mathias Koehrer)
MSI:
- Use positive flags in pci_alloc_irq_vectors() (Christoph Hellwig)
- Call pci_intx() when using legacy interrupts in pci_alloc_irq_vectors() (Christoph Hellwig)
Intel VMD host bridge driver:
- Fix infinite loop executing irq's (Keith Busch)"
* tag 'pci-v4.8-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
x86/PCI: VMD: Fix infinite loop executing irq's
PCI: Call pci_intx() when using legacy interrupts in pci_alloc_irq_vectors()
PCI: Use positive flags in pci_alloc_irq_vectors()
PCI: Update "pci=resource_alignment" documentation
|
|
Rework configs accessors so a future patch can use them in _probe() with
struct altera_pcie instead of struct pci_bus.
Signed-off-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The PTM Control register (PCIe r3.1, sec 7.32.3) contains an Effective
Granularity field:
This provides information relating to the expected accuracy of the PTM
clock, but does not otherwise affect the PTM mechanism.
Set the Effective Granularity based on the PTM Root and any intervening PTM
Time Sources.
This does not set Effective Granularity for Root Complex Integrated
Endpoints because I don't know how to figure out clock granularity for
them. The spec says:
... system software must set [Effective Granularity] to the value
reported in the Local Clock Granularity field by the associated PTM
Time Source.
but I don't know how to identify the associated PTM Time Source. Normally
it's the upstream bridge, but an integrated endpoint has no upstream
bridge.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
This code is not being built as a module by anyone:
obj-$(CONFIG_HOTPLUG_PCI_PCIE) += pciehp.o
pciehp-objs := pciehp_core.o \
drivers/pci/pcie/Kconfig:config HOTPLUG_PCI_PCIE
drivers/pci/pcie/Kconfig: bool "PCI Express Hotplug driver"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, module_init() translates to
device_initcall(). One could argue that we should use subsys_initcall()
here, but for now we stick with runtime equivalence.
We delete module.h but we keep the moduleparam.h include, since we are
keeping the module_param() that the file has as-is for now.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Kristen Carlson Accardi <kristen@linux.intel.com>
|
|
This code is not being built as a module by anyone:
obj-$(CONFIG_HOTPLUG_PCI) += pci_hotplug.o
[...]
pci_hotplug-objs := pci_hotplug_core.o
drivers/pci/hotplug/Kconfig:menuconfig HOTPLUG_PCI
drivers/pci/hotplug/Kconfig: bool "Support for PCI Hotplug"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Remove orphaned exit function in cpci_hotplug_core.c.
Note that for non-modular code, module_init() translates to
device_initcall(). One could argue that we should use subsys_initcall()
here, but for now we stick with runtime equivalence.
We would delete module.h and just keep the moduleparam.h include (since the
file does use module_param), but there is a try_module_get and module_put
pairing that prevents us from doing that.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Scott Murray <scott@spiteful.org>
CC: Kristen Carlson Accardi <kristen@linux.intel.com>
|
|
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_XILINX_NWL
drivers/pci/host/Kconfig: bool "NWL PCIe Core"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers. Delete several functions only used by the remove function.
Note that for non-modular code, builtin_platform_driver() uses the same
init level priority as module_platform_driver(), so this doesn't change
init ordering.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <michal.simek@xilinx.com>
CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
CC: Marc Zyngier <marc.zyngier@arm.com>
CC: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
|
|
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_XILINX
drivers/pci/host/Kconfig: bool "Xilinx AXI PCIe host bridge support"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, builtin_platform_driver() uses the same
init level priority as module_platform_driver(), so this doesn't change
init ordering.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <michal.simek@xilinx.com>
CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
|
|
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCIE_QCOM
drivers/pci/host/Kconfig: bool "Qualcomm PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
builtin_platform_driver() uses the same init level priority as
module_platform_driver(), so this doesn't change init ordering.
Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Stanimir Varbanov <svarbanov@mm-sol.com>
|
|
This code is not being built as a module by anyone:
drivers/pci/host/Kconfig:config PCI_DRA7XX
drivers/pci/host/Kconfig: bool "TI DRA7xx PCIe controller"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, MODULE_DEVICE_TABLE is a no-op and
builtin_platform_driver_probe() uses the same init level priority as
module_platform_driver_probe(), so this doesn't change init ordering.
Explicitly disallow driver unbind, since that doesn't have a sensible use
case anyway, and it allows us to drop the ".remove" code for non-modular
drivers.
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Kishon Vijay Abraham I <kishon@ti.com>
|
|
This code is not being built as a module by anyone:
obj-$(CONFIG_PCIEAER) += aerdriver.o
aerdriver-objs := aerdrv_errprint.o aerdrv_core.o aerdrv.o
drivers/pci/pcie/aer/Kconfig:config PCIEAER
drivers/pci/pcie/aer/Kconfig: bool "Root Port Advanced Error Reporting support"
Remove uses of MODULE_DESCRIPTION(), MODULE_AUTHOR(), MODULE_LICENSE(),
etc., so that when reading the driver there is no doubt it is builtin-only.
The information is preserved in comments at the top of the file.
Note that for non-modular code, module_init() translates to
device_initcall().
[bhelgaas: changelog]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Tom Long Nguyen <tom.l.nguyen@intel.com>
|
|
This code is not being built as a module by anyone:
config PCIE_PME
def_bool y
depends on PCIEPORTBUS && PM
Remove traces of modularity so that when reading the driver there is no
doubt it is builtin-only.
Also delete the .remove function, since that doesn't seem to have a
sensible use case. With "normal" endpoint drivers, we have in the past set
the suppress_bind_attrs bit to make it clear that the use of ".remove" in a
builtin driver was deleted, but here for PCI, it seems overkill to jump
through the pcie_port_service_driver and into the struct device_driver in
order to finally try and do something similar with the bind setting.
Note that for non-modular code, module_init() translates to
device_initcall().
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|