Skip to content
Snippets Groups Projects
  1. Jul 18, 2018
    • Sergei Shtylyov's avatar
      PCI: versatile: Fix I/O space page leak · 0018b265
      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: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      [lorenzo.pieralisi@arm.com: updated the commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      0018b265
  2. Jun 08, 2018
  3. May 30, 2018
  4. Jan 28, 2018
  5. Dec 19, 2017
    • Bjorn Helgaas's avatar
      PCI: Remove PCI_REASSIGN_ALL_RSRC use on arm and arm64 · 7153884c
      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: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarManikanta Maddireddy <mmaddireddy@nvidia.com>
      Reviewed-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      7153884c
  6. Jul 02, 2017
  7. Apr 28, 2017
    • Brian Norris's avatar
      PCI: Don't allow unbinding host controllers that aren't prepared · a5f40e80
      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: default avatarBjorn Helgaas <helgaas@kernel.org>
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      a5f40e80
  8. Apr 24, 2017
  9. Feb 08, 2017
  10. Sep 06, 2016
    • Lorenzo Pieralisi's avatar
      PCI: versatile: Fix pci_remap_iospace() failure path · 53f4f7ee
      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: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Rob Herring <robh@kernel.org>
      53f4f7ee
  11. Jun 25, 2016
  12. Nov 25, 2015
    • Lorenzo Pieralisi's avatar
      PCI: generic,versatile: Remove unused pci_sys_data structures · a574795b
      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: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      CC: Will Deacon <will.deacon@arm.com>
      CC: Rob Herring <robh@kernel.org>
      a574795b
  13. Apr 09, 2015
  14. Mar 19, 2015
    • Yijing Wang's avatar
      PCI: Assign resources before drivers claim devices (pci_scan_root_bus()) · b97ea289
      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: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarBjorn 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>
      b97ea289
  15. Feb 27, 2015
  16. Jan 29, 2015
Loading