From: Amit Pundir <amit.pundir@linaro.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Marcel Holtmann <marcel@holtmann.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Kalle Valo <kvalo@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Saravana Kannan <saravanak@google.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Arnd Bergmann <arnd@arndb.de>,
Neil Armstrong <neil.armstrong@linaro.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Alex Elder <elder@linaro.org>,
Srini Kandagatla <srinivas.kandagatla@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Abel Vesa <abel.vesa@linaro.org>,
Manivannan Sadhasivam <mani@kernel.org>,
Lukas Wunner <lukas@wunner.de>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
linux-pm@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users
Date: Tue, 5 Mar 2024 18:20:50 +0530 [thread overview]
Message-ID: <CAMi1Hd0D_jSHtcurh1R7uf=jpe2Lkn0yNxrEii2pNc0=ARU_FQ@mail.gmail.com> (raw)
In-Reply-To: <20240216203215.40870-1-brgl@bgdev.pl>
On Sat, 17 Feb 2024 at 02:03, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> First, I'd like to apologize for the somewhat chaotic previous iterations
> of this series and improper versioning which was rightfully pointed out
> to me. I figured that the scope changed so much that it didn't make sense
> to consider previous submissions part of the same series as the original
> RFC but others thought otherwise so this one becomes v5 and I'll keep the
> versioning going forward.
>
> This is the summary of the work so far:
>
> v1: Original RFC:
>
> https://lore.kernel.org/lkml/20240104130123.37115-1-brgl@bgdev.pl/T/
>
> v2: First real patch series (should have been PATCH v2) adding what I
> referred to back then as PCI power sequencing:
>
> https://lore.kernel.org/linux-arm-kernel/2024021413-grumbling-unlivable-c145@gregkh/T/
>
> v3: RFC for the DT representation of the PMU supplying the WLAN and BT
> modules inside the QCA6391 package (was largely separate from the
> series but probably should have been called PATCH or RFC v3):
>
> https://lore.kernel.org/all/CAMRc=Mc+GNoi57eTQg71DXkQKjdaoAmCpB=h2ndEpGnmdhVV-Q@mail.gmail.com/T/
>
> v4: Second attempt at the full series with changed scope (introduction of
> the pwrseq subsystem, should have been RFC v4)
>
> https://lore.kernel.org/lkml/20240201155532.49707-1-brgl@bgdev.pl/T/
>
> ===
>
> With that out of the way, I'd like to get down to explaining the two
> problems I'm trying to solve.
>
> Problem statement #1: Dynamic bus chicken-and-egg problem.
>
> Certain on-board PCI devices need to be powered up before they are can be
> detected but their PCI drivers won't get bound until the device is
> powered-up so enabling the relevant resources in the PCI device driver
> itself is impossible.
>
> Problem statement #2: Sharing inter-dependent resources between devices.
>
> Certain devices that use separate drivers (often on different busses)
> share resources (regulators, clocks, etc.). Typically these resources
> are reference-counted but in some cases there are additional interactions
> between them to consider, for example specific power-up sequence timings.
>
> ===
>
> The reason for tackling both of these problems in a single series is the
> fact the the platform I'm working on - Qualcomm RB5 - deals with both and
> both need to be addressed in order to enable WLAN and Bluetooth support
> upstream.
>
> The on-board WLAN/BT package - QCA6391 - has a Power Management Unit that
> takes inputs from the host and exposes LDO outputs consumed by the BT and
> WLAN modules which can be powered-up and down independently. However
> a delay of 100ms must be respected between enabling the BT- and
> WLAN-enable GPIOs[*].
>
> ===
>
> This series is logically split into several sections. I'll go
> patch-by-patch and explain each step.
>
> Patch 1/18:
>
> This is a commit taken from the list by Jonathan Cameron that adds
> a __free() helper for OF nodes. Not strictly related to the series but
> until said commit ends in next, I need to carry it with this series.
>
> Patch 2/18:
>
> This enables the ath12k PCI module in arm64 defconfig as Qualcomm sm8650
> and sm8550 reference platforms use it in the WCN7850 module.
>
> Patches 3/18-6/18:
>
> These contain all relevant DT bindings changes. We add new documents for
> the QCA6390 PMU and ATH12K devices as well as extend the bindings for the
> Qualcomm Bluetooth and ATH11K modules with regulators used by them in
> QCA6390.
>
> Patches 7/18-9/18:
>
> These contain changes to device-tree sources for the three platforms we
> work with in this series. As the WCN7850 module doesn't require any
> specific timings introducing dependencies between the Bluetooth and WLAN
> modules, while the QCA6390 does, we take two different approaches to how
> me model them in DT.
>
> For WCN7850 we hide the existence of the PMU as modeling it is simply not
> necessary. The BT and WLAN devices on the device-tree are represented as
> consuming the inputs (relevant to the functionality of each) of the PMU
> directly.
>
> For QCA6390 on RB5 we add the PMU node as a platform device. It consumes
> regulators and GPIOs from the host and exposed regulators consumer in turn
> by the BT and WLAN modules. This represents the internal structure of the
> package.
>
> Patches 10/18-14/18:
>
> These contain the bulk of the PCI changes for this series. We introduce
> a simple framework for powering up PCI devices before detecting them on
> the bus and the first user of this library in the form of the WCN7850 PCI
> power control driver.
>
> The general approach is as follows: PCI devices that need special
> treatment before they can be powered up, scanned and bound to their PCI
> drivers must be described on the device-tree as child nodes of the PCI
> port node. These devices will be instantiated on the platform bus. They
> will in fact be generic platform devices with the compatible of the form
> used for PCI devices already upstream ("pci<vendor ID>,<device ID">). We
> add a new directory under drivers/pci/pwrctl/ that contains PCI pwrctl
> drivers. These drivers are platform drivers that will now be matched
> against the devices instantiated from port children just like any other
> platform pairs.
>
> Both the power control platform device *AND* the associated PCI device
> reuse the same OF node and have access to the same properties. The goal
> of the platform driver is to request and bring up any required resources
> and let the pwrctl framework know that it's now OK to rescan the bus and
> detect the devices. When the device is bound, we are notified about it
> by the PCI bus notifier event and can establish a device link between the
> power control device and the PCI device so that any future extension for
> power-management will already be able to work with the correct hierachy.
>
> The reusing of the OF node is the reason for the small changes to the PCI
> OF core: as the bootloader can possibly leave the relevant regulators on
> before booting linux, the PCI device can be detected before its platform
> abstraction is probed. In this case, we find that device first and mark
> its OF node as reused. The pwrctl framework handles the opposite case
> (when the PCI device is detected only after the platform driver
> successfully enabled it).
>
> Patches 15/18-16/18:
>
> These add a relatively simple power sequencing subsystem and the first
> driver using it: the pwrseq module for the QCA6390 PMU.
>
> For the record: Bjorn suggested a different solution: a regulator driver
> that would - based on which regulators are enabled by a consumer - enable
> relevant resources (drive the enable GPIOs) while respecting the
> HW-specific delays. This would however require significant and yet
> unprecised changed to the regulator subsystem as well as be an abuse of
> the regulator provider API akin to using the reset framework for power
> sequencing as proposed before.
>
> Instead I'm proposing to add a subsystem that allows different devices to
> use a shared power sequence split into consumer-specific as well as
> common "units".
>
> A power sequence provider driver registers a set of units with pwrseq
> core. Each unit can be enabled and disabled and contains an optional list
> of other units which must be enabled before it itself can be. A unit
> represents a discreet chunk of the power sequence.
>
> It also registers a list of targets: a target is an abstraction wrapping
> a unit which allows consumers to tell pwrseq which unit they want to
> reach. Real-life example is the driver we're adding here: there's a set
> of common regulators, two PCIe-specific ones and two enable GPIOs: one
> for Bluetooth and one for WLAN.
>
> The Bluetooth driver requests a descriptor to the power sequencer and
> names the target it wants to reach:
>
> pwrseq = devm_pwrseq_get(dev, "bluetooth");
>
> The pwrseq core then knows that when the driver calls:
>
> pwrseq_power_on(pwrseq);
>
> It must enable the "bluetooth-enable" unit but it depends on the
> "regulators-common" unit so this one is enabled first. The provider
> driver is also in charge of assuring an appropriate delay between
> enabling the BT and WLAN enable GPIOs. The WLAN-specific resources are
> handled by the "wlan-enable" unit and so are not enabled until the WLAN
> driver requests the "wlan" target to be powered on.
>
> Another thing worth discussing is the way we associate the consumer with
> the relevant power sequencer. DT maintainers have expressed a discontent
> with the existing mmc pwrseq bindings and have NAKed an earlier
> initiative to introduce global pwrseq bindings to the kernel[1].
>
> In this approach, we model the existing regulators and GPIOs in DT but
> the pwrseq subsystem requires each provider to provide a .match()
> callback. Whenever a consumer requests a power sequencer handle, we
> iterate over the list of pwrseq drivers and call .match() for each. It's
> up to the driver to verify in a platform-specific way whether it deals
> with its consumer and let the core pwrseq code know.
>
> The advantage of this over reusing the regulator or reset subsystem is
> that it's more generalized and can handle resources of all kinds as well
> as deal with any kind of power-on sequences: for instance, Qualcomm has
> a PCI switch they want a driver for but this switch requires enabling
> some resources first (PCI pwrctl) and then configuring the device over
> I2C (which can be handled by the pwrseq provider).
>
> Patch 17/18:
>
> This patch makes the Qualcomm Bluetooth driver get and use the power
> sequencer for QCA6390.
>
> Patch 18/18:
>
> While tiny, this patch is possibly the highlight of the entire series.
> It uses the two abstraction layers we introduced before to create an
> elegant power sequencing PCI power control driver and supports the ath11k
> module on QCA6390.
>
> With this series we can now enable BT and WLAN on several new Qualcomm
> boards upstream.
>
> I tested the series on RB5 while Neil tested it on sm8650-qrd and
> sm8550-qrd.
Tested-by: Amit Pundir <amit.pundir@linaro.org> # On RB5 running AOSP
>
> Best Regards,
> Bartosz Golaszewski
>
> It's hard to list the changes between versions here as the scope changed
> significantly between each iteration and some versions were not even full
> series but rather RFCs for parts of the solution. For this reason, I'll
> only start listing changes starting from v6.
>
> [*] This is what the docs say. In practice it seems that this delay can be
> ignored. However the subsequent model - QCA6490 - *does* require users to
> respect it, so the problem remains valid.
>
> [1] https://lore.kernel.org/netdev/20210829131305.534417-1-dmitry.baryshkov@linaro.org/
>
> Bartosz Golaszewski (15):
> arm64: defconfig: enable ath12k as a module
> dt-bindings: regulator: describe the PMU module of the QCA6390 package
> dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
> dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on
> QCA6390
> dt-bindings: new: wireless: describe the ath12k PCI module
> arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391
> PCI: hold the rescan mutex when scanning for the first time
> PCI/pwrctl: reuse the OF node for power controlled devices
> PCI/pwrctl: create platform devices for child OF nodes of the port
> node
> PCI/pwrctl: add PCI power control core code
> PCI/pwrctl: add a power control driver for WCN7850
> power: sequencing: implement the pwrseq core
> power: pwrseq: add a driver for the QCA6390 PMU module
> Bluetooth: qca: use the power sequencer for QCA6390
> PCI/pwrctl: add a PCI power control driver for power sequenced devices
>
> Jonathan Cameron (1):
> of: Add cleanup.h based auto release via __free(device_node) markings.
>
> Neil Armstrong (2):
> arm64: dts: qcom: sm8550-qrd: add the Wifi node
> arm64: dts: qcom: sm8650-qrd: add the Wifi node
>
> .../net/bluetooth/qualcomm-bluetooth.yaml | 17 +
> .../net/wireless/qcom,ath11k-pci.yaml | 28 +
> .../net/wireless/qcom,ath12k-pci.yaml | 103 ++
> .../bindings/regulator/qcom,qca6390-pmu.yaml | 166 +++
> MAINTAINERS | 8 +
> arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 123 +-
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 10 +
> arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 37 +
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 10 +
> arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 29 +
> arch/arm64/boot/dts/qcom/sm8650.dtsi | 10 +
> arch/arm64/configs/defconfig | 1 +
> drivers/bluetooth/hci_qca.c | 31 +
> drivers/pci/Kconfig | 1 +
> drivers/pci/Makefile | 1 +
> drivers/pci/bus.c | 9 +-
> drivers/pci/of.c | 14 +-
> drivers/pci/probe.c | 2 +
> drivers/pci/pwrctl/Kconfig | 25 +
> drivers/pci/pwrctl/Makefile | 7 +
> drivers/pci/pwrctl/core.c | 136 +++
> drivers/pci/pwrctl/pci-pwrctl-pwrseq.c | 84 ++
> drivers/pci/pwrctl/pci-pwrctl-wcn7850.c | 202 ++++
> drivers/pci/remove.c | 2 +
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/sequencing/Kconfig | 28 +
> drivers/power/sequencing/Makefile | 6 +
> drivers/power/sequencing/core.c | 1065 +++++++++++++++++
> drivers/power/sequencing/pwrseq-qca6390.c | 353 ++++++
> include/linux/of.h | 2 +
> include/linux/pci-pwrctl.h | 51 +
> include/linux/pwrseq/consumer.h | 56 +
> include/linux/pwrseq/provider.h | 75 ++
> 34 files changed, 2678 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k-pci.yaml
> create mode 100644 Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
> create mode 100644 drivers/pci/pwrctl/Kconfig
> create mode 100644 drivers/pci/pwrctl/Makefile
> create mode 100644 drivers/pci/pwrctl/core.c
> create mode 100644 drivers/pci/pwrctl/pci-pwrctl-pwrseq.c
> create mode 100644 drivers/pci/pwrctl/pci-pwrctl-wcn7850.c
> create mode 100644 drivers/power/sequencing/Kconfig
> create mode 100644 drivers/power/sequencing/Makefile
> create mode 100644 drivers/power/sequencing/core.c
> create mode 100644 drivers/power/sequencing/pwrseq-qca6390.c
> create mode 100644 include/linux/pci-pwrctl.h
> create mode 100644 include/linux/pwrseq/consumer.h
> create mode 100644 include/linux/pwrseq/provider.h
>
> --
> 2.40.1
>
>
prev parent reply other threads:[~2024-03-05 12:51 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-16 20:31 [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users Bartosz Golaszewski
2024-02-16 20:31 ` [PATCH v5 01/18] of: Add cleanup.h based auto release via __free(device_node) markings Bartosz Golaszewski
2024-02-16 20:31 ` [PATCH v5 02/18] arm64: defconfig: enable ath12k as a module Bartosz Golaszewski
2024-02-19 7:31 ` Krzysztof Kozlowski
2024-02-19 7:56 ` Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 03/18] dt-bindings: regulator: describe the PMU module of the QCA6390 package Bartosz Golaszewski
2024-02-17 15:48 ` Mark Brown
2024-02-17 18:32 ` Bartosz Golaszewski
2024-02-17 20:43 ` Mark Brown
2024-02-19 7:32 ` Krzysztof Kozlowski
2024-02-19 12:53 ` Bartosz Golaszewski
2024-02-19 21:23 ` Krzysztof Kozlowski
2024-02-19 7:34 ` Krzysztof Kozlowski
2024-02-16 20:32 ` [PATCH v5 04/18] dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390 Bartosz Golaszewski
2024-02-19 7:34 ` Krzysztof Kozlowski
2024-02-16 20:32 ` [PATCH v5 05/18] dt-bindings: new: wireless: qcom,ath11k: describe the ath11k on QCA6390 Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 06/18] dt-bindings: new: wireless: describe the ath12k PCI module Bartosz Golaszewski
2024-02-17 6:34 ` Kalle Valo
2024-02-17 18:30 ` Bartosz Golaszewski
2024-02-17 20:02 ` Jeff Johnson
2024-02-19 7:38 ` Krzysztof Kozlowski
2024-02-22 23:56 ` Rob Herring
2024-02-16 20:32 ` [PATCH v5 07/18] arm64: dts: qcom: sm8550-qrd: add the Wifi node Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 08/18] arm64: dts: qcom: sm8650-qrd: " Bartosz Golaszewski
2024-02-16 23:09 ` Dmitry Baryshkov
2024-02-17 18:53 ` Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391 Bartosz Golaszewski
2024-02-19 18:03 ` Mark Brown
2024-02-19 18:48 ` Bartosz Golaszewski
2024-02-19 19:59 ` Mark Brown
2024-02-20 11:16 ` Bartosz Golaszewski
2024-02-20 13:31 ` Mark Brown
2024-02-20 13:38 ` Bartosz Golaszewski
2024-02-20 13:48 ` Mark Brown
2024-02-20 13:51 ` Bartosz Golaszewski
2024-02-20 14:10 ` Mark Brown
2024-02-20 16:30 ` Dmitry Baryshkov
2024-02-20 17:53 ` Bartosz Golaszewski
2024-02-20 18:11 ` Dmitry Baryshkov
2024-02-16 20:32 ` [PATCH v5 10/18] PCI: hold the rescan mutex when scanning for the first time Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 11/18] PCI/pwrctl: reuse the OF node for power controlled devices Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 12/18] PCI/pwrctl: create platform devices for child OF nodes of the port node Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 13/18] PCI/pwrctl: add PCI power control core code Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 14/18] PCI/pwrctl: add a power control driver for WCN7850 Bartosz Golaszewski
2024-02-19 17:49 ` Mark Brown
2024-02-20 11:22 ` Bartosz Golaszewski
2024-02-20 12:47 ` Mark Brown
2024-02-20 21:21 ` Konrad Dybcio
2024-02-20 23:44 ` Mark Brown
2024-02-22 9:22 ` Bartosz Golaszewski
2024-02-22 12:21 ` Mark Brown
2024-02-22 12:26 ` Bartosz Golaszewski
2024-02-22 13:15 ` Mark Brown
2024-02-22 13:26 ` Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 15/18] power: sequencing: implement the pwrseq core Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 16/18] power: pwrseq: add a driver for the QCA6390 PMU module Bartosz Golaszewski
2024-02-16 23:17 ` Dmitry Baryshkov
2024-02-17 19:09 ` Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 17/18] Bluetooth: qca: use the power sequencer for QCA6390 Bartosz Golaszewski
2024-02-16 20:32 ` [PATCH v5 18/18] PCI/pwrctl: add a PCI power control driver for power sequenced devices Bartosz Golaszewski
2024-02-18 12:53 ` [PATCH v5 00/18] power: sequencing: implement the subsystem and add first users Dmitry Baryshkov
2024-02-19 8:14 ` Neil Armstrong
2024-02-19 9:22 ` Dmitry Baryshkov
2024-02-19 9:42 ` neil.armstrong
2024-02-19 10:26 ` Dmitry Baryshkov
2024-02-19 12:23 ` Bartosz Golaszewski
2024-02-19 12:33 ` Dmitry Baryshkov
2024-02-19 17:18 ` neil.armstrong
2024-02-19 22:21 ` Dmitry Baryshkov
2024-02-22 11:00 ` Bartosz Golaszewski
2024-02-22 11:26 ` Dmitry Baryshkov
2024-02-22 12:27 ` Bartosz Golaszewski
2024-02-22 12:47 ` Dmitry Baryshkov
2024-02-22 12:50 ` Bartosz Golaszewski
2024-02-22 13:46 ` neil.armstrong
2024-02-24 8:52 ` Krzysztof Kozlowski
2024-02-19 8:16 ` Neil Armstrong
2024-03-05 12:50 ` Amit Pundir [this message]
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='CAMi1Hd0D_jSHtcurh1R7uf=jpe2Lkn0yNxrEii2pNc0=ARU_FQ@mail.gmail.com' \
--to=amit.pundir@linaro.org \
--cc=abel.vesa@linaro.org \
--cc=andersson@kernel.org \
--cc=arnd@arndb.de \
--cc=bartosz.golaszewski@linaro.org \
--cc=bhelgaas@google.com \
--cc=brgl@bgdev.pl \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=edumazet@google.com \
--cc=elder@linaro.org \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=lukas@wunner.de \
--cc=m.szyprowski@samsung.com \
--cc=mani@kernel.org \
--cc=marcel@holtmann.org \
--cc=neil.armstrong@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=will@kernel.org \
/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).