linux-kernel - Re: [RFC PATCH 2/6] ACPI: Reference devices in ACPI Power Resource

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201202172334.04301.rjw@sisk.pl>
Date:	Fri, 17 Feb 2012 23:34:04 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Zhang Rui <rui.zhang@...el.com>
Cc:	Lin Ming <ming.m.lin@...el.com>, Jeff Garzik <jgarzik@...ox.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Tejun Heo <tj@...nel.org>, Len Brown <lenb@...nel.org>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	linux-scsi@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [RFC PATCH 2/6] ACPI: Reference devices in ACPI Power Resource

On Thursday, February 16, 2012, Zhang Rui wrote:
> On 二, 2012-02-14 at 23:36 +0100, Rafael J. Wysocki wrote:
> > > > > + */
> > > > > +struct acpi_powered_device {
> > > > > +	struct list_head node;
> > > > > +	struct device *dev;
> > > > > +};
> > > > > +
> > > > >  /* --------------------------------------------------------------------------
> > > > >                               Power Resource Management
> > > > >     -------------------------------------------------------------------------- */
> > > > > @@ -455,6 +470,118 @@ int acpi_disable_wakeup_device_power(struct acpi_device *dev)
> > > > >                               Device Power Management
> > > > >     -------------------------------------------------------------------------- */
> > > > >  
> > > > > +int acpi_power_resource_register_device(struct device *dev, acpi_handle handle)
> > > > > +{
> > > > > +	struct acpi_power_resource *resource;
> > > > > +	struct acpi_device *acpi_dev, *res_dev;
> > > > > +	acpi_handle res_handle = NULL;
> > > > > +	struct acpi_powered_device *apd;
> > > > > +	int i;
> > > > > +	int ret;
> > > > > +
> > > > > +	if (!handle || !dev)
> > > > > +		return -EINVAL;
> > > > > +
> > > > > +	ret = acpi_bus_get_device(handle, &acpi_dev);
> > > > > +	if (ret)
> > > > > +		goto no_power_resource;
> > > > > +
> > > > > +	if (!acpi_dev->power.flags.power_resources)
> > > > > +		goto no_power_resource;
> > > > > +
> > > > > +	for (i = 0; i <= ACPI_STATE_D3; i++) {
> > > > > +		struct acpi_device_power_state *ps = &acpi_dev->power.states[i];
> > > > > +
> > > > > +		if (!ps->flags.valid)
> > > > > +			continue;
> > > > > +
> > > > > +		if (ps->resources.count > 1)
> > > > > +			return 0;
> > > > > +
> > > > > +		if (!res_handle)
> > > > > +			res_handle = ps->resources.handles[0];
> > > > > +		else if (res_handle != ps->resources.handles[0])
> > > > > +			return 0;
> > > > > +	}
> > > > 
> > > > I'm not sure what the above checks are needed for.  It seems that this function
> > > > will only be called from acpi_bus_add_power_resource() (which needs to be
> > > > modified for this purpose, BTW), so it doesn't need to check all those things
> > > > (those checks have been made already).
> > > > 
> > > No. These two APIs are introduced to support the runtime D3_COLD remote
> > > wakeup. And they should be invoked by drivers, either in driver code or
> > > via bus layer code.
> > > 
> > > Say, ATA port, who has _PR3 in its ACPI node, knows that it can enter
> > > D3_COLD at run time, and it supports remote wakeup in D3_COLD because it
> > > has _S0W (return value 4).
> > > When remote wakeup event is triggered, there is an ACPI event sent to
> > > the ATA controller/port, which sets the ATA controller/port back to D0
> > > state.
> > > At this time, what we actually need is to resume the ZPODD, rather than
> > > the ATA controller/port. To follow the runtime PM model (runtime resume
> > > starts from leaf devices),
> > 
> > Well, this isn't the case.  Parents are always resumed first.
> > 
> Well, I mean runtime resume request issued by leaf devices first.

That still causes runtime PM callbacks for parents to be run before runtime PM
callbacks for the children.

It is impossible to runtime-resume a child device (using the runtime PM
framework's functions at least) if the parent of it is not "active".

> > > ATA code can use these two APIs to tell ACPI
> > > to runtime resume ZPODD device directly, because ZPODD is powered by
> > > this Power Resource as well.
> > 
> > I'm not exactly sure what you're trying to achieve and what you mean by
> > "resume a device directly"?  Do you want to run the device's resume
> > callback at the time when another device is being resumed?
> > 
> I mean, wakeup event is sent to ATA port, but our goal is to resume
> ZPODD after receiving this wakeup event.
> Ideally, it is ACPI that resumes ATA port. And then, the ATA port
> runtime resumes ZPODD. But this does not look good to runtime resume a
> child device in the parent's .runtime_resume callback.

OK, I think I see what the problem is.

> So I introduced these two APIs so that an runtime_resume request can be
> sent to ZPODD directly and the runtime PM core can resume all the
> parents of ZPODD automatically.

It seems that you're confusing things.  In the Linux driver model a device
cannot have more than a single parent.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/