linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lan Tianyu <tianyu.lan@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: lenb@kernel.org, mika.westerberg@linux.intel.com,
	wsa@the-dreams.de, robert.moore@intel.com, lv.zheng@intel.com,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org
Subject: Re: [RFC PATCH] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA
Date: Fri, 26 Sep 2014 13:23:29 +0800	[thread overview]
Message-ID: <5424F851.1020809@intel.com> (raw)
In-Reply-To: <2232717.X50lT6IYgQ@vostro.rjw.lan>

On 2014年09月26日 03:27, Rafael J. Wysocki wrote:
> I'm not sure what you mean.  "Dependent" means "depending on something", so the
> question reads "This requires the devices with _DEP to have a list of devices
> that depend on them" which is probably not what you meant.
> 

Sorry, I didn't say clearly. The "dependent device" I meant is device
pointed to by _DEP(the master you mentioned at the bottom). I thought
master also needed a list to find its slave(device with _DEP).

> For each device with _DEP we have dep_devices, so if you pass a pointer
> (opregion_adev) to the device that has just installed an operation region
> handler to acpi_walk_dep_device_list() as an argument, then you can do
> 
> 	for (i = 0; i < adev->dep_devices.count; i++)
> 		if (opregion_adev->handle == adev->dep_devices.handles[i]) {
> 			adev->dep_unmet = false;
> 			acpi_bus_attach(adev);
> 			list_del(&dep->node);
> 			kfree(dep);
> 		}
> 
> and of course appropriate locking needs to be there in case this races with
> enumeration during hotplug after loading a new ACPI table on demand).
> 

Yes, we can scan all devices on the list and match the opregion_adev
with adev->dep_devices. This is comparatively simple solution.

> I think you can even define
>   
> struct acpi_dep_data {
> 	struct list_head node;
> 	struct acpi_device *master;
> 	struct acpi_device *slave;
> };
> 
> and create that for every valid pair of master (device pointed to by _DEP)/slave
> (device with _DEP) and create a list of these.  Then, you won't need dep_devices
> in struct acpi_device any more and your acpi_walk_dep_device_list() will only
> need to walk the list until it finds the matching master/slave pair.

One question is that when create struct acpi_dep_data for the dependency
relationship between master and slave. If do this when slave's ACPI
device is created during ACPI namespace scan, master's ACPI device maybe
not created at that point. So acpi_handle maybe more suitable than
struct acpi_device here.

> 
> That will handle the case when one device depends on multiple other devices too
> I think.
> 
>>>> > >> +		dep_adev = acpi_bus_get_acpi_device(
>>>> > >> +				adev->dep_devices.handles[i]);
>> > 


-- 
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-09-26  5:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23  7:06 [RFC PATCH] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA Lan Tianyu
     [not found] ` <1411456003-29541-1-git-send-email-tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-09-24 22:27   ` Rafael J. Wysocki
     [not found]     ` <5595235.8OhLbSk3cf-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-09-25  9:44       ` Lan Tianyu
     [not found]         ` <5423E40B.8010302-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-09-25 19:27           ` Rafael J. Wysocki
     [not found]             ` <2232717.X50lT6IYgQ-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-09-25 20:15               ` Rafael J. Wysocki
2014-09-26  5:23             ` Lan Tianyu [this message]
2014-09-26 13:48               ` Rafael J. Wysocki

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=5424F851.1020809@intel.com \
    --to=tianyu.lan@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=wsa@the-dreams.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).