- Jul 18, 2018
-
-
Sergei Shtylyov authored
When testing the R-Car PCIe driver on the Condor board, if the PCIe PHY driver was left disabled, the kernel crashed with this BUG: kernel BUG at lib/ioremap.c:72! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092 Hardware name: Renesas Condor board based on r8a77980 (DT) Workqueue: events deferred_probe_work_func pstate: 80000005 (Nzcv daif -PAN -UAO) pc : ioremap_page_range+0x370/0x3c8 lr : ioremap_page_range+0x40/0x3c8 sp : ffff000008da39e0 x29: ffff000008da39e0 x28: 00e8000000000f07 x27: ffff7dfffee00000 x26: 0140000000000000 x25: ffff7dfffef00000 x24: 00000000000fe100 x23: ffff80007b906000 x22: ffff000008ab8000 x21: ffff000008bb1d58 x20: ffff7dfffef00000 x19: ffff800009c30fb8 x18: 0000000000000001 x17: 00000000000152d0 x16: 00000000014012d0 x15: 0000000000000000 x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 x11: 0720072007300730 x10: 00000000000000ae x9 : 0000000000000000 x8 : ffff7dffff000000 x7 : 0000000000000000 x6 : 0000000000000100 x5 : 0000000000000000 x4 : 000000007b906000 x3 : ffff80007c61a880 x2 : ffff7dfffeefffff x1 : 0000000040000000 x0 : 00e80000fe100f07 Process kworker/0:1 (pid: 39, stack limit = 0x (ptrval)) Call trace: ioremap_page_range+0x370/0x3c8 pci_remap_iospace+0x7c/0xac pci_parse_request_of_pci_ranges+0x13c/0x190 rcar_pcie_probe+0x4c/0xb04 platform_drv_probe+0x50/0xbc driver_probe_device+0x21c/0x308 __device_attach_driver+0x98/0xc8 bus_for_each_drv+0x54/0x94 __device_attach+0xc4/0x12c device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 deferred_probe_work_func+0xb0/0x150 process_one_work+0x12c/0x29c worker_thread+0x200/0x3fc kthread+0x108/0x134 ret_from_fork+0x10/0x18 Code: f9004ba2 54000080 aa0003fb 17ffff48 (d4210000) It turned out that pci_remap_iospace() wasn't undone when the driver's probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER, the probe was retried, finally causing the BUG due to trying to remap already remapped pages. The Versatile PCI controller driver has the same issue. Replace pci_remap_iospace() with the devm_ managed version to fix the bug. Fixes: b7e78170 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [lorenzo.pieralisi@arm.com: updated the commit log] Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org>
-
- Jun 08, 2018
-
-
Shawn Lin authored
Native PCI drivers for root complex devices were originally all in drivers/pci/host/. Some of these devices can also be operated in endpoint mode. Drivers for endpoint mode didn't seem to fit in the "host" directory, so we put both the root complex and endpoint drivers in per-device directories, e.g., drivers/pci/dwc/, drivers/pci/cadence/, etc. These per-device directories contain trivial Kconfig and Makefiles and clutter drivers/pci/. Make a new drivers/pci/controllers/ directory and collect all the device-specific drivers there. No functional change intended. Link: https://lkml.kernel.org/r/1520304202-232891-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> [bhelgaas: changelog] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- May 30, 2018
-
-
Jan Kiszka authored
of_pci_get_host_bridge_resources() allocates the resource structures it fills dynamically, but none of its callers care to release them so far. Rather than requiring everyone to do this explicitly, convert the existing function to a managed version. Tested-by:
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Acked-by:
Joao Pinto <jpinto@synopsys.com> Acked-by:
Jingoo Han <jingoohan1@gmail.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
Jan Kiszka authored
Another step towards a managed version of of_pci_get_host_bridge_resources(): Feed in the underlying device, rather than just the OF node. This will allow us to use managed resource allocation internally later on. Tested-by:
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Acked-by:
Jingoo Han <jingoohan1@gmail.com> CC: Joao Pinto <Joao.Pinto@synopsys.com> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- Jan 28, 2018
-
-
Bjorn Helgaas authored
Add SPDX GPL-2.0 to all PCI files that specified the GPL version 2 license. Remove the boilerplate GPL version 2 language, relying on the assertion in b2441318 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") that the SPDX identifier may be used instead of the full boilerplate text. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Dec 19, 2017
-
-
Bjorn Helgaas authored
On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(), which helps decide whether to reconfigure bridge bus numbers. It has nothing to do with BAR assignments. On arm64 and powerpc, pcibios_assign_all_busses() tests PCI_REASSIGN_ALL_BUS, which makes more sense. Align arm with arm64 and powerpc, so they all use PCI_REASSIGN_ALL_BUS for pcibios_assign_all_busses(). Remove PCI_REASSIGN_ALL_RSRC from the generic, Tegra, Versatile, and R-Car drivers. These drivers are used only on arm or arm64, where PCI_REASSIGN_ALL_RSRC is not used after this change, so removing it should have no effect. No functional change intended. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- Jul 02, 2017
-
-
Bjorn Helgaas authored
Use a local "struct device *dev" for brevity and consistency with other drivers. No functional change intended. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Lorenzo Pieralisi authored
Since, through struct pci_host_bridge.map/swizzle_irq hooks, IRQs are now allocated in the pci_assign_irq() callback automatically, PCI host bridge drivers can stop relying on pci_fixup_irqs() for IRQ allocation. Drop pci_fixup_irqs() usage from PCI versatile host bridge driver. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> [bhelgaas: folded in typo fix from Arnd Bergmann <arnd@arndb.de>: http://lkml.kernel.org/r/20170621215323.3921382-4-arnd@arndb.de ] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: Rob Herring <robh@kernel.org>
-
Lorenzo Pieralisi authored
The introduction of pci_scan_root_bus_bridge() provides a PCI core API to scan a PCI root bus backed by an already initialized struct pci_host_bridge object, which simplifies the bus scan interface and makes the PCI scan root bus interface easier to generalize as members are added to the struct pci_host_bridge. Convert PCI versatile host code to pci_scan_root_bus_bridge() to improve the PCI root bus scanning interface. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> [bhelgaas: folded in fix from Arnd Bergmann <arnd@arndb.de>: http://lkml.kernel.org/r/20170621215323.3921382-3-arnd@arndb.de ] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: Rob Herring <robh@kernel.org>
-
- Apr 28, 2017
-
-
Brian Norris authored
Many PCI host controller drivers aren't prepared to have their devices unbound from them forcefully (e.g., through /sys/.../<driver>/unbind), as they don't provide any driver .remove callback, where they'd detach the root bus, release resources, etc. Keeping the driver built in (i.e., not a loadable module) is not enough; and providing no .remove callback just means we don't do any teardown. To rule out the possibility of unbinding a device via sysfs, we need to set the ".suppress_bind_attrs" field. I found the suspect drivers via the following search: git grep -l platform_driver $(git grep -L -e '\.remove' -e suppress_bind_attrs drivers/pci/) Then I inspected them to ensure that (a) they set up a PCI bus in their probe() and (b) they don't have a remove() callback for undoing the setup Suggested-by:
Bjorn Helgaas <helgaas@kernel.org> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- Apr 24, 2017
-
-
Lorenzo Pieralisi authored
PCI configuration space should be mapped with a memory region type that generates on the CPU host bus non-posted write transations. Update the driver to use the devm_ioremap_nopost* interface to make sure the correct memory mappings for PCI configuration space are used. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: Rob Herring <robh@kernel.org>
-
- Feb 08, 2017
-
-
Bjorn Helgaas authored
Make sure PCIe MPS settings are valid when we enumerate a new hierarchy. Based-on-patch-by:
Jon Mason <jon.mason@broadcom.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- Sep 06, 2016
-
-
Lorenzo Pieralisi authored
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: b7e78170 ("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>
-
- Jun 25, 2016
-
-
Bjorn Helgaas authored
The switch is the only statement in the resource_list_for_each_entry() loop, so remove unnecessary "continue" statements in the switch. Simplify checking for the required non-prefetchable memory aperture. No functional change intended. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Use devm_request_pci_bus_resources() to request host bridge window resources instead of doing it by hand in the driver. No functional change intended. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- Nov 25, 2015
-
-
Lorenzo Pieralisi authored
Commit b3a72384 ("ARM/PCI: Replace pci_sys_data->align_resource with global function pointer") removed the struct pci_sys_data dependency from the ARM pcibios functions that are part of the common ARM PCI arch back-end, e.g., pcibios_align_resource(), so that struct pci_sys_data has now become data that is only used internally by the ARM bios32 layer, i.e., pci_common_init_dev(), and by host controllers drivers callbacks, e.g., pci_sys_data.setup, that rely on the ARM bios32 API to probe. PCI host controller drivers that do not rely on ARM bios32 calls to probe do not need to have the pci_bus.sysdata pointer field pointing at a struct pci_sys_data anymore, therefore it can be removed from the respective drivers data structures. Remove the pci_sys_data structures from the host controller drivers that do not rely on ARM bios32 interface to scan the PCI bus, completing the pci_sys_data clean-up and removing the related dependency on arch/arm specific data. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> CC: Will Deacon <will.deacon@arm.com> CC: Rob Herring <robh@kernel.org>
-
- Apr 09, 2015
-
-
Jisheng Zhang authored
Check for failure of devm_ioremap_resource(). devm_ioremap_resource() validates the resource it receives, so if we check for devm_ioremap_resource() failure, we need not check for failure of the preceding platform_get_resource(). [bhelgaas: changelog] Signed-off-by:
Jisheng Zhang <jszhang@marvell.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- Mar 19, 2015
-
-
Yijing Wang authored
Previously, pci_scan_root_bus() created a root PCI bus, enumerated the devices on it, and called pci_bus_add_devices(), which made the devices available for drivers to claim them. Most callers assigned resources to devices after pci_scan_root_bus() returns, which may be after drivers have claimed the devices. This is incorrect; the PCI core should not change device resources while a driver is managing the device. Remove pci_bus_add_devices() from pci_scan_root_bus() and do it after any resource assignment in the callers. Note that ARM's pci_common_init_dev() already called pci_bus_add_devices() after pci_scan_root_bus(), so we only need to remove the first call: pci_common_init_dev pcibios_init_hw pci_scan_root_bus pci_bus_add_devices # first call pci_bus_assign_resources pci_bus_add_devices # second call [bhelgaas: changelog, drop "root_bus" var in alpha common_init_pci(), return failure earlier in mn10300, add "return" in x86 pcibios_scan_root(), return early if xtensa platform_pcibios_fixup() fails] Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Richard Henderson <rth@twiddle.net> CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru> CC: Matt Turner <mattst88@gmail.com> CC: David Howells <dhowells@redhat.com> CC: Tony Luck <tony.luck@intel.com> CC: Michal Simek <monstr@monstr.eu> CC: Ralf Baechle <ralf@linux-mips.org> CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> CC: Sebastian Ott <sebott@linux.vnet.ibm.com> CC: "David S. Miller" <davem@davemloft.net> CC: Chris Metcalf <cmetcalf@ezchip.com> CC: Chris Zankel <chris@zankel.net> CC: Max Filippov <jcmvbkbc@gmail.com> CC: Thomas Gleixner <tglx@linutronix.de>
-
- Feb 27, 2015
-
-
Joachim Nilsson authored
In Linux 4.0-rc1 ARM Versatile PCI build fails to build due to what appears to be an API update. This patch is a very simple correction, merely posted as a heads-up to the maintainers. Hopefully a better fix can be forwarded to Linus. [ arnd: the patch actually looks correct, so let's take this version ] Signed-off-by:
Joachim Nilsson <troglobit@gmail.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jan 29, 2015
-
-
Rob Herring authored
This converts the Versatile PCI host code to a platform driver using the commom DT parsing and setup. The driver uses only an empty ARM pci_sys_data struct and does not use pci_common_init_dev init function. The old host code will be removed in a subsequent commit when Versatile is completely converted to DT. I've tested this on QEMU with the sym53c8xx driver in both i/o and memory mapped modes. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> CC: Russell King <linux@arm.linux.org.uk> CC: Peter Maydell <peter.maydell@linaro.org>
-