The reserved_mem array must be statically allocated because it is used
prior to memblock being aware of all "no-map" or otherwise reserved
regions which have fixed physical addresses. Due to this limitation,
if one architecture/board has a large number of reserved_mem regions,
this limit must be raised for all.
In particular, certain new qcom boards currently have 63 reserved memory
regions, which when new features are added, pushes them over the existing
limit of 64.
A generalized breakdown by region type:
13 for linux-loaded device firmware
9 for guest-vms or inter-vm communication
15 cma heaps/dma-buf heaps
24 for bootloaders/hypervisor/secure-world devices or software
2 misc
Although this number could be reduced by a minor amount by combining
physically adjacent regions, this comes at the cost of losing
documention on what/who the regions are used by. In addition, combining
adjacent regions is not possible if there are phandles in devicetree
refering to the regions in question, such as "memory-region".
Vmlinux size before:
text data bss dec hex filename
31030829 15807732 588524 47427085 2d3ae0d dist/vmlinux
text data bss dec hex filename
31030877 15807668 592108 47430653 2d3bbfd dist/vmlinux
Bug: 229767760
Link: https://lore.kernel.org/linux-devicetree/1650488954-26662-1-git-send-email-quic_pdaly@quicinc.com/T/#u
Change-Id: I2bdc6ad1ecfe273aad3c72390283b6d1247b18c3
Signed-off-by: Patrick Daly <quic_pdaly@quicinc.com>
Signed-off-by: Sukadev Bhattiprolu <quic_sukadev@quicinc.com>
(cherry picked from commit 63d1aaef5982744d17575435381e96795f806b0f)
6bf3324ebd