mirror of https://gitee.com/openkylin/linux.git
docs: remove :c:func: from genalloc.rst
As of 5.3, the automarkup extension will do the right thing with function() notation, so we don't need to clutter the text with :c:func: invocations. So remove them. Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
049500715e
commit
f11b46f314
|
@ -23,7 +23,7 @@ begins with the creation of a pool using one of:
|
||||||
.. kernel-doc:: lib/genalloc.c
|
.. kernel-doc:: lib/genalloc.c
|
||||||
:functions: devm_gen_pool_create
|
:functions: devm_gen_pool_create
|
||||||
|
|
||||||
A call to :c:func:`gen_pool_create` will create a pool. The granularity of
|
A call to gen_pool_create() will create a pool. The granularity of
|
||||||
allocations is set with min_alloc_order; it is a log-base-2 number like
|
allocations is set with min_alloc_order; it is a log-base-2 number like
|
||||||
those used by the page allocator, but it refers to bytes rather than pages.
|
those used by the page allocator, but it refers to bytes rather than pages.
|
||||||
So, if min_alloc_order is passed as 3, then all allocations will be a
|
So, if min_alloc_order is passed as 3, then all allocations will be a
|
||||||
|
@ -32,7 +32,7 @@ required to track the memory in the pool. The nid parameter specifies
|
||||||
which NUMA node should be used for the allocation of the housekeeping
|
which NUMA node should be used for the allocation of the housekeeping
|
||||||
structures; it can be -1 if the caller doesn't care.
|
structures; it can be -1 if the caller doesn't care.
|
||||||
|
|
||||||
The "managed" interface :c:func:`devm_gen_pool_create` ties the pool to a
|
The "managed" interface devm_gen_pool_create() ties the pool to a
|
||||||
specific device. Among other things, it will automatically clean up the
|
specific device. Among other things, it will automatically clean up the
|
||||||
pool when the given device is destroyed.
|
pool when the given device is destroyed.
|
||||||
|
|
||||||
|
@ -55,10 +55,10 @@ to the pool. That can be done with one of:
|
||||||
.. kernel-doc:: lib/genalloc.c
|
.. kernel-doc:: lib/genalloc.c
|
||||||
:functions: gen_pool_add_owner
|
:functions: gen_pool_add_owner
|
||||||
|
|
||||||
A call to :c:func:`gen_pool_add` will place the size bytes of memory
|
A call to gen_pool_add() will place the size bytes of memory
|
||||||
starting at addr (in the kernel's virtual address space) into the given
|
starting at addr (in the kernel's virtual address space) into the given
|
||||||
pool, once again using nid as the node ID for ancillary memory allocations.
|
pool, once again using nid as the node ID for ancillary memory allocations.
|
||||||
The :c:func:`gen_pool_add_virt` variant associates an explicit physical
|
The gen_pool_add_virt() variant associates an explicit physical
|
||||||
address with the memory; this is only necessary if the pool will be used
|
address with the memory; this is only necessary if the pool will be used
|
||||||
for DMA allocations.
|
for DMA allocations.
|
||||||
|
|
||||||
|
@ -74,11 +74,11 @@ are:
|
||||||
.. kernel-doc:: lib/genalloc.c
|
.. kernel-doc:: lib/genalloc.c
|
||||||
:functions: gen_pool_free_owner
|
:functions: gen_pool_free_owner
|
||||||
|
|
||||||
As one would expect, :c:func:`gen_pool_alloc` will allocate size< bytes
|
As one would expect, gen_pool_alloc() will allocate size< bytes
|
||||||
from the given pool. The :c:func:`gen_pool_dma_alloc` variant allocates
|
from the given pool. The gen_pool_dma_alloc() variant allocates
|
||||||
memory for use with DMA operations, returning the associated physical
|
memory for use with DMA operations, returning the associated physical
|
||||||
address in the space pointed to by dma. This will only work if the memory
|
address in the space pointed to by dma. This will only work if the memory
|
||||||
was added with :c:func:`gen_pool_add_virt`. Note that this function
|
was added with gen_pool_add_virt(). Note that this function
|
||||||
departs from the usual genpool pattern of using unsigned long values to
|
departs from the usual genpool pattern of using unsigned long values to
|
||||||
represent kernel addresses; it returns a void * instead.
|
represent kernel addresses; it returns a void * instead.
|
||||||
|
|
||||||
|
@ -94,9 +94,9 @@ of interest:
|
||||||
.. kernel-doc:: lib/genalloc.c
|
.. kernel-doc:: lib/genalloc.c
|
||||||
:functions: gen_pool_set_algo
|
:functions: gen_pool_set_algo
|
||||||
|
|
||||||
Allocations with :c:func:`gen_pool_alloc_algo` specify an algorithm to be
|
Allocations with gen_pool_alloc_algo() specify an algorithm to be
|
||||||
used to choose the memory to be allocated; the default algorithm can be set
|
used to choose the memory to be allocated; the default algorithm can be set
|
||||||
with :c:func:`gen_pool_set_algo`. The data value is passed to the
|
with gen_pool_set_algo(). The data value is passed to the
|
||||||
algorithm; most ignore it, but it is occasionally needed. One can,
|
algorithm; most ignore it, but it is occasionally needed. One can,
|
||||||
naturally, write a special-purpose algorithm, but there is a fair set
|
naturally, write a special-purpose algorithm, but there is a fair set
|
||||||
already available:
|
already available:
|
||||||
|
|
Loading…
Reference in New Issue