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;
Message-ID: <217ebecf-3630-b423-ea0b-037e0943e17b@igalia.com>
Date:   Wed, 11 Jan 2023 10:01:03 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH] pstore/ram: Rework logic for detecting ramoops
To:     Mukesh Ojha <quic_mojha@quicinc.com>, keescook@chromium.org,
        tony.luck@intel.com
Cc:     linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
References: <1673428065-22356-1-git-send-email-quic_mojha@quicinc.com>
Content-Language: en-US
From:   "Guilherme G. Piccoli" <gpiccoli@igalia.com>
In-Reply-To: <1673428065-22356-1-git-send-email-quic_mojha@quicinc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Thanks for the patch Mukesh! I don't have a DT hardware at hand right
now, so cannot test this one myself. I'll just provide a (really) minor
feedback, something to address in a potential V2 or even in merge time,
see below.


On 11/01/2023 06:07, 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 is not desirable
> in environments where it is preferred the region to be dynamically
> allocated at runtime, as opposed to being fixed at compile time.
> 
> Also, Some of the platforms might be still expecting dedicated

I'd write "Also, some" instead of upper "Some".

> memory region for ramoops node where the region is known
> beforehand and platform_get_resource() is used in that case.
> 
> So, Add logic to detect the start and size of the ramoops memory

Same here, maybe "So, add".

Really minor nits, though!
Cheers,


Guilherme