On Tue, Sep 12, 2023 at 11:18:20AM +0100, Will Deacon wrote: > On Mon, Sep 11, 2023 at 04:23:50PM +0530, Mukesh Ojha wrote: > > 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 <quic_mojha@xxxxxxxxxxx> > > --- > > arch/arm64/mm/init.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++ > > Why does this need to be in the arch code? There's absolutely nothing > arm64-specific here. I would agree: this needs to be in ramoops itself, IMO. It should be a ramoops module argument, too. It being unhelpful for systems that don't have an external consumer is certainly true, but I think it would still make more sense for this change to live entirely within ramoops. Specifically: you're implementing a pstore backend behavioral change. In the same way that patch 10 is putting the "output" side of this into pstore/, I'd expect the "input" side also in pstore/ More comments there, though. -- Kees Cook
