From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM <linux-pm@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Lukas Wunner <lukas@wunner.de>,
Bjorn Helgaas <bhelgaas@google.com>,
Alan Stern <stern@rowland.harvard.edu>,
LKML <linux-kernel@vger.kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Linux Documentation <linux-doc@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Kevin Hilman <khilman@kernel.org>,
Wolfram Sang <wsa@the-dreams.de>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: [Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
Date: Mon, 23 Oct 2017 18:37:41 +0200 [thread overview]
Message-ID: <CAPDyKFpYr-W8yni2_OEkYfx1T0=U_9Ru6NYxzBVoeRj253+Gxw@mail.gmail.com> (raw)
In-Reply-To: <11013815.Nxk07oyMGD@aspire.rjw.lan>
On 19 October 2017 at 01:17, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> 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.
>
> To that end, add a driver_flags field to struct dev_pm_info for flags
> that can be set by device drivers at the probe time to inform the PM
> core and/or bus types, PM domains and so on on the capabilities and/or
> preferences of device drivers. Also add two static inline helpers
> for setting that field and testing it against a given set of flags
> and make the driver core clear it automatically on driver remove
> and probe failures.
>
> Define and document two PM driver flags related to the direct-
> complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
> respectively, to indicate to the PM core that the direct-complete
> mechanism should never be used for the device and to inform the
> middle layer code (bus types, PM domains etc) that it can only
> request the PM core to use the direct-complete mechanism for
> the device (by returning a positive value from its ->prepare
> callback) if it also has been requested by the driver.
>
> While at it, make the core check pm_runtime_suspended() when
> setting power.direct_complete so that it doesn't need to be
> checked by ->prepare callbacks.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> -> v2: Change the data type for driver_flags to u32 as suggested by Greg
> and fix a couple of documentation typos pointed out by Lukas.
>
> ---
> Documentation/driver-api/pm/devices.rst | 14 ++++++++++++++
> Documentation/power/pci.txt | 19 +++++++++++++++++++
> drivers/acpi/device_pm.c | 3 +++
> drivers/base/dd.c | 2 ++
> drivers/base/power/main.c | 4 +++-
> drivers/pci/pci-driver.c | 5 ++++-
> include/linux/device.h | 10 ++++++++++
> include/linux/pm.h | 20 ++++++++++++++++++++
> 8 files changed, 75 insertions(+), 2 deletions(-)
>
> Index: linux-pm/include/linux/device.h
> ===================================================================
> --- linux-pm.orig/include/linux/device.h
> +++ linux-pm/include/linux/device.h
> @@ -1070,6 +1070,16 @@ static inline void dev_pm_syscore_device
> #endif
> }
>
> +static inline void dev_pm_set_driver_flags(struct device *dev, u32 flags)
> +{
> + dev->power.driver_flags = flags;
> +}
> +
> +static inline bool dev_pm_test_driver_flags(struct device *dev, u32 flags)
> +{
> + return !!(dev->power.driver_flags & flags);
> +}
> +
> static inline void device_lock(struct device *dev)
> {
> mutex_lock(&dev->mutex);
> Index: linux-pm/include/linux/pm.h
> ===================================================================
> --- linux-pm.orig/include/linux/pm.h
> +++ linux-pm/include/linux/pm.h
> @@ -550,6 +550,25 @@ struct pm_subsys_data {
> #endif
> };
>
> +/*
> + * Driver flags to control system suspend/resume behavior.
> + *
> + * These flags can be set by device drivers at the probe time. They need not be
> + * cleared by the drivers as the driver core will take care of that.
> + *
> + * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
> + * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
> + *
> + * Setting SMART_PREPARE instructs bus types and PM domains which may want
> + * system suspend/resume callbacks to be skipped for the device to return 0 from
> + * their ->prepare callbacks if the driver's ->prepare callback returns 0 (in
> + * other words, the system suspend/resume callbacks can only be skipped for the
> + * device if its driver doesn't object against that). This flag has no effect
> + * if NEVER_SKIP is set.
In principle ACPI/PCI middle-layer/PM domain could have started out by
respecting the return values from driver's ->prepare() callbacks in
case those existed, but they didn't, and that is the reason to why the
SMART_PREPARE is needed. Right?
My point is, I don't think we should encourage other middle-layer to
support the SMART_PREPARE flag, simply because they should be able to
cope without it. To make this more obvious we could try to find a
different name of the flag indicating that, or at least make it clear
that we don't want it to be used by others than ACPI/PCI via
documenting that.
> + */
> +#define DPM_FLAG_NEVER_SKIP BIT(0)
> +#define DPM_FLAG_SMART_PREPARE BIT(1)
> +
> struct dev_pm_info {
> pm_message_t power_state;
> unsigned int can_wakeup:1;
> @@ -561,6 +580,7 @@ struct dev_pm_info {
> bool is_late_suspended:1;
> bool early_init:1; /* Owned by the PM core */
> bool direct_complete:1; /* Owned by the PM core */
> + u32 driver_flags;
> spinlock_t lock;
> #ifdef CONFIG_PM_SLEEP
> struct list_head entry;
> Index: linux-pm/drivers/base/dd.c
> ===================================================================
> --- linux-pm.orig/drivers/base/dd.c
> +++ linux-pm/drivers/base/dd.c
> @@ -464,6 +464,7 @@ pinctrl_bind_failed:
> if (dev->pm_domain && dev->pm_domain->dismiss)
> dev->pm_domain->dismiss(dev);
> pm_runtime_reinit(dev);
> + dev_pm_set_driver_flags(dev, 0);
>
> switch (ret) {
> case -EPROBE_DEFER:
> @@ -869,6 +870,7 @@ static void __device_release_driver(stru
> if (dev->pm_domain && dev->pm_domain->dismiss)
> dev->pm_domain->dismiss(dev);
> pm_runtime_reinit(dev);
> + dev_pm_set_driver_flags(dev, 0);
>
> klist_remove(&dev->p->knode_driver);
> device_pm_check_callbacks(dev);
> Index: linux-pm/drivers/base/power/main.c
> ===================================================================
> --- linux-pm.orig/drivers/base/power/main.c
> +++ linux-pm/drivers/base/power/main.c
> @@ -1700,7 +1700,9 @@ unlock:
> * applies to suspend transitions, however.
> */
> spin_lock_irq(&dev->power.lock);
> - dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND;
> + dev->power.direct_complete = state.event == PM_EVENT_SUSPEND &&
> + pm_runtime_suspended(dev) && ret > 0 &&
> + !dev_pm_test_driver_flags(dev, DPM_FLAG_NEVER_SKIP);
> spin_unlock_irq(&dev->power.lock);
> return 0;
> }
> Index: linux-pm/drivers/pci/pci-driver.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-driver.c
> +++ linux-pm/drivers/pci/pci-driver.c
> @@ -682,8 +682,11 @@ static int pci_pm_prepare(struct device
>
> if (drv && drv->pm && drv->pm->prepare) {
> int error = drv->pm->prepare(dev);
> - if (error)
> + if (error < 0)
> return error;
> +
> + if (!error && dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_PREPARE))
> + return 0;
> }
> return pci_dev_keep_suspended(to_pci_dev(dev));
> }
> Index: linux-pm/drivers/acpi/device_pm.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/device_pm.c
> +++ linux-pm/drivers/acpi/device_pm.c
> @@ -965,6 +965,9 @@ int acpi_subsys_prepare(struct device *d
> if (ret < 0)
> return ret;
>
> + if (!ret && dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_PREPARE))
> + return 0;
So if the driver don't implement the ->prepare() callback, you still
want to treat this flag as it has one assigned and that it returns 0?
It seems not entirely according to what you have documented about the flag.
> +
> if (!adev || !pm_runtime_suspended(dev))
> return 0;
>
> Index: linux-pm/Documentation/driver-api/pm/devices.rst
> ===================================================================
> --- linux-pm.orig/Documentation/driver-api/pm/devices.rst
> +++ linux-pm/Documentation/driver-api/pm/devices.rst
> @@ -354,6 +354,20 @@ the phases are: ``prepare``, ``suspend``
> is because all such devices are initially set to runtime-suspended with
> runtime PM disabled.
>
> + This feature also can be controlled by device drivers by using the
> + ``DPM_FLAG_NEVER_SKIP`` and ``DPM_FLAG_SMART_PREPARE`` driver power
> + management flags. [Typically, they are set at the time the driver is
> + probed against the device in question by passing them to the
> + :c:func:`dev_pm_set_driver_flags` helper function.] If the first of
> + these flags is set, the PM core will not apply the direct-complete
> + procedure described above to the given device and, consequenty, to any
> + of its ancestors. The second flag, when set, informs the middle layer
> + code (bus types, device types, PM domains, classes) that it should take
> + the return value of the ``->prepare`` callback provided by the driver
> + into account and it may only return a positive value from its own
> + ``->prepare`` callback if the driver's one also has returned a positive
> + value.
> +
> 2. The ``->suspend`` methods should quiesce the device to stop it from
> performing I/O. They also may save the device registers and put it into
> the appropriate low-power state, depending on the bus type the device is
> Index: linux-pm/Documentation/power/pci.txt
> ===================================================================
> --- linux-pm.orig/Documentation/power/pci.txt
> +++ linux-pm/Documentation/power/pci.txt
> @@ -961,6 +961,25 @@ dev_pm_ops to indicate that one suspend
> .suspend(), .freeze(), and .poweroff() members and one resume routine is to
> be pointed to by the .resume(), .thaw(), and .restore() members.
>
> +3.1.19. Driver Flags for Power Management
> +
> +The PM core allows device drivers to set flags that influence the handling of
> +power management for the devices by the core itself and by middle layer code
> +including the PCI bus type. The flags should be set once at the driver probe
> +time with the help of the dev_pm_set_driver_flags() function and they should not
> +be updated directly afterwards.
I am wondering if we really need to make a statement generic to all
"driver PM flags" that these flags must be set at ->probe(). Maybe
that is better documented per flag, rather than for all. The reason
why I bring it up, is that I would not be surprised if a new flag
comes a long and which may be used a bit differently, not requiring
that.
Of course we can also update that later on, if needed.
> +
> +The DPM_FLAG_NEVER_SKIP flag prevents the PM core from using the direct-complete
> +mechanism allowing device suspend/resume callbacks to be skipped if the device
> +is in runtime suspend when the system suspend starts. That also affects all of
> +the ancestors of the device, so this flag should only be used if absolutely
> +necessary.
> +
> +The DPM_FLAG_SMART_PREPARE flag instructs the PCI bus type to only return a
> +positive value from pci_pm_prepare() if the ->prepare callback provided by the
> +driver of the device returns a positive value. That allows the driver to opt
> +out from using the direct-complete mechanism dynamically.
> +
> 3.2. Device Runtime Power Management
> ------------------------------------
> In addition to providing device power management callbacks PCI device drivers
>
Kind regards
Uffe
next prev parent reply other threads:[~2017-10-23 16:37 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 1:12 [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags Rafael J. Wysocki
2017-10-16 5:34 ` Lukas Wunner
2017-10-16 22:03 ` Rafael J. Wysocki
2017-10-16 6:28 ` Greg Kroah-Hartman
2017-10-16 22:05 ` Rafael J. Wysocki
2017-10-17 7:15 ` Greg Kroah-Hartman
2017-10-17 15:26 ` Rafael J. Wysocki
2017-10-18 6:56 ` Greg Kroah-Hartman
2017-10-16 6:31 ` Greg Kroah-Hartman
2017-10-16 22:07 ` Rafael J. Wysocki
2017-10-17 13:26 ` Greg Kroah-Hartman
2017-10-16 20:16 ` Alan Stern
2017-10-16 22:11 ` Rafael J. Wysocki
2017-10-18 23:17 ` [Update][PATCH v2 " Rafael J. Wysocki
2017-10-19 7:33 ` Greg Kroah-Hartman
2017-10-20 11:11 ` Rafael J. Wysocki
2017-10-20 11:35 ` Greg Kroah-Hartman
2017-10-20 11:28 ` Rafael J. Wysocki
2017-10-23 16:37 ` Ulf Hansson [this message]
2017-10-23 20:41 ` Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 02/12] PCI / PM: Use the NEVER_SKIP driver flag Rafael J. Wysocki
2017-10-23 16:40 ` Ulf Hansson
2017-10-16 1:29 ` [PATCH 03/12] PM: i2c-designware-platdrv: Use DPM_FLAG_SMART_PREPARE Rafael J. Wysocki
2017-10-23 16:57 ` Ulf Hansson
2017-10-16 1:29 ` [PATCH 04/12] PM / core: Add SMART_SUSPEND driver flag Rafael J. Wysocki
2017-10-23 19:01 ` Ulf Hansson
2017-10-24 5:22 ` Ulf Hansson
2017-10-24 8:55 ` Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 05/12] PCI / PM: Drop unnecessary invocations of pcibios_pm_ops callbacks Rafael J. Wysocki
2017-10-23 19:06 ` Ulf Hansson
2017-10-16 1:29 ` [PATCH 06/12] PCI / PM: Take SMART_SUSPEND driver flag into account Rafael J. Wysocki
2017-10-16 1:29 ` [PATCH 07/12] ACPI / LPSS: Consolidate runtime PM and system sleep handling Rafael J. Wysocki
2017-10-23 19:09 ` Ulf Hansson
2017-10-16 1:30 ` [PATCH 08/12] ACPI / PM: Take SMART_SUSPEND driver flag into account Rafael J. Wysocki
2017-10-16 1:30 ` [PATCH 09/12] PM / mfd: intel-lpss: Use DPM_FLAG_SMART_SUSPEND Rafael J. Wysocki
2017-10-31 15:09 ` Lee Jones
2017-10-31 16:28 ` Rafael J. Wysocki
2017-11-01 9:28 ` Lee Jones
2017-11-01 20:26 ` Rafael J. Wysocki
2017-11-08 11:08 ` Lee Jones
2017-10-16 1:30 ` [PATCH 10/12] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-10-23 19:38 ` Ulf Hansson
2017-10-16 1:31 ` [PATCH 11/12] PM: i2c-designware-platdrv: Optimize power management Rafael J. Wysocki
2017-10-26 20:41 ` Wolfram Sang
2017-10-26 21:14 ` Rafael J. Wysocki
2017-10-16 1:32 ` [PATCH 12/12] PM / core: Add AVOID_RPM driver flag Rafael J. Wysocki
2017-10-17 15:33 ` Andy Shevchenko
2017-10-17 15:59 ` Rafael J. Wysocki
2017-10-17 16:25 ` Andy Shevchenko
2017-10-16 7:08 ` [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume Greg Kroah-Hartman
2017-10-16 21:50 ` Rafael J. Wysocki
2017-10-17 8:36 ` Ulf Hansson
2017-10-17 15:25 ` Rafael J. Wysocki
2017-10-17 19:41 ` Ulf Hansson
2017-10-17 20:12 ` Alan Stern
2017-10-17 23:07 ` Rafael J. Wysocki
2017-10-18 0:39 ` Rafael J. Wysocki
2017-10-18 10:24 ` Rafael J. Wysocki
2017-10-18 12:34 ` Ulf Hansson
2017-10-18 21:54 ` Rafael J. Wysocki
2017-10-18 11:57 ` Ulf Hansson
2017-10-18 13:00 ` Rafael J. Wysocki
2017-10-18 14:11 ` Ulf Hansson
2017-10-18 19:45 ` Grygorii Strashko
2017-10-18 21:48 ` Rafael J. Wysocki
2017-10-19 8:33 ` Ulf Hansson
2017-10-19 17:21 ` Grygorii Strashko
2017-10-19 18:04 ` Ulf Hansson
2017-10-19 18:11 ` Ulf Hansson
2017-10-19 21:31 ` Grygorii Strashko
2017-10-20 6:05 ` Ulf Hansson
2017-10-18 22:12 ` Rafael J. Wysocki
2017-10-19 12:21 ` Ulf Hansson
2017-10-19 18:01 ` Ulf Hansson
2017-10-20 1:19 ` Rafael J. Wysocki
2017-10-20 5:57 ` Ulf Hansson
2017-10-20 20:46 ` Bjorn Helgaas
2017-10-21 1:04 ` Rafael J. Wysocki
2017-10-27 22:11 ` [PATCH v2 0/6] PM / sleep: Driver flags for system suspend/resume (part 1) Rafael J. Wysocki
2017-10-27 22:17 ` [PATCH v2 1/6] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags Rafael J. Wysocki
2017-11-06 8:07 ` Ulf Hansson
2017-10-27 22:19 ` [PATCH v2 2/6] PCI / PM: Use the NEVER_SKIP driver flag Rafael J. Wysocki
2017-10-27 22:22 ` [PATCH v2 3/6] PM / core: Add SMART_SUSPEND " Rafael J. Wysocki
2017-11-06 8:09 ` Ulf Hansson
2017-11-06 11:23 ` Rafael J. Wysocki
2017-10-27 22:23 ` [PATCH v2 4/6] PCI / PM: Drop unnecessary invocations of pcibios_pm_ops callbacks Rafael J. Wysocki
2017-10-27 22:27 ` [PATCH v2 5/6] PCI / PM: Take SMART_SUSPEND driver flag into account Rafael J. Wysocki
2017-10-31 22:48 ` Bjorn Helgaas
2017-10-27 22:30 ` [PATCH v2 6/6] ACPI " Rafael J. Wysocki
2017-11-08 0:41 ` [PATCH v2 0/6] PM / sleep: Driver flags for system suspend/resume (part 2) Rafael J. Wysocki
2017-11-08 13:25 ` [PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-11-10 9:09 ` Ulf Hansson
2017-11-10 23:45 ` Rafael J. Wysocki
2017-11-11 0:41 ` Rafael J. Wysocki
2017-11-11 1:36 ` Rafael J. Wysocki
2017-11-14 16:07 ` Ulf Hansson
2017-11-15 1:48 ` Rafael J. Wysocki
2017-11-16 10:18 ` Ulf Hansson
2017-11-08 13:28 ` [PATCH v2 2/6] PCI / PM: Support for " Rafael J. Wysocki
2017-11-08 20:38 ` Bjorn Helgaas
2017-11-08 21:09 ` Rafael J. Wysocki
2017-11-08 13:34 ` [PATCH v2 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain Rafael J. Wysocki
2017-11-08 13:37 ` [PATCH v2 4/6] PM / core: Add helpers for subsystem callback selection Rafael J. Wysocki
2017-11-08 13:38 ` [PATCH v2 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki
2017-11-08 13:39 ` [PATCH v2 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization Rafael J. Wysocki
2017-11-12 0:34 ` [PATCH v3 0/6] PM / sleep: Driver flags for system suspend/resume (part 2) Rafael J. Wysocki
2017-11-12 0:37 ` [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-11-16 15:10 ` Ulf Hansson
2017-11-16 23:07 ` Rafael J. Wysocki
2017-11-17 6:11 ` Ulf Hansson
2017-11-17 13:18 ` Rafael J. Wysocki
2017-11-17 13:49 ` Ulf Hansson
2017-11-17 14:31 ` Rafael J. Wysocki
2017-11-17 15:57 ` Ulf Hansson
2017-11-17 12:45 ` Rafael J. Wysocki
2017-11-12 0:40 ` [PATCH v3 2/6] PCI / PM: Support for " Rafael J. Wysocki
2017-11-12 0:40 ` [PATCH v3 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain Rafael J. Wysocki
2017-11-12 0:42 ` [PATCH v3 4/6] PM / core: Add helpers for subsystem callback selection Rafael J. Wysocki
2017-11-15 7:43 ` Ulf Hansson
2017-11-15 17:55 ` Rafael J. Wysocki
2017-11-12 0:43 ` [PATCH v3 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki
2017-11-12 0:44 ` [PATCH v3 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization Rafael J. Wysocki
2017-11-18 14:27 ` [PATCH v4 0/6] PM / sleep: Driver flags for system suspend/resume (part 2) Rafael J. Wysocki
2017-11-18 14:31 ` [PATCH v4 1/6] PM / core: Add LEAVE_SUSPENDED driver flag Rafael J. Wysocki
2017-11-20 12:25 ` Ulf Hansson
2017-11-21 0:16 ` Rafael J. Wysocki
2017-11-18 14:33 ` [PATCH v4 2/6] PCI / PM: Support for " Rafael J. Wysocki
2017-11-18 14:35 ` [PATCH v4 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain Rafael J. Wysocki
2017-11-18 14:37 ` [PATCH v4 4/6] PM / core: Add helpers for subsystem callback selection Rafael J. Wysocki
2017-11-18 14:41 ` [PATCH v4 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED Rafael J. Wysocki
2017-11-20 13:42 ` Ulf Hansson
2017-11-22 1:10 ` Rafael J. Wysocki
2017-11-22 1:28 ` Rafael J. Wysocki
2017-11-18 14:44 ` [PATCH v4 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPDyKFpYr-W8yni2_OEkYfx1T0=U_9Ru6NYxzBVoeRj253+Gxw@mail.gmail.com' \
--to=ulf.hansson@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=rjw@rjwysocki.net \
--cc=stern@rowland.harvard.edu \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).