Please consider pulling my PCI tree from
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 linux-next
There are some real changes in here, notably Alex's changes to the core to add
real hotplug support, Matthew's multiple MSI support, and Yu's SR-IOV support.
Overall, v12n users should be happy with this set of changes. And as is
customary we got a good collection of fixes from the usual suspects: Kenji-san,
Yinghai, and Bjorn. Oh and Alpha has support for sysfs PCI resources now,
thanks to a commit from Ivan.
I note you've been having some tree management discussions with people this
time around, so I figured it would be good to describe how I've been handling
things.
I generally have two branches going: for-linus and linux-next. The for-linus
branch rarely gets merge commits or rebases. Merges will generally only
happen if I have some dependencies with another tree (like ACPI), and rebases
only occur when I need to drop a patch. Other than that it's just fast
forwards from pulling your tree (after you've pulled mine) and commits for
new patches.
I try to keep the linux-next branch a superset of my for-linus branch at the
request of my downstream developers. This means periodic rebasing after the
merge window closes, but it's generally important to get your latest stuff
into that branch so that downstream developers don't have to fight with bugs
that have been fixed upstream. This isn't pain free (downstream developers
with large patchsets then have to rebase their stuff) but so far it seems
like the path of least pain for our purposes, probably because I haven't
started pulling trees from downstream (yet). If I did, I of course would
avoid rebasing at that point...
Anyway hope this pull is ok. I went through every warning by hand to make
sure none were caused by PCI commits, but that was with the bits in this
tree, which are -rc8 vintage.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
Alex Chiang (12):
PCI: enhance physical slot debug information
PCI: PCIe portdrv: eliminate double kfree in remove path
PCIe: portdrv: call pci_disable_device during remove
PCI: always scan child buses
PCI: do not initialize bridges more than once
PCI: do not enable bridges more than once
PCI: Introduce pci_rescan_bus()
PCI: Introduce /sys/bus/pci/rescan
PCI: Introduce /sys/bus/pci/devices/.../remove
PCI: Introduce /sys/bus/pci/devices/.../rescan
PCI Hotplug: rename legacy_fakephp to fakephp
PCI Hotplug: schedule fakephp for feature removal
Andrew Morton (1):
PCI: constify pci_bus_assign_resources()
Bjorn Helgaas (4):
PCI/x86: make early dump handle multi-function devices
PCI/x86: format early dump like other PCI output
PCI/x86: document pci=earlydump argument
x86: use dev_printk in quirk message
Chris Wright (1):
PCI: add remove_id sysfs entry
Dave Airlie (1):
PCI: expose boot VGA device via sysfs.
David O'Shea (1):
PCI: Compaq Evo D510 SMBus quirk using USB instead of VGA
Ed Swierk (1):
x86/PCI: Detect mmconfig on nVidia MCP55
Eric W. Biederman (1):
PCI: pcie_portdriver: fix pcie_port_device_remove
Frank Seidel (1):
PCI: add missing KERN_* constants to printks
Geert Uytterhoeven (1):
PCI: Use kzalloc() in pci_create_bus()
Harvey Harrison (1):
PCI: __FUNCTION__ is gcc-specific, use __func__
Ivan Kokshaysky (1):
PCI/alpha: pci sysfs resources
Jesse Barnes (1):
powerpc/PCI: include pci.h in powerpc MSI implementation
Jiri Slaby (1):
PCI quirk: don't mark one netmos as class other
Julia Lawall (1):
PCI: introduce missing kfree
Kay Sievers (1):
PCI: struct device - replace bus_id with dev_name(), dev_set_name()
Kenji Kaneshige (15):
PCI: pciehp: fix possible endless loop in pcie_isr
PCI: pciehp: enable software notification on empty slots
PCI: pciehp: make cmd_busy flag one bit
PCI/ACPI: move _OSC code to pci_root.c
PCI/ACPI: rename pci_osc_control_set()
PCI/ACPI: fix wrong assumption in acpi_pci_get_bridge_handle
PCI/ACPI: fix wrong assumption in acpi_find_root_bridge_handle
PCI hotplug: fix wrong assumption in acpi_get_hp_params_from_firmware
PCI hotplug: fix wrong assumption in acpi_get_hp_hw_control_from_firmware
PCI: fix wrong assumption in pci_find_upstream_pcie_bridge
PCI: fix wrong assumption in pci_read_bridge_bases
PCI: fix wrong assumption in pci_get_interrupt_pin
PCI: fix wrong assumption in pci_common_swizzle
PCI: pci_is_root_bus helper
PCI: fix kernel oops on bridge removal
Matthew Wilcox (6):
Rewrite MSI-HOWTO
PCI MSI: Replace 'type' with 'is_msix'
PCI MSI: msi_desc->dev is always initialised
PCI MSI: Use mask_pos instead of mask_base when appropriate
PCI MSI: Refactor interrupt masking code
PCI MSI: Add support for multiple MSI
Michael Ellerman (3):
PCI/MSI: Use #ifdefs instead of weak functions
PCI/MSI: Allow arch code to return the number of MSI-X available
PCI MSI: Add example request loop to MSI-HOWTO.txt
Rafael J. Wysocki (9):
PCI: PCIe portdrv: Use driver data to simplify code
PCI: PCIe portdrv: Aviod using service devices with wrong interrupts
PCI: PCIe portdrv: Do not enable port device before setting up interrupts
PCI: PCIe portdrv: Remove unnecessary function
PCI: PCIe portdrv: Simplily probe callback of service drivers
PCI: PCIe portdrv: Remove struct pcie_port_service_id
PCI/MSI: Introduce pci_msix_table_size()
PCI/PCIe portdrv: Fix allocation of interrupts
PCI: PCIe portdrv: Implement pm object
Roel Kluin (1):
PCI hotplug: shpchp: fix bus number check to avoid false positive
Sheng Yang (1):
PCI: Speed up device reset function
Stephen Rothwell (1):
PCI: update fakephp for bus_id removal
Trent Piepho (3):
PCI: don't scan existing devices
PCI: pci_scan_slot() returns newly found devices
PCI Hotplug: restore fakephp interface with complete reimplementation
Yinghai Lu (5):
PCI/x86: detect host bridge config space size w/o using quirks
x86/PCI: host mmconfig detect clean up
x86/PCI: make pci=lastbus=255 work when acpi is on
PCI: don't enable too much HT MSI mapping
PCI: fix HT MSI mapping fix
Yu Zhao (12):
PCI: check if a bus is added when removing it
PCI: fix incorrect mask of PM No_Soft_Reset bit
PCI: initialize and release SR-IOV capability
PCI: restore saved SR-IOV state
PCI: reserve bus range for SR-IOV device
PCI: centralize device setup code
PCI: add SR-IOV API for Physical Function driver
PCI: handle SR-IOV Virtual Function Migration
PCI: document SR-IOV sysfs entries
PCI: manual for SR-IOV user and driver developer
PCI: fix conflict between SR-IOV and config space sizing
PCI: save and restore PCIe 2.0 registers
Yuji Shimada (1):
PCI: allow assignment of memory resources with a specified alignment
[email protected] (1):
PCI: constify pci_bus_add_devices()
Documentation/ABI/testing/sysfs-bus-pci | 70 +++
Documentation/DocBook/kernel-api.tmpl | 1 +
Documentation/PCI/MSI-HOWTO.txt | 814 +++++++++++----------------
Documentation/PCI/pci-iov-howto.txt | 99 ++++
Documentation/feature-removal-schedule.txt | 33 ++
Documentation/filesystems/sysfs-pci.txt | 10 +
Documentation/kernel-parameters.txt | 11 +
arch/alpha/include/asm/pci.h | 14 +
arch/alpha/kernel/Makefile | 2 +-
arch/alpha/kernel/pci-sysfs.c | 366 +++++++++++++
arch/powerpc/include/asm/pci.h | 4 +
arch/powerpc/kernel/msi.c | 5 +
arch/x86/include/asm/pci.h | 3 +
arch/x86/kernel/io_apic.c | 4 +
arch/x86/kernel/pci-dma.c | 3 +-
arch/x86/pci/early.c | 19 +-
arch/x86/pci/fixup.c | 20 -
arch/x86/pci/legacy.c | 3 +-
arch/x86/pci/mmconfig-shared.c | 227 ++++++--
arch/x86/pci/mmconfig_64.c | 17 +-
drivers/acpi/pci_root.c | 180 ++++++-
drivers/pci/Kconfig | 10 +
drivers/pci/Makefile | 2 +
drivers/pci/bus.c | 8 +-
drivers/pci/hotplug/acpi_pcihp.c | 58 +--
drivers/pci/hotplug/cpqphp_sysfs.c | 3 +-
drivers/pci/hotplug/fakephp.c | 444 ++++------------
drivers/pci/hotplug/pciehp.h | 13 +-
drivers/pci/hotplug/pciehp_acpi.c | 21 +-
drivers/pci/hotplug/pciehp_core.c | 18 +-
drivers/pci/hotplug/pciehp_hpc.c | 34 +-
drivers/pci/hotplug/shpchp.h | 10 +-
drivers/pci/hotplug/shpchp_pci.c | 2 +-
drivers/pci/intel-iommu.c | 2 +-
drivers/pci/iov.c | 680 +++++++++++++++++++++++
drivers/pci/msi.c | 426 ++++++++--------
drivers/pci/msi.h | 6 -
drivers/pci/pci-acpi.c | 215 --------
drivers/pci/pci-driver.c | 81 +++-
drivers/pci/pci-sysfs.c | 124 ++++-
drivers/pci/pci.c | 193 ++++++-
drivers/pci/pci.h | 65 +++
drivers/pci/pcie/aer/aerdrv.c | 28 +-
drivers/pci/pcie/aer/aerdrv_acpi.c | 2 +-
drivers/pci/pcie/aer/aerdrv_core.c | 10 +-
drivers/pci/pcie/portdrv.h | 14 +-
drivers/pci/pcie/portdrv_bus.c | 18 +-
drivers/pci/pcie/portdrv_core.c | 379 +++++++++-----
drivers/pci/pcie/portdrv_pci.c | 50 +-
drivers/pci/probe.c | 210 +++++---
drivers/pci/quirks.c | 221 +++++++--
drivers/pci/remove.c | 4 +
drivers/pci/search.c | 2 +-
drivers/pci/setup-bus.c | 7 +-
drivers/pci/setup-res.c | 15 +
drivers/pci/slot.c | 18 +-
include/linux/acpi.h | 34 ++
include/linux/msi.h | 13 +-
include/linux/pci-acpi.h | 67 +--
include/linux/pci.h | 61 ++-
include/linux/pci_ids.h | 1 +
include/linux/pci_regs.h | 37 ++-
include/linux/pcieport_if.h | 36 +-
63 files changed, 3644 insertions(+), 1903 deletions(-)
create mode 100644 Documentation/PCI/pci-iov-howto.txt
create mode 100644 arch/alpha/kernel/pci-sysfs.c
create mode 100644 drivers/pci/iov.c
On Tue, 31 Mar 2009, Jesse Barnes wrote:
>
> Please consider pulling my PCI tree from
> git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 linux-next
This produces
WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in reference from the function dev_rescan_store() to the function .devinit.text:pci_rescan_bus()
The function dev_rescan_store() references
the function __devinit pci_rescan_bus().
This is often because dev_rescan_store lacks a __devinit
annotation or the annotation of pci_rescan_bus is wrong.
Hmm?
> Anyway hope this pull is ok. I went through every warning by hand to make
> sure none were caused by PCI commits, but that was with the bits in this
> tree, which are -rc8 vintage.
You can tell it's rebased, but at least it's not rebased five minutes ago,
so I assume it has some testing. It's the "I just rebased a couple of
minutes before posting this 'please pull' message" that I find really
annoying, since it's so clear that the end result has no real testing at
all.
Linus
On Wed, 1 Apr 2009 10:01:12 -0700 (PDT)
Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 31 Mar 2009, Jesse Barnes wrote:
> >
> > Please consider pulling my PCI tree from
> > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
> > linux-next
>
> This produces
>
> WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in
> reference from the function dev_rescan_store() to the
> function .devinit.text:pci_rescan_bus() The function
> dev_rescan_store() references the function __devinit
> pci_rescan_bus(). This is often because dev_rescan_store lacks a
> __devinit annotation or the annotation of pci_rescan_bus is wrong.
>
> Hmm?
Arg how did I miss that? Maybe the last build I did was missing
hotplug support or something... Anyway looking now (at first glance I
think pci_rescan_bus needs to drop __devinit).
> > Anyway hope this pull is ok. I went through every warning by hand
> > to make sure none were caused by PCI commits, but that was with the
> > bits in this tree, which are -rc8 vintage.
>
> You can tell it's rebased, but at least it's not rebased five minutes
> ago, so I assume it has some testing. It's the "I just rebased a
> couple of minutes before posting this 'please pull' message" that I
> find really annoying, since it's so clear that the end result has no
> real testing at all.
Yeah, this tree generally sees a good amount of testing, especially
from the hotplug folks. And yeah, I'd never rebase and then do a pull
request; I like to let things sit in linux-next for at least a day to
flush out any build errors and give a chance for people to test any
merge conflicts I resolved.
--
Jesse Barnes, Intel Open Source Technology Center
* Jesse Barnes <[email protected]>:
> On Wed, 1 Apr 2009 10:01:12 -0700 (PDT)
> Linus Torvalds <[email protected]> wrote:
>
> >
> >
> > On Tue, 31 Mar 2009, Jesse Barnes wrote:
> > >
> > > Please consider pulling my PCI tree from
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
> > > linux-next
> >
> > This produces
> >
> > WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in
> > reference from the function dev_rescan_store() to the
> > function .devinit.text:pci_rescan_bus() The function
> > dev_rescan_store() references the function __devinit
> > pci_rescan_bus(). This is often because dev_rescan_store lacks a
> > __devinit annotation or the annotation of pci_rescan_bus is wrong.
> >
> > Hmm?
>
> Arg how did I miss that? Maybe the last build I did was missing
> hotplug support or something... Anyway looking now (at first glance I
> think pci_rescan_bus needs to drop __devinit).
This was my fault. pci_rescan_bus() definitely does not want
__devinit.
But I'm confused -- didn't we used to have an option in
menuconfig under Kernel Hacking that would turn on section
mismatch warnings? I used to have that turned on, and don't
remember turning it off, and I can't find it now.
I'm told that we're supposed to set it on the make command line,
like:
make CONFIG_DEBUG_SECTION_MISMATCH=y -j16
or something. Has this changed recently or am I just imagining
things (or just plain stupid?)
Thanks.
/ac
On Wed, Apr 01, 2009 at 12:37:49PM -0600, Alex Chiang wrote:
> * Jesse Barnes <[email protected]>:
> > On Wed, 1 Apr 2009 10:01:12 -0700 (PDT)
> > Linus Torvalds <[email protected]> wrote:
> >
> > >
> > >
> > > On Tue, 31 Mar 2009, Jesse Barnes wrote:
> > > >
> > > > Please consider pulling my PCI tree from
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
> > > > linux-next
> > >
> > > This produces
> > >
> > > WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in
> > > reference from the function dev_rescan_store() to the
> > > function .devinit.text:pci_rescan_bus() The function
> > > dev_rescan_store() references the function __devinit
> > > pci_rescan_bus(). This is often because dev_rescan_store lacks a
> > > __devinit annotation or the annotation of pci_rescan_bus is wrong.
> > >
> > > Hmm?
> >
> > Arg how did I miss that? Maybe the last build I did was missing
> > hotplug support or something... Anyway looking now (at first glance I
> > think pci_rescan_bus needs to drop __devinit).
>
> This was my fault. pci_rescan_bus() definitely does not want
> __devinit.
>
> But I'm confused -- didn't we used to have an option in
> menuconfig under Kernel Hacking that would turn on section
> mismatch warnings? I used to have that turned on, and don't
> remember turning it off, and I can't find it now.
>
> I'm told that we're supposed to set it on the make command line,
> like:
>
> make CONFIG_DEBUG_SECTION_MISMATCH=y -j16
>
> or something. Has this changed recently or am I just imagining
> things (or just plain stupid?)
That was maybe one year ago we had it in menuconfig.
When I get on top of things I will enable it and try to
help fixing the remaining warnings.
I have resisted enabling it for now as I cannot support the people
that see the warnings atm.
The patch to enable it is simple so if anyone want
to help fix the warnings then...
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9638d99..ee5e6f3 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -95,10 +95,6 @@ config HEADERS_CHECK
config DEBUG_SECTION_MISMATCH
bool "Enable full Section mismatch analysis"
- depends on UNDEFINED
- # This option is on purpose disabled for now.
- # It will be enabled when we are down to a resonable number
- # of section mismatch warnings (< 10 for an allyesconfig build)
help
The section mismatch analysis checks if there are illegal
references from one section to another section.
Sam
* Sam Ravnborg <[email protected]>:
> On Wed, Apr 01, 2009 at 12:37:49PM -0600, Alex Chiang wrote:
> > * Jesse Barnes <[email protected]>:
> > > On Wed, 1 Apr 2009 10:01:12 -0700 (PDT)
> > > Linus Torvalds <[email protected]> wrote:
> > > > On Tue, 31 Mar 2009, Jesse Barnes wrote:
> > > > >
> > > > > Please consider pulling my PCI tree from
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
> > > > > linux-next
> > > >
> > > > This produces
> > > >
> > > > WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in
> > > > reference from the function dev_rescan_store() to the
> > > > function .devinit.text:pci_rescan_bus() The function
> > > > dev_rescan_store() references the function __devinit
> > > > pci_rescan_bus(). This is often because dev_rescan_store lacks a
> > > > __devinit annotation or the annotation of pci_rescan_bus is wrong.
> > > >
> > > > Hmm?
> > >
> > > Arg how did I miss that? Maybe the last build I did was missing
> > > hotplug support or something... Anyway looking now (at first glance I
> > > think pci_rescan_bus needs to drop __devinit).
> >
> > This was my fault. pci_rescan_bus() definitely does not want
> > __devinit.
> >
> > But I'm confused -- didn't we used to have an option in
> > menuconfig under Kernel Hacking that would turn on section
> > mismatch warnings? I used to have that turned on, and don't
> > remember turning it off, and I can't find it now.
> >
> > I'm told that we're supposed to set it on the make command line,
> > like:
> >
> > make CONFIG_DEBUG_SECTION_MISMATCH=y -j16
> >
> > or something. Has this changed recently or am I just imagining
> > things (or just plain stupid?)
>
> That was maybe one year ago we had it in menuconfig.
> When I get on top of things I will enable it and try to
> help fixing the remaining warnings.
Ah, ok.
> I have resisted enabling it for now as I cannot support the people
> that see the warnings atm.
Nod, makes sense.
I took a look at the warning that Linus mentioned, and I'm not
entirely sure how to fix it. The problem is this:
http://git.kernel.org/?p=linux/kernel/git/jbarnes/pci-2.6.git;a=commit;h=3ed4fd96b3188406ac5357d9290bcffa08c65cf6
I initially annoted pci_rescan_bus as __devinit, which it
shouldn't have. Removing the annotation though, produces these
other warnings:
WARNING: vmlinux.o(.text+0x1b9be6): Section mismatch in reference from the function pci_rescan_bus() to the function .devinit.text:pci_scan_child_bus()
The function pci_rescan_bus() references
the function __devinit pci_scan_child_bus().
This is often because pci_rescan_bus lacks a __devinit
annotation or the annotation of pci_scan_child_bus is wrong.
Reading through Documentation/PCI/pci.txt says that under
CONFIG_HOTPLUG, __devinit should be a nop?
I do have this in my .config:
CONFIG_HOTPLUG=y
So I'm not sure what I'm doing wrong?
Thanks.
/ac
Hi Linus,
* Jesse Barnes <[email protected]>:
> On Wed, 1 Apr 2009 10:01:12 -0700 (PDT)
> Linus Torvalds <[email protected]> wrote:
> > On Tue, 31 Mar 2009, Jesse Barnes wrote:
> > >
> > > Please consider pulling my PCI tree from
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
> > > linux-next
> >
> > This produces
> >
> > WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in
> > reference from the function dev_rescan_store() to the
> > function .devinit.text:pci_rescan_bus() The function
> > dev_rescan_store() references the function __devinit
> > pci_rescan_bus(). This is often because dev_rescan_store lacks a
> > __devinit annotation or the annotation of pci_rescan_bus is wrong.
> >
> > Hmm?
>
> Arg how did I miss that? Maybe the last build I did was missing
> hotplug support or something... Anyway looking now (at first glance I
> think pci_rescan_bus needs to drop __devinit).
This patch eliminates the warning in what I think is the correct
manner.
Thanks.
/ac
From: Alex Chiang <[email protected]>
PCI: annotate pci_rescan_bus as __ref, not __devinit
pci_rescan_bus was annotated as __devinit, which is wrong,
because it will never be part of device initialization.
Howevever, we can't simply drop the annotation, because then we
get section warnings about calling pci_scan_child_bus (which is
correctly marked as __devinit).
pci_rescan_bus will only get built when CONFIG_HOTPLUG is set,
meaning that __devinit is a nop, so we know that pci_scan_child_bus
has not been freed.
Annotate as __ref to silence modpost.
Signed-off-by: Alex Chiang <[email protected]>
---
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e2f3dd0..8eb50df 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1220,7 +1220,7 @@ EXPORT_SYMBOL(pci_scan_bus_parented);
*
* Returns the max number of subordinate bus discovered.
*/
-unsigned int __devinit pci_rescan_bus(struct pci_bus *bus)
+unsigned int __ref pci_rescan_bus(struct pci_bus *bus)
{
unsigned int max;
struct pci_dev *dev;
On Wed, Apr 01, 2009 at 04:23:10PM -0600, Alex Chiang wrote:
> * Sam Ravnborg <[email protected]>:
> > On Wed, Apr 01, 2009 at 12:37:49PM -0600, Alex Chiang wrote:
> > > * Jesse Barnes <[email protected]>:
> > > > On Wed, 1 Apr 2009 10:01:12 -0700 (PDT)
> > > > Linus Torvalds <[email protected]> wrote:
> > > > > On Tue, 31 Mar 2009, Jesse Barnes wrote:
> > > > > >
> > > > > > Please consider pulling my PCI tree from
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
> > > > > > linux-next
> > > > >
> > > > > This produces
> > > > >
> > > > > WARNING: drivers/built-in.o(.text+0x69a1): Section mismatch in
> > > > > reference from the function dev_rescan_store() to the
> > > > > function .devinit.text:pci_rescan_bus() The function
> > > > > dev_rescan_store() references the function __devinit
> > > > > pci_rescan_bus(). This is often because dev_rescan_store lacks a
> > > > > __devinit annotation or the annotation of pci_rescan_bus is wrong.
> > > > >
> > > > > Hmm?
> > > >
> > > > Arg how did I miss that? Maybe the last build I did was missing
> > > > hotplug support or something... Anyway looking now (at first glance I
> > > > think pci_rescan_bus needs to drop __devinit).
> > >
> > > This was my fault. pci_rescan_bus() definitely does not want
> > > __devinit.
> > >
> > > But I'm confused -- didn't we used to have an option in
> > > menuconfig under Kernel Hacking that would turn on section
> > > mismatch warnings? I used to have that turned on, and don't
> > > remember turning it off, and I can't find it now.
> > >
> > > I'm told that we're supposed to set it on the make command line,
> > > like:
> > >
> > > make CONFIG_DEBUG_SECTION_MISMATCH=y -j16
> > >
> > > or something. Has this changed recently or am I just imagining
> > > things (or just plain stupid?)
> >
> > That was maybe one year ago we had it in menuconfig.
> > When I get on top of things I will enable it and try to
> > help fixing the remaining warnings.
>
> Ah, ok.
>
> > I have resisted enabling it for now as I cannot support the people
> > that see the warnings atm.
>
> Nod, makes sense.
>
> I took a look at the warning that Linus mentioned, and I'm not
> entirely sure how to fix it. The problem is this:
>
> http://git.kernel.org/?p=linux/kernel/git/jbarnes/pci-2.6.git;a=commit;h=3ed4fd96b3188406ac5357d9290bcffa08c65cf6
>
> I initially annoted pci_rescan_bus as __devinit, which it
> shouldn't have. Removing the annotation though, produces these
> other warnings:
>
> WARNING: vmlinux.o(.text+0x1b9be6): Section mismatch in reference from the function pci_rescan_bus() to the function .devinit.text:pci_scan_child_bus()
> The function pci_rescan_bus() references
> the function __devinit pci_scan_child_bus().
> This is often because pci_rescan_bus lacks a __devinit
> annotation or the annotation of pci_scan_child_bus is wrong.
>
> Reading through Documentation/PCI/pci.txt says that under
> CONFIG_HOTPLUG, __devinit should be a nop?
The documentation is not up-to-date in this respect.
Annotating a function __devinit will no matter the configuration
locate the code in a section named .devinit.text
We then postprocess this section for illegal references using modpost.
The PCI_HOTPLUG code has often been troublesome with respect to these checks
as this code is only relevant if CONFIG_HOTPLUG is enabled
and will often not even be included in the kernel if not enabled.
This is true for pci_rescan_bus() for example.
And we would like to export these symbols too. But we do not allow exported
symbols to be annotated __devinit as this code will be blown away in some configurations.
So the correct solution which you also used in your patch is to tell
modpost to ignore references to *init sections from this specific funtion
as they are OK.
Sam
* Sam Ravnborg <[email protected]>:
> >
> > Reading through Documentation/PCI/pci.txt says that under
> > CONFIG_HOTPLUG, __devinit should be a nop?
> The documentation is not up-to-date in this respect.
>
> Annotating a function __devinit will no matter the configuration
> locate the code in a section named .devinit.text
Ok, I'll update the documentation.
> We then postprocess this section for illegal references using modpost.
>
> The PCI_HOTPLUG code has often been troublesome with respect to these checks
> as this code is only relevant if CONFIG_HOTPLUG is enabled
> and will often not even be included in the kernel if not enabled.
> This is true for pci_rescan_bus() for example.
>
> And we would like to export these symbols too. But we do not allow exported
> symbols to be annotated __devinit as this code will be blown away in some configurations.
>
> So the correct solution which you also used in your patch is to tell
> modpost to ignore references to *init sections from this specific funtion
> as they are OK.
Does this count as an Acked-by?
Thanks.
On Wed, 1 Apr 2009 18:24:12 -0600
Alex Chiang <[email protected]> wrote:
> PCI: annotate pci_rescan_bus as __ref, not __devinit
Applied, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, Apr 06, 2009 at 09:19:31AM -0600, Alex Chiang wrote:
> * Sam Ravnborg <[email protected]>:
> > >
> > > Reading through Documentation/PCI/pci.txt says that under
> > > CONFIG_HOTPLUG, __devinit should be a nop?
> > The documentation is not up-to-date in this respect.
> >
> > Annotating a function __devinit will no matter the configuration
> > locate the code in a section named .devinit.text
>
> Ok, I'll update the documentation.
>
> > We then postprocess this section for illegal references using modpost.
> >
> > The PCI_HOTPLUG code has often been troublesome with respect to these checks
> > as this code is only relevant if CONFIG_HOTPLUG is enabled
> > and will often not even be included in the kernel if not enabled.
> > This is true for pci_rescan_bus() for example.
> >
> > And we would like to export these symbols too. But we do not allow exported
> > symbols to be annotated __devinit as this code will be blown away in some configurations.
> >
> > So the correct solution which you also used in your patch is to tell
> > modpost to ignore references to *init sections from this specific funtion
> > as they are OK.
>
> Does this count as an Acked-by?
If this is not too late - yes.
Sam