linux-toradex.git/drivers/of/of_reserved_mem.c, branch v5.17-rc4

memblock: rename memblock_free to memblock_phys_free

2021-11-06T20:30:41+00:00

Since memblock_free() operates on a physical range, make its name
reflect it and rename it to memblock_phys_free(), so it will be a
logical counterpart to memblock_phys_alloc().

The callers are updated with the below semantic patch:

    @@
    expression addr;
    expression size;
    @@
    - memblock_free(addr, size);
    + memblock_phys_free(addr, size);

Link: https://lkml.kernel.org/r/20210930185031.18648-6-rppt@kernel.org
Signed-off-by: Mike Rapoport 
Cc: Christophe Leroy 
Cc: Juergen Gross 
Cc: Shahab Vahedi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: exclude MEMBLOCK_NOMAP regions from kmemleak

2021-10-22T04:30:49+00:00

Vladimir Zapolskiy reports:

Commit a7259df76702 ("memblock: make memblock_find_in_range method
private") invokes a kernel panic while running kmemleak on OF platforms
with nomaped regions:

  Unable to handle kernel paging request at virtual address fff000021e00000
  [...]
    scan_block+0x64/0x170
    scan_gray_list+0xe8/0x17c
    kmemleak_scan+0x270/0x514
    kmemleak_write+0x34c/0x4ac

The memory allocated from memblock is registered with kmemleak, but if
it is marked MEMBLOCK_NOMAP it won't have linear map entries so an
attempt to scan such areas will fault.

Ideally, memblock_mark_nomap() would inform kmemleak to ignore
MEMBLOCK_NOMAP memory, but it can be called before kmemleak interfaces
operating on physical addresses can use __va() conversion.

Make sure that functions that mark allocated memory as MEMBLOCK_NOMAP
take care of informing kmemleak to ignore such memory.

Link: https://lore.kernel.org/all/8ade5174-b143-d621-8c8e-dc6a1898c6fb@linaro.org
Link: https://lore.kernel.org/all/c30ff0a2-d196-c50d-22f0-bd50696b1205@quicinc.com
Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private")
Reported-by: Vladimir Zapolskiy 
Signed-off-by: Mike Rapoport 
Reviewed-by: Catalin Marinas 
Tested-by: Vladimir Zapolskiy 
Tested-by: Qian Cai 
Signed-off-by: Linus Torvalds

memblock: make memblock_find_in_range method private

2021-09-03T16:58:17+00:00

There are a lot of uses of memblock_find_in_range() along with
memblock_reserve() from the times memblock allocation APIs did not exist.

memblock_find_in_range() is the very core of memblock allocations, so any
future changes to its internal behaviour would mandate updates of all the
users outside memblock.

Replace the calls to memblock_find_in_range() with an equivalent calls to
memblock_phys_alloc() and memblock_phys_alloc_range() and make
memblock_find_in_range() private method of memblock.

This simplifies the callers, ensures that (unlikely) errors in
memblock_reserve() are handled and improves maintainability of
memblock_find_in_range().

Link: https://lkml.kernel.org/r/20210816122622.30279-1-rppt@kernel.org
Signed-off-by: Mike Rapoport 
Reviewed-by: Catalin Marinas 		[arm64]
Acked-by: Kirill A. Shutemov 
Acked-by: Rafael J. Wysocki 	[ACPI]
Acked-by: Russell King (Oracle) 
Acked-by: Nick Kossifidis 			[riscv]
Tested-by: Guenter Roeck 
Acked-by: Rob Herring 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

of: of_reserved_mem: mark nomap memory instead of removing

2021-06-24T19:47:26+00:00

Since commit 86588296acbf ("fdt: Properly handle "no-map" field in the memory region"),
nomap memory is changed to call memblock_mark_nomap() instead of
memblock_remove(). But it only changed the reserved memory with fixed
addr and size case in early_init_dt_reserve_memory_arch(), not
including the dynamical allocation by size case in
early_init_dt_alloc_reserved_memory_arch().

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Signed-off-by: Dong Aisheng 
Reviewed-by: Quentin Perret 
Link: https://lore.kernel.org/r/20210611131153.3731147-2-aisheng.dong@nxp.com
Signed-off-by: Rob Herring

of: of_reserved_mem: only call memblock_free for normal reserved memory

2021-06-24T19:47:26+00:00

For nomap case, the memory block will be removed by memblock_remove()
in early_init_dt_alloc_reserved_memory_arch(). So it's meaningless to
call memblock_free() on error path.

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Signed-off-by: Dong Aisheng 
Link: https://lore.kernel.org/r/20210611131153.3731147-1-aisheng.dong@nxp.com
Signed-off-by: Rob Herring

of: Fix truncation of memory sizes on 32-bit platforms

2021-06-16T19:55:05+00:00

Variable "size" has type "phys_addr_t", which can be either 32-bit or
64-bit on 32-bit systems, while "unsigned long" is always 32-bit on
32-bit systems.  Hence the cast in

    (unsigned long)size / SZ_1M

may truncate a 64-bit size to 32-bit, as casts have a higher operator
precedence than divisions.

Fix this by inverting the order of the cast and division, which should
be safe for memory blocks smaller than 4 PiB.  Note that the division is
actually a shift, as SZ_1M is a power-of-two constant, hence there is no
need to use div_u64().

While at it, use "%lu" to format "unsigned long".

Fixes: e8d9d1f5485b52ec ("drivers: of: add initialization code for static reserved memory")
Fixes: 3f0c8206644836e4 ("drivers: of: add initialization code for dynamic reserved memory")
Signed-off-by: Geert Uytterhoeven 
Acked-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be
Signed-off-by: Rob Herring

of: Move reserved memory private function declarations

2021-06-03T01:59:28+00:00

fdt_init_reserved_mem() and fdt_reserved_mem_save_node() are private to
the DT code, so move there declarations to of_private.h. There's no need
for the dummy functions as CONFIG_OF_RESERVED_MEM is always enabled for
CONFIG_OF_EARLY_FLATTREE.

Cc: Frank Rowand 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20210527193841.1284169-1-robh@kernel.org

of: of_reserved_mem: Demote kernel-doc abuses

2021-03-23T21:27:53+00:00

Fixes the following W=1 kernel build warning(s):

 drivers/of/of_reserved_mem.c:53: warning: Function parameter or member 'node' not described in 'fdt_reserved_mem_save_node'
 drivers/of/of_reserved_mem.c:53: warning: Function parameter or member 'uname' not described in 'fdt_reserved_mem_save_node'
 drivers/of/of_reserved_mem.c:53: warning: Function parameter or member 'base' not described in 'fdt_reserved_mem_save_node'
 drivers/of/of_reserved_mem.c:53: warning: Function parameter or member 'size' not described in 'fdt_reserved_mem_save_node'
 drivers/of/of_reserved_mem.c:76: warning: Function parameter or member 'node' not described in '__reserved_mem_alloc_size'
 drivers/of/of_reserved_mem.c:76: warning: Function parameter or member 'uname' not described in '__reserved_mem_alloc_size'
 drivers/of/of_reserved_mem.c:76: warning: Function parameter or member 'res_base' not described in '__reserved_mem_alloc_size'
 drivers/of/of_reserved_mem.c:76: warning: Function parameter or member 'res_size' not described in '__reserved_mem_alloc_size'
 drivers/of/of_reserved_mem.c:171: warning: Function parameter or member 'rmem' not described in '__reserved_mem_init_node'

Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Marek Szyprowski 
Cc: Josh Cartwright 
Cc: devicetree@vger.kernel.org
Signed-off-by: Lee Jones 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20210318104036.3175910-11-lee.jones@linaro.org

of: Fix reserved-memory overlap detection

2020-10-26T01:37:55+00:00

The reserved-memory overlap detection code fails to detect overlaps if
either of the regions starts at address 0x0.  The code explicitly checks
for and ignores such regions, apparently in order to ignore dynamically
allocated regions which have an address of 0x0 at this point.  These
dynamically allocated regions also have a size of 0x0 at this point, so
fix this by removing the check and sorting the dynamically allocated
regions ahead of any static regions at address 0x0.

For example, there are two overlaps in this case but they are not
currently reported:

	foo@0 {
	        reg = <0x0 0x2000>;
	};

	bar@0 {
	        reg = <0x0 0x1000>;
	};

	baz@1000 {
	        reg = <0x1000 0x1000>;
	};

	quux {
	        size = <0x1000>;
	};

but they are after this patch:

 OF: reserved mem: OVERLAP DETECTED!
 bar@0 (0x00000000--0x00001000) overlaps with foo@0 (0x00000000--0x00002000)
 OF: reserved mem: OVERLAP DETECTED!
 foo@0 (0x00000000--0x00002000) overlaps with baz@1000 (0x00001000--0x00002000)

Signed-off-by: Vincent Whitchurch 
Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com
Signed-off-by: Rob Herring

treewide: Convert macro and uses of section(foo) to section("foo")

2020-10-25T21:51:49+00:00

Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.

Remove the quote operator # from compiler_attributes.h __section macro.

Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.

Conversion done using the script at:

    https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl

Signed-off-by: Joe Perches 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Miguel Ojeda 
Signed-off-by: Linus Torvalds