Received: by 10.223.164.221 with SMTP id h29csp930207wrb; Mon, 16 Oct 2017 14:54:53 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCyd6fJXcIhXd8iAABPPJf8i3wUxMAQ1/qUNvBEsFrEKRHuIIbA3o2WXKYkOtgJITzA8hWu X-Received: by 10.98.83.5 with SMTP id h5mr9952582pfb.131.1508190892982; Mon, 16 Oct 2017 14:54:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508190892; cv=none; d=google.com; s=arc-20160816; b=D4ekU4ozdlCTuGndZl7tzqvluuB6VAnB0YGU3nfpYoXOZcQkbG8FQUNBxZ3vBmIWux 7CqIWImiLFmwvi2QK+WyLIJxwkZQzYOaQIOreUvH2sxIpppNiCzudIjWaMAaMk5rNiiF KDW5sxgsG1TuB3nzaLmR1TYXo4/TaWSl1IEe+JJCpyqTjo7LLkKKPm+gbCXXtByGFfuc rQzcSa7jApMPwgm87NL+FDWiVtNsu7WKBqIA2x0+75GXIDeLIvgQYVw0B/3OKnNP31Yb CKxKjzNwhw8AyqBOcjxEnbNiB2QdLbDOHoLdoR+OjIY/CyfD1sJLj1Z52Ru1IWWrZUyc MHxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=36IHHhDi2kZ629akljhmBBsrPJ/1EWEeGnsf0WgUGeo=; b=gOCMYWMNdtFtTAFlmKibWTVcyXAGSp+lYyxO/1lStcgGzUQgOd21juRMWcwc5LCZlF nKb+wB5xVo+Rlq9QpQE+OQtaHc5+bLOEYHYbg9c85ITA6n7wiOtukg1upJOMrkQsyAH3 WF9eUFYgpArrzRz80ngm9Z9TIdI/zxAXYRl1/2tLGYFvVw0D3pGRJU7KMuufTk12hX4k WYjotKwb8yYzoz/+0ndtgUGaHoTWKTKC3O1MhKUMIYEaRAMS/51I0fY478NkJNWnt8Li 7FtqBJRg6Nk7BG1P04EvDpPVyRvzV9WLqFz1W165cbWzWz9ZJt3K07xvnDVicah9cIZE btlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h184si4547817pgc.784.2017.10.16.14.54.39; Mon, 16 Oct 2017 14:54:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932428AbdJPUQS (ORCPT + 99 others); Mon, 16 Oct 2017 16:16:18 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:36390 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1757269AbdJPUQQ (ORCPT ); Mon, 16 Oct 2017 16:16:16 -0400 Received: (qmail 3025 invoked by uid 2102); 16 Oct 2017 16:16:15 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Oct 2017 16:16:15 -0400 Date: Mon, 16 Oct 2017 16:16:15 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Rafael J. Wysocki" cc: Linux PM , Bjorn Helgaas , Greg Kroah-Hartman , LKML , Linux ACPI , Linux PCI , Linux Documentation , Mika Westerberg , Ulf Hansson , Andy Shevchenko , Kevin Hilman , Wolfram Sang , , Lee Jones Subject: Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags In-Reply-To: <1998650.Q52BuGQTI4@aspire.rjw.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 16 Oct 2017, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The motivation for this change is to provide a way to work around > a problem with the direct-complete mechanism used for avoiding > system suspend/resume handling for devices in runtime suspend. > > The problem is that some middle layer code (the PCI bus type and > the ACPI PM domain in particular) returns positive values from its > system suspend ->prepare callbacks regardless of whether the driver's > ->prepare returns a positive value or 0, which effectively prevents > drivers from being able to control the direct-complete feature. > Some drivers need that control, however, and the PCI bus type has > grown its own flag to deal with this issue, but since it is not > limited to PCI, it is better to address it by adding driver flags at > the core level. I'm curious: Why does the PCI bus type (and others) do this? Why doesn't it do what the driver says to do? Alan Stern From 1581394704933328879@xxx Mon Oct 16 06:31:54 +0000 2017 X-GM-THRID: 1581376692983994326 X-Gmail-Labels: Inbox,Category Forums