Re: [Xen-devel] [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path

["Rafael J. Wysocki" <rjw@xxxxxxx>]

On Wednesday, June 26, 2013 04:45:53 PM Jan Beulich wrote:
> >>> On 26.06.13 at 17:03, Ben Guthro <benjamin.guthro@xxxxxxxxxx> wrote:
> > On Wed, Jun 26, 2013 at 10:41 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>>> On 26.06.13 at 16:06, Ben Guthro <benjamin.guthro@xxxxxxxxxx> 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@xxxxxxxxxx>
> >>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >>
> >> 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@xxxxxxxxxx>
> > 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.

Actually, I'd prefer not to add new dependencies on the "old" include either.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel