[RFC] Include ACPI DSDT from INITRD patch into mainline

[RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

I'd be willing to bet that most distros have this patch in their kernel.
One of those things we can't really live without.

What I haven't understood is why it isn't included in the mainline
kernel yet. There's enough kernel hackers out there using this that I
doubt it will get stale or broken for very long.

I'm willing to do the grunt work to get it suitable.

Patch attached for convenience.

diff -urpN -X linux-2.6.18/Documentation/dontdiff linux-2.6.18.bak/Documentation/dsdt-initrd.txt linux-2.6.18/Documentation/dsdt-initrd.txt
--- linux-2.6.18.bak/Documentation/dsdt-initrd.txt	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.18/Documentation/dsdt-initrd.txt	2006-08-12 11:15:13.000000000 +0200
@@ -0,0 +1,98 @@
+ACPI Custom DSDT read from initramfs
+
+2003 by Markuss Gaugusch < dsdt at gaugusch dot org >
+Special thanks go to Thomas Renninger from SuSE, who updated the patch for
+2.6.0 and later modified it to read inside initramfs
+2004 - 2006 maintained by Eric Piel < eric dot piel at tremplin-utc dot net >
+
+This option is intended for people who would like to hack their DSDT and don't want
+to recompile their kernel after every change. It can also be useful to distros
+which offers pre-compiled kernels and want to allow their users to use a
+modified DSDT. In the Kernel config, enable the initial RAM filesystem support
+(in Device Drivers|Block Devices) and enable ACPI_CUSTOM_DSDT_INITRD at the ACPI
+options (General Setup|ACPI Support|Read custom DSDT from initrd).
+
+A custom DSDT (Differentiated System Description Table) is useful when your
+computer uses ACPI but problems occur due to broken implementation. Typically,
+your computer works but there are some troubles with the hardware detection or
+the power management. You can check that troubles come from errors in the DSDT by
+activating the ACPI debug option and reading the logs. This table is provided
+by the BIOS, therefore it might be a good idea to check for BIOS update on your
+vendor website before going any further. Errors are often caused by vendors
+testing their hardware only with Windows or because there is code which is
+executed only on a specific OS with a specific version and Linux hasn't been
+considered during the development.
+
+Before you run away from customising your DSDT, you should note that already
+corrected tables are available for a fair amount of computers on this web-page:
+http://acpi.sf.net/dsdt . If you are part of the unluckies who cannot find
+their hardware in this database, you can modify your DSDT by yourself. This
+process is less painful than it sounds. Download the Intel ASL 
+compiler/decompiler at http://www.intel.com/technology/IAPC/acpi/downloads.htm .
+As root, you then have to dump your DSDT and decompile it. By using the
+compiler messages as well as the kernel ACPI debug messages and the reference book
+(available at the Intel website and also at http://www.acpi.info), it is quite
+easy to obtain a fully working table.
+
+Once your new DSDT is ready you'll have to add it to an initrd so that the
+kernel can read the table at the very beginning of the boot. As the file has
+to be accessed very early during the boot process the initrd has to be an
+initramfs. The file is contained into the initramfs under the name /DSDT.aml .
+To obtain such an initrd, you might have to modify your mkinitrd script or you
+can add it later to the initrd with the script appended to this document. The
+command will look like:
+initrd-add-dsdt initrd.img my-dsdt.aml
+
+In case you don't use any initrd, the possibilities you have are to either start
+using one (try mkinitrd or yaird), or use the "Include Custom DSDT" configure
+option to directly include your DSDT inside the kernel.
+
+The message "Looking for DSDT in initramfs..." will tell you if the DSDT was
+found or not. If you need to update your DSDT, generate a new initrd and
+perform the steps above. Don't forget that with Lilo, you'll have to re-run it.
+
+
+======================= Here starts initrd-add-dsdt ===============================
+#!/bin/bash
+# Adds a DSDT file to the initrd (if it's an initramfs)
+# first argument is the name of archive
+# second argurment is the name of the file to add
+# The file will be copied as /DSDT.aml
+
+# 20060126: fix "Premature end of file" with some old cpio (Roland Robic)
+# 20060205: this time it should really work
+
+# check the arguments
+if [ $# -ne 2 ]; then
+	program_name=$(basename $0)
+	echo "\
+$program_name: too few arguments
+Usage: $program_name initrd-name.img DSDT-to-add.aml
+Adds a DSDT file to an initrd (in initramfs format)
+
+  initrd-name.img: filename of the initrd in initramfs format
+  DSDT-to-add.aml: filename of the DSDT file to add
+  " 1>&2
+    exit 1
+fi
+
+# we should check it's an initramfs
+
+tempcpio=$(mktemp -d)
+# cleanup on exit, hangup, interrupt, quit, termination
+trap 'rm -rf $tempcpio' 0 1 2 3 15
+
+# extract the archive
+gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1
+
+# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml"
+cp -f "$2" "$tempcpio"/DSDT.aml
+
+# add the file
+cd "$tempcpio"
+(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1
+cd "$OLDPWD"
+
+# re-compress the archive
+gzip -c "$tempcpio"/initramfs.cpio > "$1"
+
diff -urpN -X linux-2.6.18/Documentation/dontdiff linux-2.6.18.bak/drivers/acpi/Kconfig linux-2.6.18/drivers/acpi/Kconfig
--- linux-2.6.18.bak/drivers/acpi/Kconfig	2006-08-12 11:14:05.000000000 +0200
+++ linux-2.6.18/drivers/acpi/Kconfig	2006-08-12 11:15:13.000000000 +0200
@@ -264,6 +264,23 @@ config ACPI_CUSTOM_DSDT_FILE
 	  Enter the full path name to the file which includes the AmlCode
 	  declaration.
 
+config ACPI_CUSTOM_DSDT_INITRD
+	bool "Read Custom DSDT from initramfs"
+	depends on BLK_DEV_INITRD
+	default y
+	help
+	  The DSDT (Differentiated System Description Table) often needs to be
+	  overridden because of broken BIOS implementations. If this feature is
+	  activated you will be able to provide a customized DSDT by adding it
+	  to your initramfs.  For now you need to use a special mkinitrd tool.
+	  For more details see <file:Documentation/dsdt-initrd.txt> or 
+	  <http://gaugusch.at/kernel.shtml>. If there is no table found, it 
+	  will fallback to the custom DSDT in-kernel (if activated) or to the
+	  DSDT from the BIOS.
+
+	  Even if you do not need a new one at the moment, you may want to use a
+	  better implemented DSDT later. It is safe to say Y here.
+
 config ACPI_BLACKLIST_YEAR
 	int "Disable ACPI for systems before Jan 1st this year" if X86_32
 	default 0
diff -urpN -X linux-2.6.18/Documentation/dontdiff linux-2.6.18.bak/drivers/acpi/osl.c linux-2.6.18/drivers/acpi/osl.c
--- linux-2.6.18.bak/drivers/acpi/osl.c	2006-08-12 11:14:05.000000000 +0200
+++ linux-2.6.18/drivers/acpi/osl.c	2006-08-12 11:16:08.000000000 +0200
@@ -69,6 +69,10 @@ extern char line_buf[80];
 int acpi_specific_hotkey_enabled = TRUE;
 EXPORT_SYMBOL(acpi_specific_hotkey_enabled);
 
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+int acpi_must_unregister_table = FALSE;
+#endif
+
 static unsigned int acpi_irq_irq;
 static acpi_osd_handler acpi_irq_handler;
 static void *acpi_irq_context;
@@ -219,6 +223,67 @@ acpi_os_predefined_override(const struct
 	return AE_OK;
 }
 
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+struct acpi_table_header * acpi_find_dsdt_initrd(void)
+{
+	struct file *firmware_file;
+	mm_segment_t oldfs;
+	unsigned long len, len2;
+	struct acpi_table_header *dsdt_buffer, *ret = NULL;
+	struct kstat stat;
+	/* maybe this could be an argument on the cmd line, but let's keep it simple for now */
+	char *ramfs_dsdt_name = "/DSDT.aml";
+
+	printk(KERN_INFO PREFIX "Looking for DSDT in initramfs... ");
+
+	/* 
+	 * Never do this at home, only the user-space is allowed to open a file.
+	 * The clean way would be to use the firmware loader. But this code must be run
+	 * before there is any userspace available. So we need a static/init firmware 
+	 * infrastructure, which doesn't exist yet...
+	 */
+	if (vfs_stat(ramfs_dsdt_name, &stat) < 0) {
+		printk("error, file %s not found.\n", ramfs_dsdt_name);
+		return ret;
+	}
+
+	len = stat.size;
+	/* check especially against empty files */
+	if (len <= 4) {
+		printk("error file is too small, only %lu bytes.\n", len);
+		return ret;
+	}
+
+	firmware_file = filp_open(ramfs_dsdt_name, O_RDONLY, 0);
+	if (IS_ERR(firmware_file)) {
+		printk("error, could not open file %s.\n", ramfs_dsdt_name);
+		return ret;
+	}
+
+	dsdt_buffer = ACPI_ALLOCATE(len);
+	if (!dsdt_buffer) {
+		printk("error when allocating %lu bytes of memory.\n", len);
+		goto err;
+	}
+
+	oldfs = get_fs();
+	set_fs(KERNEL_DS);
+	len2 = vfs_read(firmware_file, (char __user *)dsdt_buffer, len, &firmware_file->f_pos);
+	set_fs(oldfs);
+	if (len2 < len) {
+		printk("error trying to read %lu bytes from %s.\n", len, ramfs_dsdt_name);
+		ACPI_FREE(dsdt_buffer);
+		goto err;
+	}
+
+	printk("successfully read %lu bytes from %s.\n", len, ramfs_dsdt_name);
+	ret = dsdt_buffer;
+err:
+	filp_close(firmware_file, NULL);
+	return ret;
+}
+#endif
+
 acpi_status
 acpi_os_table_override(struct acpi_table_header * existing_table,
 		       struct acpi_table_header ** new_table)
@@ -226,13 +291,20 @@ acpi_os_table_override(struct acpi_table
 	if (!existing_table || !new_table)
 		return AE_BAD_PARAMETER;
 
+	*new_table = NULL;
+
 #ifdef CONFIG_ACPI_CUSTOM_DSDT
 	if (strncmp(existing_table->signature, "DSDT", 4) == 0)
 		*new_table = (struct acpi_table_header *)AmlCode;
-	else
-		*new_table = NULL;
-#else
-	*new_table = NULL;
+#endif
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+	if (strncmp(existing_table->signature, "DSDT", 4) == 0) {
+		struct acpi_table_header* initrd_table = acpi_find_dsdt_initrd();
+		if (initrd_table) {
+			*new_table = initrd_table;
+			acpi_must_unregister_table = TRUE;
+		}
+	}
 #endif
 	return AE_OK;
 }
diff -urpN -X linux-2.6.18/Documentation/dontdiff linux-2.6.18.bak/drivers/acpi/tables/tbget.c linux-2.6.18/drivers/acpi/tables/tbget.c
--- linux-2.6.18.bak/drivers/acpi/tables/tbget.c	2006-08-12 11:14:05.000000000 +0200
+++ linux-2.6.18/drivers/acpi/tables/tbget.c	2006-08-12 11:15:27.000000000 +0200
@@ -278,6 +278,14 @@ acpi_tb_table_override(struct acpi_table
 	address.pointer.logical = new_table;
 
 	status = acpi_tb_get_this_table(&address, new_table, table_info);
+
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+	if (acpi_must_unregister_table) {
+		ACPI_FREE(new_table);
+		acpi_must_unregister_table = FALSE;
+	}
+#endif
+
 	if (ACPI_FAILURE(status)) {
 		ACPI_EXCEPTION((AE_INFO, status, "Could not copy ACPI table"));
 		return_ACPI_STATUS(status);
diff -urpN -X linux-2.6.18/Documentation/dontdiff linux-2.6.18.bak/include/acpi/acpiosxf.h linux-2.6.18/include/acpi/acpiosxf.h
--- linux-2.6.18.bak/include/acpi/acpiosxf.h	2006-08-12 11:14:05.000000000 +0200
+++ linux-2.6.18/include/acpi/acpiosxf.h	2006-08-12 11:15:13.000000000 +0200
@@ -95,6 +95,10 @@ acpi_status
 acpi_os_table_override(struct acpi_table_header *existing_table,
 		       struct acpi_table_header **new_table);
 
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+extern int acpi_must_unregister_table;
+#endif
+
 /*
  * Spinlock primitives
  */
diff -urpN -X linux-2.6.18/Documentation/dontdiff linux-2.6.18.bak/init/main.c linux-2.6.18/init/main.c
--- linux-2.6.18.bak/init/main.c	2006-08-12 11:14:05.000000000 +0200
+++ linux-2.6.18/init/main.c	2006-08-12 11:15:13.000000000 +0200
@@ -581,8 +581,6 @@ asmlinkage void __init start_kernel(void
 
 	check_bugs();
 
-	acpi_early_init(); /* before LAPIC and SMP init */
-
 	/* Do the rest non-__init'ed, we're now alive */
 	rest_init();
 }
@@ -699,6 +697,14 @@ static int init(void * unused)
 	 */
 	child_reaper = current;
 
+ 	/*
+ 	 * Do this before initcalls, because some drivers want to access
+ 	 * firmware files.
+ 	 */
+ 	populate_rootfs();
+ 
+ 	acpi_early_init(); /* before LAPIC and SMP init */
+
 	smp_prepare_cpus(max_cpus);
 
 	do_pre_smp_initcalls();
@@ -708,12 +714,6 @@ static int init(void * unused)
 
 	cpuset_init_smp();
 
-	/*
-	 * Do this before initcalls, because some drivers want to access
-	 * firmware files.
-	 */
-	populate_rootfs();
-
 	do_basic_setup();
 
 	/*

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Alan]

On Fri, 01 Dec 2006 13:36:19 -0500
Ben Collins <ben.collins@ubuntu.com> wrote:

> I'd be willing to bet that most distros have this patch in their kernel.
> One of those things we can't really live without.

This has been suggested various times before. 

| +Before you run away from customising your DSDT, you should note that
| already +corrected tables are available for a fair amount of computers
| on this web-page: +http://acpi.sf.net/dsdt

Generally without copyright permission from the owner of the copyrighted
work in question to have it modified and redistributed.

The whole approach of using filp_open() not the firmware interface
is horribly ugly and does not belong mainstream. 

Alan

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 18:56 +0000, Alan wrote:
> On Fri, 01 Dec 2006 13:36:19 -0500
> Ben Collins <ben.collins@ubuntu.com> wrote:
> 
> > I'd be willing to bet that most distros have this patch in their kernel.
> > One of those things we can't really live without.
> 
> This has been suggested various times before. 
> 
> | +Before you run away from customising your DSDT, you should note that
> | already +corrected tables are available for a fair amount of computers
> | on this web-page: +http://acpi.sf.net/dsdt
> 
> Generally without copyright permission from the owner of the copyrighted
> work in question to have it modified and redistributed.
> 
> The whole approach of using filp_open() not the firmware interface
> is horribly ugly and does not belong mainstream. 

What about the point that userspace (udev, and such) is not available
when DSDT loading needs to occur? Init hasn't even started at that
point.

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Arjan van de Ven]

On Fri, 2006-12-01 at 14:35 -0500, Ben Collins wrote:
> What about the point that userspace (udev, and such) is not available
> when DSDT loading needs to occur? Init hasn't even started at that
> point.

that's a moot point; you need to load firmware from the initramfs ANYWAY
for things like qlogic and others...




-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Alan]

> > The whole approach of using filp_open() not the firmware interface
> > is horribly ugly and does not belong mainstream. 
> 
> What about the point that userspace (udev, and such) is not available
> when DSDT loading needs to occur? Init hasn't even started at that
> point.

Does that change the fact it is ugly ?

Alan

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 19:53 +0000, Alan wrote:
> > > The whole approach of using filp_open() not the firmware interface
> > > is horribly ugly and does not belong mainstream. 
> > 
> > What about the point that userspace (udev, and such) is not available
> > when DSDT loading needs to occur? Init hasn't even started at that
> > point.
> 
> Does that change the fact it is ugly ?

No, but it does beg the question "how else can it be done"?

Distros need a way for users to add a fixed DSDT without recompiling
their own kernels.

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 20:45 +0100, Arjan van de Ven wrote:
> On Fri, 2006-12-01 at 14:35 -0500, Ben Collins wrote:
> > What about the point that userspace (udev, and such) is not available
> > when DSDT loading needs to occur? Init hasn't even started at that
> > point.
> 
> that's a moot point; you need to load firmware from the initramfs ANYWAY
> for things like qlogic and others...

I don't see how that relates. The DSDT needs to be loaded even before
driver initialization begins. Things like qlogic can over come this by
being compiled as modules, and letting initramfs-tools take care of
things.

That's not the case for DSDT loading. I'm not saying this patch is the
epitome of good coding, just that it's a needed feature.

If there's a better way to do it, I'm volunteering to do the grunt work,
but I haven't heard of any alternatives to this solution.

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Arjan van de Ven]

On Fri, 2006-12-01 at 16:01 -0500, Ben Collins wrote:
> On Fri, 2006-12-01 at 20:45 +0100, Arjan van de Ven wrote:
> > On Fri, 2006-12-01 at 14:35 -0500, Ben Collins wrote:
> > > What about the point that userspace (udev, and such) is not available
> > > when DSDT loading needs to occur? Init hasn't even started at that
> > > point.
> > 
> > that's a moot point; you need to load firmware from the initramfs ANYWAY
> > for things like qlogic and others...
> 
> I don't see how that relates. The DSDT needs to be loaded even before
> driver initialization begins. 

in fact it needs to be loaded even before the ACPI engine starts
executing, otherwise you're hot-replacing code underneath a live
system...  at which point you can do this same feature in another way :)
there already is a feature that builds a dsdt into the kernel image, all
a distro would need is a bit of objcopy magic to build the right one
into the vmlinuz...

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Alan]

> > Does that change the fact it is ugly ?
> 
> No, but it does beg the question "how else can it be done"?

Agreed.
 
> Distros need a way for users to add a fixed DSDT without recompiling
> their own kernels.

Legal rights to do so aside, do they ? and if they do does it have to be
an ugly hack in the mainstream kernel. 

Alan

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Arkadiusz Miskiewicz]

On Friday 01 December 2006 22:55, Alan wrote:
> > > Does that change the fact it is ugly ?
> >
> > No, but it does beg the question "how else can it be done"?
>
> Agreed.

So how else can it be done?

> > Distros need a way for users to add a fixed DSDT without recompiling
> > their own kernels.
>
> Legal rights to do so aside, do they ? 

Acer notebook users here dump DSDT from their own machine, fix it and then 
load via initrd. No legal problems. (... and without that even battery can't 
be monitored on sych notebooks)

> and if they do does it have to be 
> an ugly hack in the mainstream kernel.

Can it be done without hacks somehow (in the way that adding fixed DSDT is 
easy for user)?

> Alan

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Alan]

On Fri, 1 Dec 2006 23:01:20 +0100
Arkadiusz Miskiewicz <arekm@maven.pl> wrote:

> Acer notebook users here dump DSDT from their own machine, fix it and then 
> load via initrd. 

Under EU law thats two copies without permission and modification without
permission of the rights holder....

> > and if they do does it have to be 
> > an ugly hack in the mainstream kernel.
> 
> Can it be done without hacks somehow (in the way that adding fixed DSDT is 
> easy for user)?

Arjan - can you explain the linking dsdt one in more detail ?

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Ben Collins]

On Fri, 2006-12-01 at 22:49 +0100, Arjan van de Ven wrote:
> On Fri, 2006-12-01 at 16:01 -0500, Ben Collins wrote:
> > On Fri, 2006-12-01 at 20:45 +0100, Arjan van de Ven wrote:
> > > On Fri, 2006-12-01 at 14:35 -0500, Ben Collins wrote:
> > > > What about the point that userspace (udev, and such) is not available
> > > > when DSDT loading needs to occur? Init hasn't even started at that
> > > > point.
> > > 
> > > that's a moot point; you need to load firmware from the initramfs ANYWAY
> > > for things like qlogic and others...
> > 
> > I don't see how that relates. The DSDT needs to be loaded even before
> > driver initialization begins. 
> 
> in fact it needs to be loaded even before the ACPI engine starts
> executing, otherwise you're hot-replacing code underneath a live
> system...  at which point you can do this same feature in another way :)
> there already is a feature that builds a dsdt into the kernel image, all
> a distro would need is a bit of objcopy magic to build the right one
> into the vmlinuz...

Providing object files for on-demand relinking of the kernel just adds a
shit load of overhead. If you're suggesting modifying vmlinuz in place
instead, that just seems really undesirable. Last thing I want is
something mucking with the kernel binary.

It's easier for me to keep this patch in my tree, especially since most
users have come to expect this as the "standard" method for inserting
their DSDT replacement.

The only other thing I can think of is grub providing the DSDT just like
it does for the initrd.

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Dave Jones]

On Fri, Dec 01, 2006 at 03:58:14PM -0500, Ben Collins wrote:
 > On Fri, 2006-12-01 at 19:53 +0000, Alan wrote:
 > > > > The whole approach of using filp_open() not the firmware interface
 > > > > is horribly ugly and does not belong mainstream. 
 > > > 
 > > > What about the point that userspace (udev, and such) is not available
 > > > when DSDT loading needs to occur? Init hasn't even started at that
 > > > point.
 > > 
 > > Does that change the fact it is ugly ?
 > 
 > No, but it does beg the question "how else can it be done"?
 > 
 > Distros need a way for users to add a fixed DSDT without recompiling
 > their own kernels.

There already is a way. It's called beating up the braindead bios authors,
and pressuring motherboard vendors to push out updates.

		Dave

-- 
http://www.codemonkey.org.uk

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Arjan van de Ven]

> Providing object files for on-demand relinking of the kernel just adds a
> shit load of overhead. If you're suggesting modifying vmlinuz in place
> instead, that just seems really undesirable. Last thing I want is
> something mucking with the kernel binary.

... while randomly mucking with the bios content is something you do
want? While it's already *running* ? How much do you trust the end user
to himself randomly edit the AML code to force it to compile (usually
it's not more than that)?

> 
> It's easier for me to keep this patch in my tree, especially since most
> users have come to expect this as the "standard" method for inserting
> their DSDT replacement.

now here's another question... the ACPI layer got improved over the last
18 months bigtime to behave more like windows in many ways. How much of
this is still really needed? 

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Arjan van de Ven]

On Fri, 2006-12-01 at 19:21 -0500, Dave Jones wrote:
> On Fri, Dec 01, 2006 at 03:58:14PM -0500, Ben Collins wrote:
>  > On Fri, 2006-12-01 at 19:53 +0000, Alan wrote:
>  > > > > The whole approach of using filp_open() not the firmware interface
>  > > > > is horribly ugly and does not belong mainstream. 
>  > > > 
>  > > > What about the point that userspace (udev, and such) is not available
>  > > > when DSDT loading needs to occur? Init hasn't even started at that
>  > > > point.
>  > > 
>  > > Does that change the fact it is ugly ?
>  > 
>  > No, but it does beg the question "how else can it be done"?
>  > 
>  > Distros need a way for users to add a fixed DSDT without recompiling
>  > their own kernels.
> 
> There already is a way. It's called beating up the braindead bios authors,
> and pressuring motherboard vendors to push out updates.

and it includes pointing them at the linux-ready firmware developer kit
(URL in sig) so that it's really easy for them to test Linux with their
bios. 

If you or anyone else experience bios horkage that's not caught, please
let us know, so that we can add tests....

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Arjan van de Ven]

On Fri, 2006-12-01 at 22:17 +0000, Alan wrote:
> On Fri, 1 Dec 2006 23:01:20 +0100
> Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> 
> > Acer notebook users here dump DSDT from their own machine, fix it and then 
> > load via initrd. 
> 
> Under EU law thats two copies without permission and modification without
> permission of the rights holder....
> 
> > > and if they do does it have to be 
> > > an ugly hack in the mainstream kernel.
> > 
> > Can it be done without hacks somehow (in the way that adding fixed DSDT is 
> > easy for user)?
> 
> Arjan - can you explain the linking dsdt one in more detail ?


 config ACPI_CUSTOM_DSDT
       bool "Include Custom DSDT"
        depends on !STANDALONE
        default n 
        help
          This option is to load a custom ACPI DSDT
          If you don't know what that is, say N.

config ACPI_CUSTOM_DSDT_FILE
        string "Custom DSDT Table file to include"
        depends on ACPI_CUSTOM_DSDT
        default ""
        help
          Enter the full path name to the file which includes the
AmlCode
          declaration.


these allow you to nicely build a DSDT into the kernel, so that it can
be used FROM THE START. Not as some of the hacks do, replacing the DSDT
code while it is running. (would you really want to replace a kernel
modules' code while it's running by some other version of the module? If
the answer is no, why would you want to do it to bios code... )

Now for distro kernels this is somewhat awkward, however that's only a
bit of glue away realistically; stick it in it's own section and objcopy
the right one into the vmlinuz isn't that big a deal....

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Arjan van de Ven]

On Fri, 2006-12-01 at 13:36 -0500, Ben Collins wrote:
> I'd be willing to bet that most distros have this patch in their kernel.
> One of those things we can't really live without.
> 
> What I haven't understood is why it isn't included in the mainline
> kernel yet.

it's not that hard ;)

replacing the DSDT code *while it's live* is just a bad idea. The kernel
already has a facility to override the DSDT, but that one does it *from
the start*. Sounds like that one should be used or maybe enhanced a
little to make it more distro friendly if something is lacking.

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Jan Engelhardt]

>> I'd be willing to bet that most distros have this patch in their kernel.
>> One of those things we can't really live without.
>> 
>> What I haven't understood is why it isn't included in the mainline
>> kernel yet.
>
>it's not that hard ;)
>
>replacing the DSDT code *while it's live* is just a bad idea. The kernel
>already has a facility to override the DSDT, but that one does it *from
>the start*. Sounds like that one should be used or maybe enhanced a
>little to make it more distro friendly if something is lacking.

Speaking of that, would not it be "cleanest" to load the DSDT between 
grub/lilo and the kernel? GRUB can do fs harvesting (lookup) so you 
would not even need to recreate an initrd.


	-`J'
-- 

Acer smart battery (was Re: [RFC] Include ACPI DSDT from INITRD patch into mainline)

[Pavel Machek]

Hi!

> > > > Does that change the fact it is ugly ?
> > >
> > > No, but it does beg the question "how else can it be done"?
> >
> > Agreed.
> 
> So how else can it be done?
> 
> > > Distros need a way for users to add a fixed DSDT without recompiling
> > > their own kernels.
> >
> > Legal rights to do so aside, do they ? 
> 
> Acer notebook users here dump DSDT from their own machine, fix it and then 
> load via initrd. No legal problems. (... and without that even battery can't 
> be monitored on sych notebooks)

Merge smart battery support, instead of hacking DSDT. It is about time
linux started supporting smart batteries, and yes they are documented.

-- 
Thanks for all the (sleeping) penguins.

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Sat, 02 Dec 2006 11:30:32 +0100 Arjan van de Ven wrote:

> On Fri, 2006-12-01 at 13:36 -0500, Ben Collins wrote:
> > I'd be willing to bet that most distros have this patch in their kernel.
> > One of those things we can't really live without.
> >
> > What I haven't understood is why it isn't included in the mainline
> > kernel yet.
>
> it's not that hard ;)
>
> replacing the DSDT code *while it's live* is just a bad idea.

But the suggested patch does not do this.

> The kernel already has a facility to override the DSDT, but that one
> does it *from the start*. Sounds like that one should be used or
> maybe enhanced a little to make it more distro friendly if something
> is lacking.

The patch replaces the DSDT with the binary from initramfs in the same
acpi_os_table_override() function as the currently available
CONFIG_ACPI_CUSTOM_DSDT does:

@@ -226,13 +291,20 @@ acpi_os_table_override(struct acpi_table
 	if (!existing_table || !new_table)
 		return AE_BAD_PARAMETER;

+	*new_table = NULL;
+
 #ifdef CONFIG_ACPI_CUSTOM_DSDT
 	if (strncmp(existing_table->signature, "DSDT", 4) == 0)
 		*new_table = (struct acpi_table_header *)AmlCode;
-	else
-		*new_table = NULL;
-#else
-	*new_table = NULL;
+#endif
+#ifdef CONFIG_ACPI_CUSTOM_DSDT_INITRD
+	if (strncmp(existing_table->signature, "DSDT", 4) == 0) {
+		struct acpi_table_header* initrd_table = acpi_find_dsdt_initrd();
+		if (initrd_table) {
+			*new_table = initrd_table;
+			acpi_must_unregister_table = TRUE;
+		}
+	}
 #endif
 	return AE_OK;
 }

However, this patch slightly changes initialization order of some
kernel parts:

 - The call to populate_rootfs() is moved before calls to
   smp_prepare_cpus(max_cpus), do_pre_smp_initcalls(), smp_init(),
   sched_init_smp() and cpuset_init_smp().

 - The call to acpi_early_init() is moved from start_kernel() (where
   it is done just before rest_init()) to rest_init(), where it is now
   preceded by lock_kernel(), set_cpus_allowed(current, CPU_MASK_ALL),
   child_reaper = current and the moved populate_rootfs().

Not sure if this reordering is safe in theory, but it works for many
users of the patch.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Acer smart battery (was Re: [RFC] Include ACPI DSDT from INITRD patch into mainline)

[Arkadiusz Miskiewicz]

On Saturday 02 December 2006 13:50, Pavel Machek wrote:

> > Acer notebook users here dump DSDT from their own machine, fix it and
> > then load via initrd. No legal problems. (... and without that even
> > battery can't be monitored on sych notebooks)
>
> Merge smart battery support, instead of hacking DSDT. It is about time
> linux started supporting smart batteries, and yes they are documented.
Are you talking about this?
https://sourceforge.net/forum/forum.php?forum_id=604605

It's seem to be already merged and I didn't even know about that feature.
-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: Acer smart battery (was Re: [RFC] Include ACPI DSDT from INITRD patch into mainline)

[Pavel Machek]

On Sat 2006-12-02 18:34:59, Arkadiusz Miskiewicz wrote:
> On Saturday 02 December 2006 13:50, Pavel Machek wrote:
> 
> > > Acer notebook users here dump DSDT from their own machine, fix it and
> > > then load via initrd. No legal problems. (... and without that even
> > > battery can't be monitored on sych notebooks)
> >
> > Merge smart battery support, instead of hacking DSDT. It is about time
> > linux started supporting smart batteries, and yes they are documented.
> Are you talking about this?
> https://sourceforge.net/forum/forum.php?forum_id=604605

Yes.

> It's seem to be already merged and I didn't even know about that
>feature.

Aha, I did not know that. Anyway, it should mean
no-longer-patching-DSDT.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC] Include ACPI DSDT from INITRD patch into mainline

[Stefan Seyfried]

On Sat, Dec 02, 2006 at 08:45:52AM +0100, Arjan van de Ven wrote:

> now here's another question...

And a good one, indeed.

> the ACPI layer got improved over the last
> 18 months bigtime to behave more like windows in many ways. How much of
> this is still really needed? 

I have not used a machine that really needed this for quite some time now.
Usually even DSDTs that do not pass the "disassemble, then recompile with
iasl"-test seem to work much better in practice than they did before.

And seeing what stupid ideas people come up with (sharing DSDTs on
acpi.sf.net _is_ stupid, since the DSDT usually depends on things you
configured in your BIOS settings, memory size, etc.pp) it is probably
a good idea to keep this patch out of mainline.

It is usefull for debugging, sure, but somebody who can debug on this
level should also be able to patch his kernel :-)
-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out."