On Tue, Jan 9, 2018 at 9:03 PM, Greg KH <g...@kroah.com> wrote:
> On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote:
>> + LKML
>>
>> ---------- Forwarded message ----------
>> From: Arend van Spriel <aspr...@gmail.com>
>> Date: Tue, Jan 9, 2018 at 8:19 PM
>> Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump
>> To: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>>
>>
>> On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> > On Tue, Dec 19, 2017 at 11:03:20AM +0100, Arend van Spriel wrote:
>> >> From: Arend van Spriel <aspr...@gmail.com>
>> >>
>> >> 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.
>> >
>> > What driver is going to set this? I don't want to add new options to
>> > the kernel that never get used, do you have a driver to use it?
>>
>> Hi Greg,
>>
>> After sending these patches I realized that was going to be your
>> response, but decided to wait for it. Obviously there is a driver for
>> which I would like to have an option to create a device coredump from
>> user-space, ie. the brcm80211 drivers (maintained by my alter-ego ;-)
>> ). I can post these patches again as RFC including the brcm80211
>> driver patches. Here a bit of background about this itch. A couple of
>> other driver support their own coredump implementation, ie. not using
>> dev_coredump class and some support user-space initiated coredump
>> through debugfs. As that depends on a Kconfig option I looked for
>> other solutions. At first I considered doing it in dev_coredump class
>> itself by doing:
>>
>> # echo 0000:04:00.0 > /sys/class/devcoredump/trigger
>>
>> with 'trigger' being a new sysfs attribute for devcoredump. However,
>> using the driver core turned out to be much simpler, but I am still
>> open for other/better options.
>
> Nah, I don't object to the patches, but I want someone to use it. So
> can you resend these, with a RFC for the driver you want using it as the
> last patch?
Thanks. Will do that. FWIW, there are a couple more drivers that I
would like to change to using this as well.
Regards,
Arend
