From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Linux Doc Mailing List <linux-doc@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: [PATCH 43/53] docs: PCI: acpi-info.rst: avoid using UTF-8 chars
Date: Mon, 10 May 2021 12:26:55 +0200 [thread overview]
Message-ID: <94842f2c0062c71b53144e55c648ec18fdde8eca.1620641727.git.mchehab+huawei@kernel.org> (raw)
In-Reply-To: <cover.1620641727.git.mchehab+huawei@kernel.org>
While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:
- U+00a0 (' '): NO-BREAK SPACE
- U+2013 ('–'): EN DASH
- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
Documentation/PCI/acpi-info.rst | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/PCI/acpi-info.rst b/Documentation/PCI/acpi-info.rst
index 060217081c79..9b4b04039982 100644
--- a/Documentation/PCI/acpi-info.rst
+++ b/Documentation/PCI/acpi-info.rst
@@ -22,9 +22,9 @@ or if the device has INTx interrupts connected by platform interrupt
controllers and a _PRT is needed to describe those connections.
ACPI resource description is done via _CRS objects of devices in the ACPI
-namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
+namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
_CRS and figure out what resource is being consumed even if it doesn't have
-a driver for the device [3]. That's important because it means an old OS
+a driver for the device [3]. That's important because it means an old OS
can work correctly even on a system with new devices unknown to the OS.
The new devices might not do anything, but the OS can at least make sure no
resources conflict with them.
@@ -41,15 +41,15 @@ ACPI, that device will have a specific _HID/_CID that tells the OS what
driver to bind to it, and the _CRS tells the OS and the driver where the
device's registers are.
-PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
-describe all the address space they consume. This includes all the windows
+PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
+describe all the address space they consume. This includes all the windows
they forward down to the PCI bus, as well as registers of the host bridge
-itself that are not forwarded to PCI. The host bridge registers include
+itself that are not forwarded to PCI. The host bridge registers include
things like secondary/subordinate bus registers that determine the bus
range below the bridge, window registers that describe the apertures, etc.
These are all device-specific, non-architected things, so the only way a
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
-the device-specific details. The host bridge registers also include ECAM
+the device-specific details. The host bridge registers also include ECAM
space, since it is consumed by the host bridge.
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
@@ -66,7 +66,7 @@ the PNP0A03/PNP0A08 device itself. The workaround was to describe the
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
With the exception of ECAM, the bridge register space is device-specific
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
-know about it.
+know about it.
New architectures should be able to use "Consumer" Extended Address Space
descriptors in the PNP0A03 device for bridge registers, including ECAM,
@@ -75,9 +75,9 @@ ia64 kernels assume all address space descriptors, including "Consumer"
Extended Address Space ones, are windows, so it would not be safe to
describe bridge registers this way on those architectures.
-PNP0C02 "motherboard" devices are basically a catch-all. There's no
+PNP0C02 "motherboard" devices are basically a catch-all. There's no
programming model for them other than "don't use these resources for
-anything else." So a PNP0C02 _CRS should claim any address space that is
+anything else." So a PNP0C02 _CRS should claim any address space that is
(1) not claimed by _CRS under any other device object in the ACPI namespace
and (2) should not be assigned by the OS to something else.
@@ -125,7 +125,7 @@ address always corresponds to bus 0, even if the bus range below the bridge
requirements of the device. It may also call _CRS to find the current
resource settings for the device. Using this information, the Plug and
Play system determines what resources the device should consume and
- sets those resources by calling the device’s _SRS control method.
+ sets those resources by calling the device's _SRS control method.
In ACPI, devices can consume resources (for example, legacy keyboards),
provide resources (for example, a proprietary PCI bridge), or do both.
@@ -140,8 +140,8 @@ address always corresponds to bus 0, even if the bus range below the bridge
Extended Address Space Descriptor (.4)
General Flags: Bit [0] Consumer/Producer:
- * 1 – This device consumes this resource
- * 0 – This device produces and consumes this resource
+ * 1 - This device consumes this resource
+ * 0 - This device produces and consumes this resource
[5] ACPI 6.2, sec 19.6.43:
ResourceUsage specifies whether the Memory range is consumed by
@@ -156,7 +156,7 @@ address always corresponds to bus 0, even if the bus range below the bridge
4.1.3) must be reserved by declaring a motherboard resource. For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
- the resources in this case should not be claimed in the root PCI bus’s
+ the resources in this case should not be claimed in the root PCI bus's
_CRS. The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.
--
2.30.2
next prev parent reply other threads:[~2021-05-10 10:35 UTC|newest]
Thread overview: 219+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 10:26 [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII Mauro Carvalho Chehab
2021-05-10 10:26 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 10:26 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 01/53] docs: cdrom-standard.rst: get rid of uneeded UTF-8 chars Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 02/53] docs: ABI: remove a meaningless UTF-8 character Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 03/53] docs: ABI: remove some spurious characters Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 04/53] docs: index.rst: avoid using UTF-8 chars Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 05/53] docs: hwmon: " Mauro Carvalho Chehab
2021-05-10 13:30 ` Guenter Roeck
2021-05-10 10:26 ` [PATCH 06/53] docs: admin-guide: " Mauro Carvalho Chehab
2021-05-10 18:40 ` Gabriel Krisman Bertazi
2021-05-12 8:44 ` Mauro Carvalho Chehab
2021-05-12 9:25 ` David Woodhouse
2021-05-12 10:22 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 07/53] docs: admin-guide: media: ipu3.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 08/53] docs: admin-guide: sysctl: kernel.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 09/53] docs: admin-guide: perf: imx-ddr.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 10/53] docs: admin-guide: pm: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 11/53] docs: trace: coresight: coresight-etm4x-reference.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 19:28 ` Mathieu Poirier
2021-05-10 19:28 ` Mathieu Poirier
2021-05-10 10:26 ` [PATCH 12/53] docs: driver-api: " Mauro Carvalho Chehab
[not found] ` <CAHp75Vegsb-+fVppv3C7Jp0a=mEGAh2pchX=Cr5ZvOMFt+G73Q@mail.gmail.com>
2021-05-12 8:49 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 13/53] docs: driver-api: fpga: " Mauro Carvalho Chehab
2021-05-10 17:48 ` Moritz Fischer
2021-05-10 10:26 ` [PATCH 14/53] docs: driver-api: iio: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 15/53] docs: driver-api: thermal: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 16/53] docs: driver-api: media: drivers: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 17/53] docs: driver-api: firmware: other_interfaces.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 18/53] docs: driver-api: nvdimm: btt.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 19/53] docs: fault-injection: nvme-fault-injection.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 20/53] docs: usb: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 21/53] docs: process: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 22/53] docs: block: data-integrity.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 23/53] docs: userspace-api: media: fdl-appendix.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 24/53] docs: userspace-api: media: v4l: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 25/53] docs: userspace-api: media: dvb: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 26/53] docs: vm: zswap.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [f2fs-dev] [PATCH 27/53] docs: filesystems: f2fs.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-11 3:16 ` [f2fs-dev] " Chao Yu
2021-05-11 3:16 ` Chao Yu
2021-05-10 10:26 ` [PATCH 28/53] docs: filesystems: ext4: " Mauro Carvalho Chehab
2021-05-10 19:23 ` Theodore Ts'o
2021-05-10 10:26 ` [PATCH 29/53] docs: kernel-hacking: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 30/53] docs: hid: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 31/53] docs: security: tpm: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 32/53] docs: security: keys: trusted-encrypted.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 33/53] docs: riscv: vm-layout.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 34/53] docs: networking: scaling.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 35/53] docs: networking: devlink: devlink-dpipe.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 36/53] docs: networking: device_drivers: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 37/53] docs: x86: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 38/53] docs: scheduler: sched-deadline.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 39/53] docs: dev-tools: testing-overview.rst: " Mauro Carvalho Chehab
2021-05-10 10:48 ` Marco Elver
2021-05-12 8:52 ` Mauro Carvalho Chehab
2021-05-10 23:35 ` David Gow
2021-05-12 8:14 ` Mauro Carvalho Chehab
2021-05-12 8:29 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 40/53] docs: power: powercap: powercap.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 41/53] docs: ABI: " Mauro Carvalho Chehab
2021-05-10 13:53 ` Guenter Roeck
2021-05-10 10:26 ` [PATCH 42/53] docs: doc-guide: contributing.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab [this message]
2021-05-10 10:37 ` [PATCH 43/53] docs: PCI: acpi-info.rst: " Krzysztof Wilczyński
2021-05-10 10:26 ` [PATCH 44/53] docs: gpu: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 11:16 ` Jani Nikula
2021-05-10 11:16 ` Jani Nikula
2021-05-10 11:16 ` Jani Nikula
2021-05-10 12:36 ` [Intel-gfx] " Liviu Dudau
2021-05-10 12:36 ` Liviu Dudau
2021-05-10 12:36 ` Liviu Dudau
2021-05-10 10:26 ` [PATCH 45/53] docs: sound: kernel-api: writing-an-alsa-driver.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 46/53] docs: arm64: arm-acpi.rst: " Mauro Carvalho Chehab
2021-05-10 10:26 ` Mauro Carvalho Chehab
2021-05-10 10:26 ` [PATCH 47/53] docs: infiniband: tag_matching.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 48/53] docs: timers: no_hz.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 49/53] docs: misc-devices: ibmvmc.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 50/53] docs: firmware-guide: acpi: lpit.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 51/53] docs: firmware-guide: acpi: dsd: graph.rst: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 52/53] docs: virt: kvm: " Mauro Carvalho Chehab
2021-05-10 10:27 ` [PATCH 53/53] docs: RCU: " Mauro Carvalho Chehab
2021-05-11 0:05 ` Paul E. McKenney
2021-05-10 10:52 ` [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII Thorsten Leemhuis
2021-05-10 10:52 ` [Intel-wired-lan] " Thorsten Leemhuis
2021-05-10 10:52 ` Thorsten Leemhuis
2021-05-10 10:52 ` [f2fs-dev] " Thorsten Leemhuis
2021-05-10 10:52 ` [Intel-gfx] " Thorsten Leemhuis
2021-05-10 10:52 ` Thorsten Leemhuis
2021-05-10 10:52 ` Thorsten Leemhuis
2021-05-10 11:19 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 11:19 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 11:19 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 11:19 ` Mauro Carvalho Chehab
2021-05-10 11:19 ` Mauro Carvalho Chehab
2021-05-10 11:19 ` Mauro Carvalho Chehab
2021-05-10 11:19 ` Mauro Carvalho Chehab
2021-05-10 12:27 ` Mauro Carvalho Chehab
2021-05-10 12:27 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 12:27 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 12:27 ` Mauro Carvalho Chehab
2021-05-10 12:27 ` Mauro Carvalho Chehab
2021-05-10 12:27 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 12:27 ` Mauro Carvalho Chehab
2021-05-10 10:54 ` [Intel-gfx] " David Woodhouse
2021-05-10 10:54 ` [Intel-wired-lan] " David Woodhouse
2021-05-10 10:54 ` David Woodhouse
2021-05-10 10:54 ` David Woodhouse
2021-05-10 10:54 ` David Woodhouse
2021-05-10 10:54 ` David Woodhouse
2021-05-10 11:55 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 11:55 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 11:55 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 11:55 ` Mauro Carvalho Chehab
2021-05-10 11:55 ` Mauro Carvalho Chehab
2021-05-10 11:55 ` Mauro Carvalho Chehab
2021-05-10 11:55 ` Mauro Carvalho Chehab
2021-05-10 12:29 ` [f2fs-dev] " beroal
2021-05-10 13:16 ` Edward Cree
2021-05-10 13:16 ` [Intel-wired-lan] " Edward Cree
2021-05-10 13:16 ` Edward Cree
2021-05-10 13:16 ` [Intel-gfx] " Edward Cree
2021-05-10 13:16 ` Edward Cree
2021-05-10 13:16 ` Edward Cree
2021-05-10 13:16 ` Edward Cree
2021-05-10 13:38 ` Mauro Carvalho Chehab
2021-05-10 13:38 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-10 13:38 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-10 13:38 ` Mauro Carvalho Chehab
2021-05-10 13:38 ` Mauro Carvalho Chehab
2021-05-10 13:38 ` Mauro Carvalho Chehab
2021-05-10 13:38 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 13:58 ` Edward Cree
2021-05-10 13:58 ` [Intel-wired-lan] " Edward Cree
2021-05-10 13:58 ` Edward Cree
2021-05-10 13:58 ` Edward Cree
2021-05-10 13:58 ` [Intel-gfx] " Edward Cree
2021-05-10 13:58 ` [f2fs-dev] " Edward Cree
2021-05-10 13:58 ` Edward Cree
2021-05-10 13:59 ` Matthew Wilcox
2021-05-10 13:59 ` [Intel-wired-lan] " Matthew Wilcox
2021-05-10 13:59 ` Matthew Wilcox
2021-05-10 13:59 ` [f2fs-dev] " Matthew Wilcox
2021-05-10 13:59 ` Matthew Wilcox
2021-05-10 13:59 ` [Intel-gfx] " Matthew Wilcox
2021-05-10 13:59 ` Matthew Wilcox
2021-05-10 14:33 ` Edward Cree
2021-05-10 14:33 ` [Intel-wired-lan] " Edward Cree
2021-05-10 14:33 ` [Intel-gfx] " Edward Cree
2021-05-10 14:33 ` Edward Cree
2021-05-10 14:33 ` Edward Cree
2021-05-10 14:33 ` [f2fs-dev] " Edward Cree
2021-05-10 14:33 ` Edward Cree
2021-05-11 9:00 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-11 9:00 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-11 9:00 ` Mauro Carvalho Chehab
2021-05-11 9:00 ` Mauro Carvalho Chehab
2021-05-11 9:00 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-11 9:00 ` Mauro Carvalho Chehab
2021-05-11 9:00 ` Mauro Carvalho Chehab
2021-05-11 9:19 ` [Intel-gfx] " David Woodhouse
2021-05-11 9:19 ` [Intel-wired-lan] " David Woodhouse
2021-05-11 9:19 ` David Woodhouse
2021-05-11 9:19 ` David Woodhouse
2021-05-11 9:19 ` David Woodhouse
2021-05-11 9:19 ` David Woodhouse
2021-05-10 13:49 ` [Intel-gfx] " David Woodhouse
2021-05-10 13:49 ` [Intel-wired-lan] " David Woodhouse
2021-05-10 13:49 ` David Woodhouse
2021-05-10 13:49 ` David Woodhouse
2021-05-10 13:49 ` David Woodhouse
2021-05-10 13:49 ` David Woodhouse
2021-05-10 19:22 ` Theodore Ts'o
2021-05-10 19:22 ` [Intel-wired-lan] " Theodore Ts'o
2021-05-10 19:22 ` Theodore Ts'o
2021-05-10 19:22 ` Theodore Ts'o
2021-05-10 19:22 ` [Intel-gfx] " Theodore Ts'o
2021-05-10 19:22 ` [f2fs-dev] " Theodore Ts'o
2021-05-10 19:22 ` Theodore Ts'o
2021-05-11 9:37 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-11 9:37 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-11 9:37 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-11 9:37 ` Mauro Carvalho Chehab
2021-05-11 9:37 ` Mauro Carvalho Chehab
2021-05-11 9:37 ` Mauro Carvalho Chehab
2021-05-11 9:37 ` Mauro Carvalho Chehab
2021-05-11 9:25 ` Mauro Carvalho Chehab
2021-05-11 9:25 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-11 9:25 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-11 9:25 ` Mauro Carvalho Chehab
2021-05-11 9:25 ` Mauro Carvalho Chehab
2021-05-11 9:25 ` Mauro Carvalho Chehab
2021-05-11 9:25 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-10 14:00 ` Ben Boeckel
2021-05-10 14:00 ` [Intel-wired-lan] " Ben Boeckel
2021-05-10 14:00 ` [Intel-gfx] " Ben Boeckel
2021-05-10 14:00 ` Ben Boeckel
2021-05-10 14:00 ` [f2fs-dev] " Ben Boeckel
2021-05-10 14:00 ` Ben Boeckel
2021-05-10 14:00 ` Ben Boeckel
2021-05-10 21:57 ` [f2fs-dev] " Adam Borowski
2021-05-10 21:57 ` [Intel-wired-lan] " Adam Borowski
2021-05-10 21:57 ` [Intel-gfx] " Adam Borowski
2021-05-10 21:57 ` Adam Borowski
2021-05-10 21:57 ` Adam Borowski
2021-05-10 21:57 ` Adam Borowski
2021-05-10 21:57 ` Adam Borowski
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=94842f2c0062c71b53144e55c648ec18fdde8eca.1620641727.git.mchehab+huawei@kernel.org \
--to=mchehab+huawei@kernel.org \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.