[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <51CB28D102000078000E0DF8@nat28.tlf.novell.com>
Date: Wed, 26 Jun 2013 16:45:53 +0100
From: "Jan Beulich" <JBeulich@...e.com>
To: "Ben Guthro" <benjamin.guthro@...rix.com>
Cc: "Bob Moore" <robert.moore@...el.com>, <xen-devel@...ts.xen.org>,
"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
"Rafaell J . Wysocki" <rjw@...k.pl>, <linux-acpi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in
reduced hardware sleep path
>>> On 26.06.13 at 17:03, Ben Guthro <benjamin.guthro@...rix.com> wrote:
> On Wed, Jun 26, 2013 at 10:41 AM, Jan Beulich <JBeulich@...e.com> wrote:
>>>>> On 26.06.13 at 16:06, Ben Guthro <benjamin.guthro@...rix.com> wrote:
>>> In version 3.4 acpi_os_prepare_sleep() got introduced in parallel with
>>> reduced hardware sleep support, and the two changes didn't get
>>> synchronized: The new code doesn't call the hook function (if so
>>> requested). Fix this, requiring a parameter to be added to the
>>> hook function to distinguish "extended" from "legacy" sleep.
>>>
>>> Signed-off-by: Ben Guthro <benjamin.guthro@...rix.com>
>>> Signed-off-by: Jan Beulich <jbeulich@...e.com>
>>
>> I think these are intended to reflect the flow of things, so
>> should be reversed (also in the other patches).
>>
>>> --- a/drivers/acpi/acpica/hwesleep.c
>>> +++ b/drivers/acpi/acpica/hwesleep.c
>>> @@ -43,6 +43,7 @@
>>> */
>>>
>>> #include <acpi/acpi.h>
>>> +#include <linux/acpi.h>
>>
>> This also got complaints, so I'd be very surprised if they took it now.
>
> I did see these complaints in the last version.
> However, the file drivers/acpi/acpica/hwsleep.c contains this include,
> and has since
>
> commit 09f98a825a821f7a3f1b162f9ed023f37213a63b
> Author: Tang Liang <liang.tang@...cle.com>
> Date: Fri Dec 9 10:05:54 2011 +0800
>
> So since this is the extended sleep file, vs the standard one - I
> don't see why such a restriction would be placed on the former, but
> not the latter.
In essence they said (in the same thread I pointed you to) that
according to the current policy this include is wrong and should
be dropped.
Now, if you can get along without dropping it that'll likely be fine,
but I doubt they'll allow you to add another instance of this.
Jan
--
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/
Powered by blists - more mailing lists