From: Kukjin Kim <kgene.kim@gmail.com>
To: Brian Masney <bmasney@redhat.com>
Cc: Mukesh Ojha <quic_mojha@quicinc.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
linux-samsung-soc@vger.kernel.org,
linux-mediatek@lists.infradead.org,
lkml <linux-kernel@vger.kernel.org>,
Trilok Soni <quic_tsoni@quicinc.com>,
"open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org,
Alim Akhtar <alim.akhtar@samsung.com>,
Kukjin Kim <kgene@kernel.org>,
Vignesh Raghavendra <vigneshr@ti.com>, Nishanth Menon <nm@ti.com>,
Matthias Brugger <matthias.bgg@gmail.com>
Subject: Re: Feedback on Qualcomm's minidump (debug) solution for end user device crash
Date: Wed, 9 Aug 2023 16:49:23 +0900 [thread overview]
Message-ID: <1DAA278D-BDFE-4880-8453-99F098D4E259@gmail.com> (raw)
In-Reply-To: <ZNEJAh0in/fjq6s9@brian-x1>
> 2023. 8. 8. 오전 12:08, Brian Masney <bmasney@redhat.com> 작성:
>
> On Mon, Aug 07, 2023 at 06:01:27PM +0530, Mukesh Ojha wrote:
>>> On 7/30/2023 5:14 PM, Krzysztof Kozlowski wrote:
>>> On 24/07/2023 18:59, Brian Masney wrote:
>>>> + linux-arm-kernel list
>>>>
>>>> On Thu, Jul 20, 2023 at 08:32:24PM +0530, Mukesh Ojha wrote:
>>>>> Hi Samsung/MTK/Any other SOC vendors,
>>>>>
>>>>> This is to bring to your notice that, we (Qualcomm) are working on
>>>>> upstreaming our minidump solution which is to address the problem of
>>>>> debugging on field device crashes where collecting entire ddr dump
>>>>> would not be feasible and collecting minimal data from the ddr would
>>>>> help in debug direction or even help in root causing issue.
>>>>>
>>>>> We have recently posted v4 version here [1]
>>>>>
>>>>> Based on comments[2], community is more worried about, if each SOC
>>>>> vendor come up with their own dumping method today or in future and
>>>>> whether it can have a common solution to a similar problem faced by
>>>>> other SOC vendor.
>>>>>
>>>>> We wanted to take your feedback if you also encounter a similar problem
>>>>> or maintain something similar solution in downstream which can be
>>>>> upstreamed. This will help us in a way to have a common solution in
>>>>> upstream.
>>>>>
>>>>> [1]
>>>>> https://lore.kernel.org/lkml/10dd2ead-758a-89f0-cda4-70ae927269eb@quicinc.com/
>>>>>
>>>>> [2]
>>>>> https://lore.kernel.org/lkml/CAL_JsqLO9yey2-4FcWsaGxijiS6hGL0SH9VoMuiyei-u9=Cv=w@mail.gmail.com/
>>>>
>>>> Adding the main ARM list to solicit feedback from other silicon
>>>> manufacturers.
>>>>
>>>> The cover sheet on the v4 patch set is available at:
>>>> https://lore.kernel.org/lkml/1687955688-20809-1-git-send-email-quic_mojha@quicinc.com/
>>>
>>> I doubt anyone follows the lists, so at least Cc some maintainers.
>>>
>>> +Cc Alim, Kukjin, Vignesh, Nishanth, Matthias.
>>
>> Thanks @Krzysztof/@Brian for extending the list.
>
> Hi Mukesh,
>
> Since no one has responded yet: I suspect your best bet to land the
> minidump functionality upstream is to refactor it to use the pstore
> functionality that Rob suggested:
>
> https://lore.kernel.org/lkml/CAL_JsqK7MHR09U5h01=Gf1ZLeDVCgZdN-W1hQRH3AX+E94_uUg@mail.gmail.com/
>
> Brian
>
Hi all,
Sorry for the late response and thanks for the asking.
In Samsung side, we’re checking about that internally as well. I’d like to know whether the minidump upstreaming is considered to be used in other chipset or some logic of that can be used. In addition, if Samsung wants, own the way upstreaming can be acceptable. It doesn’t mean we have a plan at this moment though.
Thanks,
Kukjin Kim <kgene(at)kernel.org>
_______________________________________________
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-08-09 7:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0199db00-1b1d-0c63-58ff-03efae02cb21@quicinc.com>
[not found] ` <ZL6t/sZTZBfvSYOm@brian-x1>
2023-07-30 11:44 ` Feedback on Qualcomm's minidump (debug) solution for end user device crash Krzysztof Kozlowski
2023-08-07 12:31 ` Mukesh Ojha
2023-08-07 15:08 ` Brian Masney
2023-08-09 7:49 ` Kukjin Kim [this message]
2023-08-09 16:17 ` 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=1DAA278D-BDFE-4880-8453-99F098D4E259@gmail.com \
--to=kgene.kim@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=bmasney@redhat.com \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=nm@ti.com \
--cc=quic_mojha@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=vigneshr@ti.com \
/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