]> git.baikalelectronics.ru Git - kernel.git/commit
drivers: of: increase MAX_RESERVED_REGIONS to 32
authorStewart Smith <stewart@linux.vnet.ibm.com>
Tue, 26 Sep 2017 08:40:00 +0000 (18:40 +1000)
committerRob Herring <robh@kernel.org>
Thu, 12 Oct 2017 17:23:45 +0000 (12:23 -0500)
commit4f0d6c0fe0b7f0810f4f7f5f0dc223f47bb17c07
tree7b16a03941009c19bded54824f8c05d252f871d8
parent3401972d972eea98294ee40d2d4d86bdbfbfb584
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 38c57b379c9aa (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>
drivers/of/of_reserved_mem.c