linux-mips
[Top] [All Lists]

Re: PCI Section mismatch error in linux-next.

To: Greg KH <gregkh@linuxfoundation.org>
Subject: Re: PCI Section mismatch error in linux-next.
From: Thierry Reding <thierry.reding@avionic-design.de>
Date: Mon, 20 Aug 2012 09:16:41 +0200
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>
In-reply-to: <20120820053036.GA23166@kroah.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
References: <CAErSpo7a77wAxrgZYfg_UdqLEtEf0wUxcbxTghnR7HbRsncKRQ@mail.gmail.com> <20120817182931.GA27391@avionic-0098.adnet.avionic-design.de> <CAErSpo6xhbpmd-rnLqKp9SuRQCp5a7jUzKhz0n6zGGLNHybWqA@mail.gmail.com> <20120817200755.GA16021@avionic-0098.adnet.avionic-design.de> <CAErSpo4XX7mQBmJfYWzmXCSDAt4BzZoJV6gU9__409K=fpvC6A@mail.gmail.com> <20120817204839.GA2017@avionic-0098.mockup.avionic-design.de> <20120817210718.GA14842@avionic-0098.mockup.avionic-design.de> <CAErSpo7bwHNUchZHeJByxzhsc0uN7RJMLivBo5FuOJzA0Gz2Jg@mail.gmail.com> <20120817213247.GA1056@avionic-0098.mockup.avionic-design.de> <20120820053036.GA23166@kroah.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, Aug 19, 2012 at 10:30:36PM -0700, Greg KH wrote:
> 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.

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

Attachment: pgpXHGWaplKbK.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>