07 Jan, 2012

1 commit

  • We'd like to supply a list of resources when we create a new PCI bus,
    e.g., the root bus under a PCI host bridge. These are helpers for
    constructing that list.

    These are exported because the plan is to replace this exported interface:
    pci_scan_bus_parented()
    with this one:
    pci_add_resource(resources, ...)
    pci_scan_root_bus(..., resources)

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

22 May, 2011

1 commit


18 Dec, 2010

2 commits


13 Nov, 2010

1 commit

  • When a PCI bus has two resources with the same start/end, e.g.,

    pci_bus 0000:04: resource 2 [mem 0xd0000000-0xd7ffffff pref]
    pci_bus 0000:04: resource 7 [mem 0xd0000000-0xd7ffffff]

    the previous pci_bus_find_resource_prev() implementation would alternate
    between them forever:

    pci_bus_find_resource_prev(... [mem 0xd0000000-0xd7ffffff pref])
    returns [mem 0xd0000000-0xd7ffffff]
    pci_bus_find_resource_prev(... [mem 0xd0000000-0xd7ffffff])
    returns [mem 0xd0000000-0xd7ffffff pref]
    pci_bus_find_resource_prev(... [mem 0xd0000000-0xd7ffffff pref])
    returns [mem 0xd0000000-0xd7ffffff]
    ...

    This happened because there was no ordering between two resources with the
    same start and end. A resource that had the same start and end as the
    cursor, but was not itself the cursor, was considered to be before the
    cursor.

    This patch fixes the hang by making a fixed ordering between any two
    resources.

    In addition, it tries to allocate from positively decoded regions before
    using any subtractively decoded resources. This means we will use a
    positive decode region before a subtractive decode one, even if it means
    using a smaller address.

    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=22062
    Reported-by: Borislav Petkov
    Tested-by: Borislav Petkov
    Acked-by: Linus Torvalds
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

29 Oct, 2010

1 commit

  • and branch 'for-linus' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm

    * 'for-linus' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm:
    xen: register xen pci notifier
    xen: initialize cpu masks for pv guests in xen_smp_init
    xen: add a missing #include to arch/x86/pci/xen.c
    xen: mask the MTRR feature from the cpuid
    xen: make hvc_xen console work for dom0.
    xen: add the direct mapping area for ISA bus access
    xen: Initialize xenbus for dom0.
    xen: use vcpu_ops to setup cpu masks
    xen: map a dummy page for local apic and ioapic in xen_set_fixmap
    xen: remap MSIs into pirqs when running as initial domain
    xen: remap GSIs as pirqs when running as initial domain
    xen: introduce XEN_DOM0 as a silent option
    xen: map MSIs into pirqs
    xen: support GSI -> pirq remapping in PV on HVM guests
    xen: add xen hvm acpi_register_gsi variant
    acpi: use indirect call to register gsi in different modes
    xen: implement xen_hvm_register_pirq
    xen: get the maximum number of pirqs from xen
    xen: support pirq != irq

    * 'stable/xen-pcifront-0.8.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: (27 commits)
    X86/PCI: Remove the dependency on isapnp_disable.
    xen: Update Makefile with CONFIG_BLOCK dependency for biomerge.c
    MAINTAINERS: Add myself to the Xen Hypervisor Interface and remove Chris Wright.
    x86: xen: Sanitse irq handling (part two)
    swiotlb-xen: On x86-32 builts, select SWIOTLB instead of depending on it.
    MAINTAINERS: Add myself for Xen PCI and Xen SWIOTLB maintainer.
    xen/pci: Request ACS when Xen-SWIOTLB is activated.
    xen-pcifront: Xen PCI frontend driver.
    xenbus: prevent warnings on unhandled enumeration values
    xenbus: Xen paravirtualised PCI hotplug support.
    xen/x86/PCI: Add support for the Xen PCI subsystem
    x86: Introduce x86_msi_ops
    msi: Introduce default_[teardown|setup]_msi_irqs with fallback.
    x86/PCI: Export pci_walk_bus function.
    x86/PCI: make sure _PAGE_IOMAP it set on pci mappings
    x86/PCI: Clean up pci_cache_line_size
    xen: fix shared irq device passthrough
    xen: Provide a variant of xen_poll_irq with timeout.
    xen: Find an unbound irq number in reverse order (high to low).
    xen: statically initialize cpu_evtchn_mask_p
    ...

    Fix up trivial conflicts in drivers/pci/Makefile

    Linus Torvalds
     

27 Oct, 2010

1 commit

  • Allocate space from the highest-address PCI bus resource first, then work
    downward.

    Previously, we looked for space in PCI host bridge windows in the order
    we discovered the windows. For example, given the following windows
    (discovered via an ACPI _CRS method):

    pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
    pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
    pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]
    pci_root PNP0A03:00: host bridge window [mem 0xbff00000-0xf7ffffff]
    pci_root PNP0A03:00: host bridge window [mem 0xff980000-0xff980fff]
    pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]
    pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xfed9ffff]

    we attempted to allocate from [mem 0x000a0000-0x000bffff] first, then
    [mem 0x000c0000-0x000effff], and so on.

    With this patch, we allocate from [mem 0xff980000-0xff980fff] first, then
    [mem 0xff97c000-0xff97ffff], [mem 0xfed20000-0xfed9ffff], etc.

    Allocating top-down follows Windows practice, so we're less likely to
    trip over BIOS defects in the _CRS description.

    On the machine above (a Dell T3500), the [mem 0xbff00000-0xbfffffff] region
    doesn't actually work and is likely a BIOS defect. The symptom is that we
    move the AHCI controller to 0xbff00000, which leads to "Boot has failed,
    sleeping forever," a BUG in ahci_stop_engine(), or some other boot failure.

    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=16228#c43
    Reference: https://bugzilla.redhat.com/show_bug.cgi?id=620313
    Reference: https://bugzilla.redhat.com/show_bug.cgi?id=629933
    Reported-by: Brian Bloniarz
    Reported-and-tested-by: Stefan Becker
    Reported-by: Denys Vlasenko
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

18 Oct, 2010

1 commit

  • In preperation of modularizing Xen-pcifront the pci_walk_bus
    needs to be exported so that the xen-pcifront module can walk
    call the pci subsystem to walk the PCI devices and claim them.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Konrad Rzeszutek Wilk
    Acked-by: Jesse Barnes [http://marc.info/?l=linux-pci&m=126149958010298&w=2]

    Konrad Rzeszutek Wilk
     

31 Jul, 2010

2 commits


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

08 Mar, 2010

1 commit

  • In the future, we are going to be changing the lock type for struct
    device (once we get the lockdep infrastructure properly worked out) To
    make that changeover easier, and to possibly burry the lock in a
    different part of struct device, let's create some functions to lock and
    unlock a device so that no out-of-core code needs to be changed in the
    future.

    This patch creates the device_lock/unlock/trylock() functions, and
    converts all in-tree users to them.

    Cc: Thomas Gleixner
    Cc: Jean Delvare
    Cc: Dave Young
    Cc: Ming Lei
    Cc: Jiri Kosina
    Cc: Phil Carmody
    Cc: Arjan van de Ven
    Cc: Cornelia Huck
    Cc: Rafael J. Wysocki
    Cc: Pavel Machek
    Cc: Len Brown
    Cc: Magnus Damm
    Cc: Alan Stern
    Cc: Randy Dunlap
    Cc: Stefan Richter
    Cc: David Brownell
    Cc: Vegard Nossum
    Cc: Jesse Barnes
    Cc: Alex Chiang
    Cc: Kenji Kaneshige
    Cc: Andrew Morton
    Cc: Andrew Patterson
    Cc: Yu Zhao
    Cc: Dominik Brodowski
    Cc: Samuel Ortiz
    Cc: Wolfram Sang
    Cc: CHENG Renquan
    Cc: Oliver Neukum
    Cc: Frans Pop
    Cc: David Vrabel
    Cc: Kay Sievers
    Cc: Sarah Sharp
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

24 Feb, 2010

2 commits

  • Previously we used a table of size PCI_BUS_NUM_RESOURCES (16) for resources
    forwarded to a bus by its upstream bridge. We've increased this size
    several times when the table overflowed.

    But there's no good limit on the number of resources because host bridges
    and subtractive decode bridges can forward any number of ranges to their
    secondary buses.

    This patch reduces the table to only PCI_BRIDGE_RESOURCE_NUM (4) entries,
    which corresponds to the number of windows a PCI-to-PCI (3) or CardBus (4)
    bridge can positively decode. Any additional resources, e.g., PCI host
    bridge windows or subtractively-decoded regions, are kept in a list.

    I'd prefer a single list rather than this split table/list approach, but
    that requires simultaneous changes to every architecture. This approach
    only requires immediate changes where we set up (a) host bridges with more
    than four windows and (b) subtractive-decode P2P bridges, and we can
    incrementally change other architectures to use the list.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • No functional change; this converts loops that iterate from 0 to
    PCI_BUS_NUM_RESOURCES through pci_bus resource[] table to use the
    pci_bus_for_each_resource() iterator instead.

    This doesn't change the way resources are stored; it merely removes
    dependencies on the fact that they're in a table.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

23 Feb, 2010

2 commits


17 Jun, 2009

1 commit

  • Based on PCI Express AER specs, a root port might receive multiple
    TLP errors while it could only save a correctable error source id
    and an uncorrectable error source id at the same time. In addition,
    some root port hardware might be unable to provide a correct source
    id, i.e., the source id, or the bus id part of the source id provided
    by root port might be equal to 0.

    The patchset implements the support in kernel by searching the device
    tree under the root port.

    Patch 1 changes parameter cb of function pci_walk_bus to return a value.
    When cb return non-zero, pci_walk_bus stops more searching on the
    device tree.

    Reviewed-by: Andrew Patterson
    Signed-off-by: Zhang Yanmin
    Signed-off-by: Jesse Barnes

    Zhang, Yanmin
     

12 Jun, 2009

1 commit

  • We should not assign 64bit ranges to PCI devices that only take 32bit
    prefetchable addresses.

    Try to set IORESOURCE_MEM_64 in 64bit resource of pci_device/pci_bridge
    and make the bus resource only have that bit set when all devices under
    it support 64bit prefetchable memory. Use that flag to allocate
    resources from that range.

    Reported-by: Yannick
    Reviewed-by: Ivan Kokshaysky
    Signed-off-by: Yinghai Lu
    Signed-off-by: Jesse Barnes

    Yinghai Lu
     

07 Apr, 2009

1 commit

  • This patch sets up disabled bridges even if buses have already been
    added.

    pci_assign_unassigned_resources is called after buses are added.
    pci_assign_unassigned_resources calls pci_bus_assign_resources.
    pci_bus_assign_resources calls pci_setup_bridge to configure BARs of
    bridges.

    Currently pci_setup_bridge returns immediately if the bus have already
    been added. So pci_assign_unassigned_resources can't configure BARs of
    bridges that were added in a disabled state; this patch fixes the issue.

    On logical hot-add, we need to prevent the kernel from re-initializing
    bridges that have already been initialized. To achieve this,
    pci_setup_bridge returns immediately if the bridge have already been
    enabled.

    We don't need to check whether the specified bus is a root bus or not.
    pci_setup_bridge is not called on a root bus, because a root bus does
    not have a bridge.

    The patch adds a new helper function, pci_is_enabled. I made the
    function name similar to pci_is_managed. The codes which use
    enable_cnt directly are changed to use pci_is_enabled.

    Acked-by: Alex Chiang
    Signed-off-by: Yuji Shimada
    Signed-off-by: Jesse Barnes

    Yuji Shimada
     

21 Mar, 2009

1 commit


20 Mar, 2009

1 commit


08 Jan, 2009

3 commits


21 Oct, 2008

1 commit

  • Stephen Hemminger wrote:
    > Looks like Mike created cpulistaffinty in sysfs but never completed
    > the job.

    This patch hooks things up correctly, taking care to remove the new file
    when the bus is destroyed.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: Mike Travis
    Signed-off-by: Jesse Barnes

    Mike Travis
     

21 Apr, 2008

2 commits


14 Mar, 2008

1 commit

  • PCI busses can be registered multiple times, so we need to detect if we
    have registered our bus structure in sysfs already. If so, don't do it
    again.

    Thanks to Guennadi Liakhovetski for reporting
    the problem, and to Linus for poking me to get me to believe that it was
    a real problem.

    Cc: Linus Torvalds
    Cc: Guennadi Liakhovetski
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

05 Mar, 2008

1 commit


02 Feb, 2008

2 commits

  • This moves the pci_bus class device to be a real struct device and at
    the same time, place it in the device tree in the correct location.

    Note, the old "bridge" symlink is now gone, but this was a non-standard
    link and no userspace program used it. If you need to determine the
    device that the bus is on, follow the standard device symlink, or walk
    up the device tree.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • This patch removes the following unused exports:
    - remove the following unused EXPORT_SYMBOL's:
    - pci-acpi.c: pci_osc_support_set
    - proc.c: pci_proc_detach_bus
    - remove the following unused EXPORT_SYMBOL_GPL's:
    - bus.c: pci_walk_bus
    - probe.c: pci_create_bus
    - setup-res.c: pci_claim_resource

    Signed-off-by: Adrian Bunk
    Signed-off-by: Greg Kroah-Hartman

    Adrian Bunk
     

03 May, 2007

1 commit

  • Functions marked __devinit will be removed after kernel init. But being
    exported they are potentially called by a module much later.

    So the safer choice seems to be to keep the function even in the non
    CONFIG_HOTPLUG case.

    This silence the follwoing section mismatch warnings:
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_device from __ksymtab_gpl between '__ksymtab_pci_bus_add_device' (at offset 0x20) and '__ksymtab_pci_walk_bus'
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_create_bus from __ksymtab_gpl between '__ksymtab_pci_create_bus' (at offset 0x40) and '__ksymtab_pci_stop_bus_device'
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_max_busnr from __ksymtab_gpl between '__ksymtab_pci_bus_max_busnr' (at offset 0xc0) and '__ksymtab_pci_assign_resource_fixed'
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_claim_resource from __ksymtab_gpl between '__ksymtab_pci_claim_resource' (at offset 0xe0) and '__ksymtab_pcie_port_bus_type'
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_devices from __ksymtab between '__ksymtab_pci_bus_add_devices' (at offset 0x70) and '__ksymtab_pci_bus_alloc_resource'
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_scan_bus_parented from __ksymtab between '__ksymtab_pci_scan_bus_parented' (at offset 0x90) and '__ksymtab_pci_root_buses'
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_assign_resources from __ksymtab between '__ksymtab_pci_bus_assign_resources' (at offset 0x4d0) and '__ksymtab_pci_bus_size_bridges'
    WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_size_bridges from __ksymtab between '__ksymtab_pci_bus_size_bridges' (at offset 0x4e0) and '__ksymtab_pci_setup_cardbus'

    Signed-off-by: Sam Ravnborg
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Sam Ravnborg
     

27 Sep, 2006

1 commit


28 Jun, 2006

1 commit


22 Jun, 2006

1 commit

  • pci_walk_bus has a race with pci_destroy_dev. When cb is called
    in pci_walk_bus, pci_destroy_dev might unlink the dev pointed by next.
    Later on in the next loop, pointer next becomes NULL and cause
    kernel panic.

    Below patch against 2.6.17-rc4 fixes it by changing pci_bus_lock (spin_lock)
    to pci_bus_sem (rw_semaphore).

    Signed-off-by: Zhang Yanmin
    Signed-off-by: Greg Kroah-Hartman

    Zhang Yanmin
     

09 Sep, 2005

2 commits

  • The PCI error recovery infrastructure needs to be able to contact all
    the drivers affected by a PCI error event, which may mean traversing
    all the devices under a given PCI-PCI bridge. This patch adds a
    function to the PCI core that traverses all the PCI devices on a PCI
    bus and under any PCI-PCI bridges on that bus (and so on), calling a
    given function for each device. This provides a way for the error
    recovery code to iterate through all devices that are affected by an
    error event.

    This version is not implemented as a recursive function. Instead,
    when we reach a PCI-PCI bridge, we set the pointers to start doing the
    devices on the bus under the bridge, and when we reach the end of a
    bus's devices, we use the bus->self pointer to go back up to the next
    higher bus and continue doing its devices.

    Signed-off-by: Paul Mackerras
    Signed-off-by: Greg Kroah-Hartman

    Paul Mackerras
     
  • Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

03 Aug, 2005

1 commit

  • The reason we have PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO is because
    we want to protect badly documented motherboard PCI resources and thus
    don't want to allocate new resources in low IO/MEM space.

    However, if we have already discovered a PCI bridge with a specified
    resource base, that should override that decision.

    This change will allow us to move the "careful" region upwards without
    resulting in problems allocating resources in low mappings. This was
    brought on by us having allocated a bus resource at 0x1000, conflicting
    with a undocumented VAIO Sony PI resources.

    Linus Torvalds
     

28 Jun, 2005

1 commit

  • When a pci child bus is created, add it to the parent's children list
    immediately rather than waiting till pci_bus_add_devices(). For hot-plug
    bridges/devices, pci_bus_add_devices() may be called much later, after they
    have been properly configured. In the meantime, this allows us to use the
    normal pci bus search functions for the hot-plug bridges/buses.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds