Thanks for the response.

On 9/12/2023 3:48 PM, Will Deacon wrote:

On Mon, Sep 11, 2023 at 04:23:50PM +0530, Mukesh Ojha wrote:

quoted

The reserved memory region for ramoops is assumed to be at a fixed
and known location when read from the devicetree. This may not be
required for something like Qualcomm's minidump which is interested
in knowing addresses of ramoops region but it does not put hard
requirement of address being fixed as most of it's SoC does not
support warm reset and does not use pstorefs at all instead it has
firmware way of collecting ramoops region if it gets to know the
address and register it with apss minidump table which is sitting
in shared memory region in DDR and firmware will have access to
these table during reset and collects it on crash of SoC.

So, add the support of reserving ramoops region to be dynamically
allocated early during boot if it is request through command line
via 'dyn_ramoops_size=' and fill up reserved resource structure and
export the structure, so that it can be read by ramoops driver.

Signed-off-by: Mukesh Ojha <redacted>
---
  arch/arm64/mm/init.c       | 94 ++++++++++++++++++++++++++++++++++++++++++++++

Why does this need to be in the arch code? There's absolutely nothing
arm64-specific here.

Current clients of this cmdline would be only arm64, and that is the
reason of putting this here.

I was checking the places where memblock_phys_alloc_range() gets called
and found either it is arch/*/ and drivers/of/of_reserved_mem.c .

Since, this is not related to device tree, did not find a proper place
than this, i took the reference of this place from
reserve_crashkernel(). Also, not sure how could it be of help to other
non-arch64 users at this point.

-Mukesh

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel