Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5251927ybp; Mon, 14 Oct 2019 18:33:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqwQxv0e8q7WlGW4iQ8gjaGFjdBKR0XaYd1gW2ovUop1s5KZKWk3SQacWvEnF1d3P7ZLjywK X-Received: by 2002:aa7:ccd3:: with SMTP id y19mr15496546edt.122.1571103182046; Mon, 14 Oct 2019 18:33:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571103182; cv=none; d=google.com; s=arc-20160816; b=GcMlJjYbv0Hyu0VXrMf4c7zENByHx7U37er1uk71agcP7suJe4g1cEsQ4liOu0wsDE PFPTNNAQ+SaAJmp6H8nYJs5hkH68ldHpxOsAqrvRAJI6WJlOuIOh3lOsgGyt6KyG0Yfe tghMwTI7axIn5wDEWKPOVeyeMxUEILkbux81BrWsmdPSBTR4es5MmaGXDDYo/PhXNNak oXNDun5u+Wi0nz2gvbeazv/K9jhrIGnlAE9YpiXO8OIidG1CaegYYhjGLImA8Awojc0H AaUBhniYct59krvKDFBXBPCRtr57lOn7TZqdxDSk4jXpKG4g8I8bFWM51Id4vGzQMxTP r8dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=TfyKf5oV+JwfYK9UavZin+0RBd/TmANKS98W6AG1tzY=; b=lvTWRz8J6Zxwlrba30OwoeFGpDeZeeM5NhYOngO4Kb6C9LWZ11F6k/8KBuMWOtLZq0 bM/X9M/LgRXyrzibej4wEanRtKKPyNA0Xq0FCBuM07ZTjrngsMfVyqOLPDJI90Y4HJXS CEpbTD88mmWtkIUzMIHXWJfIS0ErgM7WsoffrwMN8lHN8SP5vW9LhRZsEV8RrQHjpris UgG9YsuGOD7ybDedA6xeVZfGDg8S147xehjs9LJkmF2FaRoUoiwHWVIrqfLJ64AF+mzB W28KQO+qOMMyGG+kT7E2GTmsdTrYEsqVzgowl1kNWl2Lpl+SpgY2xXeYbmFPDY6YVDzW teaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="W18/YeT6"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l45si13552163edc.185.2019.10.14.18.32.38; Mon, 14 Oct 2019 18:33:02 -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; dkim=pass header.i=@kernel.org header.s=default header.b="W18/YeT6"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726415AbfJNXCM (ORCPT + 99 others); Mon, 14 Oct 2019 19:02:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:52510 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726225AbfJNXCI (ORCPT ); Mon, 14 Oct 2019 19:02:08 -0400 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 80597217F9; Mon, 14 Oct 2019 23:02:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571094126; bh=e5ELKufEIki4aTdl20aS5WbH85Df9dXGiXMAgJHmzvk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W18/YeT62/0vSMnL2xR4IGUluqcwtOJNKnCnKTJ5CbOtbg7lnOhFzamXjXcfcap6A RYqbVJBkfVtSTxVGbZd8AqDWOpW8ZDomLnAySVvC4XYGdk8KcWe7swNspRp9tNj6l+ ACQAOPSq7IaI3k3uw40y8kGIRvVk1iv85/lFVoD4= From: Bjorn Helgaas To: Dexuan Cui Cc: "Rafael J . Wysocki" , Lorenzo Pieralisi , Michael Kelley , Sasha Levin , Haiyang Zhang , KY Srinivasan , Stephen Hemminger , olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, vkuznets@redhat.com, marcelo.cerri@canonical.com, jackm@mellanox.com, linux-pci@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, driverdev-devel@linuxdriverproject.org, Bjorn Helgaas Subject: [PATCH 6/7] PCI/PM: Wrap long lines in documentation Date: Mon, 14 Oct 2019 18:00:15 -0500 Message-Id: <20191014230016.240912-7-helgaas@kernel.org> X-Mailer: git-send-email 2.23.0.700.g56cf767bdb-goog In-Reply-To: <20191014230016.240912-1-helgaas@kernel.org> References: <20191014230016.240912-1-helgaas@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Bjorn Helgaas Documentation/power/pci.rst is wrapped to fit in 80 columns, but directory structure changes made a few lines longer. Wrap them so they all fit in 80 columns again. Signed-off-by: Bjorn Helgaas --- Documentation/power/pci.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst index 1525c594d631..db41a770a2f5 100644 --- a/Documentation/power/pci.rst +++ b/Documentation/power/pci.rst @@ -426,12 +426,12 @@ pm->runtime_idle() callback. 2.4. System-Wide Power Transitions ---------------------------------- There are a few different types of system-wide power transitions, described in -Documentation/driver-api/pm/devices.rst. Each of them requires devices to be handled -in a specific way and the PM core executes subsystem-level power management -callbacks for this purpose. They are executed in phases such that each phase -involves executing the same subsystem-level callback for every device belonging -to the given subsystem before the next phase begins. These phases always run -after tasks have been frozen. +Documentation/driver-api/pm/devices.rst. Each of them requires devices to be +handled in a specific way and the PM core executes subsystem-level power +management callbacks for this purpose. They are executed in phases such that +each phase involves executing the same subsystem-level callback for every device +belonging to the given subsystem before the next phase begins. These phases +always run after tasks have been frozen. 2.4.1. System Suspend ^^^^^^^^^^^^^^^^^^^^^ @@ -636,12 +636,12 @@ System restore requires a hibernation image to be loaded into memory and the pre-hibernation memory contents to be restored before the pre-hibernation system activity can be resumed. -As described in Documentation/driver-api/pm/devices.rst, the hibernation image is loaded -into memory by a fresh instance of the kernel, called the boot kernel, which in -turn is loaded and run by a boot loader in the usual way. After the boot kernel -has loaded the image, it needs to replace its own code and data with the code -and data of the "hibernated" kernel stored within the image, called the image -kernel. For this purpose all devices are frozen just like before creating +As described in Documentation/driver-api/pm/devices.rst, the hibernation image +is loaded into memory by a fresh instance of the kernel, called the boot kernel, +which in turn is loaded and run by a boot loader in the usual way. After the +boot kernel has loaded the image, it needs to replace its own code and data with +the code and data of the "hibernated" kernel stored within the image, called the +image kernel. For this purpose all devices are frozen just like before creating the image during hibernation, in the prepare, freeze, freeze_noirq @@ -691,8 +691,8 @@ controlling the runtime power management of their devices. At the time of this writing there are two ways to define power management callbacks for a PCI device driver, the recommended one, based on using a -dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and the -"legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and +dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and +the "legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and .resume() callbacks from struct pci_driver are used. The legacy approach, however, doesn't allow one to define runtime power management callbacks and is not really suitable for any new drivers. Therefore it is not covered by this -- 2.23.0.700.g56cf767bdb-goog