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>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH 46/53] docs: arm64: arm-acpi.rst: avoid using UTF-8 chars Date: Mon, 10 May 2021 12:26:58 +0200 [thread overview] Message-ID: <ea4905192df5262beed5bf2edbed08a32c5cb67e.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+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> --- Documentation/arm64/arm-acpi.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst index 47ecb9930dde..ceb109ff82aa 100644 --- a/Documentation/arm64/arm-acpi.rst +++ b/Documentation/arm64/arm-acpi.rst @@ -36,12 +36,12 @@ of the summary text almost directly, to be honest. The short form of the rationale for ACPI on ARM is: -- ACPI’s byte code (AML) allows the platform to encode hardware behavior, +- ACPI's byte code (AML) allows the platform to encode hardware behavior, while DT explicitly does not support this. For hardware vendors, being able to encode behavior is a key tool used in supporting operating system releases on new hardware. -- ACPI’s OSPM defines a power management model that constrains what the +- ACPI's OSPM defines a power management model that constrains what the platform is allowed to do into a specific model, while still providing flexibility in hardware design. @@ -69,7 +69,7 @@ Key to the use of ACPI is the support model. For servers in general, the responsibility for hardware behaviour cannot solely be the domain of the kernel, but rather must be split between the platform and the kernel, in order to allow for orderly change over time. ACPI frees the OS from needing -to understand all the minute details of the hardware so that the OS doesn’t +to understand all the minute details of the hardware so that the OS doesn't need to be ported to each and every device individually. It allows the hardware vendors to take responsibility for power management behaviour without depending on an OS release cycle which is not under their control. @@ -81,7 +81,7 @@ in place. DT does exactly what Linux needs it to when working with vertically integrated devices, but there are no good processes for supporting what the server vendors need. Linux could potentially get there with DT, but doing so really just duplicates something that already works. ACPI already does what -the hardware vendors need, Microsoft won’t collaborate on DT, and hardware +the hardware vendors need, Microsoft won't collaborate on DT, and hardware vendors would still end up providing two completely separate firmware interfaces -- one for Linux and one for Windows. -- 2.30.2
WARNING: multiple messages have this Message-ID (diff)
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>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH 46/53] docs: arm64: arm-acpi.rst: avoid using UTF-8 chars Date: Mon, 10 May 2021 12:26:58 +0200 [thread overview] Message-ID: <ea4905192df5262beed5bf2edbed08a32c5cb67e.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+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> --- Documentation/arm64/arm-acpi.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst index 47ecb9930dde..ceb109ff82aa 100644 --- a/Documentation/arm64/arm-acpi.rst +++ b/Documentation/arm64/arm-acpi.rst @@ -36,12 +36,12 @@ of the summary text almost directly, to be honest. The short form of the rationale for ACPI on ARM is: -- ACPI’s byte code (AML) allows the platform to encode hardware behavior, +- ACPI's byte code (AML) allows the platform to encode hardware behavior, while DT explicitly does not support this. For hardware vendors, being able to encode behavior is a key tool used in supporting operating system releases on new hardware. -- ACPI’s OSPM defines a power management model that constrains what the +- ACPI's OSPM defines a power management model that constrains what the platform is allowed to do into a specific model, while still providing flexibility in hardware design. @@ -69,7 +69,7 @@ Key to the use of ACPI is the support model. For servers in general, the responsibility for hardware behaviour cannot solely be the domain of the kernel, but rather must be split between the platform and the kernel, in order to allow for orderly change over time. ACPI frees the OS from needing -to understand all the minute details of the hardware so that the OS doesn’t +to understand all the minute details of the hardware so that the OS doesn't need to be ported to each and every device individually. It allows the hardware vendors to take responsibility for power management behaviour without depending on an OS release cycle which is not under their control. @@ -81,7 +81,7 @@ in place. DT does exactly what Linux needs it to when working with vertically integrated devices, but there are no good processes for supporting what the server vendors need. Linux could potentially get there with DT, but doing so really just duplicates something that already works. ACPI already does what -the hardware vendors need, Microsoft won’t collaborate on DT, and hardware +the hardware vendors need, Microsoft won't collaborate on DT, and hardware vendors would still end up providing two completely separate firmware interfaces -- one for Linux and one for Windows. -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-10 10:41 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 ` [Intel-gfx] " Mauro Carvalho Chehab 2021-05-10 10:26 ` Mauro Carvalho Chehab 2021-05-10 10:26 ` Mauro Carvalho Chehab 2021-05-10 10:26 ` [f2fs-dev] " Mauro Carvalho Chehab 2021-05-10 10:26 ` 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 ` [PATCH 27/53] docs: filesystems: f2fs.rst: " Mauro Carvalho Chehab 2021-05-10 10:26 ` [f2fs-dev] " Mauro Carvalho Chehab 2021-05-11 3:16 ` 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 ` [PATCH 43/53] docs: PCI: acpi-info.rst: " Mauro Carvalho Chehab 2021-05-10 10:37 ` Krzysztof Wilczyński 2021-05-10 10:26 ` [PATCH 44/53] docs: gpu: " Mauro Carvalho Chehab 2021-05-10 10:26 ` [Intel-gfx] " Mauro Carvalho Chehab 2021-05-10 10:26 ` Mauro Carvalho Chehab 2021-05-10 11:16 ` Jani Nikula 2021-05-10 11:16 ` [Intel-gfx] " Jani Nikula 2021-05-10 11:16 ` Jani Nikula 2021-05-10 12:36 ` Liviu Dudau 2021-05-10 12:36 ` [Intel-gfx] " 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 ` Mauro Carvalho Chehab [this message] 2021-05-10 10:26 ` [PATCH 46/53] docs: arm64: arm-acpi.rst: " 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 ` [Intel-gfx] " Thorsten Leemhuis 2021-05-10 10:52 ` Thorsten Leemhuis 2021-05-10 10:52 ` Thorsten Leemhuis 2021-05-10 10:52 ` [f2fs-dev] " Thorsten Leemhuis 2021-05-10 10:52 ` Thorsten Leemhuis 2021-05-10 11:19 ` 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 ` [f2fs-dev] " 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 ` David Woodhouse 2021-05-10 10:54 ` [Intel-wired-lan] " David Woodhouse 2021-05-10 10:54 ` [Intel-gfx] " 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 ` 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 ` [f2fs-dev] " 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 ` [Intel-gfx] " Edward Cree 2021-05-10 13:16 ` Edward Cree 2021-05-10 13:16 ` Edward Cree 2021-05-10 13:16 ` [f2fs-dev] " 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 ` [f2fs-dev] " Mauro Carvalho Chehab 2021-05-10 13:38 ` 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 ` [Intel-gfx] " Edward Cree 2021-05-10 13:58 ` Edward Cree 2021-05-10 13:58 ` 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 ` [Intel-gfx] " Matthew Wilcox 2021-05-10 13:59 ` 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 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 ` Mauro Carvalho Chehab 2021-05-11 9:00 ` [Intel-wired-lan] " 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:00 ` [f2fs-dev] " Mauro Carvalho Chehab 2021-05-11 9:00 ` Mauro Carvalho Chehab 2021-05-11 9:19 ` David Woodhouse 2021-05-11 9:19 ` [Intel-wired-lan] " David Woodhouse 2021-05-11 9:19 ` [Intel-gfx] " 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 ` David Woodhouse 2021-05-10 13:49 ` [Intel-wired-lan] " David Woodhouse 2021-05-10 13:49 ` [Intel-gfx] " 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 ` [Intel-gfx] " Theodore Ts'o 2021-05-10 19:22 ` Theodore Ts'o 2021-05-10 19:22 ` 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 ` 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 ` [f2fs-dev] " 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 ` [f2fs-dev] " Mauro Carvalho Chehab 2021-05-11 9:25 ` 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 ` Ben Boeckel 2021-05-10 14:00 ` [f2fs-dev] " Ben Boeckel 2021-05-10 14:00 ` Ben Boeckel 2021-05-10 21:57 ` 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 ` [f2fs-dev] " 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=ea4905192df5262beed5bf2edbed08a32c5cb67e.1620641727.git.mchehab+huawei@kernel.org \ --to=mchehab+huawei@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.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: linkBe 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.