#
54c180e7 |
|
11-Mar-2024 |
Rob Herring <robh@kernel.org> |
of: Move all FDT reserved-memory handling into of_reserved_mem.c The split of /reserved-memory handling between fdt.c and of_reserved_mem.c makes for reading and restructuring the code difficult. As of_reserved_mem.c is only built for CONFIG_OF_EARLY_FLATTREE already, move all the code to one spot. Acked-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com> Link: https://lore.kernel.org/r/20240311181303.1516514-2-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
4cea2821 |
|
14-Jun-2023 |
Stephan Gerhold <stephan@gerhold.net> |
of: reserved_mem: Use stable allocation order sort() in Linux is based on heapsort which is not a stable sort algorithm - equal elements are being reordered. For reserved memory in the device tree this happens mainly for dynamic allocations: They do not have an address to sort with, so they are reordered somewhat randomly when adding/removing other unrelated reserved memory nodes. Functionally this is not a big problem, but it's confusing during development when all the addresses change after adding unrelated reserved memory nodes. Make the order stable by sorting dynamic allocations according to the node order in the device tree. Static allocations are not affected by this because they are still sorted by their (fixed) address. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230510-dt-resv-bottom-up-v2-2-aeb2afc8ac25@gerhold.net Signed-off-by: Rob Herring <robh@kernel.org>
|
#
83ba7361 |
|
14-Jun-2023 |
Stephan Gerhold <stephan@gerhold.net> |
of: reserved_mem: Try to keep range allocations contiguous Right now dynamic reserved memory regions are allocated either bottom-up or top-down, depending on the memblock setting of the architecture. This is fine when the address is arbitrary. However, when using "alloc-ranges" the regions are often placed somewhere in the middle of (free) RAM, even if the range starts or ends next to another (static) reservation. Try to detect this situation, and choose explicitly between bottom-up or top-down to allocate the memory close to the other reservations: 1. If the "alloc-range" starts at the end or inside an existing reservation, use bottom-up. 2. If the "alloc-range" ends at the start or inside an existing reservation, use top-down. 3. If both or none is the case, keep the current (architecture-specific) behavior. There are plenty of edge cases where only a more complex algorithm would help, but even this simple approach helps in many cases to keep the reserved memory (and therefore also the free memory) contiguous. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230510-dt-resv-bottom-up-v2-1-aeb2afc8ac25@gerhold.net Signed-off-by: Rob Herring <robh@kernel.org>
|
#
6ee7afba |
|
16-Feb-2023 |
Geert Uytterhoeven <geert+renesas@glider.be> |
of: reserved_mem: Use proper binary prefix The printed reserved memory information uses the non-standard "K" prefix, while all other printed values use proper binary prefixes. Fix this by using "Ki" instead. While at it, drop the superfluous spaces inside the parentheses, to reduce printed line length. Fixes: aeb9267eb6b1df99 ("of: reserved-mem: print out reserved-mem details during boot") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230216083725.1244817-1-geert+renesas@glider.be Signed-off-by: Rob Herring <robh@kernel.org>
|
#
aeb9267e |
|
09-Feb-2023 |
Martin Liu <liumartin@google.com> |
of: reserved-mem: print out reserved-mem details during boot It's important to know reserved-mem information in mobile world since reserved memory via device tree keeps increased in platform (e.g., 45% in our platform). Therefore, it's crucial to know the reserved memory sizes breakdown for the memory accounting. This patch prints out reserved memory details during boot to make them visible. Below is an example output: [ 0.000000] OF: reserved mem: 0x00000009f9400000..0x00000009fb3fffff ( 32768 KB ) map reusable test1 [ 0.000000] OF: reserved mem: 0x00000000ffdf0000..0x00000000ffffffff ( 2112 KB ) map non-reusable test2 [ 0.000000] OF: reserved mem: 0x0000000091000000..0x00000000912fffff ( 3072 KB ) nomap non-reusable test3 Signed-off-by: Martin Liu <liumartin@google.com> Link: https://lore.kernel.org/r/20230209160954.1471909-1-liumartin@google.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
ce4d9a1e |
|
08-Feb-2023 |
Isaac J. Manjarres <isaacmanjarres@google.com> |
of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem Patch series "Fix kmemleak crashes when scanning CMA regions", v2. When trying to boot a device with an ARM64 kernel with the following config options enabled: CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y CONFIG_DEBUG_KMEMLEAK=y a crash is encountered when kmemleak starts to scan the list of gray or allocated objects that it maintains. Upon closer inspection, it was observed that these page-faults always occurred when kmemleak attempted to scan a CMA region. At the moment, kmemleak is made aware of CMA regions that are specified through the devicetree to be dynamically allocated within a range of addresses. However, kmemleak should not need to scan CMA regions or any reserved memory region, as those regions can be used for DMA transfers between drivers and peripherals, and thus wouldn't contain anything useful for kmemleak. Additionally, since CMA regions are unmapped from the kernel's address space when they are freed to the buddy allocator at boot when CONFIG_DEBUG_PAGEALLOC is enabled, kmemleak shouldn't attempt to access those memory regions, as that will trigger a crash. Thus, kmemleak should ignore all dynamically allocated reserved memory regions. This patch (of 1): Currently, kmemleak ignores dynamically allocated reserved memory regions that don't have a kernel mapping. However, regions that do retain a kernel mapping (e.g. CMA regions) do get scanned by kmemleak. This is not ideal for two reasons: 1 kmemleak works by scanning memory regions for pointers to allocated objects to determine if those objects have been leaked or not. However, reserved memory regions can be used between drivers and peripherals for DMA transfers, and thus, would not contain pointers to allocated objects, making it unnecessary for kmemleak to scan these reserved memory regions. 2 When CONFIG_DEBUG_PAGEALLOC is enabled, along with kmemleak, the CMA reserved memory regions are unmapped from the kernel's address space when they are freed to buddy at boot. These CMA reserved regions are still tracked by kmemleak, however, and when kmemleak attempts to scan them, a crash will happen, as accessing the CMA region will result in a page-fault, since the regions are unmapped. Thus, use kmemleak_ignore_phys() for all dynamically allocated reserved memory regions, instead of those that do not have a kernel mapping associated with them. Link: https://lkml.kernel.org/r/20230208232001.2052777-1-isaacmanjarres@google.com Link: https://lkml.kernel.org/r/20230208232001.2052777-2-isaacmanjarres@google.com Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private") Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Kirill A. Shutemov <kirill.shtuemov@linux.intel.com> Cc: Nick Kossifidis <mick@ics.forth.gr> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Rob Herring <robh@kernel.org> Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Cc: Saravana Kannan <saravanak@google.com> Cc: <stable@vger.kernel.org> [5.15+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
#
6991cd74 |
|
28-Jun-2022 |
Vincent Whitchurch <vincent.whitchurch@axis.com> |
of: reserved-memory: Print allocation/reservation failures as error If the allocation/reservation of reserved-memory fails, it is normally an error, so print it as an error so that it doesn't get hidden from the console due to the loglevel. Also make the allocation failure include the size just like the reservation failure. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220628113540.2790835-1-vincent.whitchurch@axis.com
|
#
e16faf26 |
|
22-Mar-2022 |
David Hildenbrand <david@redhat.com> |
cma: factor out minimum alignment requirement Patch series "mm: enforce pageblock_order < MAX_ORDER". Having pageblock_order >= MAX_ORDER seems to be able to happen in corner cases and some parts of the kernel are not prepared for it. For example, Aneesh has shown [1] that such kernels can be compiled on ppc64 with 64k base pages by setting FORCE_MAX_ZONEORDER=8, which will run into a WARN_ON_ONCE(order >= MAX_ORDER) in comapction code right during boot. We can get pageblock_order >= MAX_ORDER when the default hugetlb size is bigger than the maximum allocation granularity of the buddy, in which case we are no longer talking about huge pages but instead gigantic pages. Having pageblock_order >= MAX_ORDER can only make alloc_contig_range() of such gigantic pages more likely to succeed. Reliable use of gigantic pages either requires boot time allcoation or CMA, no need to overcomplicate some places in the kernel to optimize for corner cases that are broken in other areas of the kernel. This patch (of 2): Let's enforce pageblock_order < MAX_ORDER and simplify. Especially patch #1 can be regarded a cleanup before: [PATCH v5 0/6] Use pageblock_order for cma and alloc_contig_range alignment. [2] [1] https://lkml.kernel.org/r/87r189a2ks.fsf@linux.ibm.com [2] https://lkml.kernel.org/r/20220211164135.1803616-1-zi.yan@sent.com Link: https://lkml.kernel.org/r/20220214174132.219303-2-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: Rob Herring <robh@kernel.org> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: John Garry via iommu <iommu@lists.linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
3ecc6834 |
|
05-Nov-2021 |
Mike Rapoport <rppt@kernel.org> |
memblock: rename memblock_free to memblock_phys_free 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 <rppt@linux.ibm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Juergen Gross <jgross@suse.com> Cc: Shahab Vahedi <Shahab.Vahedi@synopsys.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
658aafc8 |
|
21-Oct-2021 |
Mike Rapoport <rppt@kernel.org> |
memblock: exclude MEMBLOCK_NOMAP regions from kmemleak 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 <vladimir.zapolskiy@linaro.org> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Tested-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a7259df7 |
|
02-Sep-2021 |
Mike Rapoport <rppt@kernel.org> |
memblock: make memblock_find_in_range method private 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 <rppt@linux.ibm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> [arm64] Acked-by: Kirill A. Shutemov <kirill.shtuemov@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ACPI] Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Nick Kossifidis <mick@ics.forth.gr> [riscv] Tested-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7b25995f |
|
11-Jun-2021 |
Dong Aisheng <aisheng.dong@nxp.com> |
of: of_reserved_mem: mark nomap memory instead of removing 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 <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Reviewed-by: Quentin Perret <qperret@google.com> Link: https://lore.kernel.org/r/20210611131153.3731147-2-aisheng.dong@nxp.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
3c6867a1 |
|
11-Jun-2021 |
Dong Aisheng <aisheng.dong@nxp.com> |
of: of_reserved_mem: only call memblock_free for normal reserved memory 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 <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Link: https://lore.kernel.org/r/20210611131153.3731147-1-aisheng.dong@nxp.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
2892d8a0 |
|
16-Jun-2021 |
Geert Uytterhoeven <geert+renesas@glider.be> |
of: Fix truncation of memory sizes on 32-bit platforms 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 <geert+renesas@glider.be> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be Signed-off-by: Rob Herring <robh@kernel.org>
|
#
12d55d3b |
|
27-May-2021 |
Rob Herring <robh@kernel.org> |
of: Move reserved memory private function declarations 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 <frowand.list@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210527193841.1284169-1-robh@kernel.org
|
#
ad1ce1ab |
|
18-Mar-2021 |
Lee Jones <lee.jones@linaro.org> |
of: of_reserved_mem: Demote kernel-doc abuses 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 <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Josh Cartwright <joshc@codeaurora.org> Cc: devicetree@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210318104036.3175910-11-lee.jones@linaro.org
|
#
ca05f333 |
|
21-Oct-2020 |
Vincent Whitchurch <vincent.whitchurch@axis.com> |
of: Fix reserved-memory overlap detection 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 <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
33def849 |
|
21-Oct-2020 |
Joe Perches <joe@perches.com> |
treewide: Convert macro and uses of __section(foo) to __section("foo") 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 <joe@perches.com> Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
6f1188b4 |
|
30-Jul-2020 |
Yue Hu <huyue2@yulong.com> |
of: reserved-memory: remove duplicated call to of_get_flat_dt_prop() for no-map node Just use nomap instead of the second call to of_get_flat_dt_prop(). And change nomap as a bool type due to != NULL operator. Also, correct comment about node of 'align' -> 'alignment'. Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lore.kernel.org/r/20200730092353.15644-1-zbestahu@gmail.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
418370ff |
|
03-Jun-2020 |
Danny Lin <danny@kdrag0n.dev> |
of: reserved_mem: Fix typo in the too-many-regions message Minor fix for a missing preposition in the error message that appears when there are too many reserved memory regions for the allocated array to store. Signed-off-by: Danny Lin <danny@kdrag0n.dev> Link: https://lore.kernel.org/r/20200604054900.200317-1-danny@kdrag0n.dev Signed-off-by: Rob Herring <robh@kernel.org>
|
#
c8813f7e |
|
11-May-2020 |
chenqiwu <chenqiwu@xiaomi.com> |
drivers/of: keep description of function consistent with function name Currently, there are some descriptions of function not consistent with function name, fixing them will make the code more readable. Signed-off-by: chenqiwu <chenqiwu@xiaomi.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
081df76a |
|
03-Apr-2020 |
Thierry Reding <treding@nvidia.com> |
of: reserved-memory: Support multiple regions per device While the lookup/initialization code already supports multiple memory regions per device, the release code will only ever release the first matching memory region. Enhance the code to release all matching regions. Each attachment of a region to a device is uniquely identifiable using a struct device pointer and a pointer to the memory region's struct reserved_mem. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
|
#
0da0e316 |
|
03-Apr-2020 |
Thierry Reding <treding@nvidia.com> |
of: reserved-memory: Support lookup of regions by name Add support for looking up memory regions by name. This looks up the given name in the newly introduced memory-region-names property and returns the memory region at the corresponding index in the memory- region(s) property. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
|
#
632c9908 |
|
24-Feb-2020 |
Patrick Daly <pdaly@codeaurora.org> |
of: of_reserved_mem: Increase limit on number of reserved regions Certain SoCs need to support a large amount of reserved memory regions. For example, Qualcomm's SM8150 SoC requires that 20 regions of memory be reserved for a variety of reasons (e.g. loading a peripheral subsystem's firmware image into a particular space). When adding more reserved memory regions to cater to different usecases, the remaining number of reserved memory regions--12 to be exact--becomes too small. Thus, double the existing limit of reserved memory regions. Signed-off-by: Patrick Daly <pdaly@codeaurora.org> Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
5dba5175 |
|
19-Oct-2019 |
Chris Goldsworthy <cgoldswo@codeaurora.org> |
of: reserved_mem: add missing of_node_put() for proper ref-counting Commit d698a388146c ("of: reserved-memory: ignore disabled memory-region nodes") added an early return in of_reserved_mem_device_init_by_idx(), but didn't call of_node_put() on a device_node whose ref-count was incremented in the call to of_parse_phandle() preceding the early exit. Fixes: d698a388146c ("of: reserved-memory: ignore disabled memory-region nodes") Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: stable@vger.kernel.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
d698a388 |
|
22-May-2019 |
Krishna Reddy <vdumpa@nvidia.com> |
of: reserved-memory: ignore disabled memory-region nodes Ignore disabled nodes in the memory-region nodes list and continue to initialize the rest of enabled nodes. Check if the "reserved-memory" node is available and if it's not available, return 0 to ignore the "reserved-memory" node and continue parsing with next node in memory-region nodes list. Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Signed-off-by: Puneet Saxena <puneets@nvidia.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
d0b8ed47 |
|
19-Feb-2019 |
pierre Kuo <vichy.kuo@gmail.com> |
of: reserved_mem: fix reserve memory leak The __reserved_mem_init_node will call region specific reserved memory init codes, but once all compatibled init codes failed, the memory region will left in memory.reserved and cause leakage. Take cma reserve memory DTS for example, if user declare 1MB size, which is not align to (PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)), rmem_cma_setup will return -EINVAL. Meanwhile, rmem_dma_setup will also return -EINVAL since "reusable" property is not set. If finally there is no reserved memory init pick up this memory, kernel will left the 1MB leak in memory.reserved. This patch will remove this kind of memory from memory.reserved, only when __reserved_mem_init_node return neither 0 nor -ENOENT. Signed-off-by: pierre Kuo <vichy.kuo@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
5c01a25a |
|
12-Mar-2019 |
Mike Rapoport <rppt@kernel.org> |
of: fix kmemleak crash caused by imbalance in early memory reservation Marc Gonzalez reported the following kmemleak crash: Unable to handle kernel paging request at virtual address ffffffc021e00000 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____) [ffffffc021e00000] pgd=000000017e3ba803, pud=000000017e3ba803, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 6 PID: 523 Comm: kmemleak Tainted: G S W 5.0.0-rc1 #13 Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT) pstate: 80000085 (Nzcv daIf -PAN -UAO) pc : scan_block+0x70/0x190 lr : scan_block+0x6c/0x190 Process kmemleak (pid: 523, stack limit = 0x(____ptrval____)) Call trace: scan_block+0x70/0x190 scan_gray_list+0x108/0x1c0 kmemleak_scan+0x33c/0x7c0 kmemleak_scan_thread+0x98/0xf0 kthread+0x11c/0x120 ret_from_fork+0x10/0x1c Code: f9000fb4 d503201f 97ffffd2 35000580 (f9400260) The crash happens when a no-map area is allocated in early_init_dt_alloc_reserved_memory_arch(). The allocated region is registered with kmemleak, but it is then removed from memblock using memblock_remove() that is not kmemleak-aware. Replacing memblock_phys_alloc_range() with memblock_find_in_range() makes sure that the allocated memory is not added to kmemleak and then memblock_remove()'ing this memory is safe. As a bonus, since memblock_find_in_range() ensures the allocation in the specified range, the bounds check can be removed. [rppt@linux.ibm.com: of: fix parameters order for call to memblock_find_in_range()] Link: http://lkml.kernel.org/r/20190221112619.GC32004@rapoport-lnx Link: http://lkml.kernel.org/r/20190213181921.GB15270@rapoport-lnx Fixes: 3f0c820664483 ("drivers: of: add initialization code for dynamic reserved memory") Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Prateek Patel <prpatel@nvidia.com> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
42b46aef |
|
12-Mar-2019 |
Mike Rapoport <rppt@kernel.org> |
memblock: drop __memblock_alloc_base() The __memblock_alloc_base() function tries to allocate a memory up to the limit specified by its max_addr parameter. Depending on the value of this parameter, the __memblock_alloc_base() can is replaced with the appropriate memblock_phys_alloc*() variant. Link: http://lkml.kernel.org/r/1548057848-15136-9-git-send-email-rppt@linux.ibm.com Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Christoph Hellwig <hch@lst.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Dennis Zhou <dennis@kernel.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greentime Hu <green.hu@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Guo Ren <guoren@kernel.org> Cc: Guo Ren <ren_guo@c-sky.com> [c-sky] Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Juergen Gross <jgross@suse.com> [Xen] Cc: Mark Salter <msalter@redhat.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Burton <paul.burton@mips.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Richard Weinberger <richard@nod.at> Cc: Rich Felker <dalias@libc.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Stafford Horne <shorne@gmail.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
221e1e0b |
|
11-Feb-2019 |
Christoph Hellwig <hch@lst.de> |
of: mark early_init_dt_alloc_reserved_memory_arch static This function is only used in of_reserved_mem.c, and never overridden despite the __weak marker. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
42e45a94 |
|
14-Jan-2019 |
Robin Murphy <robin.murphy@arm.com> |
media: s5p-mfc: Fix memdev DMA configuration Having of_reserved_mem_device_init() forcibly reconfigure DMA for all callers, potentially overriding the work done by a bus-specific .dma_configure method earlier, is at best a bad idea and at worst actively harmful. If drivers really need virtual devices to own dma-coherent memory, they should explicitly configure those devices based on the appropriate firmware node as they create them. It looks like the only driver not passing in a proper OF platform device is s5p-mfc, so move the rogue of_dma_configure() call into that driver where it logically belongs. Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
7e1c4e27 |
|
30-Oct-2018 |
Mike Rapoport <rppt@linux.vnet.ibm.com> |
memblock: stop using implicit alignment to SMP_CACHE_BYTES When a memblock allocation APIs are called with align = 0, the alignment is implicitly set to SMP_CACHE_BYTES. Implicit alignment is done deep in the memblock allocator and it can come as a surprise. Not that such an alignment would be wrong even when used incorrectly but it is better to be explicit for the sake of clarity and the prinicple of the least surprise. Replace all such uses of memblock APIs with the 'align' parameter explicitly set to SMP_CACHE_BYTES and stop implicit alignment assignment in the memblock internal allocation functions. For the case when memblock APIs are used via helper functions, e.g. like iommu_arena_new_node() in Alpha, the helper functions were detected with Coccinelle's help and then manually examined and updated where appropriate. The direct memblock APIs users were updated using the semantic patch below: @@ expression size, min_addr, max_addr, nid; @@ ( | - memblock_alloc_try_nid_raw(size, 0, min_addr, max_addr, nid) + memblock_alloc_try_nid_raw(size, SMP_CACHE_BYTES, min_addr, max_addr, nid) | - memblock_alloc_try_nid_nopanic(size, 0, min_addr, max_addr, nid) + memblock_alloc_try_nid_nopanic(size, SMP_CACHE_BYTES, min_addr, max_addr, nid) | - memblock_alloc_try_nid(size, 0, min_addr, max_addr, nid) + memblock_alloc_try_nid(size, SMP_CACHE_BYTES, min_addr, max_addr, nid) | - memblock_alloc(size, 0) + memblock_alloc(size, SMP_CACHE_BYTES) | - memblock_alloc_raw(size, 0) + memblock_alloc_raw(size, SMP_CACHE_BYTES) | - memblock_alloc_from(size, 0, min_addr) + memblock_alloc_from(size, SMP_CACHE_BYTES, min_addr) | - memblock_alloc_nopanic(size, 0) + memblock_alloc_nopanic(size, SMP_CACHE_BYTES) | - memblock_alloc_low(size, 0) + memblock_alloc_low(size, SMP_CACHE_BYTES) | - memblock_alloc_low_nopanic(size, 0) + memblock_alloc_low_nopanic(size, SMP_CACHE_BYTES) | - memblock_alloc_from_nopanic(size, 0, min_addr) + memblock_alloc_from_nopanic(size, SMP_CACHE_BYTES, min_addr) | - memblock_alloc_node(size, 0, nid) + memblock_alloc_node(size, SMP_CACHE_BYTES, nid) ) [mhocko@suse.com: changelog update] [akpm@linux-foundation.org: coding-style fixes] [rppt@linux.ibm.com: fix missed uses of implicit alignment] Link: http://lkml.kernel.org/r/20181016133656.GA10925@rapoport-lnx Link: http://lkml.kernel.org/r/1538687224-17535-1-git-send-email-rppt@linux.vnet.ibm.com Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Suggested-by: Michal Hocko <mhocko@suse.com> Acked-by: Paul Burton <paul.burton@mips.com> [MIPS] Acked-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc] Acked-by: Michal Hocko <mhocko@suse.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Chris Zankel <chris@zankel.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Ingo Molnar <mingo@redhat.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Richard Weinberger <richard@nod.at> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
aca52c39 |
|
30-Oct-2018 |
Mike Rapoport <rppt@linux.vnet.ibm.com> |
mm: remove CONFIG_HAVE_MEMBLOCK All architecures use memblock for early memory management. There is no need for the CONFIG_HAVE_MEMBLOCK configuration option. [rppt@linux.vnet.ibm.com: of/fdt: fixup #ifdefs] Link: http://lkml.kernel.org/r/20180919103457.GA20545@rapoport-lnx [rppt@linux.vnet.ibm.com: csky: fixups after bootmem removal] Link: http://lkml.kernel.org/r/20180926112744.GC4628@rapoport-lnx [rppt@linux.vnet.ibm.com: remove stale #else and the code it protects] Link: http://lkml.kernel.org/r/1538067825-24835-1-git-send-email-rppt@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/1536927045-23536-4-git-send-email-rppt@linux.vnet.ibm.com Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Acked-by: Michal Hocko <mhocko@suse.com> Tested-by: Jonathan Cameron <jonathan.cameron@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Chris Zankel <chris@zankel.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greentime Hu <green.hu@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Ingo Molnar <mingo@redhat.com> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Jonas Bonn <jonas@southpole.se> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Ley Foon Tan <lftan@altera.com> Cc: Mark Salter <msalter@redhat.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Matt Turner <mattst88@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Simek <monstr@monstr.eu> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Paul Burton <paul.burton@mips.com> Cc: Richard Kuo <rkuo@codeaurora.org> Cc: Richard Weinberger <richard@nod.at> Cc: Rich Felker <dalias@libc.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Serge Semin <fancer.lancer@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
3d6ce86e |
|
03-May-2018 |
Christoph Hellwig <hch@lst.de> |
drivers: remove force dma flag from buses With each bus implementing its own DMA configuration callback, there is no need for bus to explicitly set the force_dma flag. Modify the of_dma_configure function to accept an input parameter which specifies if implicit DMA configuration is required when it is not described by the firmware. Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # PCI parts Reviewed-by: Rob Herring <robh@kernel.org> [hch: tweaked the changelog a bit] Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
af6074fc |
|
26-Dec-2017 |
Rob Herring <robh@kernel.org> |
of: Use SPDX license tag for DT files Convert remaining DT files to use SPDX-License-Identifier tags. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
eb297bc7 |
|
10-Oct-2017 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
of: reserved_mem: Accessor for acquiring reserved_mem In some cases drivers referencing a reserved-memory region might want to remap the entire region, but when defining the reserved-memory by "size" the client driver has no means to know the associated base address of the reserved memory region. This patch adds an accessor for such drivers to acquire a handle to their associated reserved-memory for this purpose. A complicating factor for the implementation is that the reserved_mem objects are created from the flattened DeviceTree, as such we can't use the device_node address for comparison. Fortunately the name of the node will be used as "name" of the reserved_mem and will be used when building the full_name, so we can compare the "name" with the basename of the full_name to find the match. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
|
#
22f8cc6e |
|
26-Sep-2017 |
Stewart Smith <stewart@linux.vnet.ibm.com> |
drivers: of: increase MAX_RESERVED_REGIONS to 32 There are two types of memory reservations firmware can ask the kernel to make in the device tree: static and dynamic. See Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt If you have greater than 16 entries in /reserved-memory (as we do on POWER9 systems) you would get this scary looking error message: [ 0.000000] OF: reserved mem: not enough space all defined regions. This is harmless if all your reservations are static (which with OPAL on POWER9, they are). It is not harmless if you have any dynamic reservations after the 16th. In the first pass over the fdt to find reservations, the child nodes of /reserved-memory are added to a static array in of_reserved_mem.c so that memory can be reserved in a 2nd pass. The array has 16 entries. This is why, on my dual socket POWER9 system, I get that error 4 times with 20 static reservations. We don't have a problem on ppc though, as in arch/powerpc/kernel/prom.c we look at the new style /reserved-ranges property to do reservations, and this logic was introduced in 0962e8004e974 (well before any powernv system shipped). A Google search shows up no occurances of that exact error message, so we're probably safe in that no machine that people use has memory not being reserved when it should be. The simple fix is to bump the length of the array to 32 which "should be enough for everyone(TM)". The simple fix of not recording static allocations in the array would cause problems for devices with "memory-region" properties. A more future-proof fix is likely possible, although more invasive and this simple fix is perfectly suitable in the meantime while a more future-proof fix is developed. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> Tested-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
df3ed932 |
|
11-May-2017 |
Rob Herring <robh@kernel.org> |
Partially Revert "of: fix sparse warnings in fdt, irq, reserved mem, and resolver code" A change to function pointers that was meant to address a sparse warning turned out to cause hundreds of new gcc-7 warnings: include/linux/of_irq.h:11:13: error: type qualifiers ignored on function return type [-Werror=ignored-qualifiers] drivers/of/of_reserved_mem.c: In function '__reserved_mem_init_node': drivers/of/of_reserved_mem.c:200:7: error: type qualifiers ignored on function return type [-Werror=ignored-qualifiers] int const (*initfn)(struct reserved_mem *rmem) = i->data; Turns out the sparse warnings were spurious and have been fixed in upstream sparse since 0.5.0 in commit "sparse: treat function pointers as pointers to const data". This partially reverts commit 17a70355ea576843a7ac851f1db26872a50b2850. Fixes: 17a70355ea57 ("of: fix sparse warnings in fdt, irq, reserved mem, and resolver code") Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
17a70355 |
|
03-May-2017 |
Rob Herring <robh@kernel.org> |
of: fix sparse warnings in fdt, irq, reserved mem, and resolver code sparse generates the following warnings in drivers/of/: ../drivers/of/fdt.c:63:36: warning: cast to restricted __be32 ../drivers/of/fdt.c:68:33: warning: cast to restricted __be32 ../drivers/of/irq.c:105:88: warning: incorrect type in initializer (different base types) ../drivers/of/irq.c:105:88: expected restricted __be32 ../drivers/of/irq.c:105:88: got int ../drivers/of/irq.c:526:35: warning: incorrect type in assignment (different modifiers) ../drivers/of/irq.c:526:35: expected int ( *const [usertype] irq_init_cb )( ... ) ../drivers/of/irq.c:526:35: got void const *const data ../drivers/of/of_reserved_mem.c:200:50: warning: incorrect type in initializer (different modifiers) ../drivers/of/of_reserved_mem.c:200:50: expected int ( *[usertype] initfn )( ... ) ../drivers/of/of_reserved_mem.c:200:50: got void const *const data ../drivers/of/resolver.c:95:42: warning: incorrect type in assignment (different base types) ../drivers/of/resolver.c:95:42: expected unsigned int [unsigned] [usertype] <noident> ../drivers/of/resolver.c:95:42: got restricted __be32 [usertype] <noident> All these are harmless type mismatches fixed by adjusting the types. Signed-off-by: Rob Herring <robh@kernel.org>
|
#
a3b398e6 |
|
20-Dec-2016 |
Smitha T Murthy <smitha.t@samsung.com> |
of: reserved_mem: set dma_ops for devices using reserved mem For some IPs, there may be virtual child devices created and for them its necessary to set the dma_ops if it's using reserved memory else it will call the dummy dma_ops during buffer operations for the child devices which will lead to memory mapping failure. Signed-off-by: Smitha T Murthy <smitha.t@samsung.com> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
606ad42a |
|
15-Jun-2016 |
Rob Herring <robh@kernel.org> |
of: use pr_fmt prefix for all console printing Clean-up all the DT printk functions to use common pr_fmt prefix. Some print statements such as kmalloc errors were redundant, so just drop those. Cc: Frank Rowand <frowand.list@gmail.com> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Reviewed-by: Frank Rowand <frank.rowand@am.sony.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
9f5a802b |
|
08-Jun-2016 |
Marek Szyprowski <m.szyprowski@samsung.com> |
[media] of: reserved_mem: restore old behavior when no region is defined Change return value back to -ENODEV when no region is defined for given device. This restores old behavior of this function, as some drivers rely on such error code. Fixes: 59ce4039727ef40 ("of: reserved_mem: add support for using more than one region for given device") Reported-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Sumit Semwal <sumit.semwal@linaro.org>
|
#
aaaab56d |
|
30-May-2016 |
Stephen Rothwell <sfr@canb.auug.org.au> |
of: silence warnings due to max() usage pageblock_order can be (at least) an unsigned int or an unsigned long depending on the kernel config and architecture, so use max_t(unsigned long ...) when comparing it. fixes these warnings: In file included from include/linux/list.h:8:0, from include/linux/kobject.h:20, from include/linux/of.h:21, from drivers/of/of_reserved_mem.c:17: drivers/of/of_reserved_mem.c: In function ‘__reserved_mem_alloc_size’: include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); \ ^ include/linux/kernel.h:747:9: note: in definition of macro ‘max’ typeof(y) _max2 = (y); \ ^ drivers/of/of_reserved_mem.c:131:48: note: in expansion of macro ‘max’ align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_ord ^ include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast (void) (&_max1 == &_max2); \ ^ include/linux/kernel.h:747:21: note: in definition of macro ‘max’ typeof(y) _max2 = (y); \ ^ drivers/of/of_reserved_mem.c:131:48: note: in expansion of macro ‘max’ align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_ord ^ Fixes: 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with CMA setup") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
7d482813 |
|
24-May-2016 |
Jaewon <jaewon31.kim@samsung.com> |
drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent There was an alignment mismatch issue for CMA and it was fixed by commit 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with CMA setup"). However the way of the commit considers not only dma-contiguous(CMA) but also dma-coherent which has no that requirement. This patch checks more to distinguish dma-contiguous(CMA) from dma-coherent. Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com> Acked-by: Jason Liu <r64343@freescale.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> [robh: remove erroneous opening bracket] Signed-off-by: Rob Herring <robh@kernel.org>
|
#
59ce4039 |
|
24-May-2016 |
Marek Szyprowski <m.szyprowski@samsung.com> |
of: reserved_mem: add support for using more than one region for given device This patch allows device drivers to initialize more than one reserved memory region assigned to given device. When driver needs to use more than one reserved memory region, it should allocate child devices and initialize regions by index for each of its child devices. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
#
e53b50c0 |
|
22-Feb-2016 |
Vinayak Menon <vinmenon@codeaurora.org> |
of: alloc anywhere from memblock if range not specified early_init_dt_alloc_reserved_memory_arch passes end as 0 to __memblock_alloc_base, when limits are not specified. But __memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE and limits the end to memblock.current_limit. This results in regions never being placed in HIGHMEM area, for e.g. CMA. Let __memblock_alloc_base allocate from anywhere in memory if limits are not specified. Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org> Cc: stable@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
9eb8cd2b |
|
18-Nov-2015 |
Michael Ellerman <mpe@ellerman.id.au> |
of: Fix comparison of reserved memory regions In order to check for overlapping reserved memory regions, we first need to sort the array of memory regions. This is implemented using sort(), and a custom comparison function __rmem_cmp(). Unfortunatley __rmem_cmp() doesn't work in all cases. Because the two base values are phys_addr_t, they may be u64 on some platforms, in which case subtracting one from the other and then (implicitly) casting to int does not give us the -ve/0/+ve value we need. This leads to incorrect reports about overlaps, eg: ibm,slw-image@1ffe600000 (0x0000001ffe600000--0x0000001ffe700000) overlaps with ibm,firmware-allocs-memory@1000000000 (0x0000001000000000--0x0000001000dc0200) Fix it by just doing the standard double if and return 0 logic. Fixes: ae1add247bf8 ("of: Check for overlap in reserved memory regions") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
1cc8e345 |
|
10-Nov-2015 |
Jason Liu <r64343@freescale.com> |
drivers: of: of_reserved_mem: fixup the alignment with CMA setup There is an alignment mismatch issue between the of_reserved_mem and the CMA setup requirement. The of_reserved_mem will try to get the alignment value from the DTS and pass it to __memblock_alloc_base to do the memory block base allocation, but the alignment value specified in the DTS may not satisfy the CAM setup requirement since CMA setup required the alignment as the following in the code: align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); The sanity check in the function of rmem_cma_setup will fail if the alignment does not setup correctly and thus CMA will fail to setup. This patch is to fixup the alignment to meet the CMA setup required. Mailing-list-thread: https://lkml.org/lkml/2015/11/9/138 Signed-off-by: Jason Liu <r64343@freescale.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
85a1c77f |
|
09-Nov-2015 |
Michael Ellerman <mpe@ellerman.id.au> |
of: Print rather than WARN'ing when overlap check fails __rmem_check_for_overlap() is called very early in boot, and on some powerpc systems it's not safe to call WARN that early in boot. If the overlap check fails the system will oops instead of printing a warning. Furthermore because it's so early in boot the console is not up and the user doesn't see the oops, they just get a dead system. Fix it by printing an error instead of calling WARN. Fixes: ae1add247bf8 ("of: Check for overlap in reserved memory regions") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
ae1add24 |
|
15-Sep-2015 |
Mitchel Humpherys <mitchelh@codeaurora.org> |
of: Check for overlap in reserved memory regions Any overlap in the reserved memory regions (those specified in the reserved-memory DT node) is a bug. These bugs might go undetected as long as the contested region isn't used simultaneously by multiple software agents, which makes such bugs hard to debug. Fix this by printing a scary warning during boot if overlap is detected. Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
615fde79 |
|
09-Jan-2015 |
George G. Davis <ggdavisiv@gmail.com> |
drivers: of: Export of_reserved_mem_device_{init,release} Export of_reserved_mem_device_{init,release} so that modules can initialize and release their assigned per-device cma_area. Signed-off-by: George G. Davis <george_davis@mentor.com> [robh: s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/] Signed-off-by: Rob Herring <robh@kernel.org>
|
#
47f29df7 |
|
29-Oct-2014 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drivers: of: add return value to of_reserved_mem_device_init() Driver calling of_reserved_mem_device_init() might be interested if the initialization has been successful or not, so add support for returning error code. This fixes a build warining caused by commit 7bfa5ab6fa1b ("drivers: dma-coherent: add initialization from device tree"), which has been merged without this change and without fixing function return value. Fixes: 7bfa5ab6fa1b1 ("drivers: dma-coherent: add initialization from device tree") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Laura Abbott <lauraa@codeaurora.org> Cc: Josh Cartwright <joshc@codeaurora.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9dcfee01 |
|
14-Jul-2014 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drivers: of: add automated assignment of reserved regions to client devices This patch adds code for automated assignment of reserved memory regions to struct device. reserved_mem->ops->device_init()/device_cleanup() callbacks are called to perform reserved memory driver specific initialization and cleanup Based on previous code provided by Josh Cartwright <joshc@codeaurora.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
|
#
9dd31075 |
|
08-May-2014 |
Rob Herring <robh@kernel.org> |
of: align RESERVEDMEM_OF_DECLARE function callbacks to other callbacks All the parameters for RESERVEDMEM_OF_DECLARE function callbacks are members of struct reserved_mem, so just pass the struct ptr to callback functions so the function callback is more in line with other OF match table callbacks. Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
9d0c4dfe |
|
01-Apr-2014 |
Rob Herring <robh@kernel.org> |
of/fdt: update of_get_flat_dt_prop in prep for libfdt Make of_get_flat_dt_prop arguments compatible with libfdt fdt_getprop call in preparation to convert FDT code to use libfdt. Make the return value const and the property length ptr type an int. Signed-off-by: Rob Herring <robh@kernel.org> Tested-by: Michal Simek <michal.simek@xilinx.com> Tested-by: Grant Likely <grant.likely@linaro.org> Tested-by: Stephen Chivers <schivers@csc.com>
|
#
f618c470 |
|
28-Feb-2014 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drivers: of: add support for custom reserved memory drivers Add support for custom reserved memory drivers. Call their init() function for each reserved region and prepare for using operations provided by them with by the reserved_mem->ops array. Based on previous code provided by Josh Cartwright <joshc@codeaurora.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
|
#
3f0c8206 |
|
28-Feb-2014 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drivers: of: add initialization code for dynamic reserved memory This patch adds support for dynamically allocated reserved memory regions declared in device tree. Such regions are defined by 'size', 'alignment' and 'alloc-ranges' properties. Based on previous code provided by Josh Cartwright <joshc@codeaurora.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
|
#
1931ee14 |
|
11-Oct-2013 |
Marek Szyprowski <m.szyprowski@samsung.com> |
Revert "drivers: of: add initialization code for dma reserved memory" This reverts commit 9d8eab7af79cb4ce2de5de39f82c455b1f796963. There is still no consensus on the bindings for the reserved memory and various drawbacks of the proposed solution has been shown, so the best now is to revert it completely and start again from scratch later. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
|
#
aca0156a |
|
10-Sep-2013 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drivers: of: fix build break if asm/dma-contiguous.h is missing It is not needed to include asm/dma-contiguous.h header to compile reserved memory initialization code, so remove it to avoid build break on architectures without CMA support. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Guenter Roeck <linux@roeck-us.net>
|
#
9d8eab7a |
|
26-Aug-2013 |
Marek Szyprowski <m.szyprowski@samsung.com> |
drivers: of: add initialization code for dma reserved memory This patch adds device tree support for contiguous and reserved memory regions defined in device tree. Large memory blocks can be reliably reserved only during early boot. This must happen before the whole memory management subsystem is initialized, because we need to ensure that the given contiguous blocks are not yet allocated by kernel. Also it must happen before kernel mappings for the whole low memory are created, to ensure that there will be no mappings (for reserved blocks) or mapping with special properties can be created (for CMA blocks). This all happens before device tree structures are unflattened, so we need to get reserved memory layout directly from fdt. Later, those reserved memory regions are assigned to devices on each device structure initialization. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Michal Nazarewicz <mina86@mina86.com> Acked-by: Tomasz Figa <t.figa@samsung.com> Acked-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Rob Herring <rob.herring@calxeda.com>
|