From owner-freebsd-current@freebsd.org Wed Aug 1 22:24:49 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F318B106B015 for ; Wed, 1 Aug 2018 22:24:48 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f65.google.com (mail-it0-f65.google.com [209.85.214.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B9728B389 for ; Wed, 1 Aug 2018 22:24:48 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f65.google.com with SMTP id s7-v6so478106itb.4 for ; Wed, 01 Aug 2018 15:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=laZsIh0SSchmqwEQRUlZCfCFxbJF1SIZzPikQRwwANs=; b=kbLG2IovrdWSFl152Qj3USQrd5y67++14FlzdcZbxcGsdzYotkSMVLGSV5BM2js9M9 AbJv/KhoeZCWJR8MLrDyRoAQY91aYbiJrUrAvOb6tIRpDkV1r6viMmZHb4mIS6k38tBf jPvx36f46M3szc7E5JCeVRP0ObNk9TSbJS0VOVD5f79NPZAaUaBDavIG1UlSI0bz/2Gp 8KyvviIUZReHxlwHoziWo2FcgR9Lh3BvhedO5XBea1YIBSayTs3SKtH5jb2M225lMwTa HWI0WQktfLmZL1g6QL3sVVMpq1BgQDsZ/SK32vBdgG/rblzph4auLQaBTAgozDD7c1th a5uw== X-Gm-Message-State: AOUpUlGNGeqANdIIDGNHSEL/0toA2SYck1+HAQyqV8OK0a2Sny9QSXmw eB9ln8cySzUXzG+o6tKd1HtZtsri X-Google-Smtp-Source: AAOMgpcj3Snzj+zuLK0/ElMBcJCIZ/hbjTemK+IgYm9h/2vUaMqL3T0L3SL8s/+prFhqcArMNMQeaQ== X-Received: by 2002:a24:4f52:: with SMTP id c79-v6mr349004itb.36.1533161855950; Wed, 01 Aug 2018 15:17:35 -0700 (PDT) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com. [209.85.214.44]) by smtp.gmail.com with ESMTPSA id b81-v6sm5785itg.6.2018.08.01.15.17.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 15:17:35 -0700 (PDT) Received: by mail-it0-f44.google.com with SMTP id d10-v6so452544itj.5 for ; Wed, 01 Aug 2018 15:17:35 -0700 (PDT) X-Received: by 2002:a24:be8f:: with SMTP id i137-v6mr326360itf.61.1533161855537; Wed, 01 Aug 2018 15:17:35 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 15:17:34 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Wed, 1 Aug 2018 15:17:34 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: acpiconf -s 3 does not call acpi sleep event handlers To: Johannes Lundberg Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 22:24:49 -0000 I don't understand the concern. There is only one listener to the event and it just invokes ReqSleepState, which is responsible for performing all suspend behavior. The behavior is identical between lid close and acpiconf. On Wed, Aug 1, 2018 at 3:00 PM, Johannes Lundberg wrot= e: > > > On Wed, Aug 1, 2018 at 22:55 Conrad Meyer wrote: >> >> ReqSleepState is the routine that takes care of suspend, not the >> eventhandler. I'm not sure what difference the proposed change is >> supposed to make. > > > Listeners to acpi_sleep_event don=E2=80=99t get the event when suspending= with > acpiconf (but they do when suspending via lid or sleep button). > > I think one would expect the same behavior when suspending via command li= ne > or physical switch. > > >> >> >> Best, >> Conrad >> >> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg >> wrote: >> > >> > >> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer wrote: >> >> >> >> It seems deliberate, although the commit message does not call it out >> >> and the event is perhaps poorly named. The event currently indicates >> >> that the lid was closed. And the final registered eventhandler for >> >> the event calls ReqSleepState. >> >> >> >> The ReqSleepState routine, as well as the userspace ioctl that >> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather >> >> than invoking the acpi sleep event), were introduced together in >> >> r170976. >> >> >> > >> > Unless there's a way of calling suspend properly from the cli (zzz use= s >> > acpiconf...) maybe something like this makes more sense to get the sam= e >> > behavior on for example lid close as zzz or acpiconf -s 3? (untested) >> > >> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c >> > index c1bfd880c89..87b506d6bf5 100644 >> > --- a/sys/dev/acpica/acpi.c >> > +++ b/sys/dev/acpica/acpi.c >> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t >> > addr, >> > int flag, struct thread *t >> > case ACPIIO_REQSLPSTATE: >> > state =3D *(int *)addr; >> > if (state !=3D ACPI_STATE_S5) >> > - return (acpi_ReqSleepState(sc, state)); >> > + return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER, >> > + acpi_invoke_sleep_eventhandler, &state)) ? 0 : >> > ENXIO; >> > device_printf(sc->acpi_dev, "power off via acpi ioctl not >> > supported\n"); >> > error =3D EOPNOTSUPP; >> > break; >> > >> > >> >> >> >> Best, >> >> Conrad >> >> >> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg >> >> wrote: >> >> > Hi >> >> > >> >> > As the title says, callbacks registered with >> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, .... >> >> > does not get called when calling acpiconf -s 3. >> >> > They do however, when suspending with lid or sleep button. >> >> > >> >> > Is this deliberate or an oversight? >> >> > >> >> > Cheers >> >> > _______________________________________________ >> >> > freebsd-current@freebsd.org mailing list >> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > To unsubscribe, send any mail to >> >> > "freebsd-current-unsubscribe@freebsd.org"