linux-toradex.git/drivers/of/of_reserved_mem.c, branch v6.11

of: reserved_mem: Remove the use of phandle from the reserved_mem APIs

2024-05-03T12:49:13+00:00

The __find_rmem() function is the only place that references the phandle
field of the reserved_mem struct. __find_rmem() is used to match a
device_node object to its corresponding entry in the reserved_mem array
using its phandle value. But, there is already a function called
of_reserved_mem_lookup() which carries out the same action using the
name of the node.

Using the of_reserved_mem_lookup() function is more reliable because
every node is guaranteed to have a name, but not all nodes will have a
phandle.

Nodes are only assigned a phandle if they are explicitly defined in the
DT using "phandle = ", or if they are referenced by
another node in the DT. Hence, If the phandle field is empty, then
__find_rmem() will return a false negative.

Hence, delete the __find_rmem() function and switch to using the
of_reserved_mem_lookup() function to find the corresponding entry of a
device_node in the reserved_mem array. Since the phandle field of the
reserved_mem struct is now unused, delete that as well.

Signed-off-by: Oreoluwa Babatunde 
Link: https://lore.kernel.org/r/20240502192403.3307277-1-quic_obabatun@quicinc.com
Signed-off-by: Rob Herring (Arm)

of: Move all FDT reserved-memory handling into of_reserved_mem.c

2024-03-12T15:23:26+00:00

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 
Reviewed-by: Oreoluwa Babatunde 
Link: https://lore.kernel.org/r/20240311181303.1516514-2-robh@kernel.org
Signed-off-by: Rob Herring

of: reserved_mem: Use stable allocation order

2023-06-20T15:34:58+00:00

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 
Link: https://lore.kernel.org/r/20230510-dt-resv-bottom-up-v2-2-aeb2afc8ac25@gerhold.net
Signed-off-by: Rob Herring

of: reserved_mem: Try to keep range allocations contiguous

2023-06-20T15:34:47+00:00

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 
Link: https://lore.kernel.org/r/20230510-dt-resv-bottom-up-v2-1-aeb2afc8ac25@gerhold.net
Signed-off-by: Rob Herring

Merge tag 'devicetree-for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2023-02-24T21:31:53+00:00

Pull devicetree updates from Rob Herring:
 "DT core:

   - Add node lifecycle unit tests

   - Add of_property_present() helper aligned with fwnode API

   - Print more information on reserved regions on boot

   - Update dtc to upstream v1.6.1-66-gabbd523bae6e

   - Use strscpy() to instead of strncpy() in DT core

   - Add option for schema validation on %.dtb targets

  Bindings:

   - Add/fix support for listing multiple patterns in DT_SCHEMA_FILES

   - Rework external memory controller/bus bindings to properly support
     controller specific child node properties

   - Convert loongson,ls1x-intc, fcs,fusb302, sil,sii8620, Rockchip
     RK3399 PCIe, Synquacer I2C, and Synquacer EXIU bindings to DT
     schema format

   - Add RiscV SBI PMU event mapping binding

   - Add missing contraints on Arm SCMI child node allowed properties

   - Add a bunch of missing Socionext UniPhier glue block bindings and
     example fixes

   - Various fixes for duplicate or conflicting type definitions on DT
     properties"

* tag 'devicetree-for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (66 commits)
  dt-bindings: regulator: Add mps,mpq7932 power-management IC
  of: dynamic: Fix spelling mistake "kojbect" -> "kobject"
  dt-bindings: drop Sagar Kadam from SiFive binding maintainership
  dt-bindings: sram: qcom,imem: document sm8450
  dt-bindings: interrupt-controller: convert loongson,ls1x-intc.txt to json-schema
  dt-bindings: arm: Add Cortex-A715 and X3
  of: dynamic: add lifecycle docbook info to node creation functions
  of: add consistency check to of_node_release()
  of: do not use "%pOF" printk format on node with refcount of zero
  of: unittest: add node lifecycle tests
  of: update kconfig unittest help
  of: add processing of EXPECT_NOT to of_unittest_expect
  of: prepare to add processing of EXPECT_NOT to of_unittest_expect
  of: Use preferred of_property_read_* functions
  of: Use of_property_present() helper
  of: Add of_property_present() helper
  of: reserved_mem: Use proper binary prefix
  dt-bindings: Fix multi pattern support in DT_SCHEMA_FILES
  of: reserved-mem: print out reserved-mem details during boot
  dt-bindings: serial: restrict possible child node names
  ...

of: reserved_mem: Use proper binary prefix

2023-02-17T21:21:36+00:00

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 
Link: https://lore.kernel.org/r/20230216083725.1244817-1-geert+renesas@glider.be
Signed-off-by: Rob Herring

of: reserved-mem: print out reserved-mem details during boot

2023-02-15T21:07:42+00:00

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 
Link: https://lore.kernel.org/r/20230209160954.1471909-1-liumartin@google.com
Signed-off-by: Rob Herring

of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem

2023-02-09T23:56:51+00:00

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 
Acked-by: Mike Rapoport (IBM) 
Acked-by: Catalin Marinas 
Cc: Frank Rowand 
Cc: Kirill A. Shutemov 
Cc: Nick Kossifidis 
Cc: Rafael J. Wysocki 
Cc: Rob Herring 
Cc: Russell King (Oracle) 
Cc: Saravana Kannan 
Cc: 	[5.15+]
Signed-off-by: Andrew Morton

of: reserved-memory: Print allocation/reservation failures as error

2022-06-28T20:15:36+00:00

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 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220628113540.2790835-1-vincent.whitchurch@axis.com

cma: factor out minimum alignment requirement

2022-03-22T22:57:05+00:00

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 
Reviewed-by: Zi Yan 
Acked-by: Rob Herring 
Cc: Aneesh Kumar K.V 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Frank Rowand 
Cc: Michael S. Tsirkin 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Minchan Kim 
Cc: Vlastimil Babka 
Cc: John Garry via iommu 

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds