All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Starikovskiy <astarikovskiy@suse.de>
To: Zhao Yakui <yakui.zhao@intel.com>
Cc: Alexey Starikovskiy <aystarik@gmail.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [RFC]  [PATCH] ACPI :Remove the EC space handler explicitly	when failing in _REG object
Date: Fri, 28 Nov 2008 11:08:21 +0300	[thread overview]
Message-ID: <492FA6F5.7070105@suse.de> (raw)
In-Reply-To: <1227841044.4035.70.camel@yakui_zhao.sh.intel.com>

Zhao Yakui wrote:
> On Thu, 2008-11-27 at 17:42 +0800, Alexey Starikovskiy wrote:
>> Zhao Yakui wrote:
>>> On Thu, 2008-11-27 at 04:03 +0800, Alexey Starikovskiy wrote:
>>>> This is hardly a "fix", you just disable EC on this machine... Famous 
>>> Yes. This can't fix the issue on the box of bug11884. 
>>> But in theory if the incorrect status is returned by
>>> acpi_install_address_space_handler, the EC space handler should be
>>> removed explicitly. Right? In such case the EC device will be disabled
>>> on this box. 
>> Wrong. If any function is allowed to fail, you should not call counter function
>> to recover -- you don't call free() on failed malloc(), you don't call close() on
>> failed open().
> 
> In the function of acpi_install_address_space_handler the following two
> steps are done in ACPCA:
>    a. Install the space handler for one operation region. This space
> handler is applied for the same type operation region of every device.
>    b. run the _REG object for all the operation regions using the space
> id. It will enumerate the ACPI namespace to execute the _REG object for
> the same operation region
Unregister space handler will do all these things in opposite order, thus calling 
failed _REG object once again, causing more damage.
> 
> If the space handler is removed in the function of
> acpi_install_address_space_handler when failure in _REG object happens,
> it is unnecessary to remove the space handler explicitly. 
>    But in fact maybe there exists the _REG object for other operation
> region besides EC operation region. If failure in _REG object happens,
> maybe the space handler should not be applied for the corresponding
> device. PCI space handler is used by all the PCI devices. It is
> unreasonable that all the PCI devices can't use the pci space handler if
> OS fails in the _REG object of one PCI device.
>    So it is difficult to deal with this issue in the function of
> acpi_install_address_space_handler.
> 
> Maybe it will be easy to deal with such issue in driver.
> 
>>>     But if the EC space handler is not removed and EC flag in AML code
>>> still indicates that EC operation region is already accessible, the EC
>>> internal register will be accessed in AML code. At the same time the
>>> memory region pointed by acpi_ec is already freed. This is the fourth
>>> argument of ec_space_handler.
>> I already told you and here is second time -- your fixes come in wrong place.
>> You should fix acpi_install_address_space_handler(), not all the callers of it.
> It is difficult for me to fix this issue in
> acpi_install_address_space_handler. I am not willing to change the code
> of ACPICA. It is not very reasonable that all the failures in _REG
> object for all the operations region are ignored.
You have address space identifier in this function, so if you want your 
workaround to be "only for EC", check it. 
> And it is also unreasonable that the space handler is removed for the
> same type operation region of all the devices only because OS fails in
> _REG object of one device.
> If you have better method to fix such issue, please write it. 
Yakui, why should I complete all your jobs?

Alex.

  reply	other threads:[~2008-11-28  8:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-26  8:50 [RFC] [PATCH] ACPI :Remove the EC space handler explicitly when failing in _REG object Zhao Yakui
2008-11-26 20:03 ` Alexey Starikovskiy
2008-11-27  1:29   ` Zhao Yakui
2008-11-27  9:42     ` Alexey Starikovskiy
2008-11-28  2:57       ` Zhao Yakui
2008-11-28  8:08         ` Alexey Starikovskiy [this message]
2008-12-01  1:53           ` Zhao Yakui
2008-12-01  2:47           ` Zhao Yakui
2008-12-01  8:12           ` the issue about the bogus ECDT table Zhao Yakui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=492FA6F5.7070105@suse.de \
    --to=astarikovskiy@suse.de \
    --cc=aystarik@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=yakui.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.