[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c0112826-1a65-e1cc-db98-e692a312ecb0@quicinc.com>
Date: Thu, 12 Jan 2023 13:59:52 +0530
From: Mukesh Ojha <quic_mojha@...cinc.com>
To: "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
<keescook@...omium.org>, <tony.luck@...el.com>
CC: <linux-hardening@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pstore/ram: Rework logic for detecting ramoops
Hi Guilherme,
On 1/11/2023 6:31 PM, Guilherme G. Piccoli wrote:
> 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".
>
Thanks for the review.
Will fix it along with other comments.
Also, let me know if we need to change binding or document update as well.
-Mukesh
> Really minor nits, though!
> Cheers
>
>
> Guilherme
Powered by blists - more mailing lists