Re: [patch 4/5] i386: turn on CONFIG_PNP in defconfig

[Len Brown <lenb@kernel.org>]

On Thursday 18 January 2007 12:49, Bjorn Helgaas wrote:
> On Wednesday 17 January 2007 20:08, Len Brown wrote:
> > > --- mm-work13.orig/arch/i386/defconfig	2007-01-11 13:56:18.000000000 -0700
> > > +++ mm-work13/arch/i386/defconfig	2007-01-11 13:57:23.000000000 -0700
> > > @@ -466,7 +466,7 @@
> > >  #
> > >  # Plug and Play support
> > >  #
> > > -# CONFIG_PNP is not set
> > > +CONFIG_PNP=y
> > >  
> > >  #
> > >  # Block devices
> > 
> > shouldn't CONFIG_PNPACPI=y also appear in defconfig with this change?
> > If it doesn't, then somebody who runs make oldconfig will get prompted for it.
> 
> Yes, you're right.  I'll add PNPACPI=y in the next round.

Hmm, I guess if we're going to include it by default,
it is time to delete its dependency on EXPERIMENTAL:
Though so many things depend on EXPERIMENTAL
these days that maybe it doesn't mean so much.

config PNPACPI
        bool "Plug and Play ACPI support (EXPERIMENTAL)"
        depends on PNP && ACPI && EXPERIMENTAL

> > Also, do we need to be concerned about the case where
> > CONFIG_PNP=n
> > CONFIG_ACPI=y
> > This is the case that motherboard.c was intended to cover.
> > 
> > CONFIG_PNP depends on ACPI (or ISA)
> > But nothing mandates that somebody must select it.
> 
> Hmmm... true.  Could we get away with having ACPI select PNP?

Every time I've tried to use select in recent memory it seems
something goes bad.  I think there is a rule, such as the
thing selected can not depend on anything else, which if violated
breaks people's ranconfigs and adrian get grumpy about it.

So I think if we want to tie them together, then ACPI
should actually depend on PNP -- which is consistent,
with how ACPI depends on PM today.

 
> Two other, longer term thoughts:
>   1) I think it would be good if PNP reserved resources for all
>      active devices, as PCI already does (though PCI might do it
>      even for disabled devices).  Then we really wouldn't need
>      system.c or motherboard.c at all.
> 
>   2) I think we should deprecate ACPI driver registration and do
>      everything through PNP, with the ACPI stuff as an optional
>      capability of PNP devices.  Then PNP=n, ACPI=y really wouldn't
>      make much sense.

Whelp, when we're guaranteed that PNP exists when ACPI exists
then we can get smarter about PNP.

thanks,
-Len