From: Pavan Kondeti <quic_pkondeti@quicinc.com>
To: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: <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>,
<catalin.marinas@arm.com>, <will@kernel.org>,
<linus.walleij@linaro.org>, <andy.shevchenko@gmail.com>,
<vigneshr@ti.com>, <nm@ti.com>, <matthias.bgg@gmail.com>,
<kgene@kernel.org>, <alim.akhtar@samsung.com>,
<bmasney@redhat.com>, <quic_tsoni@quicinc.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-gpio@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>,
<linux-samsung-soc@vger.kernel.org>, <kernel@quicinc.com>
Subject: Re: [PATCH v5 08/17] arm64: mm: Add dynamic ramoops region support through command line
Date: Mon, 11 Sep 2023 10:52:26 +0530 [thread overview]
Message-ID: <8b0d2b06-70ae-4afa-bd04-13eaa4280c03@quicinc.com> (raw)
In-Reply-To: <1694290578-17733-9-git-send-email-quic_mojha@quicinc.com>
On Sun, Sep 10, 2023 at 01:46:09AM +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.
>
This needs to be documented at
Documentation/admin-guide/kernel-parameters.txt
> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
> ---
> arch/arm64/mm/init.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pstore_ram.h | 2 +
> 2 files changed, 96 insertions(+)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index d31c3a9290c5..14d7086758bf 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -31,6 +31,7 @@
> #include <linux/hugetlb.h>
> #include <linux/acpi_iort.h>
> #include <linux/kmemleak.h>
> +#include <linux/pstore_ram.h>
>
> #include <asm/boot.h>
> #include <asm/fixmap.h>
> @@ -73,6 +74,93 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit;
>
> #define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
>
> +#define RAMOOPS_ADDR_HIGH_MAX (PHYS_MASK + 1)
> +
> +/* Location of the reserved area for the dynamic ramoops */
> +struct resource dyn_ramoops_res = {
> + .name = "ramoops",
> + .start = 0,
> + .end = 0,
> + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> + .desc = IORES_DESC_NONE,
> +};
> +EXPORT_SYMBOL(dyn_ramoops_res);
Use EXPORT_SYMBOL_GPL.
> +
> +static int __init parse_dynamic_ramoops(char *cmdline, unsigned long long *size)
> +{
> + const char *name = "dyn_ramoops_size=";
> + char *p = NULL;
> + char *q = NULL;
> + char *tmp;
> +
> + if (!cmdline)
> + return -ENOENT;
> +
> + /* Check for "dyn_ramoops_size" and use the later if there are more */
> + p = strstr(cmdline, name);
> + while (p) {
> + q = p;
> + p = strchr(p, ' ');
> + if (!p)
> + break;
> +
> + p = strstr(p + 1, name);
> + }
> +
> + if (!q) {
> + pr_err("ramoops: No entry found for %s\n", name);
> + return -ENOENT;
> + }
> +
> + p = q + strlen(name);
> + *size = memparse(p, &tmp);
> + if (p == tmp) {
> + pr_err("ramoops: memory value expected\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int __init parse_dyn_ramoops_size_dummy(char *arg)
> +{
> + return 0;
> +}
> +early_param("dyn_ramoops_size", parse_dyn_ramoops_size_dummy);
> +
Any reason why we can't parse and cache the size in early param handler
it self?
> +/*
> + * reserve_dynamic_ramoops() - reserves memory for dynamic ramoops
> + *
> + * This enable dynamic reserve memory support for ramoops through
> + * command line.
> + */
> +static void __init reserve_dynamic_ramoops(void)
> +{
> + char *cmdline = boot_command_line;
> + unsigned long long ramoops_base;
> + unsigned long long ramoops_size;
> +
> + if (!IS_ENABLED(CONFIG_PSTORE_RAM))
> + return;
> +
Should not most part of this patch be under CONFIG_PSTORE_RAM?
> + if (parse_dynamic_ramoops(cmdline, &ramoops_size))
> + return;
> +
> + ramoops_base = memblock_phys_alloc_range(ramoops_size, SMP_CACHE_BYTES,
> + 0, RAMOOPS_ADDR_HIGH_MAX);
It may be appropriate to use one of MEMBLOCK_ALLOC_xxx flags for the end
marker.
> + if (!ramoops_base) {
> + pr_err("cannot allocate ramoops dynamic memory (size:0x%llx).\n",
> + ramoops_size);
> + return;
> + }
> +
> + kmemleak_ignore_phys(ramoops_base);
Looks like you need MEMBLOCK_ALLOC_NOLEAKTRACE
> +
> + dyn_ramoops_res.start = ramoops_base;
> + dyn_ramoops_res.end = ramoops_base + ramoops_size - 1;
> + insert_resource(&iomem_resource, &dyn_ramoops_res);
> +}
> +
> static int __init reserve_crashkernel_low(unsigned long long low_size)
> {
> unsigned long long low_base;
> @@ -456,6 +544,12 @@ void __init bootmem_init(void)
> */
> reserve_crashkernel();
>
> + /*
> + * Reserving ramoops region resource dynamically in case it is
> + * requested from command line.
> + */
> + reserve_dynamic_ramoops();
> +
> memblock_dump_all();
> }
>
> diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
> index 9d65ff94e216..07d700b7649d 100644
> --- a/include/linux/pstore_ram.h
> +++ b/include/linux/pstore_ram.h
> @@ -10,6 +10,8 @@
>
> #include <linux/pstore.h>
>
> +extern struct resource dyn_ramoops_res;
> +
What about other architectures?
> struct persistent_ram_ecc_info {
> int block_size;
> int ecc_size;
> --
> 2.7.4
>
next prev parent reply other threads:[~2023-09-11 5:23 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 20:16 [PATCH v5 00/17] Add Qualcomm Minidump kernel driver related support Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 01/17] docs: qcom: Add qualcomm minidump guide Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 02/17] soc: qcom: Add qcom_rproc_minidump module Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 03/17] remoteproc: qcom_q6v5_pas: Use qcom_rproc_minidump() Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 04/17] remoteproc: qcom: Remove minidump related data from qcom_common.c Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 05/17] init: export linux_banner data variable Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 06/17] soc: qcom: Add Qualcomm APSS minidump kernel driver Mukesh Ojha
2023-09-11 11:01 ` Krzysztof Kozlowski
2023-09-12 9:26 ` Mukesh Ojha
2023-09-12 9:54 ` Krzysztof Kozlowski
2023-09-13 7:09 ` Mukesh Ojha
2023-09-12 9:58 ` Mukesh Ojha
2023-09-11 11:07 ` Krzysztof Kozlowski
2023-09-11 19:09 ` Jeff Johnson
2023-09-11 19:33 ` Konrad Dybcio
2023-09-13 15:18 ` Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 07/17] soc: qcom: minidump: Add pending region registration Mukesh Ojha
2023-09-11 11:08 ` Krzysztof Kozlowski
2023-09-11 18:59 ` Jeff Johnson
2023-09-09 20:16 ` [PATCH v5 08/17] arm64: mm: Add dynamic ramoops region support through command line Mukesh Ojha
2023-09-11 5:22 ` Pavan Kondeti [this message]
2023-09-09 20:16 ` [PATCH v5 09/17] pstore/ram: Use dynamic ramoops reserve resource Mukesh Ojha
2023-09-11 5:33 ` Pavan Kondeti
2023-09-11 10:51 ` Mukesh Ojha
2023-09-12 0:39 ` Pavan Kondeti
2023-09-12 9:46 ` Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 10/17] pstore: Add pstore_region_defined() helper and export it Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 11/17] qcom_minidump: Register ramoops region with minidump Mukesh Ojha
2023-09-11 6:01 ` Pavan Kondeti
2023-09-11 7:58 ` Mukesh Ojha
2023-09-11 11:09 ` Krzysztof Kozlowski
2023-09-09 20:16 ` [PATCH v5 12/17] MAINTAINERS: Add entry for minidump related files Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 13/17] firmware: qcom_scm: provide a read-modify-write function Mukesh Ojha
2023-09-11 8:08 ` Kathiravan Thirumoorthy
2023-09-11 8:11 ` Kathiravan Thirumoorthy
2023-09-09 20:16 ` [PATCH v5 14/17] pinctrl: qcom: Use qcom_scm_io_update_field() Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 15/17] firmware: scm: Modify only the download bits in TCSR register Mukesh Ojha
2023-09-11 8:11 ` Kathiravan Thirumoorthy
2023-09-11 8:16 ` Kathiravan Thirumoorthy
2023-09-09 20:16 ` [PATCH v5 16/17] firmware: qcom_scm: Refactor code to support multiple download mode Mukesh Ojha
2023-09-09 20:16 ` [PATCH v5 17/17] firmware: qcom_scm: Add multiple download mode support Mukesh Ojha
2023-09-11 7:59 ` [PATCH v5 00/17] Add Qualcomm Minidump kernel driver related support Kathiravan Thirumoorthy
2023-09-11 8:52 ` Bagas Sanjaya
2023-09-11 10:39 ` Mukesh Ojha
2023-09-11 13:14 ` Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8b0d2b06-70ae-4afa-bd04-13eaa4280c03@quicinc.com \
--to=quic_pkondeti@quicinc.com \
--cc=agross@kernel.org \
--cc=alim.akhtar@samsung.com \
--cc=andersson@kernel.org \
--cc=andy.shevchenko@gmail.com \
--cc=bmasney@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=gpiccoli@igalia.com \
--cc=keescook@chromium.org \
--cc=kernel@quicinc.com \
--cc=kgene@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=matthias.bgg@gmail.com \
--cc=nm@ti.com \
--cc=quic_mojha@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=tony.luck@intel.com \
--cc=vigneshr@ti.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®