What's in pci-2.6.git - Kernel

This is a discussion on What's in pci-2.6.git - Kernel ; Quite a few patches have queued up in my linux-next branch for 2.6.28, and a couple of more are still pending (they've seen lots of review so should be just about ready), specifically the I/O virtualization code and more PCI ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: What's in pci-2.6.git

  1. What's in pci-2.6.git

    Quite a few patches have queued up in my linux-next branch for 2.6.28, and a
    couple of more are still pending (they've seen lots of review so should be
    just about ready), specifically the I/O virtualization code and more PCI slot
    driver fixes from Alex and Kenji-san.

    Full shortlog below, there's stuff all over the map...

    Jesse

    Alex Chiang (1):
    PCI: connect struct pci_dev to struct pci_slot

    Andi Kleen (1):
    PCI: Document that most pci options are shared between i386 and x86-64

    Arjan van de Ven (1):
    PCI: introduce an pci_ioremap(pdev, barnr) function

    Bjorn Helgaas (3):
    x86/PCI: follow lspci device/vendor style
    PCI: follow lspci device/vendor style
    PCI: tidy PME support messages

    Chuck Ebbert (1):
    PCI: document the pcie_aspm kernel parameter

    Greg Kroah-Hartman (1):
    PCI: fix compiler warnings in pci_get_subsys()

    Jean Delvare (1):
    PCI: Check dynids driver_data value for validity

    Jeff Garzik (1):
    PCI: documentation fix for pci_dma_mapping_error

    Jesse Barnes (5):
    PCI: fix -Wakpm warnings in pci_pm_init debug output
    PCI: remove #ifdef DEBUG around dev_dbg call
    PCI: pcie whitespace cleanup
    PCI: fix PCI sysfs rom file size for shadowed ROMs
    PCI: use pci_find_ext_capability everywhere

    Jike Song (1):
    PCI: utilize calculated results when detecting MSI features

    Kenji Kaneshige (2):
    PCI: pciehp: fix irq initialization
    PCI: fix get_##name merge error

    Mike Travis (1):
    PCI: make CPU list affinity visible

    Milton Miller (1):
    PCI: remove dynids.use_driver_data

    Rafael J. Wysocki (1):
    PCI PM: Introduce function pci_wake_from_d3

    Roland Dreier (1):
    PCI: fix MSI-HOWTO.txt info about MSI-X MMIO space

    Seth Heasley (1):
    x86/PCI: irq and pci_ids patch for Intel Ibex Peak DeviceIDs

    Stephen Hemminger (1):
    PCI: fix sparse warning in pci_remove_behind_bridge

    Stephen Rothwell (1):
    PCI: hotplug/rpaphp: remove unused error path code

    Taku Izumi (2):
    PCI: pciehp: change name tag of "hpdriver_portdrv" variable
    PCI: pciehp: replace printk with dev_printk

    Thomas Petazzoni (1):
    PCI: allow quirks to be compiled out

    Yinghai Lu (2):
    PCI: change MSI-x vector to 32bit
    PCI: use %pF instead of print_fn_descriptor_symbol() in quirks.c

    Zhang, Yanmin (1):
    PCI: merge define of PCI_CFG_SPACE_SIZE

    Zhao, Yu (1):
    PCI: fix hotplug get_##name return value problem

    akpm@linux-foundation.org (2):
    PCI: ibmphp: list_for_each to list_for_each_entry
    PCI: ibmphp: list_for_each to list_for_each_entry-checkpatch cleanups
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: What's in pci-2.6.git


    On Oct 8, 2008, at 3:21 PM, Jesse Barnes wrote:

    > Quite a few patches have queued up in my linux-next branch for
    > 2.6.28, and a
    > couple of more are still pending (they've seen lots of review so
    > should be
    > just about ready), specifically the I/O virtualization code and more
    > PCI slot
    > driver fixes from Alex and Kenji-san.
    >
    > Full shortlog below, there's stuff all over the map...
    >
    > Jesse
    >
    > Alex Chiang (1):
    > PCI: connect struct pci_dev to struct pci_slot
    >
    > Andi Kleen (1):
    > PCI: Document that most pci options are shared between i386 and
    > x86-64
    >
    > Arjan van de Ven (1):
    > PCI: introduce an pci_ioremap(pdev, barnr) function


    Does it make sense to rename iounmap to pci_iounmap, just to be
    consistent with pci_ioremap_bar?

    -Anirban
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: What's in pci-2.6.git


    On Oct 20, 2008, at 10:51 PM, Matthew Wilcox wrote:

    > On Mon, Oct 20, 2008 at 10:18:38PM -0700, Anirban Chakraborty wrote:
    >>> Arjan van de Ven (1):
    >>> PCI: introduce an pci_ioremap(pdev, barnr) function

    >>
    >> Does it make sense to rename iounmap to pci_iounmap, just to be
    >> consistent with pci_ioremap_bar?

    >
    > iounmap can be used for ioremaps that aren't necessarily from PCI
    > devices.
    > Since there's no length parameter to iounmap, there's nothing to get
    > wrong, so there's no natural counterpart to pci_ioremap().


    Yeah, that makes sense.
    Thanks,
    -Anirban
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: What's in pci-2.6.git

    On Mon, Oct 20, 2008 at 10:18:38PM -0700, Anirban Chakraborty wrote:
    > >Arjan van de Ven (1):
    > > PCI: introduce an pci_ioremap(pdev, barnr) function

    >
    > Does it make sense to rename iounmap to pci_iounmap, just to be
    > consistent with pci_ioremap_bar?


    iounmap can be used for ioremaps that aren't necessarily from PCI devices.
    Since there's no length parameter to iounmap, there's nothing to get
    wrong, so there's no natural counterpart to pci_ioremap().

    --
    Matthew Wilcox Intel Open Source Technology Centre
    "Bill, look, we understand that you're interested in selling us this
    operating system, but compare it to ours. We can't possibly take such
    a retrograde step."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread