Hi, All
I am reading Linux Kernel's IOAPIC Init routine recently and I found that Linux
2.6.17 Kernel's APIC_init_uniprocessor() routine doesn't use ACPI table's MADT
but instead will try to locate MP table. If the MP table is not there, the init
routine will simply exit. This is something
On Wed, 2006-08-02 at 22:49 +0400, Alexey Starikovskiy wrote:
I was referring to this peace of artwork(asus_info is pointer to DSDT header):
--
if (hotk-model == END_MODEL) { /* match failed */
Hi Pavel,
I guess we never felt any need for an infrastructure, else we would
have created it. I have no idea what the input infrastructure looks
like so I can't compare. If you have something to propose which would
refactor some code amongst the hardware monitoring drivers or would
Hi,
I tried out the patch Bjorn sent some days ago to autoload ACPI modules
via udev. The attached patch is based on latest test tree and includes
Bjorn's code. This works, but is not nice.
I had to tweak pnp to:
- also register ACPI devices which have no _CRS func
- allow (one byte longer)
On Thursday 03 August 2006 09:25, Thomas Renninger wrote:
I tried out the patch Bjorn sent some days ago to autoload ACPI modules
via udev. The attached patch is based on latest test tree and includes
Bjorn's code. This works, but is not nice.
I had to tweak pnp to:
- also register ACPI
Patched against latest test tree.
Compile and field tested.
Check battery after resume
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
drivers/acpi/battery.c | 33 -
1 files changed, 32 insertions(+), 1 deletion(-)
Index:
On Thu, Aug 03, 2006 at 07:17:37PM +0200, Thomas Renninger wrote:
+/*
+ * returns:
+ * 0 on success
+ * 0 on failure
+ * 1 if new battery found
+ * 2 if battery got removed
+ */
Why make this so complicated...
+result = acpi_battery_check(battery);
+if (result
On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
On Thu, Aug 03, 2006 at 12:36:00PM -0700, Greg Kroah-Hartman wrote:
That is good to know. But there is a kernel option which doesn't make
much sense in that case:
[*] Select only drivers that don't need compile-time
On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
ACPI_CUSTOM_DSDT seems to be the most interesting case.
It's anyway not usable for distribution kernels, and AFAIR the ACPI
people prefer to get the kernel working with all original DSDTs
(which usually work with at least one other
On Thu, Aug 03, 2006 at 01:28:07PM -0700, Greg Kroah-Hartman wrote:
On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
ACPI_CUSTOM_DSDT seems to be the most interesting case.
It's anyway not usable for distribution kernels, and AFAIR the ACPI
people prefer to get the kernel
On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
ACPI_CUSTOM_DSDT seems to be the most interesting case.
It's anyway not usable for distribution kernels, and AFAIR the ACPI
people prefer to get the kernel working with all original DSDTs
(which usually work with at least one other
On Thu, Aug 03, 2006 at 04:49:08PM -0400, Brown, Len wrote:
I've advised SuSE many times that they should not be shipping it,
as it means that their supported OS is running on modified firmware --
which, by definition, they can not support. Indeed, one could view
this method as
On Thu, Aug 03, 2006 at 01:51:27PM -0700, Greg Kroah-Hartman wrote:
On Thu, Aug 03, 2006 at 04:49:08PM -0400, Brown, Len wrote:
I've advised SuSE many times that they should not be shipping it,
as it means that their supported OS is running on modified firmware --
which, by definition,
On Thu, 3 Aug 2006, Adrian Bunk wrote:
On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
You're describing PREVENT_FIRMWARE_BUILD. The text Zach quoted is from
STANDALONE, which is something else completely. That allows us to not
build drivers that pull in things from /etc and
14 matches
Mail list logo
