PCI Section mismatch error in linux-next.
Subsystems (3)
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep pci_fixup_irqs() around after init) causes:
WARNING: vmlinux.o(.text+0x22c784): Section mismatch in reference from the function pci_fixup_irqs() to the function .init.text:pcibios_update_irq()
The MIPS implementation of pcibios_update_irq() is __init, so there is conflict with the removal of __init from pci_fixup_irqs() and pdev_fixup_irq().
Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of pdev_update_irq()?
Thanks,
David Daney
Bjorn Helgaas
maintainerQuoted 6 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()
Quoted 6 lines
The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?
Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Bjorn
Quoted 11 lines · Bjorn Helgaas
Quoted 10 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().
Quoted 5 lines
Quoted 2 lines
Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Oh wow... looks like I've opened a can of worms there. This requires quite a lot of other functions to have their annotations removed as well. Bjorn, how do you want to handle this?
Thierry
Bjorn Helgaas
maintainerQuoted 15 lines · Thierry Reding
Quoted 14 lines · Bjorn Helgaas
Quoted 12 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?
Quoted 6 lines
Quoted 2 lines
Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Oh wow... looks like I've opened a can of worms there. This requires quite a lot of other functions to have their annotations removed as well. Bjorn, how do you want to handle this?
David said "pdev_update_irq()," but I think he meant "pcibios_update_irq()."
Almost all the pcibios_update_irq() implementations are identical, so I think I'll just supply a weak implementation and remove the redundant arch versions.
This is just about the only thing in my "next" branch, so I'll clear it out for now, until we get this resolved.
Bjorn
Quoted 24 lines · Bjorn Helgaas
Quoted 15 lines · Thierry Reding
Quoted 14 lines · Bjorn Helgaas
Quoted 12 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?Quoted 6 lines
Quoted 2 lines
Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Oh wow... looks like I've opened a can of worms there. This requires quite a lot of other functions to have their annotations removed as well. Bjorn, how do you want to handle this?
Quoted 5 lines
David said "
pdev_update_irq()," but I think he meant "pcibios_update_irq()."Almost all the
pcibios_update_irq()implementations are identical, so I think I'll just supply a weak implementation and remove the redundant arch versions.
That makes sense. However I've just tested a build with section mismatch debugging enabled on ARM and there are a few more that need __init or __devinit removed to get rid of the warnings:
pci_common_init()
pcibios_init_hw()
pcibios_init_resources()
pcibios_swizzle()
pcibios_update_irq()
pci_scan_root_bus() also needs __devinit removed. I haven't checked the other architectures because I'll have to build cross-compilers for them first, but I suspect most of them will have a similar list. I'm not sure how well this kind of change is going to go down with the respective architecture maintainers, though.
Quoted 2 lines
This is just about the only thing in my "next" branch, so I'll clear it out for now, until we get this resolved.
Agreed. Do you want me to take a look at this or would you rather tackle it yourself?
Thierry
Bjorn Helgaas
maintainerQuoted 41 lines · Thierry Reding
Quoted 24 lines · Bjorn Helgaas
Quoted 15 lines · Thierry Reding
Quoted 14 lines · Bjorn Helgaas
Quoted 12 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?Quoted 6 lines
Quoted 2 lines
Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Oh wow... looks like I've opened a can of worms there. This requires quite a lot of other functions to have their annotations removed as well. Bjorn, how do you want to handle this?
Quoted 5 lines
David said "
pdev_update_irq()," but I think he meant "pcibios_update_irq()."Almost all the
pcibios_update_irq()implementations are identical, so I think I'll just supply a weak implementation and remove the redundant arch versions.That makes sense. However I've just tested a build with section mismatch debugging enabled on ARM and there are a few more that need
__initor__devinitremoved to get rid of the warnings:
pci_common_init()
pcibios_init_hw()
pcibios_init_resources()
pcibios_swizzle()
pcibios_update_irq()
Quoted 5 lines
pci_scan_root_bus()also needs__devinitremoved. I haven't checked the other architectures because I'll have to build cross-compilers for them first, but I suspect most of them will have a similar list. I'm not sure how well this kind of change is going to go down with the respective architecture maintainers, though.
Hmm, yeah, this is a mess, isn't it? Just about everything in PCI will need __devinit removed. We've been assuming that the only way for things to show up after init is via hotplug. But you're breaking that assumption by doing *all* enumeration after init. There are approximately a bajillion __init and __devinit annotations just in drivers/pci, not to mention those in the architectures.
Well, maybe you just need to turn on CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some __inits to __devinit, including pcibios_update_irq(), but it might be more manageable.
I started working on this, but it sounds like you're in a better position to find problems and test fixes, so how about if I just let you handle it? :)
Bjorn
Quoted 56 lines · Bjorn Helgaas
Quoted 41 lines · Thierry Reding
Quoted 24 lines · Bjorn Helgaas
Quoted 15 lines · Thierry Reding
Quoted 14 lines · Bjorn Helgaas
Quoted 12 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?Quoted 6 lines
Quoted 2 lines
Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Oh wow... looks like I've opened a can of worms there. This requires quite a lot of other functions to have their annotations removed as well. Bjorn, how do you want to handle this?
Quoted 5 lines
David said "
pdev_update_irq()," but I think he meant "pcibios_update_irq()."Almost all the
pcibios_update_irq()implementations are identical, so I think I'll just supply a weak implementation and remove the redundant arch versions.That makes sense. However I've just tested a build with section mismatch debugging enabled on ARM and there are a few more that need
__initor__devinitremoved to get rid of the warnings:
pci_common_init()
pcibios_init_hw()
pcibios_init_resources()
pcibios_swizzle()
pcibios_update_irq()Quoted 5 lines
pci_scan_root_bus()also needs__devinitremoved. I haven't checked the other architectures because I'll have to build cross-compilers for them first, but I suspect most of them will have a similar list. I'm not sure how well this kind of change is going to go down with the respective architecture maintainers, though.Hmm, yeah, this is a mess, isn't it? Just about everything in PCI will need
__devinitremoved. We've been assuming that the only way for things to show up after init is via hotplug. But you're breaking that assumption by doing *all* enumeration after init. There are approximately a bajillion__initand__devinitannotations just indrivers/pci, not to mention those in the architectures.
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.
You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep __init or __devinit respectively, right?
Quoted 3 lines
I started working on this, but it sounds like you're in a better position to find problems and test fixes, so how about if I just let you handle it? :)
I won't be able to test anything beyond Tegra because I'm lacking the hardware. But with the section mismatch debugging enabled all issues should be detected at compile time anyway, so it's just a problem of getting cross-compilers for all architectures that support PCI.
Thierry
Bjorn Helgaas
maintainerQuoted 57 lines · Thierry Reding
Quoted 56 lines · Bjorn Helgaas
Quoted 41 lines · Thierry Reding
Quoted 24 lines · Bjorn Helgaas
Quoted 15 lines · Thierry Reding
Quoted 14 lines · Bjorn Helgaas
Quoted 12 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?Quoted 6 lines
Quoted 2 lines
Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Oh wow... looks like I've opened a can of worms there. This requires quite a lot of other functions to have their annotations removed as well. Bjorn, how do you want to handle this?
Quoted 5 lines
David said "
pdev_update_irq()," but I think he meant "pcibios_update_irq()."Almost all the
pcibios_update_irq()implementations are identical, so I think I'll just supply a weak implementation and remove the redundant arch versions.That makes sense. However I've just tested a build with section mismatch debugging enabled on ARM and there are a few more that need
__initor__devinitremoved to get rid of the warnings:
pci_common_init()
pcibios_init_hw()
pcibios_init_resources()
pcibios_swizzle()
pcibios_update_irq()Quoted 5 lines
pci_scan_root_bus()also needs__devinitremoved. I haven't checked the other architectures because I'll have to build cross-compilers for them first, but I suspect most of them will have a similar list. I'm not sure how well this kind of change is going to go down with the respective architecture maintainers, though.Hmm, yeah, this is a mess, isn't it? Just about everything in PCI will need
__devinitremoved. We've been assuming that the only way for things to show up after init is via hotplug. But you're breaking that assumption by doing *all* enumeration after init. There are approximately a bajillion__initand__devinitannotations just indrivers/pci, not to mention those in the architectures.
Quoted 7 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined.
I'm suggesting that maybe we shouldn't support enumeration at runtime unless HOTPLUG is defined. So if you want to enumerate after init, set CONFIG_HOTPLUG=y.
Quoted 4 lines
Also it is
theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep__initor__devinitrespectively, right?
This is the situation (deferred probing with CONFIG_HOTPLUG=n) that I'm suggesting might not need to work. After all, hotplug essentially means "adding devices after init."
Quoted 4 lines
I won't be able to test anything beyond Tegra because I'm lacking the hardware. But with the section mismatch debugging enabled all issues should be detected at compile time anyway, so it's just a problem of getting cross-compilers for all architectures that support PCI.
I have cross-compilers for many of the architectures (relatively painless to build with
http://git.infradead.org/users/segher/buildall.git), but this is starting to look like it will take more time than I have right now.
Quoted 71 lines · Bjorn Helgaas
Quoted 57 lines · Thierry Reding
Quoted 56 lines · Bjorn Helgaas
Quoted 41 lines · Thierry Reding
Quoted 24 lines · Bjorn Helgaas
Quoted 15 lines · Thierry Reding
Quoted 14 lines · Bjorn Helgaas
Quoted 12 lines · David Daney
For MIPS, Thierry Reding's patch in linux-next (PCI: Keep
pci_fixup_irqs()around after init) causes:WARNING:
vmlinux.o(.text+0x22c784): Section mismatch in reference from the functionpci_fixup_irqs()to the function .init.text:pcibios_update_irq()The MIPS implementation of
pcibios_update_irq()is__init, so there is conflict with the removal of__initfrompci_fixup_irqs()andpdev_fixup_irq().Can you guys either remove the patch from linux-next, or improve it to also fix up any architecture implementations of
pdev_update_irq()?Quoted 6 lines
Quoted 2 lines
Crap, there are lots of arches with this issue. I'll fix it up. Thanks for pointing it out!
Oh wow... looks like I've opened a can of worms there. This requires quite a lot of other functions to have their annotations removed as well. Bjorn, how do you want to handle this?
Quoted 5 lines
David said "
pdev_update_irq()," but I think he meant "pcibios_update_irq()."Almost all the
pcibios_update_irq()implementations are identical, so I think I'll just supply a weak implementation and remove the redundant arch versions.That makes sense. However I've just tested a build with section mismatch debugging enabled on ARM and there are a few more that need
__initor__devinitremoved to get rid of the warnings:
pci_common_init()
pcibios_init_hw()
pcibios_init_resources()
pcibios_swizzle()
pcibios_update_irq()Quoted 5 lines
pci_scan_root_bus()also needs__devinitremoved. I haven't checked the other architectures because I'll have to build cross-compilers for them first, but I suspect most of them will have a similar list. I'm not sure how well this kind of change is going to go down with the respective architecture maintainers, though.Hmm, yeah, this is a mess, isn't it? Just about everything in PCI will need
__devinitremoved. We've been assuming that the only way for things to show up after init is via hotplug. But you're breaking that assumption by doing *all* enumeration after init. There are approximately a bajillion__initand__devinitannotations just indrivers/pci, not to mention those in the architectures.Quoted 7 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined.
I'm suggesting that maybe we shouldn't support enumeration at runtime unless HOTPLUG is defined. So if you want to enumerate after init, set
CONFIG_HOTPLUG=y.
Quoted 8 lines
Quoted 4 lines
Also it is
theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep__initor__devinitrespectively, right?This is the situation (deferred probing with
CONFIG_HOTPLUG=n) that I'm suggesting might not need to work. After all, hotplug essentially means "adding devices after init."
Yes, I guess that would be appropriate. However I don't see how this could be expressed in Kconfig unless the deferred probing itself is conditionalized on HOTPLUG. Even in that case it would still be possible to build a PCIe controller driver as a module and load it at runtime after init.
Quoted 9 lines
Quoted 4 lines
I won't be able to test anything beyond Tegra because I'm lacking the hardware. But with the section mismatch debugging enabled all issues should be detected at compile time anyway, so it's just a problem of getting cross-compilers for all architectures that support PCI.
I have cross-compilers for many of the architectures (relatively painless to build with
http://git.infradead.org/users/segher/buildall.git), but this is starting to look like it will take more time than I have right now.
I have my own set of scripts and I already have toolchains for ARM, MIPS, x86 and PowerPC. I've started a build for SPARC and will look at some of the more exotic ones after that.
This also looks a little daunting to me, but I'll give it a shot. I don't have plenty of time either so it may take a while.
Thierry
Quoted 1 line · Thierry Reding
On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
[...]
Quoted 10 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep
__initor__devinitrespectively, right?
Another possibility would be to make PCI select HOTPLUG or depend on it. That way it would be made sure that __devinit wouldn't cause all the functions to be discarded after init.
Also, using PCI without HOTPLUG is sort of contradictory.
Thierry
Bjorn Helgaas
maintainerQuoted 14 lines · Thierry Reding
Quoted 1 line · Thierry Reding
On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
[...]
Quoted 10 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep
__initor__devinitrespectively, right?
Quoted 3 lines
Another possibility would be to make PCI select HOTPLUG or depend on it. That way it would be made sure that
__devinitwouldn't cause all the functions to be discarded after init.
There's been some discussion recently about whether CONFIG_HOTPLUG is worth keeping any more, but nothing's been resolved yet. If we did decide to remove CONFIG_HOTPLUG, or require it for PCI, I would rather just remove all the __devinit annotations because they'd be superfluous.
Quoted 1 line
Also, using PCI without HOTPLUG is sort of contradictory.
I'm not sure I follow this one. I can easily imagine embedded systems that use PCI internally but have no slots or connectors, so there's no possibility of anything changing.
Quoted 20 lines · Bjorn Helgaas
Quoted 14 lines · Thierry Reding
Quoted 1 line · Thierry Reding
On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
[...]
Quoted 10 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep
__initor__devinitrespectively, right?Quoted 3 lines
Another possibility would be to make PCI select HOTPLUG or depend on it. That way it would be made sure that
__devinitwouldn't cause all the functions to be discarded after init.
Quoted 5 lines
There's been some discussion recently about whether
CONFIG_HOTPLUGis worth keeping any more, but nothing's been resolved yet. If we did decide to removeCONFIG_HOTPLUG, or require it for PCI, I would rather just remove all the__devinitannotations because they'd be superfluous.
I've missed that discussion. Can you point me to it?
Quoted 5 lines
Quoted 1 line
Also, using PCI without HOTPLUG is sort of contradictory.
I'm not sure I follow this one. I can easily imagine embedded systems that use PCI internally but have no slots or connectors, so there's no possibility of anything changing.
Contradictory was probably the wrong word. What I meant to say was that for systems that use PCI it probably wouldn't hurt to enable HOTPLUG as well. That would sort of go with what you said above, regarding the removal of HOTPLUG altogether.
Thierry
Bjorn Helgaas
maintainerQuoted 21 lines · Thierry Reding
Quoted 20 lines · Bjorn Helgaas
Quoted 17 lines · Thierry Reding
Quoted 1 line · Thierry Reding
On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
[...]
Quoted 10 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep
__initor__devinitrespectively, right?Another possibility would be to make PCI select HOTPLUG or depend on it. That way it would be made sure that
__devinitwouldn't cause all the functions to be discarded after init.
Quoted 7 lines
Quoted 5 lines
There's been some discussion recently about whether
CONFIG_HOTPLUGis worth keeping any more, but nothing's been resolved yet. If we did decide to removeCONFIG_HOTPLUG, or require it for PCI, I would rather just remove all the__devinitannotations because they'd be superfluous.I've missed that discussion. Can you point me to it?
Sure: http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000051.html
Quoted 10 lines
From previous email:
Quoted 3 lines
This is the situation (deferred probing with
CONFIG_HOTPLUG=n) that I'm suggesting might not need to work. After all, hotplug essentially means "adding devices after init."Yes, I guess that would be appropriate. However I don't see how this could be expressed in
Kconfigunless the deferred probing itself is conditionalized on HOTPLUG. Even in that case it would still be possible to build a PCIe controller driver as a module and load it at runtime after init.
That's exactly it -- the deferred probing and any loadable PCI host bridge drivers would have to depend on HOTPLUG. That seems like the most straightforward, least-surprises, approach for now.
Bjorn
Quoted 21 lines · Thierry Reding
Quoted 20 lines · Bjorn Helgaas
Quoted 17 lines · Thierry Reding
Quoted 1 line · Thierry Reding
On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
[...]
Quoted 10 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep
__initor__devinitrespectively, right?Another possibility would be to make PCI select HOTPLUG or depend on it. That way it would be made sure that
__devinitwouldn't cause all the functions to be discarded after init.
Quoted 7 lines
Quoted 5 lines
There's been some discussion recently about whether
CONFIG_HOTPLUGis worth keeping any more, but nothing's been resolved yet. If we did decide to removeCONFIG_HOTPLUG, or require it for PCI, I would rather just remove all the__devinitannotations because they'd be superfluous.I've missed that discussion. Can you point me to it?
It's pretty much just me saying the whole thing is a mess, causes problems, and really doesn't solve any memory usage issues. Ideally we should just:
- remove CONFIG_HOTPLUG and assume it is enabled
- because of that, we can delete the large majority of the __dev* markings
The memory savings these days are so tiny, if at all, and everyone, including me, gets it wrong all the time.
As we pretty much allow anything to be disabled/enabled at any point in time after boot, we are all running systems that rely on CONFIG_HOTPLUG anyway. To find a static system that doesn't need it is quite rare from what I have found.
greg k-h
Quoted 37 lines · Greg KH
Quoted 21 lines · Thierry Reding
Quoted 20 lines · Bjorn Helgaas
Quoted 17 lines · Thierry Reding
Quoted 1 line · Thierry Reding
On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
[...]
Quoted 10 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep
__initor__devinitrespectively, right?Another possibility would be to make PCI select HOTPLUG or depend on it. That way it would be made sure that
__devinitwouldn't cause all the functions to be discarded after init.Quoted 7 lines
Quoted 5 lines
There's been some discussion recently about whether
CONFIG_HOTPLUGis worth keeping any more, but nothing's been resolved yet. If we did decide to removeCONFIG_HOTPLUG, or require it for PCI, I would rather just remove all the__devinitannotations because they'd be superfluous.I've missed that discussion. Can you point me to it?
It's pretty much just me saying the whole thing is a mess, causes problems, and really doesn't solve any memory usage issues. Ideally we should just:
- removeCONFIG_HOTPLUGand assume it is enabled
- because of that, we can delete the large majority of the __dev* markings
Quoted 7 lines
The memory savings these days are so tiny, if at all, and everyone, including me, gets it wrong all the time.
As we pretty much allow anything to be disabled/enabled at any point in time after boot, we are all running systems that rely on
CONFIG_HOTPLUGanyway. To find a static system that doesn't need it is quite rare from what I have found.
I've been reading through the thread it seems like the consensus is to just drop it. Though there seems to be lacking a formal decision.
Thierry
Hi Greg,
Quoted 37 lines · Greg KH
Quoted 21 lines · Thierry Reding
Quoted 20 lines · Bjorn Helgaas
Quoted 17 lines · Thierry Reding
Quoted 1 line · Thierry Reding
On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
[...]
Quoted 10 lines
Quoted 4 lines
Well, maybe you just need to turn on
CONFIG_HOTPLUG. How would that affect you? I think we would still have to change some__initsto__devinit, includingpcibios_update_irq(), but it might be more manageable.You said that depending on HOTPLUG wouldn't be enough because it would exclude reenumeration at runtime if HOTPLUG wasn't defined. Also it is theoretically possible to build a kernel without HOTPLUG but have the enumeration start after init because of deferred probing. Those cases won't work if we keep
__initor__devinitrespectively, right?Another possibility would be to make PCI select HOTPLUG or depend on it. That way it would be made sure that
__devinitwouldn't cause all the functions to be discarded after init.Quoted 7 lines
Quoted 5 lines
There's been some discussion recently about whether
CONFIG_HOTPLUGis worth keeping any more, but nothing's been resolved yet. If we did decide to removeCONFIG_HOTPLUG, or require it for PCI, I would rather just remove all the__devinitannotations because they'd be superfluous.I've missed that discussion. Can you point me to it?
It's pretty much just me saying the whole thing is a mess, causes problems, and really doesn't solve any memory usage issues. Ideally we should just:
- removeCONFIG_HOTPLUGand assume it is enabled
- because of that, we can delete the large majority of the __dev* markings
Quoted 7 lines
The memory savings these days are so tiny, if at all, and everyone, including me, gets it wrong all the time.
As we pretty much allow anything to be disabled/enabled at any point in time after boot, we are all running systems that rely on
CONFIG_HOTPLUGanyway. To find a static system that doesn't need it is quite rare from what I have found.
Anyone who disables CONFIG_HOTPLUG in his defconfig files?
$ git grep CONFIG_HOTPLUG arch/*/*config arch/frv/defconfig:# CONFIG_HOTPLUG is not set arch/h8300/defconfig:# CONFIG_HOTPLUG is not set arch/um/defconfig:CONFIG_HOTPLUG=y $
Yep, (at least --- not all defconfigs are up-to-date) frv and h8300.
It seems to be hard, as it's enabled for all non-CONFIG_EXPERT (and before that non-CONFIG_EMBEDDED) builds since Nov 2005 (full-history-linux commit 712f47cea7703a340406fde61e84eb86ce781988
"[PATCH] HOTPLUG: always enable the .config option, unless EMBEDDED").
$ git grep CONFIG_EXPERT arch/*/*config arch/frv/defconfig:CONFIG_EXPERT=y arch/h8300/defconfig:CONFIG_EXPERT=y arch/s390/defconfig:CONFIG_EXPERT=y arch/um/defconfig:# CONFIG_EXPERT is not set $
The same architectures, plus s390, who used to be an explicit negative dependency before the commit above.
For a quick test, I enabled CONFIG_EXPERT and disabled CONFIG_HOTPLUG in my Atari defconfig build, and it saved 168 bytes of code and 112 bytes of data. Note that Atari doesn't have any hotpluggable hardware, hence no real hotpluggable drivers.
Anyway, I'll sleep better now ;-)
FWIW, both tile and xtensa have their own duplicates of CONFIG_HOTPLUG:
$ git grep -w 'config HOTPLUG' -- "*Kconf*" arch/tile/Kconfig:config HOTPLUG arch/xtensa/Kconfig:config HOTPLUG init/Kconfig:config HOTPLUG $
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 9 lines · Geert Uytterhoeven
Anyone who disables
CONFIG_HOTPLUGin his defconfig files?$ git grep CONFIG_HOTPLUG arch/*/*config arch/frv/defconfig:# CONFIG_HOTPLUG is not set arch/h8300/defconfig:# CONFIG_HOTPLUG is not set arch/um/defconfig:CONFIG_HOTPLUG=y $Yep, (at least --- not all defconfigs are up-to-date) frv and h8300.
Since we started stripping all the defconfigs down grepping through arch/*/configs/ doesn't yield much useful information anymore :-(
There are currently 8 MIPS default configurations that dondo not enable CONFIG_HOTPLUG. I didn't check other architectures.
Ralf
Hi Ralf,
Quoted 8 lines · Ralf Baechle
Quoted 8 lines
Anyone who disables
CONFIG_HOTPLUGin his defconfig files?$ git grep CONFIG_HOTPLUG arch/*/*config arch/frv/defconfig:# CONFIG_HOTPLUG is not set arch/h8300/defconfig:# CONFIG_HOTPLUG is not set arch/um/defconfig:CONFIG_HOTPLUG=y $
Quoted 4 lines
Quoted 1 line
Yep, (at least --- not all defconfigs are up-to-date) frv and h8300.
Since we started stripping all the defconfigs down grepping through
arch/*/configs/doesn't yield much useful information anymore :-(
Sure, but since CONFIG_HOTPLUG=y and CONFIG_EXPERT=n are the defaults, disabling CONFIG_HOTPLUG should show up in the miniconfig.
Quoted 2 lines
There are currently 8 MIPS default configurations that dondo not enable
CONFIG_HOTPLUG. I didn't check other architectures.
Strange, how come I didn't see those?
Ah, wrong file pattern. They're stored in the "configs" subdir, not in "config". Better list:
$ git grep -w CONFIG_HOTPLUG arch/*/*config* arch/arm/configs/at91x40_defconfig:# CONFIG_HOTPLUG is not set arch/arm/configs/bcmring_defconfig:# CONFIG_HOTPLUG is not set arch/arm/configs/edb7211_defconfig:# CONFIG_HOTPLUG is not set arch/arm/configs/footbridge_defconfig:# CONFIG_HOTPLUG is not set arch/arm/configs/fortunet_defconfig:# CONFIG_HOTPLUG is not set arch/arm/configs/pleb_defconfig:# CONFIG_HOTPLUG is not set arch/blackfin/configs/IP0X_defconfig:# CONFIG_HOTPLUG is not set arch/cris/configs/artpec_3_defconfig:# CONFIG_HOTPLUG is not set arch/cris/configs/etrax-100lx_v2_defconfig:# CONFIG_HOTPLUG is not set arch/cris/configs/etraxfs_defconfig:# CONFIG_HOTPLUG is not set arch/frv/defconfig:# CONFIG_HOTPLUG is not set arch/h8300/defconfig:# CONFIG_HOTPLUG is not set arch/m68k/configs/m5208evb_defconfig:# CONFIG_HOTPLUG is not set arch/m68k/configs/m5249evb_defconfig:# CONFIG_HOTPLUG is not set arch/m68k/configs/m5272c3_defconfig:# CONFIG_HOTPLUG is not set arch/m68k/configs/m5275evb_defconfig:# CONFIG_HOTPLUG is not set arch/m68k/configs/m5307c3_defconfig:# CONFIG_HOTPLUG is not set arch/m68k/configs/m5407c3_defconfig:# CONFIG_HOTPLUG is not set arch/m68k/configs/m5475evb_defconfig:# CONFIG_HOTPLUG is not set arch/microblaze/configs/mmu_defconfig:# CONFIG_HOTPLUG is not set arch/microblaze/configs/nommu_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/db1000_defconfig:CONFIG_HOTPLUG=y arch/mips/configs/db1300_defconfig:CONFIG_HOTPLUG=y arch/mips/configs/db1550_defconfig:CONFIG_HOTPLUG=y arch/mips/configs/decstation_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/e55_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/ip22_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/ip28_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/jmr3927_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/lasat_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/pnx8550-stb810_defconfig:# CONFIG_HOTPLUG is not set arch/mips/configs/rbtx49xx_defconfig:# CONFIG_HOTPLUG is not set arch/mn10300/configs/asb2303_defconfig:# CONFIG_HOTPLUG is not set arch/powerpc/configs/85xx/socrates_defconfig:# CONFIG_HOTPLUG is not set arch/powerpc/configs/85xx/tqm8540_defconfig:# CONFIG_HOTPLUG is not set arch/powerpc/configs/85xx/tqm8541_defconfig:# CONFIG_HOTPLUG is not set arch/powerpc/configs/85xx/tqm8555_defconfig:# CONFIG_HOTPLUG is not set arch/powerpc/configs/85xx/tqm8560_defconfig:# CONFIG_HOTPLUG is not set arch/powerpc/configs/mpc866_ads_defconfig:# CONFIG_HOTPLUG is not set arch/score/configs/spct6600_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/edosk7705_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/se7619_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/se7705_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/se7750_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/se7751_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/se7780_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/secureedge5410_defconfig:# CONFIG_HOTPLUG is not set arch/sh/configs/shmin_defconfig:# CONFIG_HOTPLUG is not set arch/um/defconfig:CONFIG_HOTPLUG=y arch/unicore32/configs/unicore32_defconfig:CONFIG_HOTPLUG=y arch/xtensa/configs/common_defconfig:# CONFIG_HOTPLUG is not set arch/xtensa/configs/iss_defconfig:# CONFIG_HOTPLUG is not set arch/xtensa/configs/s6105_defconfig:# CONFIG_HOTPLUG is not set $
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds