|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6 |
|
| #
89f60a5d |
| 23-Mar-2020 |
Gustavo A. R. Silva <[email protected]> |
genalloc.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declar
genalloc.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo { int stuff; struct boo array[]; };
By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this change:
"Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <[email protected]>
show more ...
|
|
Revision tags: v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1 |
|
| #
964975ac |
| 05-Dec-2019 |
Huang Shijie <[email protected]> |
lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr
Follow the kernel conventions, rename addr_in_gen_pool to gen_pool_has_addr.
[[email protected]: fix Documentation/ too] Link: http:/
lib/genalloc.c: rename addr_in_gen_pool to gen_pool_has_addr
Follow the kernel conventions, rename addr_in_gen_pool to gen_pool_has_addr.
[[email protected]: fix Documentation/ too] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Huang Shijie <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Marek Szyprowski <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7 |
|
| #
cf394fc5 |
| 25-Jun-2019 |
Fredrik Noring <[email protected]> |
lib/genalloc.c: Add algorithm, align and zeroed family of DMA allocators
Provide the algorithm option to DMA allocators as well, along with convenience variants for zeroed and aligned memory. The fo
lib/genalloc.c: Add algorithm, align and zeroed family of DMA allocators
Provide the algorithm option to DMA allocators as well, along with convenience variants for zeroed and aligned memory. The following four functions are added:
- gen_pool_dma_alloc_algo() - gen_pool_dma_alloc_align() - gen_pool_dma_zalloc_algo() - gen_pool_dma_zalloc_align()
Signed-off-by: Fredrik Noring <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc6, v5.2-rc5, v5.2-rc4 |
|
| #
40b0b3f8 |
| 03-Jun-2019 |
Thomas Gleixner <[email protected]> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 230
Based on 2 normalized pattern(s):
this source code is licensed under the gnu general public license version 2 see the file cop
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 230
Based on 2 normalized pattern(s):
this source code is licensed under the gnu general public license version 2 see the file copying for more details
this source code is licensed under general public license version 2 see
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 52 file(s).
Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Enrico Weigelt <[email protected]> Reviewed-by: Allison Randal <[email protected]> Reviewed-by: Alexios Zavras <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| #
795ee306 |
| 13-Jun-2019 |
Dan Williams <[email protected]> |
lib/genalloc: introduce chunk owners
The p2pdma facility enables a provider to publish a pool of dma addresses for a consumer to allocate. A genpool is used internally by p2pdma to collect dma reso
lib/genalloc: introduce chunk owners
The p2pdma facility enables a provider to publish a pool of dma addresses for a consumer to allocate. A genpool is used internally by p2pdma to collect dma resources, 'chunks', to be handed out to consumers. Whenever a consumer allocates a resource it needs to pin the 'struct dev_pagemap' instance that backs the chunk selected by pci_alloc_p2pmem().
Currently that reference is taken globally on the entire provider device. That sets up a lifetime mismatch whereby the p2pdma core needs to maintain hacks to make sure the percpu_ref is not released twice.
This lifetime mismatch also stands in the way of a fix to devm_memremap_pages() whereby devm_memremap_pages_release() must wait for the percpu_ref ->release() callback to complete before it can proceed to teardown pages.
So, towards fixing this situation, introduce the ability to store a 'chunk owner' at gen_pool_add() time, and a facility to retrieve the owner at gen_pool_{alloc,free}() time. For p2pdma this will be used to store and recall individual dev_pagemap reference counter instances per-chunk.
Link: http://lkml.kernel.org/r/155727338118.292046.13407378933221579644.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: "Jérôme Glisse" <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc3 |
|
| #
da83a722 |
| 29-May-2019 |
Fredrik Noring <[email protected]> |
lib/genalloc: add gen_pool_dma_zalloc() for zeroed DMA allocations
gen_pool_dma_zalloc() is a zeroed memory variant of gen_pool_dma_alloc(). Also document the return values of both, and indicate NU
lib/genalloc: add gen_pool_dma_zalloc() for zeroed DMA allocations
gen_pool_dma_zalloc() is a zeroed memory variant of gen_pool_dma_alloc(). Also document the return values of both, and indicate NULL as a "%NULL" constant.
Signed-off-by: Fredrik Noring <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
show more ...
|
|
Revision tags: v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1 |
|
| #
52fbf113 |
| 03-Jan-2019 |
Alexey Skidanov <[email protected]> |
lib/genalloc.c: fix allocation of aligned buffer from non-aligned chunk
gen_pool_alloc_algo() uses different allocation functions implementing different allocation algorithms. With gen_pool_first_f
lib/genalloc.c: fix allocation of aligned buffer from non-aligned chunk
gen_pool_alloc_algo() uses different allocation functions implementing different allocation algorithms. With gen_pool_first_fit_align() allocation function, the returned address should be aligned on the requested boundary.
If chunk start address isn't aligned on the requested boundary, the returned address isn't aligned too. The only way to get properly aligned address is to initialize the pool with chunks aligned on the requested boundary. If want to have an ability to allocate buffers aligned on different boundaries (for example, 4K, 1MB, ...), the chunk start address should be aligned on the max possible alignment.
This happens because gen_pool_first_fit_align() looks for properly aligned memory block without taking into account the chunk start address alignment.
To fix this, we provide chunk start address to gen_pool_first_fit_align() and change its implementation such that it starts looking for properly aligned block with appropriate offset (exactly as is done in CMA).
Link: https://lkml.kernel.org/lkml/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Alexey Skidanov <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Logan Gunthorpe <[email protected]> Cc: Daniel Mentz <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Laura Abbott <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1, v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1, v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4, v4.17-rc3, v4.17-rc2, v4.17-rc1, v4.16, v4.16-rc7, v4.16-rc6, v4.16-rc5, v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2, v4.15-rc1 |
|
| #
36a3d1dd |
| 17-Nov-2017 |
Stephen Bates <[email protected]> |
lib/genalloc.c: make the avail variable an atomic_long_t
If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and
lib/genalloc.c: make the avail variable an atomic_long_t
If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. This is only expected to be an issue on 64 bit systems.
Add the <linux/atomic.h> header to pull in atomic_long* operations. So that 32 bit systems continue to use atomic32_t but 64 bit systems can use atomic64_t.
Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Stephen Bates <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Reviewed-by: Daniel Mentz <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v4.14, v4.14-rc8, v4.14-rc7, v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13 |
|
| #
a27bfcab |
| 31-Aug-2017 |
Jonathan Corbet <[email protected]> |
genalloc: Fix an incorrect kerneldoc comment
The kerneldoc comment for the genpool_algo_t typedef was incomplete and incorrectly formatted, leading to a raft of warnings during the docs build. Fix i
genalloc: Fix an incorrect kerneldoc comment
The kerneldoc comment for the genpool_algo_t typedef was incomplete and incorrectly formatted, leading to a raft of warnings during the docs build. Fix it appropriately.
Signed-off-by: Jonathan Corbet <[email protected]>
show more ...
|
|
Revision tags: v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7, v4.11-rc6, v4.11-rc5, v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8, v4.10-rc7, v4.10-rc6, v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1, v4.7, v4.7-rc7, v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1, v4.6, v4.6-rc7, v4.6-rc6, v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6, v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3 |
|
| #
b26981c8 |
| 30-Nov-2015 |
Zhao Qiang <[email protected]> |
genalloc:support allocating specific region
Add new algo for genalloc, it reserve a specific region of memory
Signed-off-by: Zhao Qiang <[email protected]> Signed-off-by: Scott Wood <scottwo
genalloc:support allocating specific region
Add new algo for genalloc, it reserve a specific region of memory
Signed-off-by: Zhao Qiang <[email protected]> Signed-off-by: Scott Wood <[email protected]>
show more ...
|
| #
de2dd0eb |
| 30-Nov-2015 |
Zhao Qiang <[email protected]> |
genalloc:support memory-allocation with bytes-alignment to genalloc
Bytes alignment is required to manage some special RAM, so add gen_pool_first_fit_align to genalloc, meanwhile add gen_pool_alloc_
genalloc:support memory-allocation with bytes-alignment to genalloc
Bytes alignment is required to manage some special RAM, so add gen_pool_first_fit_align to genalloc, meanwhile add gen_pool_alloc_algo to pass algo in case user layer using more than one algo, and pass data to gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)
Signed-off-by: Zhao Qiang <[email protected]> Signed-off-by: Scott Wood <[email protected]>
show more ...
|
|
Revision tags: v4.4-rc2, v4.4-rc1, v4.3, v4.3-rc7, v4.3-rc6, v4.3-rc5, v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1 |
|
| #
c98c3635 |
| 04-Sep-2015 |
Vladimir Zapolskiy <[email protected]> |
genalloc: add support of multiple gen_pools per device
This change fills devm_gen_pool_create()/gen_pool_get() "name" argument stub with contents and extends of_gen_pool_get() functionality on this
genalloc: add support of multiple gen_pools per device
This change fills devm_gen_pool_create()/gen_pool_get() "name" argument stub with contents and extends of_gen_pool_get() functionality on this basis.
If there is no associated platform device with a device node passed to of_gen_pool_get(), the function attempts to get a label property or device node name (= repeats MTD OF partition standard) and seeks for a named gen_pool registered by device of the parent device node.
The main idea of the change is to allow registration of independent gen_pools under the same umbrella device, say "partitions" on "storage device", the original functionality of one "partition" per "storage device" is untouched.
[[email protected]: fix constness in devres_find()] [[email protected]: freeing const data pointers] Signed-off-by: Vladimir Zapolskiy <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Russell King <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Jean-Christophe Plagniol-Villard <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
| #
73858173 |
| 04-Sep-2015 |
Vladimir Zapolskiy <[email protected]> |
genalloc: add name arg to gen_pool_get() and devm_gen_pool_create()
This change modifies gen_pool_get() and devm_gen_pool_create() client interfaces adding one more argument "name" of a gen_pool obj
genalloc: add name arg to gen_pool_get() and devm_gen_pool_create()
This change modifies gen_pool_get() and devm_gen_pool_create() client interfaces adding one more argument "name" of a gen_pool object.
Due to implementation gen_pool_get() is capable to retrieve only one gen_pool associated with a device even if multiple gen_pools are created, fortunately right at the moment it is sufficient for the clients, hence provide NULL as a valid argument on both producer devm_gen_pool_create() and consumer gen_pool_get() sides.
Because only one created gen_pool per device is addressable, explicitly add a restriction to devm_gen_pool_create() to create only one gen_pool per device, this implies two possible error codes returned by the function, account it on client side (only misc/sram). This completes client side changes related to genalloc updates.
[[email protected]: gen_pool_get() cleanup] Signed-off-by: Vladimir Zapolskiy <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Russell King <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Jean-Christophe Plagniol-Villard <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1 |
|
| #
abdd4a70 |
| 30-Jun-2015 |
Vladimir Zapolskiy <[email protected]> |
genalloc: rename of_get_named_gen_pool() to of_gen_pool_get()
To be consistent with other kernel interface namings, rename of_get_named_gen_pool() to of_gen_pool_get(). In the original function nam
genalloc: rename of_get_named_gen_pool() to of_gen_pool_get()
To be consistent with other kernel interface namings, rename of_get_named_gen_pool() to of_gen_pool_get(). In the original function name "_named" suffix references to a device tree property, which contains a phandle to a device and the corresponding device driver is assumed to register a gen_pool object.
Due to a weak relation and to avoid any confusion (e.g. in future possible scenario if gen_pool objects are named) the suffix is removed.
[[email protected]: crypto/marvell/cesa - fix up for of_get_named_gen_pool() rename] Signed-off-by: Vladimir Zapolskiy <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Russell King <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Vinod Koul <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: Jaroslav Kysela <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Boris BREZILLON <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
| #
0030edf2 |
| 30-Jun-2015 |
Vladimir Zapolskiy <[email protected]> |
genalloc: rename dev_get_gen_pool() to gen_pool_get()
To be consistent with other genalloc interface namings, rename dev_get_gen_pool() to gen_pool_get(). The original omitted "dev_" prefix is remo
genalloc: rename dev_get_gen_pool() to gen_pool_get()
To be consistent with other genalloc interface namings, rename dev_get_gen_pool() to gen_pool_get(). The original omitted "dev_" prefix is removed, since it points to argument type of the function, and so it does not bring any useful information.
[[email protected]: update arch/arm/mach-socfpga/pm.c] Signed-off-by: Vladimir Zapolskiy <[email protected]> Acked-by: Nicolas Ferre <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Russell King <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Vinod Koul <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: Jaroslav Kysela <[email protected]> Cc: Mark Brown <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Alan Tull <[email protected]> Cc: Dinh Nguyen <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1 |
|
| #
9efb3a42 |
| 09-Oct-2014 |
Laura Abbott <[email protected]> |
lib/genalloc.c: add genpool range check function
After allocating an address from a particular genpool, there is no good way to verify if that address actually belongs to a genpool. Introduce addr_
lib/genalloc.c: add genpool range check function
After allocating an address from a particular genpool, there is no good way to verify if that address actually belongs to a genpool. Introduce addr_in_gen_pool which will return if an address plus size falls completely within the genpool range.
Signed-off-by: Laura Abbott <[email protected]> Acked-by: Will Deacon <[email protected]> Reviewed-by: Olof Johansson <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: David Riley <[email protected]> Cc: Ritesh Harjain <[email protected]> Cc: Russell King <[email protected]> Cc: Thierry Reding <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
| #
505e3be6 |
| 09-Oct-2014 |
Laura Abbott <[email protected]> |
lib/genalloc.c: add power aligned algorithm
One of the more common algorithms used for allocation is to align the start address of the allocation to the order of size requested. Add this as an algo
lib/genalloc.c: add power aligned algorithm
One of the more common algorithms used for allocation is to align the start address of the allocation to the order of size requested. Add this as an algorithm option for genalloc.
Signed-off-by: Laura Abbott <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Olof Johansson <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: David Riley <[email protected]> Cc: Ritesh Harjain <[email protected]> Cc: Russell King <[email protected]> Cc: Thierry Reding <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1 |
|
| #
b30afea0 |
| 23-Jan-2014 |
Shawn Guo <[email protected]> |
include/linux/genalloc.h: spinlock_t needs spinlock_types.h
Compiling a C file which includes genalloc.h but without spinlock_types.h being included before, we will see the compile error below.
in
include/linux/genalloc.h: spinlock_t needs spinlock_types.h
Compiling a C file which includes genalloc.h but without spinlock_types.h being included before, we will see the compile error below.
include/linux/genalloc.h:54:2: error: unknown type name `spinlock_t'
Include spinlock_types.h from genalloc.h to fix the problem.
Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1 |
|
| #
684f0d3d |
| 12-Nov-2013 |
Nicolin Chen <[email protected]> |
lib/genalloc: add a helper function for DMA buffer allocation
When using pool space for DMA buffer, there might be duplicated calling of gen_pool_alloc() and gen_pool_virt_to_phys() in each implemen
lib/genalloc: add a helper function for DMA buffer allocation
When using pool space for DMA buffer, there might be duplicated calling of gen_pool_alloc() and gen_pool_virt_to_phys() in each implementation.
Thus it's better to add a simple helper function, a compatible one to the common dma_alloc_coherent(), to save some code.
Signed-off-by: Nicolin Chen <[email protected]> Cc: "Hans J. Koch" <[email protected]> Cc: Dan Williams <[email protected]> Cc: Eric Miao <[email protected]> Cc: Grant Likely <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Haojian Zhuang <[email protected]> Cc: Jaroslav Kysela <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Liam Girdwood <[email protected]> Cc: Mark Brown <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Rob Herring <[email protected]> Cc: Russell King <[email protected]> Cc: Sekhar Nori <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: Vinod Koul <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1 |
|
| #
674470d9 |
| 11-Sep-2013 |
Joonyoung Shim <[email protected]> |
lib/genalloc.c: fix overflow of ending address of memory chunk
In struct gen_pool_chunk, end_addr means the end address of memory chunk (inclusive), but in the implementation it is treated as addres
lib/genalloc.c: fix overflow of ending address of memory chunk
In struct gen_pool_chunk, end_addr means the end address of memory chunk (inclusive), but in the implementation it is treated as address + size of memory chunk (exclusive), so it points to the address plus one instead of correct ending address.
The ending address of memory chunk plus one will cause overflow on the memory chunk including the last address of memory map, e.g. when starting address is 0xFFF00000 and size is 0x100000 on 32bit machine, ending address will be 0x100000000.
Use correct ending address like starting address + size - 1.
[[email protected]: add comment to struct gen_pool_chunk:end_addr] Signed-off-by: Joonyoung Shim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1 |
|
| #
9375db07 |
| 29-Apr-2013 |
Philipp Zabel <[email protected]> |
genalloc: add devres support, allow to find a managed pool by device
This patch adds three exported functions to lib/genalloc.c: devm_gen_pool_create, dev_get_gen_pool, and of_get_named_gen_pool.
d
genalloc: add devres support, allow to find a managed pool by device
This patch adds three exported functions to lib/genalloc.c: devm_gen_pool_create, dev_get_gen_pool, and of_get_named_gen_pool.
devm_gen_pool_create is a managed version of gen_pool_create that keeps track of the pool via devres and allows the management code to automatically destroy it after device removal.
dev_get_gen_pool retrieves the gen_pool for a given device, if it was created with devm_gen_pool_create, using devres_find.
of_get_named_gen_pool retrieves the gen_pool for a given device node and property name, where the property must contain a phandle pointing to a platform device node. The corresponding platform device is then fed into dev_get_gen_pool and the resulting gen_pool is returned.
[[email protected]: make the of_get_named_gen_pool() stub static, fixing a zillion link errors] [[email protected]: squish "struct device declared inside parameter list" warning] Signed-off-by: Philipp Zabel <[email protected]> Acked-by: Grant Likely <[email protected]> Tested-by: Michal Simek <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Matt Porter <[email protected]> Cc: Dong Aisheng <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Rob Herring <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Javier Martin <[email protected]> Cc: Huang Shijie <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1, v3.8, v3.8-rc7, v3.8-rc6, v3.8-rc5, v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3, v3.7-rc2, v3.7-rc1 |
|
| #
ca279cf1 |
| 05-Oct-2012 |
Benjamin Gaignard <[email protected]> |
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For example a custom algorithm could be used to manage alignment requ
genalloc: make it possible to use a custom allocation algorithm
Premit use of another algorithm than the default first-fit one. For example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation uses cases, I add a "free" field 'void *data' to pass any needed information to the allocation function. For example 'data' could be used to handle a structure where you store the alignment, the expected memory bank, the requester device, or any information that could influence the allocation algorithm.
An usage example may look like this: struct my_pool_constraints { int align; int bank; ... };
unsigned long my_custom_algo(unsigned long *map, unsigned long size, unsigned long start, unsigned int nr, void *data) { struct my_pool_constraints *constraints = data; ... deal with allocation contraints ... return the index in bitmap where perform the allocation }
void create_my_pool() { struct my_pool_constraints c; struct gen_pool *pool = gen_pool_create(...); gen_pool_add(pool, ...); gen_pool_set_algo(pool, my_custom_algo, &c); }
Add of best-fit algorithm function: most of the time best-fit is slower then first-fit but memory fragmentation is lower. The random buffer allocation/free tests don't show any arithmetic relation between the allocation time and fragmentation but the best-fit algorithm is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but fast on-chip RAM of few KB, used for high-performance uses cases like DMA linked lists, graphic accelerators, encoders/decoders. On the Ux500 (in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of static allocations becomes unmaintainable: cd arch/arm/mach-ux500 && grep -r ESRAM . ./include/mach/db8500-regs.h:/* Base address and bank offsets for ESRAM */ ./include/mach/db8500-regs.h:#define U8500_ESRAM_BASE 0x40000000 ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK_SIZE 0x00020000 ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK0 U8500_ESRAM_BASE ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK1 (U8500_ESRAM_BASE + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK2 (U8500_ESRAM_BANK1 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK3 (U8500_ESRAM_BANK2 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK4 (U8500_ESRAM_BANK3 + U8500_ESRAM_BANK_SIZE) ./include/mach/db8500-regs.h:#define U8500_ESRAM_DMA_LCPA_OFFSET 0x10000 ./include/mach/db8500-regs.h:#define U8500_DMA_LCPA_BASE (U8500_ESRAM_BANK0 + U8500_ESRAM_DMA_LCPA_OFFSET) ./include/mach/db8500-regs.h:#define U8500_DMA_LCLA_BASE U8500_ESRAM_BANK4
I want to use genalloc to do dynamic allocations but I need to be able to fine tune the allocation algorithm. I my case best-fit algorithm give better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard <[email protected]> Cc: Huang Ying <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
|
Revision tags: v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1, v3.3, v3.3-rc7, v3.3-rc6, v3.3-rc5, v3.3-rc4, v3.3-rc3, v3.3-rc2, v3.3-rc1, v3.2, v3.2-rc7, v3.2-rc6, v3.2-rc5, v3.2-rc4, v3.2-rc3, v3.2-rc2, v3.2-rc1, v3.1, v3.1-rc10, v3.1-rc9, v3.1-rc8, v3.1-rc7, v3.1-rc6, v3.1-rc5, v3.1-rc4, v3.1-rc3, v3.1-rc2, v3.1-rc1, v3.0 |
|
| #
7f184275 |
| 13-Jul-2011 |
Huang Ying <[email protected]> |
lib, Make gen_pool memory allocator lockless
This version of the gen_pool memory allocator supports lockless operation.
This makes it safe to use in NMI handlers and other special unblockable conte
lib, Make gen_pool memory allocator lockless
This version of the gen_pool memory allocator supports lockless operation.
This makes it safe to use in NMI handlers and other special unblockable contexts that could otherwise deadlock on locks. This is implemented by using atomic operations and retries on any conflicts. The disadvantage is that there may be livelocks in extreme cases. For better scalability, one gen_pool allocator can be used for each CPU.
The lockless operation only works if there is enough memory available. If new memory is added to the pool a lock has to be still taken. So any user relying on locklessness has to ensure that sufficient memory is preallocated.
The basic atomic operation of this allocator is cmpxchg on long. On architectures that don't have NMI-safe cmpxchg implementation, the allocator can NOT be used in NMI handler. So code uses the allocator in NMI handler should depend on CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG.
Signed-off-by: Huang Ying <[email protected]> Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
show more ...
|
|
Revision tags: v3.0-rc7, v3.0-rc6, v3.0-rc5, v3.0-rc4, v3.0-rc3, v3.0-rc2, v3.0-rc1 |
|
| #
3c8f370d |
| 25-May-2011 |
Jean-Christophe PLAGNIOL-VILLARD <[email protected]> |
lib/genalloc.c: add support for specifying the physical address
So we can specify the virtual address as the base of the pool chunk and then get physical addresses for hardware IP.
For example on a
lib/genalloc.c: add support for specifying the physical address
So we can specify the virtual address as the base of the pool chunk and then get physical addresses for hardware IP.
For example on at91 we will use this on spi, uart or macb
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Patrice VILCHEZ <[email protected]> Cc: Jes Sorensen <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|
| #
6aae6e03 |
| 25-May-2011 |
Jean-Christophe PLAGNIOL-VILLARD <[email protected]> |
include/linux/genalloc.h: add multiple-inclusion guards
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Patrice VILCHEZ <patri
include/linux/genalloc.h: add multiple-inclusion guards
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Patrice VILCHEZ <[email protected]> Cc: Jes Sorensen <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
show more ...
|