Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Tue, 28 Nov 2023 21:33:30 +0530
From:   Pavan Kondeti <quic_pkondeti@quicinc.com>
To:     Mukesh Ojha <quic_mojha@quicinc.com>
CC:     Pavan Kondeti <quic_pkondeti@quicinc.com>, <corbet@lwn.net>,
        <agross@kernel.org>, <andersson@kernel.org>,
        <konrad.dybcio@linaro.org>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <keescook@chromium.org>, <tony.luck@intel.com>,
        <gpiccoli@igalia.com>, <mathieu.poirier@linaro.org>,
        <vigneshr@ti.com>, <nm@ti.com>, <matthias.bgg@gmail.com>,
        <kgene@kernel.org>, <alim.akhtar@samsung.com>,
        <bmasney@redhat.com>, <linux-doc@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
        <linux-hardening@vger.kernel.org>,
        <linux-remoteproc@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-mediatek@lists.infradead.org>,
        <linux-samsung-soc@vger.kernel.org>, <kernel@quicinc.com>
Subject: Re: [Patch v6 10/12] pstore/ram: Add dynamic ramoops region support
 through commandline
Message-ID: <9d8911dd-408a-4d78-b3d1-c5ee23dbf3fc@quicinc.com>
References: <1700864395-1479-1-git-send-email-quic_mojha@quicinc.com>
 <1700864395-1479-11-git-send-email-quic_mojha@quicinc.com>
 <ad38fb23-e2a2-448e-bdea-fa0985f82b50@quicinc.com>
 <d5fa95e7-ad2a-0dc7-5c79-6a9a789dad5f@quicinc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <d5fa95e7-ad2a-0dc7-5c79-6a9a789dad5f@quicinc.com>
Precedence: bulk

On Tue, Nov 28, 2023 at 04:02:33PM +0530, Mukesh Ojha wrote:
> > >   static int ramoops_pstore_open(struct pstore_info *psi)
> > >   {
> > > @@ -915,14 +965,18 @@ static void __init ramoops_register_dummy(void)
> > >   	/*
> > >   	 * Prepare a dummy platform data structure to carry the module
> > > -	 * parameters. If mem_size isn't set, then there are no module
> > > -	 * parameters, and we can skip this.
> > > +	 * parameters. If mem_size isn't set, check for dynamic ramoops
> > > +	 * size and use if it is set.
> > >   	 */
> > > -	if (!mem_size)
> > > +	if (!mem_size && !dyn_ramoops_size)
> > >   		return;
> > 
> > If mem_size and dyn_ramoops_size are set, you are taking
> > dyn_ramoops_size precedence here. The comment is a bit confusing, pls
> > review it once.
> 
> Ideally, both should not be set and there will always be
> confusion.
> 
> Do you think, if we use mem_size a single variable both for earlier
> and dynamic ramoops where based on dyn_ramoops_size=true/on a boolean
> it will take dynamic ramoops path and if not mentioned it will take older
> path.
> 

Sounds like a good idea to me. You would need a callback for mem_size 
module param handling. Because dyn_ramoops can be passed before mem_size
parameter. Also, we can't make pstore ram as module i.e decoupling
dynamic ramoops from pstore ram module.

Thanks,
Pavan