MIME-Version: 1.0
In-Reply-To: <1515592429-17420-1-git-send-email-aspriel@gmail.com>
References: <1515592429-17420-1-git-send-email-aspriel@gmail.com>
From: Arend van Spriel <aspriel@gmail.com>
Date: Thu, 11 Jan 2018 09:34:51 +0100
Message-ID: <CAJ65rDyKNp8bWfQA2fwyxfejz-S6h6bmy7UxKrzrPAroZ4Oppg@mail.gmail.com>
Subject: Re: [PATCH V2 0/3] sysfs: allow user-space request for devcoredump
To: Greg Koah Hartmann <gregkh@linuxfoundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
        Arend van Spriel <aspriel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org

On Wed, Jan 10, 2018 at 2:53 PM, Arend van Spriel <aspriel@gmail.com> wrote:
> Since commit 833c95456a70 ("device coredump: add new device coredump class")
> device drivers have a unified way to provide binary data obtained from a
> failing_device to user-space. However, there may be use-cases in which the
> driver has no reason to obtain the data, but user-space wants to initiate
> it. This adds a coredump device attribute in sysfs when the driver bound to
> the device supports the newly added coredump driver callback. As the
> devcoredump API offers more than one option, eg. single buffer vs. scatter
> list, it is left up to the driver how to invoke the devcoredump API. As an
> example this series includes a driver implementation as RFC. There are other
> drivers having some form of device firmware coredump that could benefit
> from this, but decided to tackle that in another cycle.
>
> These patches apply to the driver-core-next branch of the driver-core
> repository.

Please drop this series. I have V3 coming with minor update.

Regards,
Arend