linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	David Daney <ddaney.cavm@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-pci@vger.kernel.org, linux-mips <linux-mips@linux-mips.org>
Subject: Re: PCI Section mismatch error in linux-next.
Date: Sun, 19 Aug 2012 22:30:36 -0700	[thread overview]
Message-ID: <20120820053036.GA23166@kroah.com> (raw)
In-Reply-To: <20120817213247.GA1056@avionic-0098.mockup.avionic-design.de>

On Fri, Aug 17, 2012 at 11:32:47PM +0200, Thierry Reding wrote:
> On Fri, Aug 17, 2012 at 03:25:22PM -0600, Bjorn Helgaas wrote:
> > On Fri, Aug 17, 2012 at 3:07 PM, Thierry Reding
> > <thierry.reding@avionic-design.de> wrote:
> > > On Fri, Aug 17, 2012 at 10:48:39PM +0200, Thierry Reding wrote:
> > >> On Fri, Aug 17, 2012 at 02:39:34PM -0600, Bjorn Helgaas wrote:
> > > [...]
> > >> > 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.
> > >>
> > >> 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?
> > >
> > > 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.
> > 
> > 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.
> 
> 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

  parent reply	other threads:[~2012-08-20  5:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17 17:36 PCI Section mismatch error in linux-next David Daney
2012-08-17 17:44 ` Bjorn Helgaas
2012-08-17 18:29   ` Thierry Reding
2012-08-17 19:32     ` Bjorn Helgaas
2012-08-17 20:07       ` Thierry Reding
2012-08-17 20:39         ` Bjorn Helgaas
2012-08-17 20:48           ` Thierry Reding
2012-08-17 21:06             ` Bjorn Helgaas
2012-08-17 21:22               ` Thierry Reding
2012-08-17 21:07             ` Thierry Reding
2012-08-17 21:25               ` Bjorn Helgaas
2012-08-17 21:32                 ` Thierry Reding
2012-08-17 21:46                   ` Bjorn Helgaas
2012-08-20  5:30                   ` Greg KH [this message]
2012-08-20  7:16                     ` Thierry Reding
2012-08-21 14:32                     ` Geert Uytterhoeven
2012-08-21 17:04                       ` Ralf Baechle
2012-08-21 18:15                         ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120820053036.GA23166@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bhelgaas@google.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ralf@linux-mips.org \
    --cc=thierry.reding@avionic-design.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).