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.
> 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?
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.
Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
