Bug 15707 - _REG evaluation required while no EC OperationRegion
_REG evaluation required while no EC OperationRegion
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: EC
All Linux
: P1 normal
Assigned To: Zhang Rui
:
: 19602 34532 42628 43156 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-07 08:32 UTC by leon7176@gmail.com
Modified: 2014-10-28 05:12 UTC (History)
23 users (show)

See Also:
Kernel Version: 2.6.32.4
Tree: Mainline
Regression: No


Attachments
dmesg_acpi_parse_error (121.22 KB, application/octet-stream)
2010-04-07 08:32 UTC, leon7176@gmail.com
Details
calpella_dmesg_REG_fail (151.00 KB, application/octet-stream)
2010-04-07 08:40 UTC, leon7176@gmail.com
Details
diff_ec_try_econ.patch (1.58 KB, patch)
2010-04-07 08:47 UTC, leon7176@gmail.com
Details | Diff
DSDT_calpella.dsl (385.11 KB, application/octet-stream)
2010-04-07 09:05 UTC, leon7176@gmail.com
Details
output of grep . /proc/acpi/battery/*/* (173 bytes, text/plain)
2010-12-18 08:48 UTC, monghitri
Details
output of zcat /proc/config.gz | grep ACPI (820 bytes, text/plain)
2010-12-18 09:05 UTC, monghitri
Details
errors in building patched 2.6.35.9 and working 2.6.34.7 /proc/acpi/BAT1/* (2.42 KB, text/plain)
2010-12-20 07:39 UTC, monghitri
Details
execute orphan EC _REG even if ECDT not present (3.67 KB, patch)
2012-11-30 04:55 UTC, Zhang Rui
Details | Diff

Description leon7176@gmail.com 2010-04-07 08:32:58 UTC
Created attachment 25888 [details]
dmesg_acpi_parse_error

Hardware Model (on what HW this bug is uncovered): Calpella platform


Bug detailed descriptions(behavior, impact, etc)
===========================================================
can not get the AC/DC status after system booting up.


Reproduce Steps(steps,current result, reproduce possibility)
===========================================================
(1)Booting up System
(2)Check the power status and AC/DC status always show 0%
(3)Check the dmesg and find ACPI Error as bellow
    ACPI Error (psargs-0359): [\_PR_.CPU0._PPC] Namespace lookup failure,
AE_NOT_FOUND
    ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.ACAD._PSR] (Node f7457798), AE_NOT_FOUND
    ACPI Exception: AE_NOT_FOUND, Error reading AC Adapter state
(20090903/ac-140)


Expected result:
===========================================================
The AC/DC status is relative to Power source.


Possible root cause:
===========================================================
It seems that the ACPI DSDT related or driver issue, but the AC/DC status is normal shown on Windows 7.
Comment 1 leon7176@gmail.com 2010-04-07 08:40:45 UTC
Created attachment 25889 [details]
calpella_dmesg_REG_fail

We do the following steps to collect dmesg
1. Compile the kernel with CONFIG_ACPI_DEGUG=y
2. Add boot opiton: acpi.debug_layer=0x10 acpi.debug_level=0x1f
3. dmeg | grep _REG to check whether _REG is evaluated or not
Comment 2 leon7176@gmail.com 2010-04-07 08:47:16 UTC
Created attachment 25890 [details]
diff_ec_try_econ.patch

we tried to re-evaluate _REG object and assign arguments (assigned 3 to Arg0
and 1 to Arg1) after acpi_ec_register_query_methods.

Then, the result of getting AC/DC status was correct.
Comment 3 Zhang Rui 2010-04-07 08:50:14 UTC
Alexey, this is the EC problem I discussed with you last time.
can you take a look at this please?
Comment 4 leon7176@gmail.com 2010-04-07 09:05:14 UTC
Created attachment 25893 [details]
DSDT_calpella.dsl

The dsdt for the calpella platform
Comment 5 leon7176@gmail.com 2010-04-07 09:06:48 UTC
We found the abnormal about dmesg(https://bugzilla.kernel.org/attachment.cgi?id=25889) as following:

[    0.395830] ACPI: Execute Method [\_SB_.PCI0.P0P2.VGA_._STA] (Node f7450d74)
[    0.396054] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.396131] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.396522] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.396597] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.397619] ACPI: Execute Method [\] (Node c1739030)
[    0.397653]   nseval-0400 [00] ns_exec_module_code   : Executed module-level
code at f821ba6e
[    0.397658] ACPI: Executed 1 blocks of module-level executable AML code
[    0.397662] Completing Region/Field/Buffer/Package
initialization:.............................................................................................................................................................................ACPI:
Execute Method [\_SB_.PCI0._BBN] (Node f744ffa4)
[    0.402026] .............................
[    0.402472] Initialized 48/49 Regions 49/49 Fields 46/47 Buffers 59/60
Packages (2092 nodes)

The _REG was executed 4 times and initialized 48/49 regions. 1 region was failed to initialize.

After applying the testing patch (https://bugzilla.kernel.org/attachment.cgi?id=25890) that
we tried to re-execute _REG after acpi_ec_register_query_methods, we can workaround the AC/DC status issue. Is the workaround proper to apply?

Or, are there any debug parameter to find out the root cause(why region initialized
failed)?

Thanks.
Comment 6 Alexey Starikovskiy 2010-04-07 16:50:12 UTC
Zhang,

I think problem is that there is no Operating Region with type EmbeddedControl.
The OpReg declared inside EC is SystemMemory for some reason.
Probably, ACPICA is not used to register OpReg handler to something not present.

Thus EC only sits on its GPE and launch _Qxx methods (quite a number of them).
Comment 7 Zhang Rui 2010-04-08 05:52:56 UTC
Yes, Alexey, you're right!

look at the code below:

static acpi_status
acpi_ev_reg_run(acpi_handle obj_handle,
                u32 level, void *context, void **return_value)
{
        ...
        /* Object is a Region */

        if (obj_desc->region.space_id != space_id) {

                /* This region is for a different address space, just ignore it */

                return (AE_OK);
        }

        status = acpi_ev_execute_reg_method(obj_desc, 1);
        return (status);
}

when installing acpi ec address space handler, the _REG method will not be invoked because there is no EmbeddedControl region.
thus _REG is never invoked with parameter 3 and 1 on this laptop.

                    Method (_REG, 2, NotSerialized)
                    {
                        If (LEqual (Arg0, 0x03))
                        {
                            Store (Arg1, Local0)
                            If (Local0)
                            {
                                Store (One, ECON)
                            }
                            Else
                            {
                                Store (Zero, ECON)
                            }
                        }
                    }
ECON will not be set unless the patch in comment #2 is applied.

I will investigate if Windows invokes _REG(3, 1) in this case first...
Comment 8 ning.w.wang 2010-04-09 07:46:54 UTC
In EC driver, ec_install_handlers calls acpi_install_address_space_handlers with  space id == 3 (ACPI_ADR_SPACE_EC) which in turns firstly calls acpi_ev_install_space_handler to attach the space id (3) to the EC region in ACPI name space, secondly calls acpi_ev_execute_reg_methods with same space id (3), which will invoke _REG with space ide (3). So it should work without any problem.
Comment 9 Alexey Starikovskiy 2010-04-09 07:54:02 UTC
There is no EC region in ACPI name space, read carefully!
Comment 10 tomsun 2010-04-09 09:21:24 UTC
hi Alexey, if i use "OperationRegion (ERAM, SystemMemory, 0xFF808201, 0x0100)" instead of "OperationRegion (ERAM, EmbeddedControl, 0xFF808201, 0x0100)" in DSDT, i will get AC/DC status, right?
Comment 11 tomsun 2010-04-09 09:25:41 UTC
hi Alexey, if i use "OperationRegion (ERAM,EmbeddedControl , 0xFF808201, 0x0100)"
instead of "OperationRegion (ERAM, SystemMemory, 0xFF808201, 0x0100)" in
DSDT, i will get AC/DC status, right?
Comment 12 Len Brown 2010-04-13 01:40:15 UTC
Is this a pre-production machine?
Does windows detect AC/DC on it?
If so, which version?
Comment 13 ning.w.wang 2010-04-13 08:01:10 UTC
(In reply to comment #12)
> Is this a pre-production machine?
> Does windows detect AC/DC on it?
> If so, which version?

Windows 7 can detect AC/DC status on this machine.
Comment 14 Len Brown 2010-04-27 01:25:23 UTC
Interesting.
Does Windows XP work as well?
Comment 15 Michael Daum 2010-10-12 23:06:16 UTC
*** Bug 19602 has been marked as a duplicate of this bug. ***
Comment 16 monghitri 2010-12-18 08:48:58 UTC
Created attachment 40642 [details]
output of grep . /proc/acpi/battery/*/*
Comment 17 monghitri 2010-12-18 08:53:18 UTC
First of all sorry if i say something wrong, it's the first time i post here and i'm not a developer. My english is very broken too.
I'm coming here from https://bugzilla.kernel.org/show_bug.cgi?id=19602
I own an Acer A0521 and i have the very same issue as bug 19602 .
I'm on slitaz distro with 2.6.36 kernel.
I cannot apply diff_ec_try_econ.patch because static int acpi_ec_add in ec.c has been changed from kernel 2.6.36, is this bug supposed to be fixed with 2.6.36?
i can't get battery info but my /proc/acpi/ac_adapter works well, so maybe the other bug would be more appropriate.
i don't have /proc/acpi/thermal_zone at all.
if needed i'm available to build a kernel with CONFIG_ACPI_EC_DEBUGFS=y and give you required info, eventually i can install a more standard distro instead of slitaz
Comment 18 monghitri 2010-12-18 09:05:32 UTC
Created attachment 40652 [details]
output of zcat /proc/config.gz | grep ACPI
Comment 19 monghitri 2010-12-20 07:39:18 UTC
Created attachment 40982 [details]
errors in building patched 2.6.35.9 and working 2.6.34.7 /proc/acpi/BAT1/*

i have switched to archlinux because i had problems building kernel others than the default one in slitaz.
patch at comment 2 applies with no error to 2.6.34.7 and to 2.6.35.9, but the last one fails to build, while patched 2.6.34.7 with standard arch configs can correctly read Acer aspire one A0521 battery details. in 2.6.36 the patch fails in the last hunk. would it be possible to make current kernel recognize A0521 battery?
Comment 20 Mario Schindeldecker 2011-02-08 12:52:15 UTC
I made a never version of this patch, since the new kernel (2.6.36-tuxonice-r4) i used does not have that patch included:

*** ec.c.orig	2011-01-07 18:05:07.000000000 +0100
--- ec.c	2011-01-07 18:05:03.000000000 +0100
***************
*** 731,736 ****
--- 731,737 ----
  static int ec_install_handlers(struct acpi_ec *ec)
  {
  	acpi_status status;
+ 		
  	if (test_bit(EC_FLAGS_HANDLERS_INSTALLED, &ec->flags))
  		return 0;
  	status = acpi_install_gpe_handler(NULL, ec->gpe,
***************
*** 745,750 ****
--- 746,752 ----
  						    &acpi_ec_space_handler,
  						    NULL, ec);
  	if (ACPI_FAILURE(status)) {
+ 		printk (KERN_INFO "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n");
  		if (status == AE_NOT_FOUND) {
  			/*
  			 * Maybe OS fails in evaluating the _REG object.
***************
*** 759,764 ****
--- 761,768 ----
  			acpi_disable_gpe(NULL, ec->gpe);
  			return -ENODEV;
  		}
+ 	}else{
+ 		printk (KERN_INFO "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB\n");
  	}
  
  	set_bit(EC_FLAGS_HANDLERS_INSTALLED, &ec->flags);
***************
*** 781,786 ****
--- 785,798 ----
  {
  	struct acpi_ec *ec = NULL;
  	int ret;
+ 	acpi_status status;
+ 	union acpi_object arg_objs[] = {
+ 		{ACPI_TYPE_INTEGER},
+ 		{ACPI_TYPE_INTEGER}
+ 	};
+ 	struct acpi_object_list args = { 2, arg_objs };
+ 	arg_objs[0].integer.value = 3;
+ 	arg_objs[1].integer.value = 1;
  
  	strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
  	strcpy(acpi_device_class(device), ACPI_EC_CLASS);
***************
*** 811,817 ****
  	if (!first_ec)
  		first_ec = ec;
  	device->driver_data = ec;
! 
  	WARN(!request_region(ec->data_addr, 1, "EC data"),
  	     "Could not request EC data io port 0x%lx", ec->data_addr);
  	WARN(!request_region(ec->command_addr, 1, "EC cmd"),
--- 823,835 ----
  	if (!first_ec)
  		first_ec = ec;
  	device->driver_data = ec;
! 	status = acpi_evaluate_object (ec->handle, "_REG", &args, NULL);
! 	
! 	if (ACPI_FAILURE(status)){
! 		printk (KERN_INFO "@@@@@@@@@@@@@ _REG\n");
! 	}
! 	
! 	
  	WARN(!request_region(ec->data_addr, 1, "EC data"),
  	     "Could not request EC data io port 0x%lx", ec->data_addr);
  	WARN(!request_region(ec->command_addr, 1, "EC cmd"),
Comment 21 Simon Ouellet 2011-02-24 13:04:52 UTC
Is this patch incuded in the kernel (or will be)?
Comment 22 Zhang Rui 2011-03-31 08:56:12 UTC
No.
Good news is that Bob has proposed a patch to fix it in ACPICA code.
Comment 23 Simon Ouellet 2011-05-19 15:41:48 UTC
Do you know if that patch has been accepted ?
Comment 24 Zhang Rui 2011-05-23 01:28:06 UTC
*** Bug 34532 has been marked as a duplicate of this bug. ***
Comment 25 gmoutso 2011-05-23 12:02:14 UTC
what steve did at https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2 worked for me. Let me know if you want old/new dmesg and dsdt.dsl.
Comment 26 Otto Domínguez 2011-05-23 21:05:23 UTC
Same here as gmoutso. Steve's solution worked wonders.
For the record, I used Steve's hack at https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2, and because I was doing this kind of stuff first time ever, below are the relevant resources:
http://homeport.org/~bcordes/satellite-l500-install.html
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
https://help.ubuntu.com/community/Kernel/Compile
Comment 27 Len Brown 2011-05-24 02:09:52 UTC
in the pipeline:

commit e2066ca1b211ff08325c98be9fb8ad95affbaba8
Author: Bob Moore <robert.moore@intel.com>
Date:   Wed Apr 13 13:22:04 2011 +0800

    ACPICA: Execute an orphan _REG method under the EC device
Comment 28 Steve 2011-05-24 22:04:55 UTC
Coming here from bug 34532
Not sure if this is still relevant but i tried the following:
vanilla 2.6.39 kernel patched with ACPICA 20110413

the new acpi_ev_orphan_ec_reg_method runs but gives up trying to
find the ECDT.
Apparently this laptop (toshiba L645 ) and Ottos dont have ECDTs.
Comment 29 Ben Burns 2011-06-08 01:33:01 UTC
Steve's fix from https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2 for using a custom DSDT made my battery show up (but wireless broke, though that's a different story).

Tried 2.6.39-1 without the custom DSDT, but that didn't work.

Toshiba Satellite L655-S5158.
Comment 30 Len Brown 2011-07-31 17:52:36 UTC
The patch in comment #27 shipped in Linux v3.0
leon7176, please report if v3.0 works for you or not,
and re-open if no.
Comment 31 Simon Ouellet 2011-07-31 19:14:09 UTC
Still not working for me... 
Gateway lt22 (linux 3.0)

still patching every kernel update manualy with this patch
https://bugzilla.redhat.com/attachment.cgi?id=470363
Comment 32 Anatoli Sakhnik 2011-07-31 19:58:42 UTC
Neither works for me, using the patch like above. Looks like I can't reopen the bug.
Comment 33 Lan Tianyu 2012-02-01 06:18:39 UTC
*** Bug 42628 has been marked as a duplicate of this bug. ***
Comment 34 Jay LaCroix 2012-02-21 17:53:34 UTC
I have what I believe is the same issue on both a Latitude E6410 and Latitude E6420, using the latest kernel available. Linux reports that no battery is available, even while running on it. Windows has no issues on either machine. The only way I know my battery is getting low is when the battery LED on my laptop starts flashing red.
Comment 35 Simon Ouellet 2012-02-21 17:58:17 UTC
My fix is still working on the 3.2 kernel... (for Gateway lt22)
Comment #31
Comment 36 Simon Ouellet 2012-03-16 21:15:21 UTC
Here is a working p1 patch for 3.3-rc7
diff -uNpr linux-3.3-rc7.orig/drivers/acpi/ec.c linux-3.3-rc7.new/drivers/acpi/ec.c
--- linux-3.3-rc7.orig/drivers/acpi/ec.c        2012-03-14 19:00:18.459994716 -0400
+++ linux-3.3-rc7.new/drivers/acpi/ec.c 2012-03-14 19:05:45.716659504 -0400
@@ -784,6 +784,15 @@ static int acpi_ec_add(struct acpi_devic
        struct acpi_ec *ec = NULL;
        int ret;

+       acpi_status status;
+       union acpi_object arg_objs[] = {
+               {ACPI_TYPE_INTEGER},
+               {ACPI_TYPE_INTEGER}
+       };
+       struct acpi_object_list args = { 2, arg_objs };
+       arg_objs[0].integer.value = 3;
+       arg_objs[1].integer.value = 1;
+
        strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
        strcpy(acpi_device_class(device), ACPI_EC_CLASS);

@@ -811,7 +820,7 @@ static int acpi_ec_add(struct acpi_devic
        if (!first_ec)
                first_ec = ec;
        device->driver_data = ec;
-
+       status = acpi_evaluate_object (ec->handle, "_REG", &args, NULL);
        WARN(!request_region(ec->data_addr, 1, "EC data"),
             "Could not request EC data io port 0x%lx", ec->data_addr);
        WARN(!request_region(ec->command_addr, 1, "EC cmd"),
Comment 37 Jonathan Nieder 2012-05-29 15:35:14 UTC
Here's a report with a Toshiba Satellite L640 of the problem
still being present on 3.2.18:

 http://bugs.debian.org/609846

Using a custom DSDT with

 OperationRegion (EMEM, SystemMemory, 0xFF808001, 0xFF)

replaced by

 OperationRegion (EMEM, EmbeddedControl, 0×00, 0xFF)

fixes it for the reporter.
Comment 38 Jonathan Nieder 2012-05-29 15:39:55 UTC
Er, sorry, this might be the wrong bug.  By "the problem" I mean that
battery status is missing for Taylor.  I don't know if the AC Adapter
state is usable.
Comment 39 Zhang Rui 2012-11-28 02:16:52 UTC
this is weird.
commit e2066ca1b211ff08325c98be9fb8ad95affbaba8 should have fixed this problem.

Bob,
this is duplicate with http://www.acpica.org/bugzilla/show_bug.cgi?id=875, right?
Comment 40 Zhang Rui 2012-11-28 02:22:12 UTC
(In reply to comment #28)
> Coming here from bug 34532
> Not sure if this is still relevant but i tried the following:
> vanilla 2.6.39 kernel patched with ACPICA 20110413
> 
> the new acpi_ev_orphan_ec_reg_method runs but gives up trying to
> find the ECDT.
> Apparently this laptop (toshiba L645 ) and Ottos dont have ECDTs.

Bob,
do you have any plan on supporting these platforms that does not have EC address space or ECDT.
Comment 41 Robert Moore 2012-11-28 04:24:25 UTC
To have an EmbeddedControl address space, all that is really needed is the EC device, ECDT is optional.

It does look to me as though the acpica fix in 875 should fix the problem. But it has been a while, I will need to look closer at it again.

Does the fix for 875 make the machine behave any different?
Comment 42 Zhang Rui 2012-11-30 01:28:27 UTC
(In reply to comment #41)
> To have an EmbeddedControl address space, all that is really needed is the EC
> device, ECDT is optional.
> 
> It does look to me as though the acpica fix in 875 should fix the problem.

the patch in comment 1 of bug 875 fixes the problem.

> But
> it has been a while, I will need to look closer at it again.
> 
> Does the fix for 875 make the machine behave any different?

I guess no, because it fails soon in acpi_ev_orphan_ec_reg_method because there is no ECDT found.

Then my question would be,
why we need ECDT? can't we get the acpi handle of ec by the acpi_namespace_node parameter in acpi_ev_execute_reg_methods?
Comment 43 Robert Moore 2012-11-30 02:11:54 UTC
After looking at the code, I see that the orphan_ec_reg_method code may not be "fully implemented". It depends on the ECDT being present in order to get a handle to the EC device quickly.

Note, the handle passed to execute_reg_methods is not the EC, it is some other device in the namespace. We are going back to the EC device to determine if a _REG method exists under EC that has not been executed (orphaned because there is no operation region under the EC that would cause the _REG to be invoked.)

I think a quick fix (at least to test the theory) would be to add a namespace walk to find the EC device (via the EC _HID) (in the case of no ECDT), and execute any orphaned _REG method found there.

There may be a better fix that we can determine later.
Comment 44 Zhang Rui 2012-11-30 04:55:46 UTC
Created attachment 87901 [details]
execute orphan EC _REG even if ECDT not present

please try this patch and see if it helps or not.
Comment 45 Zhang Rui 2012-12-11 01:22:35 UTC
ping...
Comment 46 Steve 2012-12-11 19:03:52 UTC
(In reply to comment #44)
> Created an attachment (id=87901) [details]
> execute orphan EC _REG even if ECDT not present
> 
> please try this patch and see if it helps or not.

Yes that works!
Tried it against 3.4.9 source and will will try it on a newer kernel
version tonight
Comment 47 Anatoli Sakhnik 2012-12-11 19:21:07 UTC
It works to me too. Tried with 3.6.10.
Comment 48 Steve 2012-12-12 05:29:27 UTC
Works well on 3.6.10
Comment 49 Steve 2013-02-06 16:28:47 UTC
What additional info is needed?
Comment 50 Len Brown 2013-02-09 08:39:14 UTC
marked as RESOLVED, as there is a working patch attached
that may be a candidate for upstream
Comment 51 ning.w.wang 2013-02-09 08:39:51 UTC
I'm ooo from Feb 9th to Feb 17th for Chinese New Year holiday.  Email response will be slow.
For any urgent issues, please call my cell phone.

Thanks,
Ning
Comment 52 Len Brown 2013-02-19 00:47:01 UTC
patch in comment #44 was not accepted upstream.
so this bug report is now being marked ASSIGNED
and Rui will follow-up with another fix candidate.
Comment 53 Lan Tianyu 2013-04-09 03:55:39 UTC
*** Bug 43156 has been marked as a duplicate of this bug. ***
Comment 54 Lan Tianyu 2013-04-09 04:10:45 UTC
Hi Bob:
      Do you have plan fix this bug in the ACPICA recently?
Comment 55 Lv Zheng 2013-04-11 08:31:05 UTC
It looks like we need a quirk inside EC driver to execute _REG for specific BIOS.
Comment 56 Lv Zheng 2013-04-12 01:36:58 UTC
It looks such quirk can be generic enough to having it implemented inside ACPICA.  So I assigned this bug to myself.
Comment 57 Lv Zheng 2013-04-16 03:39:45 UTC
As far as I can see, there are following 2 bugs in the Linux:

1. Orphan _REG method execution
   According to the spec, the OS will run a _REG in a given scope when the operation regions declared in that scope are available for use.
   By my reading, this means orphan _REG methods should be executed as long as all the operation regions declared below it's parent scope are all available for use -> this rule is not only for the EC device, but should be applied to all of the namespace scopes.
   This should be fixed in the ACPICA, ACPICA probably should check operation regions' availability in the acpi_install_address_space_handler and call all _REG methods under the given acpi_namespace_node.

2. the Embedded Controller space handler registration
   According to the spec, OSPM will make Embedded Controller operation regions, accessed via Embedded Controller described in ECDT, available before executing any control method.
   By my reading, this means only the Embedded Controller device pointed by the ECDT is responsible for registering EmbeddedControl space handler.
   This should be fixed in the Linux, Linux EC drivers need to check ECDT to see if it is responsible for handling EmbeddedControl space and the parameter passed to the acpi_install_address_space_handler should be ACPI_ROOT_OBJECT.

As a conclusion, I think non of the above fixes should be merged at this point as they all appear to be wrong approaches.
So please wait until a better solution can be worked out.
Comment 58 Lv Zheng 2013-04-17 02:23:43 UTC
I'm trying to call _REG with each space id that known to be "installed" for the given namespace node.
But it seems there might be _REG methods written without space_id checking that will be broken on this approach.
Sorry for the noise.
Comment 59 Robert Moore 2013-04-19 19:24:27 UTC
Rui's patch to execute an orphan _REG method that appears under the EC device (during handler installation) has been integrated into ACPICA 20130418.
Comment 60 Zhang Rui 2013-04-23 08:57:13 UTC
Great.
Mark as Resolved.
Will close the bug after ACPICA 20130418 shipped in Linux.
Comment 61 gmoutso 2013-05-12 12:37:37 UTC
patch in https://bugzilla.kernel.org/show_bug.cgi?id=15707#c44 works also on the current kernel in ubuntu 3.8.8. There are some quirks that Steve's dsdt solution in
https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2
didn't have.
1. powertop gives 4 Watts on my medium weight laptop. I think this is too small by a factor of 4-5.
2. power management in kde displays 99% for a new battery, or 30% for an old battery. I think it is showing the percentage to the design capacity. It should show 100% when fully charged, right?
Comment 62 Len Brown 2014-10-28 05:12:50 UTC
> Will close the bug after ACPICA 20130418 shipped in Linux.

That version of ACPICA shipped in Linux-3.11

Note You need to log in before you can comment on or make changes to this bug.