All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [PATCH 1/1] riscv: select CONFIG_ARCH_KEEP_MEMBLOCK
Date: Mon, 16 Aug 2021 21:50:26 +0300	[thread overview]
Message-ID: <YRqzckNDbg0awrh4@kernel.org> (raw)
In-Reply-To: <d9d9f764-2bc7-ddf4-2353-dac323e4416d@canonical.com>

Hi Heinrich,

On Mon, Aug 16, 2021 at 05:52:11PM +0200, Heinrich Schuchardt wrote:
> On 8/16/21 5:30 PM, Kefeng Wang wrote:
> > 
> > On 2021/8/16 22:47, Heinrich Schuchardt wrote:
> > > For analyzing memory blocks we can either use the memblock=debug command
> > > line argument which creates massive output or a debug file system.
> > > 
> > > Select CONFIG_ARCH_KEEP_MEMBLOCK to provide a debugfs at
> > > /sys/kernel/debug/memblock to analyze memory blocks. The
> > > same is already done for arm, arm64, mips, powerpc.
> > > 
> > > The actual provisioning of the file system depends on CONFIG_DEBUG_FS.
> > 
> > Hi,for riscv, it don't use memblock(eg, no provide pfn_valid to use
> > memblock),
> > 
> > we could call memblock_discard() to discard memblock private memory to save
> > 
> > some memory, right?  So I think we don't need this config for now.
> 
> What do you mean by "it don't use memblock?
> 
> If you boot the HiFive Unmatched with memblock=debug you will see output
> like the one below. This is the information that you can see in the debug
> file system if CONFIG_DEBUG_FS and CONFIG_ARCH_KEEP_MEMBLOCK will be
> enabled.

Indeed having this info in debugfs is more convenient, but it comes with a
cost of several kilobytes of code and data for *every* riscv build.

Why parsing "memblock=debug" output is not enough?
What is the use-case that justifies the costs associated with having the
debugfs entries?
 
> [    0.000000] MEMBLOCK configuration:
> [    0.000000]  memory size = 0x00000003ffe00000 reserved size =
> 0x000000001290fb70
> [    0.000000]  memory.cnt  = 0x25

BTW, it seems that the memory allocation by firmware is, well, suboptimal
and begs for fixes. I don't see why all these NOMAP areas cannot be put in
one contiguous chunk. I doubt they need to be NOMAP at all, but mysterious
the ways of ACPI.

> [    0.000000]  memory[0x0]     [0x0000000080200000-0x00000000fe6e2fff],
> 0x000000007e4e3000 bytes flags: 0x0
> [    0.000000]  memory[0x1]     [0x00000000fe6e3000-0x00000000fe6e5fff],
> 0x0000000000003000 bytes flags: 0x4
> [    0.000000]  memory[0x2]     [0x00000000fe6e6000-0x00000000fe709fff],
> 0x0000000000024000 bytes flags: 0x0
> [    0.000000]  memory[0x3]     [0x00000000fe70a000-0x00000000fe70bfff],
> 0x0000000000002000 bytes flags: 0x4
> [    0.000000]  memory[0x4]     [0x00000000fe70c000-0x00000000fe70ffff],
> 0x0000000000004000 bytes flags: 0x0
> [    0.000000]  memory[0x5]     [0x00000000fe710000-0x00000000fe710fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x6]     [0x00000000fe711000-0x00000000fe712fff],
> 0x0000000000002000 bytes flags: 0x0
> [    0.000000]  memory[0x7]     [0x00000000fe713000-0x00000000fe716fff],
> 0x0000000000004000 bytes flags: 0x4
> [    0.000000]  memory[0x8]     [0x00000000fe717000-0x00000000fe717fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x9]     [0x00000000fe718000-0x00000000fe71cfff],
> 0x0000000000005000 bytes flags: 0x4
> [    0.000000]  memory[0xa]     [0x00000000fe71d000-0x00000000fe71dfff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0xb]     [0x00000000fe71e000-0x00000000fe71efff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0xc]     [0x00000000fe71f000-0x00000000fe71ffff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0xd]     [0x00000000fe720000-0x00000000fe720fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0xe]     [0x00000000fe721000-0x00000000fe721fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0xf]     [0x00000000fe722000-0x00000000fe722fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x10]    [0x00000000fe723000-0x00000000fe723fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x11]    [0x00000000fe724000-0x00000000fe724fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x12]    [0x00000000fe725000-0x00000000fe725fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x13]    [0x00000000fe726000-0x00000000fe726fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x14]    [0x00000000fe727000-0x00000000fe728fff],
> 0x0000000000002000 bytes flags: 0x0
> [    0.000000]  memory[0x15]    [0x00000000fe729000-0x00000000fe729fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x16]    [0x00000000fe72a000-0x00000000fe72afff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x17]    [0x00000000fe72b000-0x00000000fe72cfff],
> 0x0000000000002000 bytes flags: 0x4
> [    0.000000]  memory[0x18]    [0x00000000fe72d000-0x00000000fe72dfff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x19]    [0x00000000fe72e000-0x00000000fe72efff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x1a]    [0x00000000fe72f000-0x00000000fe72ffff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x1b]    [0x00000000fe730000-0x00000000fe730fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x1c]    [0x00000000fe731000-0x00000000fe731fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x1d]    [0x00000000fe732000-0x00000000fe732fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x1e]    [0x00000000fe733000-0x00000000fe733fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x1f]    [0x00000000fe734000-0x00000000fe734fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x20]    [0x00000000fe735000-0x00000000fe736fff],
> 0x0000000000002000 bytes flags: 0x0
> [    0.000000]  memory[0x21]    [0x00000000fe737000-0x00000000fe737fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x22]    [0x00000000fe738000-0x00000000fff60fff],
> 0x0000000001829000 bytes flags: 0x0
> [    0.000000]  memory[0x23]    [0x00000000fff61000-0x00000000fff61fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x24]    [0x00000000fff62000-0x000000047fffffff],
> 0x000000038009e000 bytes flags: 0x0
> [    0.000000]  reserved.cnt  = 0xd
> [    0.000000]  reserved[0x0]   [0x0000000080000000-0x000000008007ffff],
> 0x0000000000080000 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0000000080200000-0x00000000815fffff],
> 0x0000000001400000 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0000000087f00000-0x0000000087f05fff],
> 0x0000000000006000 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x00000000db0a2000-0x00000000db0a48b4],
> 0x00000000000028b5 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x00000000db2a2000-0x00000000dc709fff],
> 0x0000000001468000 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x00000000fe701000-0x00000000fe701fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  reserved[0x6]   [0x00000000fe704040-0x00000000fe70404f],
> 0x0000000000000010 bytes flags: 0x0
> [    0.000000]  reserved[0x7]   [0x000000046ffe1d40-0x000000047dfe253f],
> 0x000000000e000800 bytes flags: 0x0
> [    0.000000]  reserved[0x8]   [0x000000047dfe2548-0x000000047dfe2578],
> 0x0000000000000031 bytes flags: 0x0
> [    0.000000]  reserved[0x9]   [0x000000047dfe2580-0x000000047dfe25ae],
> 0x000000000000002f bytes flags: 0x0
> [    0.000000]  reserved[0xa]   [0x000000047dfe25b0-0x000000047dfe25de],
> 0x000000000000002f bytes flags: 0x0
> [    0.000000]  reserved[0xb]   [0x000000047dfe25e0-0x000000047dfefffb],
> 0x000000000000da1c bytes flags: 0x0
> [    0.000000]  reserved[0xc]   [0x000000047dff0000-0x000000047fffffff],
> 0x0000000002010000 bytes flags: 0x0
> 
> Best regards
> 
> Heinrich
> 
> > 
> > > 
> > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > ---
> > >   arch/riscv/Kconfig | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index 4f7b70ae7c31..a6e57614c3fd 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -31,6 +31,7 @@ config RISCV
> > >       select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> > >       select ARCH_HAS_STRICT_MODULE_RWX if MMU && !XIP_KERNEL
> > >       select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> > > +    select ARCH_KEEP_MEMBLOCK
> > >       select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> > >       select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > >       select ARCH_SUPPORTS_HUGETLBFS if MMU
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [PATCH 1/1] riscv: select CONFIG_ARCH_KEEP_MEMBLOCK
Date: Mon, 16 Aug 2021 21:50:26 +0300	[thread overview]
Message-ID: <YRqzckNDbg0awrh4@kernel.org> (raw)
In-Reply-To: <d9d9f764-2bc7-ddf4-2353-dac323e4416d@canonical.com>

Hi Heinrich,

On Mon, Aug 16, 2021 at 05:52:11PM +0200, Heinrich Schuchardt wrote:
> On 8/16/21 5:30 PM, Kefeng Wang wrote:
> > 
> > On 2021/8/16 22:47, Heinrich Schuchardt wrote:
> > > For analyzing memory blocks we can either use the memblock=debug command
> > > line argument which creates massive output or a debug file system.
> > > 
> > > Select CONFIG_ARCH_KEEP_MEMBLOCK to provide a debugfs at
> > > /sys/kernel/debug/memblock to analyze memory blocks. The
> > > same is already done for arm, arm64, mips, powerpc.
> > > 
> > > The actual provisioning of the file system depends on CONFIG_DEBUG_FS.
> > 
> > Hi,for riscv, it don't use memblock(eg, no provide pfn_valid to use
> > memblock),
> > 
> > we could call memblock_discard() to discard memblock private memory to save
> > 
> > some memory, right?  So I think we don't need this config for now.
> 
> What do you mean by "it don't use memblock?
> 
> If you boot the HiFive Unmatched with memblock=debug you will see output
> like the one below. This is the information that you can see in the debug
> file system if CONFIG_DEBUG_FS and CONFIG_ARCH_KEEP_MEMBLOCK will be
> enabled.

Indeed having this info in debugfs is more convenient, but it comes with a
cost of several kilobytes of code and data for *every* riscv build.

Why parsing "memblock=debug" output is not enough?
What is the use-case that justifies the costs associated with having the
debugfs entries?
 
> [    0.000000] MEMBLOCK configuration:
> [    0.000000]  memory size = 0x00000003ffe00000 reserved size =
> 0x000000001290fb70
> [    0.000000]  memory.cnt  = 0x25

BTW, it seems that the memory allocation by firmware is, well, suboptimal
and begs for fixes. I don't see why all these NOMAP areas cannot be put in
one contiguous chunk. I doubt they need to be NOMAP at all, but mysterious
the ways of ACPI.

> [    0.000000]  memory[0x0]     [0x0000000080200000-0x00000000fe6e2fff],
> 0x000000007e4e3000 bytes flags: 0x0
> [    0.000000]  memory[0x1]     [0x00000000fe6e3000-0x00000000fe6e5fff],
> 0x0000000000003000 bytes flags: 0x4
> [    0.000000]  memory[0x2]     [0x00000000fe6e6000-0x00000000fe709fff],
> 0x0000000000024000 bytes flags: 0x0
> [    0.000000]  memory[0x3]     [0x00000000fe70a000-0x00000000fe70bfff],
> 0x0000000000002000 bytes flags: 0x4
> [    0.000000]  memory[0x4]     [0x00000000fe70c000-0x00000000fe70ffff],
> 0x0000000000004000 bytes flags: 0x0
> [    0.000000]  memory[0x5]     [0x00000000fe710000-0x00000000fe710fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x6]     [0x00000000fe711000-0x00000000fe712fff],
> 0x0000000000002000 bytes flags: 0x0
> [    0.000000]  memory[0x7]     [0x00000000fe713000-0x00000000fe716fff],
> 0x0000000000004000 bytes flags: 0x4
> [    0.000000]  memory[0x8]     [0x00000000fe717000-0x00000000fe717fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x9]     [0x00000000fe718000-0x00000000fe71cfff],
> 0x0000000000005000 bytes flags: 0x4
> [    0.000000]  memory[0xa]     [0x00000000fe71d000-0x00000000fe71dfff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0xb]     [0x00000000fe71e000-0x00000000fe71efff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0xc]     [0x00000000fe71f000-0x00000000fe71ffff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0xd]     [0x00000000fe720000-0x00000000fe720fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0xe]     [0x00000000fe721000-0x00000000fe721fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0xf]     [0x00000000fe722000-0x00000000fe722fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x10]    [0x00000000fe723000-0x00000000fe723fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x11]    [0x00000000fe724000-0x00000000fe724fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x12]    [0x00000000fe725000-0x00000000fe725fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x13]    [0x00000000fe726000-0x00000000fe726fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x14]    [0x00000000fe727000-0x00000000fe728fff],
> 0x0000000000002000 bytes flags: 0x0
> [    0.000000]  memory[0x15]    [0x00000000fe729000-0x00000000fe729fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x16]    [0x00000000fe72a000-0x00000000fe72afff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x17]    [0x00000000fe72b000-0x00000000fe72cfff],
> 0x0000000000002000 bytes flags: 0x4
> [    0.000000]  memory[0x18]    [0x00000000fe72d000-0x00000000fe72dfff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x19]    [0x00000000fe72e000-0x00000000fe72efff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x1a]    [0x00000000fe72f000-0x00000000fe72ffff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x1b]    [0x00000000fe730000-0x00000000fe730fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x1c]    [0x00000000fe731000-0x00000000fe731fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x1d]    [0x00000000fe732000-0x00000000fe732fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x1e]    [0x00000000fe733000-0x00000000fe733fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  memory[0x1f]    [0x00000000fe734000-0x00000000fe734fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x20]    [0x00000000fe735000-0x00000000fe736fff],
> 0x0000000000002000 bytes flags: 0x0
> [    0.000000]  memory[0x21]    [0x00000000fe737000-0x00000000fe737fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x22]    [0x00000000fe738000-0x00000000fff60fff],
> 0x0000000001829000 bytes flags: 0x0
> [    0.000000]  memory[0x23]    [0x00000000fff61000-0x00000000fff61fff],
> 0x0000000000001000 bytes flags: 0x4
> [    0.000000]  memory[0x24]    [0x00000000fff62000-0x000000047fffffff],
> 0x000000038009e000 bytes flags: 0x0
> [    0.000000]  reserved.cnt  = 0xd
> [    0.000000]  reserved[0x0]   [0x0000000080000000-0x000000008007ffff],
> 0x0000000000080000 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0000000080200000-0x00000000815fffff],
> 0x0000000001400000 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0000000087f00000-0x0000000087f05fff],
> 0x0000000000006000 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x00000000db0a2000-0x00000000db0a48b4],
> 0x00000000000028b5 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x00000000db2a2000-0x00000000dc709fff],
> 0x0000000001468000 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x00000000fe701000-0x00000000fe701fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  reserved[0x6]   [0x00000000fe704040-0x00000000fe70404f],
> 0x0000000000000010 bytes flags: 0x0
> [    0.000000]  reserved[0x7]   [0x000000046ffe1d40-0x000000047dfe253f],
> 0x000000000e000800 bytes flags: 0x0
> [    0.000000]  reserved[0x8]   [0x000000047dfe2548-0x000000047dfe2578],
> 0x0000000000000031 bytes flags: 0x0
> [    0.000000]  reserved[0x9]   [0x000000047dfe2580-0x000000047dfe25ae],
> 0x000000000000002f bytes flags: 0x0
> [    0.000000]  reserved[0xa]   [0x000000047dfe25b0-0x000000047dfe25de],
> 0x000000000000002f bytes flags: 0x0
> [    0.000000]  reserved[0xb]   [0x000000047dfe25e0-0x000000047dfefffb],
> 0x000000000000da1c bytes flags: 0x0
> [    0.000000]  reserved[0xc]   [0x000000047dff0000-0x000000047fffffff],
> 0x0000000002010000 bytes flags: 0x0
> 
> Best regards
> 
> Heinrich
> 
> > 
> > > 
> > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > ---
> > >   arch/riscv/Kconfig | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index 4f7b70ae7c31..a6e57614c3fd 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -31,6 +31,7 @@ config RISCV
> > >       select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
> > >       select ARCH_HAS_STRICT_MODULE_RWX if MMU && !XIP_KERNEL
> > >       select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> > > +    select ARCH_KEEP_MEMBLOCK
> > >       select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
> > >       select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
> > >       select ARCH_SUPPORTS_HUGETLBFS if MMU
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

-- 
Sincerely yours,
Mike.

  parent reply	other threads:[~2021-08-16 18:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 14:47 [PATCH 1/1] riscv: select CONFIG_ARCH_KEEP_MEMBLOCK Heinrich Schuchardt
2021-08-16 14:47 ` Heinrich Schuchardt
2021-08-16 15:30 ` Kefeng Wang
2021-08-16 15:30   ` Kefeng Wang
2021-08-16 15:52   ` Heinrich Schuchardt
2021-08-16 15:52     ` Heinrich Schuchardt
2021-08-16 16:03     ` Kefeng Wang
2021-08-16 16:03       ` Kefeng Wang
2021-08-16 18:50     ` Mike Rapoport [this message]
2021-08-16 18:50       ` Mike Rapoport
2021-09-11  6:46       ` Palmer Dabbelt
2021-09-11  6:46         ` Palmer Dabbelt

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=YRqzckNDbg0awrh4@kernel.org \
    --to=rppt@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=wangkefeng.wang@huawei.com \
    /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.