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: <0199db00-1b1d-0c63-58ff-03efae02cb21@quicinc.com>
Date:   Thu, 20 Jul 2023 20:32:24 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
To:     <linux-samsung-soc@vger.kernel.org>,
        <linux-mediatek@lists.infradead.org>,
        lkml <linux-kernel@vger.kernel.org>
CC:     Trilok Soni <quic_tsoni@quicinc.com>,
        "open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@vger.kernel.org>
From:   Mukesh Ojha <quic_mojha@quicinc.com>
Subject: Feedback on Qualcomm's minidump (debug) solution for end user device
 crash
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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/

-Mukesh