| Age | Commit message (Collapse) | Author |
|---|
|
During soft reset (e.g., "reboot" from Linux) on some iProc-based SOCs, the
LCPLL clock and PERST both go off simultaneously. This seems in accordance
with the PCIe Card Electromechanical spec, r2.0, sec 2.2.3, which says the
clock goes inactive after PERST# goes active, but doesn't specify how long
the clock should be valid after PERST#.
However, we have observed that with the iProc Stingray, some Intel NVMe
endpoints, e.g., the P3700 400GB series, are not detected correctly upon
the next boot sequence unless the clock remains valid for some time after
PERST# is asserted.
Delay 500ms after asserting PERST# before performing a reboot. The 500ms
is experimentally determined.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add spec reference, fold in iproc_pcie_shutdown()
export from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
|
|
Fix various typos and whitespace errors:
s/Synopsis/Synopsys/
s/Designware/DesignWare/
s/Keystine/Keystone/
s/gpio/GPIO/
s/pcie/PCIe/
s/phy/PHY/
s/confgiruation/configuration/
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
VMD hardware has to share its vectors among child devices in its PCI
domain so we should allocate as many as possible rather than just ones
that can be affinitized.
pci_alloc_irq_vectors_affinity() limits the number of affinitized IRQs to
the number of present CPUs (see irq_calc_affinity_vectors()). But we'd
prefer to have more vectors, even if they aren't distributed across the
CPUs, so use pci_alloc_irq_vectors() instead.
Reported-by: Brad Goodman <Bradley.Goodman@dell.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
[bhelgaas: add irq_calc_affinity_vectors() reference to changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Switch from using custom INTX_NUM macro to the generic PCI_NUM_INTX definition
for the number of INTx interrupts.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: use subject/changelog from similar patches]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
MT2712 and MT7622's PCIe host controller support MSI, but only 32-bit MSI
addresses are supported. It connects to GIC with the same IRQ number as the
INTx IRQ, so it shares the same IRQ with INTx IRQ.
Add MSI support for MT2712 and MT7622.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: changes to follow rcar & tegra: rename to mtk_pcie_msi_alloc(),
add mtk_pcie_msi_free(), free hwirq if irq_create_mapping() fails, call
irq_dispose_mapping() from mtk_msi_teardown_irq()]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
|
|
75983c6d1f38 ("PCI: mediatek: Add controller support for MT2712 and
MT7622") has put the mtk_pcie * into bus->sysdata. Take advantage of that
to get the private data and simplify the code.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
|
|
MT2712 and MT7622 using a new IP block of Gen2 controller which has two
root ports and shares the same probing flow with MT2701/MT7623.
Both MT2712 and MT7622 have the same per-port control registers, but
there are slight differences between them:
- MT7622 has more clocks than MT2712.
- MT7622 has shared control registers which are used to enable LTSSM and
ASPM while MT2712 does not.
Add host controller support for MT2712/MT7622.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
[bhelgaas: folded in fix from http://lkml.kernel.org/r/1502715868-17651-2-git-send-email-honghui.zhang@mediatek.com]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
This is a transitional patch. We currently use platfarm_get_resource() for
retrieving the IOMEM resources, but there might be some chips don't have
subsys/shared registers part, which depends on platform design, and these
will be introduced in further patches.
Switch this function to use the platform_get_resource_byname() so that the
binding can be agnostic of the resource order.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Introduce a structure "mtk_pcie_soc" to abstract the differences between
controller generations, and the .startup() hook is used to encapsulate some
SoC-dependent related setting. In doing so, the common code which will be
reused by future chips.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Rename "port->index" to "port->slot" since the ports are hardwired at
PCI_SLOT. Also rename "mtk_pcie_parse_ports()" to "mtk_pcie_parse_port()"
since it parses one port each time.
No functional change in this patch.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Wait for Gen2 training with readl_poll_timeout(), and simplify the hardware
assert logical by merging it into a new mtk_pcie_startup_port() interface.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls to
explicitly state whether the driver needs exclusive or shared reset control
behavior. Convert all drivers requesting exclusive resets to the explicit
API call so the temporary transition helpers can be removed.
No functional changes.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Call pci_unmap_iospace() to clean up if probe fails.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Call irq_domain_remove() to clean up if probe fails.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Disable vpcie0v9 regulator if resume_noirq fails.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
We observed that the clk_pciephy_ref is still enabled when we fail to probe
the driver.
root@linaro-alip:~# grep pcie /sys/kernel/debug/clk/clk_summary
clk_pciephy_ref 1 1 24000000 0 0
clk_pcie_pm 0 0 24000000 0 0
clk_pcie_core_cru 0 0 125000000 0 0
clk_pciephy_ref100m 0 0 100000000 0 0
aclk_pcie 0 0 148500000 0 0
aclk_perf_pcie 0 0 148500000 0 0
pclk_pcie 0 0 37125000 0 0
clk_pcie_core 0 0 0 0 0
clk_pciephy_ref is used by the PHY driver and we need to properly disable
it for this case. Add error handling in rockchip_pcie_init_port() and
rockchip_pcie_resume_noirq() to fix this issue.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Factor out rockchip_pcie_deinit_phys() so it can be reused by
rockchip_pcie_suspend_noirq() and rockchip_pcie_remove(). No functional
change intended.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Factor out rockchip_pcie_disable_clocks() so it can be reused by other
functions.
No functional change intended, but it does change the order of unpreparing
clocks in the rockchip_pcie_resume_noirq() error path so it matches the
other paths.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Factor out rockchip_pcie_enable_clocks() so it can be reused by
rockchip_pcie_resume_noirq() and rockchip_pcie_probe().
No functional change intended, but it does change the order of unpreparing
clocks in the rockchip_pcie_resume_noirq() error path.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Factor out rockchip_pcie_setup_irq() to prepare for future bug fixes. No
functional change intended.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The reset GPIO can be connected to a I2C or SPI IO expander, which may
sleep, so it is safer to use the gpiod_set_value_cansleep() variant
instead.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
|
|
Use the PCI_NUM_INTX macro to indicate the number of PCI INTx interrupts
rather than the magic number 4. This makes it clearer where the number
comes from & what it relates to.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
|
|
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls to
explicitly state whether the driver needs exclusive or shared reset control
behavior. Convert all drivers requesting exclusive resets to the explicit
API call so the temporary transition helpers can be removed.
No functional changes.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
|
|
Configuration Request Retry Status ("CRS") completions are a required part
of PCIe. A PCIe device may respond to config a request with a CRS
completion to indicate that it needs more time to initialize. A Root Port
that receives a CRS completion may automatically retry the request, or it
may treat the request as a failed transaction. For a failed read, it will
likely synthesize all 1's data, i.e., 0xffffffff, to complete the read to
the CPU.
CRS Software Visibility ("CRS SV") is an optional feature. Per PCIe r3.1,
sec 2.3.2, if supported and enabled, a Root Port that receives a CRS
completion for a config read of the Vendor ID will synthesize 0x0001 data
(an invalid Vendor ID) instead of retrying or failing the transaction. The
0x0001 data makes the CRS completion visible to software, so it can perform
other tasks while waiting for the device.
The iProc "Stingray" PCIe controller does not support CRS completions
correctly. From the Stingray PCIe Controller spec:
4.7.3.3. Retry Status On Configuration Cycle
Endpoints are allowed to generate retry status on configuration cycles.
In this case, the RC needs to re-issue the request. The IP does not
handle this because the number of configuration cycles needed will
probably be less than the total number of non-posted operations needed.
When a retry status is received on the User RX interface for a
configuration request that was sent on the User TX interface, it will be
indicated with a completion with the CMPL_STATUS field set to 2=CRS, and
the user will have to find the address and data values and send a new
transaction on the User TX interface. When the internal configuration
space returns a retry status during a configuration cycle (user_cscfg =
1) on the Command/Status interface, the pcie_cscrs will assert with the
pcie_csack signal to indicate the CRS status.
When the CRS Software Visibility Enable register in the Root Control
register is enabled, the IP will return the data value to 0x0001 for the
Vendor ID value and 0xffff (all 1’s) for the rest of the data in the
request for reads of offset 0 that return with CRS status. This is true
for both the User RX Interface and for the Command/Status interface.
When CRS Software Visibility is enabled, the CMPL_STATUS field of the
completion on the User RX Interface will not be 2=CRS and the pcie_cscrs
signal will not assert on the Command/Status interface.
The Stingray hardware never reissues configuration requests when it
receives CRS completions. Contrary to what sec 4.7.3.3 above says, when it
receives a CRS completion, it synthesizes 0xffff0001 data regardless of the
address of the read or the value of the CRS SV enable bit.
This is broken in two ways:
1) When CRS SV is disabled, the Root Port should never synthesize the
0x0001 value. If it receives a CRS completion, it should fail the
transaction and synthesize all 1's data.
2) When CRS SV is enabled, the Root Port should only synthesize 0x0001
data if it receives a CRS completion for a read of the Vendor ID. If it
receives a CRS completion for any other read, it should fail the
transaction and synthesize all 1's data.
This breaks pci_flr_wait(), which reads the Command register and expects to
see all 1's data if the read fails because of CRS completions. On
Stingray, it sees the incorrect 0xffff0001 data instead.
It also breaks config registers that contain the 0xffff0001 value. If we
read such a register, software can't distinguish a CRS completion from the
actual value read from the device.
On Stingray, if we read 0xffff0001 data, assume this indicates a CRS
completion and retry the read for 500ms. If we time out, return all 1's
(0xffffffff) data. Note that this corrupts registers that happen to
contain 0xffff0001.
Stingray advertises CRS SV support in its Root Capabilities register, and
the CRS SV enable bit is writable (even though the hardware ignores it).
Mask out PCI_EXP_RTCAP_CRSVIS so software doesn't try to use CRS SV.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
[bhelgaas: changelog, add probe-time warning about corruption, don't
advertise CRS SV support, remove duplicate pci_generic_config_read32(),
fix alignment based on patch from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Factor out the address calculation for memory-mapped config accesses as a
separate function. No functional change intended.
Signed-off-by: Oza Pawandeep <oza.oza@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Check the status of all lanes and idle the inactive one(s).
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
[bhelgaas: always set lanes_map, even for legacy_phy case]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
|
|
We distinguish the legacy PHY from newer per-lane PHYs by adding legacy_phy
flag. Note that the legacy PHY is still the first option to be searched in
order not to break the backward compatibility of DTB.
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
[bhelgaas: tidy rockchip_pcie_get_phys()]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
|
|
Now that we have a custom printf format specifier, convert users of
full_name() to use %pOF instead. This is preparation for removing storing
of the full path string for each node.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
|
|
Allow the xilinx-pcie driver to be built on MIPS platforms which make use
of generic PCI drivers rather than legacy MIPS-specific interfaces. This
is used on the MIPS Boston development board.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
|
|
The Xilinx AXI bridge for PCI Express device provides interrupts indicating
the completion of config space accesses. We have previously
enabled/unmasked them but do nothing with them besides acknowledge them.
Leave the interrupts masked in order to avoid servicing a large number of
pointless interrupts during boot.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
|
|
The INTx & MSI interrupt decode paths duplicated a fair bit of common
functionality. They also strictly handled interrupts in order of INTx then
MSI, so if both types of interrupt were to be asserted simultaneously and
the MSI interrupt were first in the FIFO then the INTx code would read it &
ignore it before the MSI code then had to read it again, wasting the
original FIFO read.
Unify the INTx & MSI decode in order to reduce that duplication & allow a
single FIFO read to be performed for each interrupt regardless of its type.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
|
|
The devicetree binding documentation for the Xilinx NWL PCIe root port
bridge shows an example which uses an interrupt-map property to map PCI
INTx interrupts to hardware IRQ numbers 1-4. The driver creates an IRQ
domain with size 4, which therefore covers the hwirq range 0-3.
This means that if we attempt to make use of the INTD interrupt then we're
likely to hit a WARN() in irq_domain_associate() because INTD, or hwirw=4,
is outside of the range covered by the IRQ domain. irq_domain_associate()
will then return -EINVAL and we'll be unable to make use of INTD.
Fix this by making use of the pci_irqd_intx_xlate() helper function to
translate the 1-4 range used in the DT to a 0-3 range used within the
driver, and stop adding 1 to decoded hwirq numbers.
Whilst cleaning up INTx handling we make use of the new PCI_NUM_INTX macro
& drop the custom INTX definitions.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
|
|
The pcie-xilinx driver creates an IRQ domain of size 4 for legacy PCI INTx
interrupts, which at first glance seems reasonable since there are 4
possible such interrupts. Unfortunately the driver then proceeds to use the
range 1-4 as the hwirq numbers for INTA-INTD, causing warnings & broken
interrupts when attempting to use INTD/hwirq=4 due to it being beyond the
range of the IRQ domain:
WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:365
irq_domain_associate+0x170/0x220
error: hwirq 0x4 is too large for dummy
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
4.12.0-rc5-00126-g19e1b3a10aad-dirty #427
Stack : 0000000000000000 0000000000000004 0000000000000006 ffffffff8092c78a
0000000000000061 ffffffff8018bf60 0000000000000000 0000000000000000
ffffffff8088c287 ffffffff80811d18 a8000000ffc60000 ffffffff80926678
0000000000000001 0000000000000000 ffffffff80887880 ffffffff80960000
ffffffff80920000 ffffffff801e6744 ffffffff80887880 a8000000ffc4f8f8
000000000000089c ffffffff8018d260 0000000000010000 ffffffff80811d18
0000000000000000 0000000000000001 0000000000000000 0000000000000000
0000000000000000 a8000000ffc4f840 0000000000000000 ffffffff8042cf34
0000000000000000 0000000000000000 0000000000000000 0000000000040c00
0000000000000000 ffffffff8010d1c8 0000000000000000 ffffffff8042cf34
...
Call Trace:
[<ffffffff8010d1c8>] show_stack+0x80/0xa0
[<ffffffff8042cf34>] dump_stack+0xd4/0x110
[<ffffffff8013ea98>] __warn+0xf0/0x108
[<ffffffff8013eb14>] warn_slowpath_fmt+0x3c/0x48
[<ffffffff80196528>] irq_domain_associate+0x170/0x220
[<ffffffff80196bf0>] irq_create_mapping+0x88/0x118
[<ffffffff801976a8>] irq_create_fwspec_mapping+0xb8/0x320
[<ffffffff80197970>] irq_create_of_mapping+0x60/0x70
[<ffffffff805d1318>] of_irq_parse_and_map_pci+0x20/0x38
[<ffffffff8049c210>] pci_fixup_irqs+0x60/0xe0
[<ffffffff8049cd64>] xilinx_pcie_probe+0x28c/0x478
[<ffffffff804e8ca8>] platform_drv_probe+0x50/0xd0
[<ffffffff804e73a4>] driver_probe_device+0x2c4/0x3a0
[<ffffffff804e7544>] __driver_attach+0xc4/0xd0
[<ffffffff804e5254>] bus_for_each_dev+0x64/0xa8
[<ffffffff804e5e40>] bus_add_driver+0x1f0/0x268
[<ffffffff804e8000>] driver_register+0x68/0x118
[<ffffffff801001a4>] do_one_initcall+0x4c/0x178
[<ffffffff808d3ca8>] kernel_init_freeable+0x204/0x2b0
[<ffffffff80730b68>] kernel_init+0x10/0xf8
[<ffffffff80106218>] ret_from_kernel_thread+0x14/0x1c
Fix this by making use of the new pci_irqd_intx_xlate() helper to translate
the INTx 1-4 range into the 0-3 range suitable for the IRQ domain of size
4, and stop adding 1 to the hwirq number decoded from the interrupt FIFO
which is already in the range 0-3.
Whilst we're here we switch to using PCI_NUM_INTX rather than the magic
number 4, making it clearer what the 4 means.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bharat Kumar Gogada <bharatku@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ravikiran Gummaluri <rgummal@xilinx.com>
|
|
We plan to introduce per-lane PHYs, so factor out rockchip_pcie_get_phys()
to make it easier in the future. No functional change intended.
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>
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>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
|
|
Get vpcie12v from DT and control it if available.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Use the PCI_NUM_INTX macro to indicate the number of PCI INTx interrupts
rather than the magic number 4. This makes it clearer where the number
comes from & what it relates to.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
of_irq_get() may return a negative error number as well as 0 on failure,
while the driver only checks for 0, blithely continuing with the call to
irq_set_chained_handler_and_data() -- that function expects *unsigned int*
so should probably do nothing when a large IRQ number resulting from a
conversion of a negative error number is passed to it. The driver then
probes successfully while being only partly functional...
Check for 'irq <= 0' instead and propagate the negative error number to the
probe method -- that will allow the deferred probing as well.
Fixes: d3c68e0a7e34 ("PCI: faraday: Add Faraday Technology FTPCI100 PCI Host Bridge driver")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The devicetree binding documentation for the Altera PCIe controller shows
an example which uses an interrupt-map property to map PCI INTx interrupts
to hardware IRQ numbers 1-4. The driver creates an IRQ domain with size 5
in order to cover this range, with hwirq=0 left unused.
This patch cleans up this wasted IRQ domain entry, modifying the driver to
use an IRQ domain of size 4 which matches the actual number of PCI INTx
interrupts. Since the hwirq numbers 1-4 are part of the devicetree binding,
and this is considered ABI, we cannot simply change the interrupt-map
property to use the range 0-3. Instead we make use of the
pci_irqd_intx_xlate() helper function to translate the range 1-4 used at
the DT level into the range 0-3 which is now used within the driver, and
stop adding 1 to decoded hwirq numbers in altera_pcie_isr().
Whilst cleaning up INTx handling we make use of the new PCI_NUM_INTX macro
& drop the custom INTX_NUM definition.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ley Foon Tan <lftan@altera.com>
|
|
The local variable "num_of_vectors" was unused, so remove it.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ley Foon Tan <lftan@altera.com>
|
|
Switch from using a custom LEGACY_IRQ_NUM macro to the generic PCI_NUM_INTX
definition for the number of INTx interrupts.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
When no PCIe card is inserted, there is a memory leak as
pci_free_resource_list() is not called before returning.
Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
|
|
Commit 90634e854079 ("PCI: rcar: Convert PCI scan API to
pci_scan_root_bus_bridge()") converted PCI root bus scan API to the new
pci_scan_root_bus_bridge() API; in the process some error paths were not
updated correctly which may cause memory leaks.
Fix the driver error exit path reinstating the previous correct
error exit behaviour.
Fixes: 90634e854079 ("PCI: rcar: Convert PCI scan API to pci_scan_root_bus_bridge()")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
|
|
Free up the IRQs we request on the suspend path and reallocate them on the
resume path.
Fixes this error:
CPU 111 disable failed: CPU has 9 vectors assigned and there are only 0 available.
Error taking CPU111 down: -34
Non-boot CPUs are not disabled
Enabling non-boot CPUs ...
Signed-off-by: Scott Bauer <scott.bauer@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Keith Busch <keith.busch@intel.com>
|
|
To support implementing remote TLB flushing on Hyper-V with a hypercall
we need to make vp_index available outside of vmbus module. Rename and
globalize.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Jork Loeser <Jork.Loeser@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Simon Xiao <sixiao@microsoft.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: devel@linuxdriverproject.org
Link: http://lkml.kernel.org/r/20170802160921.21791-7-vkuznets@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
The setup of MSI with Hyper-V host was sleeping with locks held. This
error is reported when doing SR-IOV hotplug with kernel built with lockdep:
BUG: sleeping function called from invalid context at kernel/sched/completion.c:93
in_atomic(): 1, irqs_disabled(): 1, pid: 1405, name: ip
3 locks held by ip/1405:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff976b10bb>] rtnetlink_rcv+0x1b/0x40
#1: (&desc->request_mutex){+.+...}, at: [<ffffffff970ddd33>] __setup_irq+0xb3/0x720
#2: (&irq_desc_lock_class){-.-...}, at: [<ffffffff970ddd65>] __setup_irq+0xe5/0x720
irq event stamp: 3476
hardirqs last enabled at (3475): [<ffffffff971b3005>] get_page_from_freelist+0x225/0xc90
hardirqs last disabled at (3476): [<ffffffff978024e7>] _raw_spin_lock_irqsave+0x27/0x90
softirqs last enabled at (2446): [<ffffffffc05ef0b0>] ixgbevf_configure+0x380/0x7c0 [ixgbevf]
softirqs last disabled at (2444): [<ffffffffc05ef08d>] ixgbevf_configure+0x35d/0x7c0 [ixgbevf]
The workaround is to poll for host response instead of blocking on
completion.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
We don't want slower IRQ handlers impacting faster devices that happen to
be assigned the same VMD interrupt vector. The driver was trying to
separate such devices by checking if MSI-X wasn't used, but really we just
don't want endpoint devices to share with bridges. Most bridges may use MSI
currently, so that criteria happened to work, but newer ones may use MSI-X,
so this patch explicitly checks the device type when choosing a vector.
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The driver has a special purpose for the VMD device's first IRQ, so this
one shouldn't be considered for IRQ affinity.
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls to
explicitly state whether the driver needs exclusive or shared reset control
behavior. Convert all drivers requesting exclusive resets to the explicit
API call so the temporary transition helpers can be removed.
No functional changes.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
|
|
The gpiod API checks for NULL descriptors, so there is no need to duplicate
the check in the driver.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com
|
|
The local variable "pcie" was unused, so remove it.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ray Jui <rjui@broadcom.com>
|
