From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934114AbeAJIW2 (ORCPT + 1 other); Wed, 10 Jan 2018 03:22:28 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:38522 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933336AbeAJIW0 (ORCPT ); Wed, 10 Jan 2018 03:22:26 -0500 Date: Wed, 10 Jan 2018 09:22:26 +0100 From: Greg KH To: Arend van Spriel Cc: LKML Subject: Re: Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump Message-ID: <20180110082226.GB32491@kroah.com> References: <1513677802-3031-1-git-send-email-arend.vanspriel@broadcom.com> <20180109184605.GA28273@kroah.com> <20180109200305.GA28050@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 09, 2018 at 09:06:21PM +0100, Arend van Spriel wrote: > On Tue, Jan 9, 2018 at 9:03 PM, Greg KH wrote: > > On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote: > >> + LKML > >> > >> ---------- Forwarded message ---------- > >> From: Arend van Spriel > >> 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 > >> > >> > >> On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman > >> wrote: > >> > On Tue, Dec 19, 2017 at 11:03:20AM +0100, Arend van Spriel wrote: > >> >> From: Arend van Spriel > >> >> > >> >> 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. Great, do it for all of them!