[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkda3CJ7G4-wDPkWmzg6nyCoEfG+u2cQH6KXWNjbftd90ow@mail.gmail.com>
Date: Tue, 4 Jul 2023 11:27:48 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Rob Herring <robh+dt@...nel.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Mukesh Ojha <quic_mojha@...cinc.com>, corbet@....net,
agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
keescook@...omium.org, tony.luck@...el.com, gpiccoli@...lia.com,
catalin.marinas@....com, will@...nel.org,
andy.shevchenko@...il.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-hardening@...r.kernel.org,
linux-remoteproc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v4 00/21] Add Qualcomm Minidump kernel driver related support
On Thu, Jun 29, 2023 at 1:12 AM Rob Herring <robh+dt@...nel.org> wrote:
> My bigger issue with this whole series is what would this all look
> like if every SoC vendor upstreamed their own custom dumping
> mechanism. That would be a mess. (I have similar opinions on the
> $soc-vendor hypervisors.)
I agree with Rob's stance.
I think it would be useful to get input from the hwtracing developers
(Alexander and Mathieu) who faced this "necessarily different" issue
with all the hwtrace mechanisms and found a way out of it. I suspect
they can have an idea of how this should be abstracted.
Yours,
Linus Walleij
Powered by blists - more mailing lists