From: Mike Rapoport <rppt@linux.ibm.com>
To: Cao jin <caoj.fnst@cn.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/memblock: cleanup doc
Date: Sun, 15 Sep 2019 08:16:40 +0300 [thread overview]
Message-ID: <20190915051640.GA11429@linux.ibm.com> (raw)
In-Reply-To: <20190912123127.8694-1-caoj.fnst@cn.fujitsu.com>
On Thu, Sep 12, 2019 at 08:31:27PM +0800, Cao jin wrote:
> fix typos for:
> elaboarte -> elaborate
> architecure -> architecture
> compltes -> completes
>
> And, convert the markup :c:func:`foo` to foo() as kernel documentation
> toolchain can recognize foo() as a function.
>
> Suggested-by: Mike Rapoport <rppt@linux.ibm.com>
> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> mm/memblock.c | 44 ++++++++++++++++++++------------------------
> 1 file changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7d4f61ae666a..c23b370cc49e 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -57,42 +57,38 @@
> * at build time. The region arrays for the "memory" and "reserved"
> * types are initially sized to %INIT_MEMBLOCK_REGIONS and for the
> * "physmap" type to %INIT_PHYSMEM_REGIONS.
> - * The :c:func:`memblock_allow_resize` enables automatic resizing of
> - * the region arrays during addition of new regions. This feature
> - * should be used with care so that memory allocated for the region
> - * array will not overlap with areas that should be reserved, for
> - * example initrd.
> + * The memblock_allow_resize() enables automatic resizing of the region
> + * arrays during addition of new regions. This feature should be used
> + * with care so that memory allocated for the region array will not
> + * overlap with areas that should be reserved, for example initrd.
> *
> * The early architecture setup should tell memblock what the physical
> - * memory layout is by using :c:func:`memblock_add` or
> - * :c:func:`memblock_add_node` functions. The first function does not
> - * assign the region to a NUMA node and it is appropriate for UMA
> - * systems. Yet, it is possible to use it on NUMA systems as well and
> - * assign the region to a NUMA node later in the setup process using
> - * :c:func:`memblock_set_node`. The :c:func:`memblock_add_node`
> - * performs such an assignment directly.
> + * memory layout is by using memblock_add() or memblock_add_node()
> + * functions. The first function does not assign the region to a NUMA
> + * node and it is appropriate for UMA systems. Yet, it is possible to
> + * use it on NUMA systems as well and assign the region to a NUMA node
> + * later in the setup process using memblock_set_node(). The
> + * memblock_add_node() performs such an assignment directly.
> *
> * Once memblock is setup the memory can be allocated using one of the
> * API variants:
> *
> - * * :c:func:`memblock_phys_alloc*` - these functions return the
> - * **physical** address of the allocated memory
> - * * :c:func:`memblock_alloc*` - these functions return the **virtual**
> - * address of the allocated memory.
> + * * memblock_phys_alloc*() - these functions return the **physical**
> + * address of the allocated memory
> + * * memblock_alloc*() - these functions return the **virtual** address
> + * of the allocated memory.
> *
> * Note, that both API variants use implict assumptions about allowed
> * memory ranges and the fallback methods. Consult the documentation
> - * of :c:func:`memblock_alloc_internal` and
> - * :c:func:`memblock_alloc_range_nid` functions for more elaboarte
> - * description.
> + * of memblock_alloc_internal() and memblock_alloc_range_nid()
> + * functions for more elaborate description.
> *
> - * As the system boot progresses, the architecture specific
> - * :c:func:`mem_init` function frees all the memory to the buddy page
> - * allocator.
> + * As the system boot progresses, the architecture specific mem_init()
> + * function frees all the memory to the buddy page allocator.
> *
> - * Unless an architecure enables %CONFIG_ARCH_KEEP_MEMBLOCK, the
> + * Unless an architecture enables %CONFIG_ARCH_KEEP_MEMBLOCK, the
> * memblock data structures will be discarded after the system
> - * initialization compltes.
> + * initialization completes.
> */
>
> #ifndef CONFIG_NEED_MULTIPLE_NODES
> --
> 2.21.0
>
>
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2019-09-15 5:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 12:31 [PATCH] mm/memblock: cleanup doc Cao jin
2019-09-15 5:16 ` Mike Rapoport [this message]
2019-11-06 14:46 ` Mike Rapoport
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=20190915051640.GA11429@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.