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
[email protected] (2):
PCI: ibmphp: list_for_each to list_for_each_entry
PCI: ibmphp: list_for_each to list_for_each_entry-checkpatch cleanups
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
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."
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