Re: loosen dependancy on rtc cmos
On Thursday 15 February 2007 9:12 pm, David Brownell wrote: > On Thursday 15 February 2007 8:38 pm, Len Brown wrote: > > > So I've taken Andi's advice and checked in the patches below. > > OK; that simplifies things for me, good! I can discard that patch > (broken by Andi's pcspkr change anyway), stop worring about whether > most folk will even see that driver, and make time to look at the > ACPI hooks for RTC wakeup, instead. :) Which, by the way, means that folk with pre-ACPI systems aren't going to be able to use this driver until someone else provides an updated patch creating an "rtc_cmos" platform device. Or on the more modern end of things ... I suspect PCs using Linux-BIOS won't do PNPACPI either, and they will also need that platform device before using this driver. What do the MiniMac systems do? At one time I thought they were ACPI-free. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Thursday 15 February 2007 9:12 pm, David Brownell wrote: On Thursday 15 February 2007 8:38 pm, Len Brown wrote: So I've taken Andi's advice and checked in the patches below. OK; that simplifies things for me, good! I can discard that patch (broken by Andi's pcspkr change anyway), stop worring about whether most folk will even see that driver, and make time to look at the ACPI hooks for RTC wakeup, instead. :) Which, by the way, means that folk with pre-ACPI systems aren't going to be able to use this driver until someone else provides an updated patch creating an rtc_cmos platform device. Or on the more modern end of things ... I suspect PCs using Linux-BIOS won't do PNPACPI either, and they will also need that platform device before using this driver. What do the MiniMac systems do? At one time I thought they were ACPI-free. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Thursday 15 February 2007 8:38 pm, Len Brown wrote: > So I've taken Andi's advice and checked in the patches below. OK; that simplifies things for me, good! I can discard that patch (broken by Andi's pcspkr change anyway), stop worring about whether most folk will even see that driver, and make time to look at the ACPI hooks for RTC wakeup, instead. :) But it would be nice to see the PNP bus infrastructure upgraded in various ways too, now that its availability is less iffy. - Add something analagous to platform_driver_probe() so that the init code can be removed after it runs. - Add shutdown() calls to the PNP bus. Otherwise e.g. one must use shutdown notifiers for PNP interfaces, while normal driver model code works for other interfaces to such hardware. Transitioning from "legacy" drivers to PNP (for PCs) and platform_bus (other platforms) is a bit awkward because of differences like those. Drivers still need too many different modes; it's too complicated to have a core with different bus glues as thin veneers ... the glue must be thicker (and thus error prone). Similarly, I/O space resource reservation acts differently. I can hope that having PNPACPI be more common will start nudging more drivers to get rid of their "legacy" modes, or at least focus on "Real Driver" modes that don't involve poking at hardware and hoping it doesn't bite back. ;) - Dave > commit 243b66e76ab722cdec1921d7f80c0cb808131c37 > Author: Len Brown <[EMAIL PROTECTED]> > Date: Thu Feb 15 22:34:36 2007 -0500 > > ACPI: always enable CONFIG_PNPACPI on CONFIG_ACPI kernels > > We removed the ACPI motherboard driver which handled > the ACPI=y, PNP=n case, so now we need to enforce that > PNP & PNPACPI are always enabled for ACPI kernels. > > Most major distros ship this way this already. > > Cc: Bjorn Helgaas <[EMAIL PROTECTED]> > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > commit 8d4956c201c2f7683289f70095443c59a39f94ef > Author: Len Brown <[EMAIL PROTECTED]> > Date: Thu Feb 15 22:46:42 2007 -0500 > > ACPI: remove non-PNPACPI version of get_rtc_dev() > > It isn't needed in ACPI code anymore because > now ACPI always includes PNPACPI. > > Cc: David Brownell <[EMAIL PROTECTED]> > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 18:47, David Brownell wrote:
> On Wednesday 14 February 2007 3:20 pm, Len Brown wrote:
> > >
> > > I still need to resubmit the patch, for X86_PC, which defines the platform
> > > device in the (common) case where PNPACPI isn't defined.
> >
> > CONFIG_PNPACPI=y is not the common case?
>
> It's certainly not in the defconfig for x86-64. And it's only been
> three weeks since the CONFIG_EXPERIMENTAL dependency got removed.
>
> So, no I would not think it's the common case.
Turns out that it is common.
It is in i386 defconfig, ships on i386 Fedora Core 6, ships on i386 OpenSuse
10.2.
For x86_64 it isn't in defconfig or OpenSuse 10.2, but is in Fedora Core 6.
So I've taken Andi's advice and checked in the patches below.
(I didn't bother updating defconfig, it will generate according to this rule
and I don't want to conflict with any re-generation andi might be checking in)
thanks,
-Len
commit 243b66e76ab722cdec1921d7f80c0cb808131c37
Author: Len Brown <[EMAIL PROTECTED]>
Date: Thu Feb 15 22:34:36 2007 -0500
ACPI: always enable CONFIG_PNPACPI on CONFIG_ACPI kernels
We removed the ACPI motherboard driver which handled
the ACPI=y, PNP=n case, so now we need to enforce that
PNP & PNPACPI are always enabled for ACPI kernels.
Most major distros ship this way this already.
Cc: Bjorn Helgaas <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 20eacc2..2d21fed 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -13,6 +13,7 @@ config ACPI
depends on IA64 || X86
depends on PCI
depends on PM
+ select PNP
default y
---help---
Advanced Configuration and Power Interface (ACPI) support for
diff --git a/drivers/pnp/pnpacpi/Kconfig b/drivers/pnp/pnpacpi/Kconfig
index ad27e5e..b04767c 100644
--- a/drivers/pnp/pnpacpi/Kconfig
+++ b/drivers/pnp/pnpacpi/Kconfig
@@ -2,17 +2,5 @@
# Plug and Play ACPI configuration
#
config PNPACPI
- bool "Plug and Play ACPI support"
- depends on PNP && ACPI
- default y
- ---help---
- Linux uses the PNPACPI to autodetect built-in
- mainboard resources (e.g. parallel port resources).
-
- Some features (e.g. real hotplug) are not currently
- implemented.
-
- If you would like the kernel to detect and allocate resources to
- your mainboard devices (on some systems they are disabled by the
- BIOS) say Y here. Also the PNPACPI can help prevent resource
- conflicts between mainboard devices and other bus devices.
+ bool
+ default (PNP && ACPI)
commit 8d4956c201c2f7683289f70095443c59a39f94ef
Author: Len Brown <[EMAIL PROTECTED]>
Date: Thu Feb 15 22:46:42 2007 -0500
ACPI: remove non-PNPACPI version of get_rtc_dev()
It isn't needed in ACPI code anymore because
now ACPI always includes PNPACPI.
Cc: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 9950087..4334c20 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -255,8 +255,6 @@ arch_initcall(init_acpi_device_notify);
static struct cmos_rtc_board_info rtc_info;
-#ifdef CONFIG_PNPACPI
-
/* PNP devices are registered in a subsys_initcall();
* ACPI specifies the PNP IDs to use.
*/
@@ -280,31 +278,6 @@ static struct device *__init get_rtc_dev(void)
return bus_find_device(_bus_type, NULL, NULL, pnp_match);
}
-#else
-
-/* We expect non-PNPACPI platforms to register an RTC device, usually
- * at or near arch_initcall(). That also helps for example PCs that
- * aren't configured with ACPI (where this code wouldn't run, but the
- * RTC would still be available). The device name matches the driver;
- * that's how the platform bus works.
- */
-#include
-
-static int __init platform_match(struct device *dev, void *data)
-{
- struct platform_device *pdev;
-
- pdev = container_of(dev, struct platform_device, dev);
- return strcmp(pdev->name, "rtc_cmos") == 0;
-}
-
-static struct device *__init get_rtc_dev(void)
-{
- return bus_find_device(_bus_type, NULL, NULL, platform_match);
-}
-
-#endif
-
static int __init acpi_rtc_init(void)
{
struct device *dev = get_rtc_dev();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 18:47, David Brownell wrote:
On Wednesday 14 February 2007 3:20 pm, Len Brown wrote:
I still need to resubmit the patch, for X86_PC, which defines the platform
device in the (common) case where PNPACPI isn't defined.
CONFIG_PNPACPI=y is not the common case?
It's certainly not in the defconfig for x86-64. And it's only been
three weeks since the CONFIG_EXPERIMENTAL dependency got removed.
So, no I would not think it's the common case.
Turns out that it is common.
It is in i386 defconfig, ships on i386 Fedora Core 6, ships on i386 OpenSuse
10.2.
For x86_64 it isn't in defconfig or OpenSuse 10.2, but is in Fedora Core 6.
So I've taken Andi's advice and checked in the patches below.
(I didn't bother updating defconfig, it will generate according to this rule
and I don't want to conflict with any re-generation andi might be checking in)
thanks,
-Len
commit 243b66e76ab722cdec1921d7f80c0cb808131c37
Author: Len Brown [EMAIL PROTECTED]
Date: Thu Feb 15 22:34:36 2007 -0500
ACPI: always enable CONFIG_PNPACPI on CONFIG_ACPI kernels
We removed the ACPI motherboard driver which handled
the ACPI=y, PNP=n case, so now we need to enforce that
PNP PNPACPI are always enabled for ACPI kernels.
Most major distros ship this way this already.
Cc: Bjorn Helgaas [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 20eacc2..2d21fed 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -13,6 +13,7 @@ config ACPI
depends on IA64 || X86
depends on PCI
depends on PM
+ select PNP
default y
---help---
Advanced Configuration and Power Interface (ACPI) support for
diff --git a/drivers/pnp/pnpacpi/Kconfig b/drivers/pnp/pnpacpi/Kconfig
index ad27e5e..b04767c 100644
--- a/drivers/pnp/pnpacpi/Kconfig
+++ b/drivers/pnp/pnpacpi/Kconfig
@@ -2,17 +2,5 @@
# Plug and Play ACPI configuration
#
config PNPACPI
- bool Plug and Play ACPI support
- depends on PNP ACPI
- default y
- ---help---
- Linux uses the PNPACPI to autodetect built-in
- mainboard resources (e.g. parallel port resources).
-
- Some features (e.g. real hotplug) are not currently
- implemented.
-
- If you would like the kernel to detect and allocate resources to
- your mainboard devices (on some systems they are disabled by the
- BIOS) say Y here. Also the PNPACPI can help prevent resource
- conflicts between mainboard devices and other bus devices.
+ bool
+ default (PNP ACPI)
commit 8d4956c201c2f7683289f70095443c59a39f94ef
Author: Len Brown [EMAIL PROTECTED]
Date: Thu Feb 15 22:46:42 2007 -0500
ACPI: remove non-PNPACPI version of get_rtc_dev()
It isn't needed in ACPI code anymore because
now ACPI always includes PNPACPI.
Cc: David Brownell [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 9950087..4334c20 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -255,8 +255,6 @@ arch_initcall(init_acpi_device_notify);
static struct cmos_rtc_board_info rtc_info;
-#ifdef CONFIG_PNPACPI
-
/* PNP devices are registered in a subsys_initcall();
* ACPI specifies the PNP IDs to use.
*/
@@ -280,31 +278,6 @@ static struct device *__init get_rtc_dev(void)
return bus_find_device(pnp_bus_type, NULL, NULL, pnp_match);
}
-#else
-
-/* We expect non-PNPACPI platforms to register an RTC device, usually
- * at or near arch_initcall(). That also helps for example PCs that
- * aren't configured with ACPI (where this code wouldn't run, but the
- * RTC would still be available). The device name matches the driver;
- * that's how the platform bus works.
- */
-#include linux/platform_device.h
-
-static int __init platform_match(struct device *dev, void *data)
-{
- struct platform_device *pdev;
-
- pdev = container_of(dev, struct platform_device, dev);
- return strcmp(pdev-name, rtc_cmos) == 0;
-}
-
-static struct device *__init get_rtc_dev(void)
-{
- return bus_find_device(platform_bus_type, NULL, NULL, platform_match);
-}
-
-#endif
-
static int __init acpi_rtc_init(void)
{
struct device *dev = get_rtc_dev();
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Thursday 15 February 2007 8:38 pm, Len Brown wrote: So I've taken Andi's advice and checked in the patches below. OK; that simplifies things for me, good! I can discard that patch (broken by Andi's pcspkr change anyway), stop worring about whether most folk will even see that driver, and make time to look at the ACPI hooks for RTC wakeup, instead. :) But it would be nice to see the PNP bus infrastructure upgraded in various ways too, now that its availability is less iffy. - Add something analagous to platform_driver_probe() so that the init code can be removed after it runs. - Add shutdown() calls to the PNP bus. Otherwise e.g. one must use shutdown notifiers for PNP interfaces, while normal driver model code works for other interfaces to such hardware. Transitioning from legacy drivers to PNP (for PCs) and platform_bus (other platforms) is a bit awkward because of differences like those. Drivers still need too many different modes; it's too complicated to have a core with different bus glues as thin veneers ... the glue must be thicker (and thus error prone). Similarly, I/O space resource reservation acts differently. I can hope that having PNPACPI be more common will start nudging more drivers to get rid of their legacy modes, or at least focus on Real Driver modes that don't involve poking at hardware and hoping it doesn't bite back. ;) - Dave commit 243b66e76ab722cdec1921d7f80c0cb808131c37 Author: Len Brown [EMAIL PROTECTED] Date: Thu Feb 15 22:34:36 2007 -0500 ACPI: always enable CONFIG_PNPACPI on CONFIG_ACPI kernels We removed the ACPI motherboard driver which handled the ACPI=y, PNP=n case, so now we need to enforce that PNP PNPACPI are always enabled for ACPI kernels. Most major distros ship this way this already. Cc: Bjorn Helgaas [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] commit 8d4956c201c2f7683289f70095443c59a39f94ef Author: Len Brown [EMAIL PROTECTED] Date: Thu Feb 15 22:46:42 2007 -0500 ACPI: remove non-PNPACPI version of get_rtc_dev() It isn't needed in ACPI code anymore because now ACPI always includes PNPACPI. Cc: David Brownell [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 3:20 pm, Len Brown wrote: > > > > I still need to resubmit the patch, for X86_PC, which defines the platform > > device in the (common) case where PNPACPI isn't defined. > > CONFIG_PNPACPI=y is not the common case? It's certainly not in the defconfig for x86-64. And it's only been three weeks since the CONFIG_EXPERIMENTAL dependency got removed. So, no I would not think it's the common case. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 14:55, David Brownell wrote: > On Wednesday 14 February 2007 10:09 am, Dave Jones wrote: > > This option is useful for all of the X86 subarchs afaik (and especially > > X86_GENERICARCH). > > You're right ... _potentially_ useful, which is the same standard used > in most of the other cases. The "X86_PC" is debris from an early version > of this patch, which limited the code to cases where it was known to work. > The X86_PC hardware standard does standardize on this particular RTC, but > non-PC platforms can use it too. > > I still need to resubmit the patch, for X86_PC, which defines the platform > device in the (common) case where PNPACPI isn't defined. CONFIG_PNPACPI=y is not the common case? -Len > Other X86 boards > would need something similar, based on what chips are wired to the CPU. > > > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> > > > > --- linux-2.6.20.noarch/drivers/rtc/Kconfig~2007-02-14 > > 13:07:07.0 -0500 > > +++ linux-2.6.20.noarch/drivers/rtc/Kconfig 2007-02-14 13:07:13.0 > > -0500 > > @@ -101,7 +101,7 @@ comment "RTC drivers" > > > > config RTC_DRV_CMOS > > tristate "PC-style 'CMOS' real time clock" > > - depends on RTC_CLASS && (X86_PC || ALPHA || ARM26 || ARM \ > > + depends on RTC_CLASS && (X86 || ALPHA || ARM26 || ARM \ > > || M32R || ATARI || POWERPC) > > help > > Say "yes" here to get direct support for the real time clock > > > > -- > > http://www.codemonkey.org.uk > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 10:09 am, Dave Jones wrote: > This option is useful for all of the X86 subarchs afaik (and especially > X86_GENERICARCH). You're right ... _potentially_ useful, which is the same standard used in most of the other cases. The "X86_PC" is debris from an early version of this patch, which limited the code to cases where it was known to work. The X86_PC hardware standard does standardize on this particular RTC, but non-PC platforms can use it too. I still need to resubmit the patch, for X86_PC, which defines the platform device in the (common) case where PNPACPI isn't defined. Other X86 boards would need something similar, based on what chips are wired to the CPU. > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> Signed-off-by: David Brownell <[EMAIL PROTECTED]> > --- linux-2.6.20.noarch/drivers/rtc/Kconfig~ 2007-02-14 13:07:07.0 > -0500 > +++ linux-2.6.20.noarch/drivers/rtc/Kconfig 2007-02-14 13:07:13.0 > -0500 > @@ -101,7 +101,7 @@ comment "RTC drivers" > > config RTC_DRV_CMOS > tristate "PC-style 'CMOS' real time clock" > - depends on RTC_CLASS && (X86_PC || ALPHA || ARM26 || ARM \ > + depends on RTC_CLASS && (X86 || ALPHA || ARM26 || ARM \ > || M32R || ATARI || POWERPC) > help > Say "yes" here to get direct support for the real time clock > > -- > http://www.codemonkey.org.uk > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 10:09 am, Dave Jones wrote: This option is useful for all of the X86 subarchs afaik (and especially X86_GENERICARCH). You're right ... _potentially_ useful, which is the same standard used in most of the other cases. The X86_PC is debris from an early version of this patch, which limited the code to cases where it was known to work. The X86_PC hardware standard does standardize on this particular RTC, but non-PC platforms can use it too. I still need to resubmit the patch, for X86_PC, which defines the platform device in the (common) case where PNPACPI isn't defined. Other X86 boards would need something similar, based on what chips are wired to the CPU. Signed-off-by: Dave Jones [EMAIL PROTECTED] Signed-off-by: David Brownell [EMAIL PROTECTED] --- linux-2.6.20.noarch/drivers/rtc/Kconfig~ 2007-02-14 13:07:07.0 -0500 +++ linux-2.6.20.noarch/drivers/rtc/Kconfig 2007-02-14 13:07:13.0 -0500 @@ -101,7 +101,7 @@ comment RTC drivers config RTC_DRV_CMOS tristate PC-style 'CMOS' real time clock - depends on RTC_CLASS (X86_PC || ALPHA || ARM26 || ARM \ + depends on RTC_CLASS (X86 || ALPHA || ARM26 || ARM \ || M32R || ATARI || POWERPC) help Say yes here to get direct support for the real time clock -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 14:55, David Brownell wrote: On Wednesday 14 February 2007 10:09 am, Dave Jones wrote: This option is useful for all of the X86 subarchs afaik (and especially X86_GENERICARCH). You're right ... _potentially_ useful, which is the same standard used in most of the other cases. The X86_PC is debris from an early version of this patch, which limited the code to cases where it was known to work. The X86_PC hardware standard does standardize on this particular RTC, but non-PC platforms can use it too. I still need to resubmit the patch, for X86_PC, which defines the platform device in the (common) case where PNPACPI isn't defined. CONFIG_PNPACPI=y is not the common case? -Len Other X86 boards would need something similar, based on what chips are wired to the CPU. Signed-off-by: Dave Jones [EMAIL PROTECTED] Signed-off-by: David Brownell [EMAIL PROTECTED] --- linux-2.6.20.noarch/drivers/rtc/Kconfig~2007-02-14 13:07:07.0 -0500 +++ linux-2.6.20.noarch/drivers/rtc/Kconfig 2007-02-14 13:07:13.0 -0500 @@ -101,7 +101,7 @@ comment RTC drivers config RTC_DRV_CMOS tristate PC-style 'CMOS' real time clock - depends on RTC_CLASS (X86_PC || ALPHA || ARM26 || ARM \ + depends on RTC_CLASS (X86 || ALPHA || ARM26 || ARM \ || M32R || ATARI || POWERPC) help Say yes here to get direct support for the real time clock -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loosen dependancy on rtc cmos
On Wednesday 14 February 2007 3:20 pm, Len Brown wrote: I still need to resubmit the patch, for X86_PC, which defines the platform device in the (common) case where PNPACPI isn't defined. CONFIG_PNPACPI=y is not the common case? It's certainly not in the defconfig for x86-64. And it's only been three weeks since the CONFIG_EXPERIMENTAL dependency got removed. So, no I would not think it's the common case. - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
