Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 16 May 2023 13:48:39 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Luca Stefani <luca.stefani.ge1@gmail.com>
Cc:     Mukesh Ojha <quic_mojha@quicinc.com>, agross@kernel.org,
        andersson@kernel.org, konrad.dybcio@linaro.org, corbet@lwn.net,
        tony.luck@intel.com, gpiccoli@igalia.com, catalin.marinas@arm.com,
        will@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        robh+dt@kernel.org, linus.walleij@linaro.org,
        linux-gpio@vger.kernel.org, srinivas.kandagatla@linaro.org,
        linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3 09/18] soc: qcom: Add qcom's pstore minidump driver
 support
Message-ID: <202305161347.80204C1A0E@keescook>
References: <1683133352-10046-1-git-send-email-quic_mojha@quicinc.com>
 <1683133352-10046-10-git-send-email-quic_mojha@quicinc.com>
 <e25723bf-be85-b458-a84c-1a45392683bb@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e25723bf-be85-b458-a84c-1a45392683bb@gmail.com>
Precedence: bulk

On Tue, May 09, 2023 at 06:06:26PM +0200, Luca Stefani wrote:
> 
> On 03/05/23 19:02, Mukesh Ojha wrote:
> > This driver was inspired from the fact pstore ram region should be
> > fixed and boot firmware need to have awarness about this region,
> > so that it will be persistent across boot. But, there are many
> > QCOM SoC which does not support warm boot from hardware but they
> > have minidump support from the software, and for them, there is
> > no need of this pstore ram region to be fixed, but at the same
> > time have interest in the pstore frontends. So, this driver
> > get the dynamic reserved region from the ram and register the
> > ramoops platform device.
> > 
> >   +---------+     +---------+   +--------+     +---------+
> >   | console |     | pmsg    |   | ftrace |     | dmesg   |
> >   +---------+     +---------+   +--------+     +---------+
> >         |             |             |              |
> >         |             |             |              |
> >         +------------------------------------------+
> >                            |
> >                           \ /
> >                    +----------------+
> >              (1)   |pstore frontends|
> >                    +----------------+
> >                            |
> >                           \ /
> >                   +------------------- +
> >              (2)  | pstore backend(ram)|
> >                   +--------------------+
> >                            |
> >                           \ /
> >                   +--------------------+
> >              (3)  |qcom_pstore_minidump|
> >                   +--------------------+
> >                            |
> >                           \ /
> >                     +---------------+
> >              (4)    | qcom_minidump |
> >                     +---------------+
> > 
> > This driver will route all the pstore front data to the stored
> > in qcom pstore reserved region and the reason of showing an
> > arrow from (3) to (4) as qcom_pstore_minidump driver will register
> > all the available frontends region with qcom minidump driver
> > in upcoming patch.
> > 
> > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
> [...]
> > +static struct qcom_ramoops_config default_ramoops_config = {
> > +	.mem_type = 2,
> > +	.record_size = 0x0,
> > +	.console_size = 0x200000,
> > +	.ftrace_size = 0x0,
> > +	.pmsg_size = 0x0,
> > +};
> 
> This is effectively hard-cording the configuration of ramoops.
> 
> Since the memory range is dynamic and by itself doesn't impose any
> limitation this should be configurable in the device-tree, like a standard
> ramoops entry backed by a memory range.
> 
> I think this should provide the same interface/knobs as pstore-ram does,
> unless there's some known limitations to minidump, in which case those
> should be expressed.

Yeah, I had the same thought reading this myself. Beyond that, it looks
fine as a way to let pstore know about a new RAM backend.

-Kees

-- 
Kees Cook