From: takahiro.akashi@linaro.org (AKASHI Takahiro) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 18/19] arm64: kdump: update a kernel doc Date: Wed, 20 Jan 2016 13:34:20 +0900 [thread overview] Message-ID: <569F0E4C.5030204@linaro.org> (raw) In-Reply-To: <20160119121014.GF25024@leverpostej> On 01/19/2016 09:10 PM, Mark Rutland wrote: > On Tue, Jan 19, 2016 at 02:31:05PM +0900, AKASHI Takahiro wrote: >> On 01/18/2016 08:29 PM, Mark Rutland wrote: >>> On Mon, Jan 18, 2016 at 07:26:04PM +0900, AKASHI Takahiro wrote: >>>> On 01/16/2016 05:16 AM, Mark Rutland wrote: >>>>> On Fri, Jan 15, 2016 at 07:18:38PM +0000, Geoff Levand wrote: >>>>>> From: AKASHI Takahiro <takahiro.akashi@linaro.org> >>>>>> >>>>>> This patch adds arch specific descriptions about kdump usage on arm64 >>>>>> to kdump.txt. >>>>>> >>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> >>>>>> --- >>>>>> Documentation/kdump/kdump.txt | 23 ++++++++++++++++++++++- >>>>>> 1 file changed, 22 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt >>>>>> index bc4bd5a..36cf978 100644 >>>>>> --- a/Documentation/kdump/kdump.txt >>>>>> +++ b/Documentation/kdump/kdump.txt >>>>>> @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to >>>>>> a remote system. >>>>>> >>>>>> Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, >>>>>> -s390x and arm architectures. >>>>>> +s390x, arm and arm64 architectures. >>>>>> >>>>>> When the system kernel boots, it reserves a small section of memory for >>>>>> the dump-capture kernel. This ensures that ongoing Direct Memory Access >>>>>> @@ -249,6 +249,20 @@ Dump-capture kernel config options (Arch Dependent, arm) >>>>>> >>>>>> AUTO_ZRELADDR=y >>>>>> >>>>>> +Dump-capture kernel config options (Arch Dependent, arm64) >>>>>> +---------------------------------------------------------- >>>>>> + >>>>>> +1) The maximum memory size on the dump-capture kernel must be limited by >>>>>> + specifying: >>>>>> + >>>>>> + mem=X[MG] >>>>>> + >>>>>> + where X should be less than or equal to the size in "crashkernel=" >>>>>> + boot parameter. Kexec-tools will automatically add this. >>>>> >>>>> >>>>> This is extremely fragile, and will trivially fail when the kernel can >>>>> be loaded anywhere (see [1]). >>>> >>>> As I said before, this restriction also exists on arm, but I understand >>>> that recent Ard's patches break it. >>>> >>>>> We must explicitly describe the set of regions the crash kernel may use >>>>> (i.e. we need base and size). NAK in the absence of that. >>>> >>>> There seem to exist several approaches: >>>> (a) use a device-tree property, "linux,usable-memory", in addition to "reg" >>> >>> I'm not opposed to the idea of a DT property, though I think that should >>> live under /chosen. >> >> In fact, powerpc uses another property, "linux,crashkernel-base(& size)", >> under /chosen in order for the *1st kernel* to export info about a memory >> region for the 2nd(crash dump) kernel to user apps (kexec-tools). > > Do you mean that said property is provided _to_ the 1st kernel, or > provided _by_ the first kernel? _by_ the 1st kernel. Based on a kernel parameter, "crashkernel=", the 1st kernel reserve some memory region at boot time and export its information through this property. Most architectures other than powerpc, however, use an iomem resource entry, "Crash kernel", in /proc/iomem instead for this purpose. >>> I see that "linux,usable-memory" exists already, though I'm confused as >>> to exactly what it is for as there is no documentation (neither in the >>> kernel nor in ePAPR). >> >> For example, >> memory at 0x80000000 { >> reg = <0x0 0x80000000 0x0 0x80000000>; >> linux,usable-memory = <0x0 0x8c000000 0x0 0x4000000>; >> } >> There exists 2GB memory available on the system, but the last 64MB can be >> used as a system ram. See early_init_dt_scan_memory() in fdt.c. > > Sure, except that's the implementation rather than the intended > semantics (which are not defined). Yeah, but the code itself was ack'ed (actually committed) by Grant:) >>> It's also painful to alter multiple memory nodes >>> to use that, and I can see that going wrong. >> >> Yeah, I implemented this feature in my old versions experimentally, >> but didn't like it as we had to touch all the memory nodes. >> >>>> under "memory" node >>>> (b) use a kernel's early parameter, "memmap=nn[@#$]ss" >>> >>> I'm not too keen on this, as I think it's fragile, and logically >>> somewhat distinct from what mem= is for (a best effort testing tool). >> >> I'm not sure whether it is fragile, and contrary to x86, as Dave >> described, I think we will only need a single memmap= on arm64 as >> efi's mem map table is accessible even on the crash kernel. > > I just realised I misread this as "mem=", apologies. > > It looks like memmap= to force a specific region of memory to be used > may work. > > I'd still err on the side of preferring an explicit property in the DT. Let's discuss in succeeding replies. >>>> Power PC takes (a), while this does not work on efi-started kernel >>>> because dtb has no "memory" nodes under efi. >>> >>> A property under /chosen would work for EFI too. >>> >>>> X86 takes (b). If we take this, we will need to overwrite a weak >>>> early_init_dt_add_memory(). >>>> (I thought that this approach was not smart as we have three different >>>> ways to specify memory regions, dtb, efi and this kernel parameter.) >>> >>> I'm not sure that's a big problem. We may be able to make this generic, >>> also. >>> >>> We don't necessarily need a weak add memory function if we can guarantee >>> nothing gets memblock_alloc'd before we carve it out. >>> >>> Something like the nomap stuff Ard put together might be useful here. >> >> I'm afraid it doesn't work. >> It doesn't matter whether it is linearly mapped or not. We should prevent >> any part of memory regions used by the 1st kernel from being reclaimed >> by memblock_alloc() and others. > > Are you certain that nomap memory can be allocated? That sounds like a > major bug. I misunderstood. __next_mem_range() called by mem_alloc stuff has some check. -Takahiro AKASHI > Nomap memory should act like reserved memory with the additional > property that the kernel must not map it implicitly. > >> Or do you mean we can introduce another memblock flag? > > That wasn't what I meant, but that would be a potential solution. > > Thanks, > Mark. >
WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org> To: Mark Rutland <mark.rutland@arm.com> Cc: ard.biesheuvel@linaro.org, Geoff Levand <geoff@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, marc.zyngier@arm.com, James Morse <james.morse@arm.com>, linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org, christoffer.dall@linaro.org Subject: Re: [PATCH 18/19] arm64: kdump: update a kernel doc Date: Wed, 20 Jan 2016 13:34:20 +0900 [thread overview] Message-ID: <569F0E4C.5030204@linaro.org> (raw) In-Reply-To: <20160119121014.GF25024@leverpostej> On 01/19/2016 09:10 PM, Mark Rutland wrote: > On Tue, Jan 19, 2016 at 02:31:05PM +0900, AKASHI Takahiro wrote: >> On 01/18/2016 08:29 PM, Mark Rutland wrote: >>> On Mon, Jan 18, 2016 at 07:26:04PM +0900, AKASHI Takahiro wrote: >>>> On 01/16/2016 05:16 AM, Mark Rutland wrote: >>>>> On Fri, Jan 15, 2016 at 07:18:38PM +0000, Geoff Levand wrote: >>>>>> From: AKASHI Takahiro <takahiro.akashi@linaro.org> >>>>>> >>>>>> This patch adds arch specific descriptions about kdump usage on arm64 >>>>>> to kdump.txt. >>>>>> >>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> >>>>>> --- >>>>>> Documentation/kdump/kdump.txt | 23 ++++++++++++++++++++++- >>>>>> 1 file changed, 22 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt >>>>>> index bc4bd5a..36cf978 100644 >>>>>> --- a/Documentation/kdump/kdump.txt >>>>>> +++ b/Documentation/kdump/kdump.txt >>>>>> @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to >>>>>> a remote system. >>>>>> >>>>>> Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64, >>>>>> -s390x and arm architectures. >>>>>> +s390x, arm and arm64 architectures. >>>>>> >>>>>> When the system kernel boots, it reserves a small section of memory for >>>>>> the dump-capture kernel. This ensures that ongoing Direct Memory Access >>>>>> @@ -249,6 +249,20 @@ Dump-capture kernel config options (Arch Dependent, arm) >>>>>> >>>>>> AUTO_ZRELADDR=y >>>>>> >>>>>> +Dump-capture kernel config options (Arch Dependent, arm64) >>>>>> +---------------------------------------------------------- >>>>>> + >>>>>> +1) The maximum memory size on the dump-capture kernel must be limited by >>>>>> + specifying: >>>>>> + >>>>>> + mem=X[MG] >>>>>> + >>>>>> + where X should be less than or equal to the size in "crashkernel=" >>>>>> + boot parameter. Kexec-tools will automatically add this. >>>>> >>>>> >>>>> This is extremely fragile, and will trivially fail when the kernel can >>>>> be loaded anywhere (see [1]). >>>> >>>> As I said before, this restriction also exists on arm, but I understand >>>> that recent Ard's patches break it. >>>> >>>>> We must explicitly describe the set of regions the crash kernel may use >>>>> (i.e. we need base and size). NAK in the absence of that. >>>> >>>> There seem to exist several approaches: >>>> (a) use a device-tree property, "linux,usable-memory", in addition to "reg" >>> >>> I'm not opposed to the idea of a DT property, though I think that should >>> live under /chosen. >> >> In fact, powerpc uses another property, "linux,crashkernel-base(& size)", >> under /chosen in order for the *1st kernel* to export info about a memory >> region for the 2nd(crash dump) kernel to user apps (kexec-tools). > > Do you mean that said property is provided _to_ the 1st kernel, or > provided _by_ the first kernel? _by_ the 1st kernel. Based on a kernel parameter, "crashkernel=", the 1st kernel reserve some memory region at boot time and export its information through this property. Most architectures other than powerpc, however, use an iomem resource entry, "Crash kernel", in /proc/iomem instead for this purpose. >>> I see that "linux,usable-memory" exists already, though I'm confused as >>> to exactly what it is for as there is no documentation (neither in the >>> kernel nor in ePAPR). >> >> For example, >> memory@0x80000000 { >> reg = <0x0 0x80000000 0x0 0x80000000>; >> linux,usable-memory = <0x0 0x8c000000 0x0 0x4000000>; >> } >> There exists 2GB memory available on the system, but the last 64MB can be >> used as a system ram. See early_init_dt_scan_memory() in fdt.c. > > Sure, except that's the implementation rather than the intended > semantics (which are not defined). Yeah, but the code itself was ack'ed (actually committed) by Grant:) >>> It's also painful to alter multiple memory nodes >>> to use that, and I can see that going wrong. >> >> Yeah, I implemented this feature in my old versions experimentally, >> but didn't like it as we had to touch all the memory nodes. >> >>>> under "memory" node >>>> (b) use a kernel's early parameter, "memmap=nn[@#$]ss" >>> >>> I'm not too keen on this, as I think it's fragile, and logically >>> somewhat distinct from what mem= is for (a best effort testing tool). >> >> I'm not sure whether it is fragile, and contrary to x86, as Dave >> described, I think we will only need a single memmap= on arm64 as >> efi's mem map table is accessible even on the crash kernel. > > I just realised I misread this as "mem=", apologies. > > It looks like memmap= to force a specific region of memory to be used > may work. > > I'd still err on the side of preferring an explicit property in the DT. Let's discuss in succeeding replies. >>>> Power PC takes (a), while this does not work on efi-started kernel >>>> because dtb has no "memory" nodes under efi. >>> >>> A property under /chosen would work for EFI too. >>> >>>> X86 takes (b). If we take this, we will need to overwrite a weak >>>> early_init_dt_add_memory(). >>>> (I thought that this approach was not smart as we have three different >>>> ways to specify memory regions, dtb, efi and this kernel parameter.) >>> >>> I'm not sure that's a big problem. We may be able to make this generic, >>> also. >>> >>> We don't necessarily need a weak add memory function if we can guarantee >>> nothing gets memblock_alloc'd before we carve it out. >>> >>> Something like the nomap stuff Ard put together might be useful here. >> >> I'm afraid it doesn't work. >> It doesn't matter whether it is linearly mapped or not. We should prevent >> any part of memory regions used by the 1st kernel from being reclaimed >> by memblock_alloc() and others. > > Are you certain that nomap memory can be allocated? That sounds like a > major bug. I misunderstood. __next_mem_range() called by mem_alloc stuff has some check. -Takahiro AKASHI > Nomap memory should act like reserved memory with the additional > property that the kernel must not map it implicitly. > >> Or do you mean we can introduce another memblock flag? > > That wasn't what I meant, but that would be a potential solution. > > Thanks, > Mark. > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2016-01-20 4:34 UTC|newest] Thread overview: 174+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-15 19:18 [PATCH 00/19] arm64 kexec kernel patches v13 Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 07/19] arm64: Add back cpu_reset routines Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 03/19] arm64: Add new asm macro copy_page Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-20 14:01 ` James Morse 2016-01-20 14:01 ` James Morse 2016-01-15 19:18 ` [PATCH 05/19] arm64: Convert hcalls to use HVC immediate value Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 02/19] arm64: kernel: Include _AC definition in page.h Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-18 10:05 ` Mark Rutland 2016-01-18 10:05 ` Mark Rutland 2016-01-15 19:18 ` [PATCH 09/19] Revert "arm64: remove dead code" Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:55 ` Mark Rutland 2016-01-15 19:55 ` Mark Rutland 2016-01-20 21:18 ` Geoff Levand 2016-01-20 21:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 04/19] arm64: Cleanup SCTLR flags Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 20:07 ` Mark Rutland 2016-01-15 20:07 ` Mark Rutland 2016-01-18 10:12 ` Marc Zyngier 2016-01-18 10:12 ` Marc Zyngier 2016-01-19 11:59 ` Dave Martin 2016-01-19 11:59 ` Dave Martin 2016-01-25 15:09 ` James Morse 2016-01-25 15:09 ` James Morse 2016-01-15 19:18 ` [PATCH 08/19] Revert "arm64: mm: remove unused cpu_set_idmap_tcr_t0sz function" Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 01/19] arm64: Fold proc-macros.S into assembler.h Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 06/19] arm64: Add new hcall HVC_CALL_FUNC Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 17/19] arm64: kdump: enable kdump in the arm64 defconfig Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 15/19] arm64: kdump: implement machine_crash_shutdown() Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 19/19] arm64: kdump: relax BUG_ON() if more than one cpus are still active Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 12/19] arm64/kexec: Enable kexec in the arm64 defconfig Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 18/19] arm64: kdump: update a kernel doc Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 20:16 ` Mark Rutland 2016-01-15 20:16 ` Mark Rutland 2016-01-18 10:26 ` AKASHI Takahiro 2016-01-18 10:26 ` AKASHI Takahiro 2016-01-18 11:29 ` Mark Rutland 2016-01-18 11:29 ` Mark Rutland 2016-01-19 5:31 ` AKASHI Takahiro 2016-01-19 5:31 ` AKASHI Takahiro 2016-01-19 12:10 ` Mark Rutland 2016-01-19 12:10 ` Mark Rutland 2016-01-20 4:34 ` AKASHI Takahiro [this message] 2016-01-20 4:34 ` AKASHI Takahiro 2016-01-19 1:43 ` Dave Young 2016-01-19 1:43 ` Dave Young 2016-01-19 1:50 ` Dave Young 2016-01-19 1:50 ` Dave Young 2016-01-19 5:35 ` AKASHI Takahiro 2016-01-19 5:35 ` AKASHI Takahiro 2016-01-19 12:28 ` Dave Young 2016-01-19 12:28 ` Dave Young 2016-01-19 12:51 ` Mark Rutland 2016-01-19 12:51 ` Mark Rutland 2016-01-19 13:45 ` Dave Young 2016-01-19 13:45 ` Dave Young 2016-01-19 14:01 ` Mark Rutland 2016-01-19 14:01 ` Mark Rutland 2016-01-20 2:49 ` Dave Young 2016-01-20 2:49 ` Dave Young 2016-01-20 6:07 ` AKASHI Takahiro 2016-01-20 6:07 ` AKASHI Takahiro 2016-01-20 6:38 ` Dave Young 2016-01-20 6:38 ` Dave Young 2016-01-20 7:00 ` Dave Young 2016-01-20 7:00 ` Dave Young 2016-01-20 8:01 ` AKASHI Takahiro 2016-01-20 8:01 ` AKASHI Takahiro 2016-01-20 8:26 ` Dave Young 2016-01-20 8:26 ` Dave Young 2016-01-20 11:54 ` Mark Rutland 2016-01-20 11:54 ` Mark Rutland 2016-01-21 2:57 ` Dave Young 2016-01-21 2:57 ` Dave Young 2016-01-21 3:03 ` Dave Young 2016-01-21 3:03 ` Dave Young 2016-01-20 11:49 ` Mark Rutland 2016-01-20 11:49 ` Mark Rutland 2016-01-21 6:53 ` AKASHI Takahiro 2016-01-21 6:53 ` AKASHI Takahiro 2016-01-21 12:02 ` Mark Rutland 2016-01-21 12:02 ` Mark Rutland 2016-01-22 6:23 ` AKASHI Takahiro 2016-01-22 6:23 ` AKASHI Takahiro 2016-01-22 11:13 ` Mark Rutland 2016-01-22 11:13 ` Mark Rutland 2016-02-02 5:18 ` AKASHI Takahiro 2016-02-02 5:18 ` AKASHI Takahiro 2016-01-25 3:19 ` Dave Young 2016-01-25 3:19 ` Dave Young 2016-01-25 4:23 ` Dave Young 2016-01-25 4:23 ` Dave Young 2016-01-20 11:28 ` Mark Rutland 2016-01-20 11:28 ` Mark Rutland 2016-01-21 2:54 ` Dave Young 2016-01-21 2:54 ` Dave Young 2016-01-20 5:25 ` AKASHI Takahiro 2016-01-20 5:25 ` AKASHI Takahiro 2016-01-20 12:02 ` Mark Rutland 2016-01-20 12:02 ` Mark Rutland 2016-01-20 12:36 ` Mark Rutland 2016-01-20 12:36 ` Mark Rutland 2016-01-20 14:59 ` Ard Biesheuvel 2016-01-20 14:59 ` Ard Biesheuvel 2016-01-20 15:04 ` Mark Rutland 2016-01-20 15:04 ` Mark Rutland 2016-01-21 5:43 ` AKASHI Takahiro 2016-01-21 5:43 ` AKASHI Takahiro 2016-01-21 13:02 ` Mark Rutland 2016-01-21 13:02 ` Mark Rutland 2016-01-19 12:17 ` Mark Rutland 2016-01-19 12:17 ` Mark Rutland 2016-01-19 13:52 ` Dave Young 2016-01-19 13:52 ` Dave Young 2016-01-19 14:05 ` Mark Rutland 2016-01-19 14:05 ` Mark Rutland 2016-01-20 2:54 ` Dave Young 2016-01-20 2:54 ` Dave Young 2016-01-15 19:18 ` [PATCH 10/19] arm64: kvm: allows kvm cpu hotplug Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-26 17:42 ` James Morse 2016-01-26 17:42 ` James Morse 2016-01-27 7:37 ` AKASHI Takahiro 2016-01-27 7:37 ` AKASHI Takahiro 2016-01-15 19:18 ` [PATCH 14/19] arm64: kdump: reserve memory for crash dump kernel Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 11/19] arm64/kexec: Add core kexec support Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 13/19] arm64/kexec: Add pr_debug output Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-15 19:18 ` [PATCH 16/19] arm64: kdump: add kdump support Geoff Levand 2016-01-15 19:18 ` Geoff Levand 2016-01-21 14:17 ` James Morse 2016-01-21 14:17 ` James Morse 2016-01-22 4:50 ` AKASHI Takahiro 2016-01-22 4:50 ` AKASHI Takahiro 2016-01-19 12:32 ` [PATCH 00/19] arm64 kexec kernel patches v13 Dave Young 2016-01-19 12:32 ` Dave Young 2016-01-20 0:15 ` Geoff Levand 2016-01-20 0:15 ` Geoff Levand 2016-01-20 2:56 ` Dave Young 2016-01-20 2:56 ` Dave Young 2016-01-20 21:15 ` Geoff Levand 2016-01-20 21:15 ` Geoff Levand 2016-01-21 12:11 ` Mark Rutland 2016-01-21 12:11 ` Mark Rutland [not found] ` <c7575f853ccc491bb0212e025aab1cc9@NASANEXM01H.na.qualcomm.com> 2016-03-01 17:54 ` Azriel Samson 2016-03-01 17:54 ` Azriel Samson 2016-03-02 1:17 ` Geoff Levand 2016-03-02 1:17 ` Geoff Levand 2016-03-02 1:38 ` Will Deacon 2016-03-02 1:38 ` Will Deacon 2016-03-02 2:28 ` AKASHI Takahiro 2016-03-02 2:28 ` AKASHI Takahiro 2016-03-02 8:07 ` Marc Zyngier 2016-03-02 8:07 ` Marc Zyngier 2016-03-02 12:33 ` Pratyush Anand 2016-03-02 12:33 ` Pratyush Anand 2016-03-02 16:51 ` Azriel Samson 2016-03-02 16:51 ` Azriel Samson
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=569F0E4C.5030204@linaro.org \ --to=takahiro.akashi@linaro.org \ --cc=linux-arm-kernel@lists.infradead.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.