Skip to content

L
linux
Switch branch/tag
  1. 11 Nov, 2010 4 commits
    • Jesse Barnes's avatar
      PCI: read current power state at enable time · 97c145f7
      Jesse Barnes authored 
      When we enable a PCI device, we avoid doing a lot of the initial setup
work if the device's enable count is non-zero.  If we don't fetch the
power state though, we may later fail to set up MSI due to the unknown
status.  So pick it up before we short circuit the rest due to a
pre-existing enable or mismatched enable/disable pair (as happens with
VGA devices, which are special in a special way).
Tested-by: default avatarJesse Brandeburg <jesse.brandeburg@gmail.com>
Reported-by: default avatarDave Airlie <airlied@linux.ie>
Tested-by: default avatarDave Airlie <airlied@linux.ie>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      97c145f7
    • Martin Wilck's avatar
      PCI: fix size checks for mmap() on /proc/bus/pci files · 3b519e4e
      Martin Wilck authored 
      The checks for valid mmaps of PCI resources made through /proc/bus/pci files
that were introduced in 9eff02e2 have several
problems:

1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0,
whereas under /sys/bus/pci/devices, the start of the resource corresponds
to offset 0. This may lead to false negatives in pci_mmap_fits(), which
implicitly assumes the /sys/bus/pci/devices layout.

2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads
to false positives, because pci_mmap_fits() doesn't treat empty resources
correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT)
in this case!).

3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus
WARNINGS for the first resources that don't fit until the correct one is found.

On many controllers the first 2-4 BARs are used, and the others are empty.
In this case, an mmap attempt will first fail on the non-empty BARs
(including the "right" BAR because of 1.) and emit bogus WARNINGS because
of 3., and finally succeed on the first empty BAR because of 2.
This is certainly not the intended behaviour.

This patch addresses all 3 issues.
Updated with an enum type for the additional parameter for pci_mmap_fits().

Cc: stable@kernel.org
Signed-off-by: default avatarMartin Wilck <martin.wilck@ts.fujitsu.com>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      3b519e4e
    • Bjorn Helgaas's avatar
      x86/PCI: coalesce overlapping host bridge windows · 4723d0f2
      Bjorn Helgaas authored 
      Some BIOSes provide PCI host bridge windows that overlap, e.g.,

    pci_root PNP0A03:00: host bridge window [mem 0xb0000000-0xffffffff]
    pci_root PNP0A03:00: host bridge window [mem 0xafffffff-0xdfffffff]
    pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xffffffff]

If we simply insert these as children of iomem_resource, the second window
fails because it conflicts with the first, and the third is inserted as a
child of the first, i.e.,

    b0000000-ffffffff PCI Bus 0000:00
      f0000000-ffffffff PCI Bus 0000:00

When we claim PCI device resources, this can cause collisions like this
if we put them in the first window:

    pci 0000:00:01.0: address space collision: [mem 0xff300000-0xff4fffff] conflicts with PCI Bus 0000:00 [mem 0xf0000000-0xffffffff]

Host bridge windows are top-level resources by definition, so it doesn't
make sense to make the third window a child of the first.  This patch
coalesces any host bridge windows that overlap.  For the example above,
the result is this single window:

    pci_root PNP0A03:00: host bridge window [mem 0xafffffff-0xffffffff]

This fixes a 2.6.34 regression.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=17011Reported-and-tested-by: default avatarAnisse Astier <anisse@astier.eu>
Reported-and-tested-by: default avatarPramod Dematagoda <pmd.lotr.gandalf@gmail.com>
Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      4723d0f2
    • Steven Rostedt's avatar
      PCI hotplug: ibmphp: Add check to prevent reading beyond mapped area · ac3abf2c
      Steven Rostedt authored 
      While testing various randconfigs with ktest.pl, I hit the following panic:

BUG: unable to handle kernel paging request at f7e54b03
IP: [<c0d63409>] ibmphp_access_ebda+0x101/0x19bb

Adding printks, I found that the loop that reads the ebda blocks
can move out of the mapped section.

ibmphp_access_ebda: start=f7e44c00 size=5120 end=f7e46000
ibmphp_access_ebda: io_mem=f7e44d80 offset=384
ibmphp_access_ebda: io_mem=f7e54b03 offset=65283

The start of the iomap was at f7e44c00 and had a size of 5120,
making the end f7e46000. We start with an offset of 0x180 or
384, giving the first read at 0xf7e44d80. Reading that location
yields 65283, which is much bigger than the 5120 that was allocated
and makes the next read at f7e54b03 which is outside the mapped area.

Perhaps this is a bug in the driver, or buggy hardware, but this patch
is more about not crashing my box on start up and just giving a warning
if it detects this error.

This patch at least lets my box boot with just a warning.

Cc: Chandru Siddalingappa <chandru@linux.vnet.ibm.com>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      ac3abf2c
  3. 09 Nov, 2010 5 commits
  5. 08 Nov, 2010 17 commits
  7. 06 Nov, 2010 7 commits
  9. 05 Nov, 2010 7 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7