From: Mukesh Ojha <quic_mojha@quicinc.com> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <corbet@lwn.net>, <keescook@chromium.org>, <tony.luck@intel.com>, <gpiccoli@igalia.com>, <catalin.marinas@arm.com>, <will@kernel.org> Cc: <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 v2 6/6] remoterproc: qcom: refactor to leverage exported minidump symbol Date: Fri, 14 Apr 2023 17:19:26 +0530 [thread overview] Message-ID: <93f5dc05-a91b-0fe6-c7e2-d3457cba8a1f@quicinc.com> (raw) In-Reply-To: <5a872001-dfcb-5c00-3b13-3c29e6be213b@linaro.org> On 4/14/2023 5:10 PM, Srinivas Kandagatla wrote: > > > On 14/04/2023 12:14, Mukesh Ojha wrote: >> >> >> On 4/14/2023 4:14 PM, Srinivas Kandagatla wrote: >>> >>> >>> On 22/03/2023 13:30, Mukesh Ojha wrote: >>>> qcom_minidump driver provides qcom_minidump_subsystem_desc() >>>> exported API which other driver can use it query subsystem >>>> descriptor. Refactor qcom_minidump() to use this symbol. >>>> >>>> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> >>>> --- >>>> drivers/remoteproc/qcom_common.c | 13 ++----------- >>>> 1 file changed, 2 insertions(+), 11 deletions(-) >>>> >>>> diff --git a/drivers/remoteproc/qcom_common.c >>>> b/drivers/remoteproc/qcom_common.c >>>> index 88fc984..240e9f7 100644 >>>> --- a/drivers/remoteproc/qcom_common.c >>>> +++ b/drivers/remoteproc/qcom_common.c >>>> @@ -94,19 +94,10 @@ void qcom_minidump(struct rproc *rproc, unsigned >>>> int minidump_id, >>>> { >>>> int ret; >>>> struct minidump_subsystem *subsystem; >>>> - struct minidump_global_toc *toc; >>>> - /* Get Global minidump ToC*/ >>>> - toc = qcom_smem_get(QCOM_SMEM_HOST_ANY, SBL_MINIDUMP_SMEM_ID, >>>> NULL); >>>> - >>>> - /* check if global table pointer exists and init is set */ >>>> - if (IS_ERR(toc) || !toc->status) { >>>> - dev_err(&rproc->dev, "Minidump TOC not found in SMEM\n"); >>>> + subsystem = qcom_minidump_subsystem_desc(minidump_id); >>>> + if (IS_ERR(subsystem)) >>>> return; >>> >>> Sorry If I am missing something but I got lost looking at the below >>> code snippet in drivers/remoteproc/qcom_common.c >>> >>> >>> -------------------->cut<----------------------------- >>> subsystem = qcom_minidump_subsystem_desc(minidump_id); >>> if (IS_ERR(subsystem)) >>> return; >>> >>> /** >>> * Collect minidump if SS ToC is valid and segment table >>> * is initialized in memory and encryption status is set. >>> */ >>> if (subsystem->regions_baseptr == 0 || >>> le32_to_cpu(subsystem->status) != 1 || >>> le32_to_cpu(subsystem->enabled) != MINIDUMP_SS_ENABLED || >>> le32_to_cpu(subsystem->encryption_status) != >>> MINIDUMP_SS_ENCR_DONE) { >>> dev_err(&rproc->dev, "Minidump not ready, skipping\n"); >>> return; >>> } >>> -------------------->cut<----------------------------- >>> >>> where does "subsystem->regions_baseptr" for this ADSP minidump >>> descriptor get set? >> >> Other co-processor such as adsp/cdsp/Mpss has their own way of >> registering their region/segment (mostly they are static known >> regions) with minidump global infra and which could be happening >> from firmware side . > If its happening from firmware side, then that ram phys address range > should be reserved from kernel usage I guess. > > Do you have more details on where exactly is this reserved from within > linux kernel? These regions are inside remoteproc memory carve-out. like. adsp_mem: memory@85e00000 { reg = <0x0 0x85e00000 0x0 0x2100000>; no-map; }; remoteproc_adsp: remoteproc@30000000 { compatible = "qcom,sm8450-adsp-pas"; reg = <0 0x30000000 0 0x100>; ... ... memory-region = <&adsp_mem>; <== -Mukesh > > > --srini > >> >> >> -Mukesh >> >>> >>> >>> --srini >>> >>>> - } >>>> - >>>> - /* Get subsystem table of contents using the minidump id */ >>>> - subsystem = &toc->subsystems[minidump_id]; >>>> /** >>>> * Collect minidump if SS ToC is valid and segment table
WARNING: multiple messages have this Message-ID (diff)
From: Mukesh Ojha <quic_mojha@quicinc.com> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, <agross@kernel.org>, <andersson@kernel.org>, <konrad.dybcio@linaro.org>, <corbet@lwn.net>, <keescook@chromium.org>, <tony.luck@intel.com>, <gpiccoli@igalia.com>, <catalin.marinas@arm.com>, <will@kernel.org> Cc: <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 v2 6/6] remoterproc: qcom: refactor to leverage exported minidump symbol Date: Fri, 14 Apr 2023 17:19:26 +0530 [thread overview] Message-ID: <93f5dc05-a91b-0fe6-c7e2-d3457cba8a1f@quicinc.com> (raw) In-Reply-To: <5a872001-dfcb-5c00-3b13-3c29e6be213b@linaro.org> On 4/14/2023 5:10 PM, Srinivas Kandagatla wrote: > > > On 14/04/2023 12:14, Mukesh Ojha wrote: >> >> >> On 4/14/2023 4:14 PM, Srinivas Kandagatla wrote: >>> >>> >>> On 22/03/2023 13:30, Mukesh Ojha wrote: >>>> qcom_minidump driver provides qcom_minidump_subsystem_desc() >>>> exported API which other driver can use it query subsystem >>>> descriptor. Refactor qcom_minidump() to use this symbol. >>>> >>>> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> >>>> --- >>>> drivers/remoteproc/qcom_common.c | 13 ++----------- >>>> 1 file changed, 2 insertions(+), 11 deletions(-) >>>> >>>> diff --git a/drivers/remoteproc/qcom_common.c >>>> b/drivers/remoteproc/qcom_common.c >>>> index 88fc984..240e9f7 100644 >>>> --- a/drivers/remoteproc/qcom_common.c >>>> +++ b/drivers/remoteproc/qcom_common.c >>>> @@ -94,19 +94,10 @@ void qcom_minidump(struct rproc *rproc, unsigned >>>> int minidump_id, >>>> { >>>> int ret; >>>> struct minidump_subsystem *subsystem; >>>> - struct minidump_global_toc *toc; >>>> - /* Get Global minidump ToC*/ >>>> - toc = qcom_smem_get(QCOM_SMEM_HOST_ANY, SBL_MINIDUMP_SMEM_ID, >>>> NULL); >>>> - >>>> - /* check if global table pointer exists and init is set */ >>>> - if (IS_ERR(toc) || !toc->status) { >>>> - dev_err(&rproc->dev, "Minidump TOC not found in SMEM\n"); >>>> + subsystem = qcom_minidump_subsystem_desc(minidump_id); >>>> + if (IS_ERR(subsystem)) >>>> return; >>> >>> Sorry If I am missing something but I got lost looking at the below >>> code snippet in drivers/remoteproc/qcom_common.c >>> >>> >>> -------------------->cut<----------------------------- >>> subsystem = qcom_minidump_subsystem_desc(minidump_id); >>> if (IS_ERR(subsystem)) >>> return; >>> >>> /** >>> * Collect minidump if SS ToC is valid and segment table >>> * is initialized in memory and encryption status is set. >>> */ >>> if (subsystem->regions_baseptr == 0 || >>> le32_to_cpu(subsystem->status) != 1 || >>> le32_to_cpu(subsystem->enabled) != MINIDUMP_SS_ENABLED || >>> le32_to_cpu(subsystem->encryption_status) != >>> MINIDUMP_SS_ENCR_DONE) { >>> dev_err(&rproc->dev, "Minidump not ready, skipping\n"); >>> return; >>> } >>> -------------------->cut<----------------------------- >>> >>> where does "subsystem->regions_baseptr" for this ADSP minidump >>> descriptor get set? >> >> Other co-processor such as adsp/cdsp/Mpss has their own way of >> registering their region/segment (mostly they are static known >> regions) with minidump global infra and which could be happening >> from firmware side . > If its happening from firmware side, then that ram phys address range > should be reserved from kernel usage I guess. > > Do you have more details on where exactly is this reserved from within > linux kernel? These regions are inside remoteproc memory carve-out. like. adsp_mem: memory@85e00000 { reg = <0x0 0x85e00000 0x0 0x2100000>; no-map; }; remoteproc_adsp: remoteproc@30000000 { compatible = "qcom,sm8450-adsp-pas"; reg = <0 0x30000000 0 0x100>; ... ... memory-region = <&adsp_mem>; <== -Mukesh > > > --srini > >> >> >> -Mukesh >> >>> >>> >>> --srini >>> >>>> - } >>>> - >>>> - /* Get subsystem table of contents using the minidump id */ >>>> - subsystem = &toc->subsystems[minidump_id]; >>>> /** >>>> * Collect minidump if SS ToC is valid and segment table _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-14 11:50 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-22 13:30 [PATCH v2 0/6] Add basic Minidump kernel driver support Mukesh Ojha 2023-03-22 13:30 ` Mukesh Ojha 2023-03-22 13:30 ` [PATCH v2 1/6] remoteproc: qcom: Expand MD_* as MINIDUMP_* Mukesh Ojha 2023-03-22 13:30 ` Mukesh Ojha 2023-03-22 13:30 ` [PATCH v2 2/6] remoteproc: qcom: Move minidump specific data to qcom_minidump.h Mukesh Ojha 2023-03-22 13:30 ` Mukesh Ojha 2023-04-13 22:32 ` Srinivas Kandagatla 2023-04-13 22:32 ` Srinivas Kandagatla 2023-04-14 7:05 ` Mukesh Ojha 2023-04-14 7:05 ` Mukesh Ojha 2023-04-14 10:40 ` Srinivas Kandagatla 2023-04-14 10:40 ` Srinivas Kandagatla 2023-04-17 13:22 ` Mukesh Ojha 2023-04-17 13:22 ` Mukesh Ojha 2023-04-18 14:02 ` Srinivas Kandagatla 2023-04-18 14:02 ` Srinivas Kandagatla 2023-04-18 14:52 ` Mukesh Ojha 2023-04-18 14:52 ` Mukesh Ojha 2023-03-22 13:30 ` [PATCH v2 3/6] docs: qcom: Add qualcomm minidump guide Mukesh Ojha 2023-03-22 13:30 ` Mukesh Ojha 2023-04-13 22:31 ` Srinivas Kandagatla 2023-04-13 22:31 ` Srinivas Kandagatla 2023-04-18 15:19 ` Mukesh Ojha 2023-04-18 15:19 ` Mukesh Ojha 2023-04-18 15:26 ` Srinivas Kandagatla 2023-04-18 15:26 ` Srinivas Kandagatla 2023-03-22 13:30 ` [PATCH v2 4/6] soc: qcom: Add Qualcomm minidump kernel driver Mukesh Ojha 2023-03-22 13:30 ` Mukesh Ojha 2023-04-13 22:31 ` Srinivas Kandagatla 2023-04-13 22:31 ` Srinivas Kandagatla 2023-03-22 13:30 ` [PATCH v2 5/6] arm64: defconfig: Enable Qualcomm minidump driver Mukesh Ojha 2023-03-22 13:30 ` Mukesh Ojha 2023-03-22 13:30 ` [PATCH v2 6/6] remoterproc: qcom: refactor to leverage exported minidump symbol Mukesh Ojha 2023-03-22 13:30 ` Mukesh Ojha 2023-04-14 10:44 ` Srinivas Kandagatla 2023-04-14 10:44 ` Srinivas Kandagatla 2023-04-14 11:14 ` Mukesh Ojha 2023-04-14 11:14 ` Mukesh Ojha 2023-04-14 11:40 ` Srinivas Kandagatla 2023-04-14 11:40 ` Srinivas Kandagatla 2023-04-14 11:49 ` Mukesh Ojha [this message] 2023-04-14 11:49 ` Mukesh Ojha 2023-04-14 12:22 ` Srinivas Kandagatla 2023-04-14 12:22 ` Srinivas Kandagatla 2023-04-03 16:25 ` [PATCH v2 0/6] Add basic Minidump kernel driver support Mukesh Ojha 2023-04-03 16:25 ` Mukesh Ojha
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=93f5dc05-a91b-0fe6-c7e2-d3457cba8a1f@quicinc.com \ --to=quic_mojha@quicinc.com \ --cc=agross@kernel.org \ --cc=andersson@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=gpiccoli@igalia.com \ --cc=keescook@chromium.org \ --cc=konrad.dybcio@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=srinivas.kandagatla@linaro.org \ --cc=tony.luck@intel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.