On 2/21/2018 11:59 PM, Brian Norris wrote:
On Wed, Feb 21, 2018 at 11:50:19AM +0100, Arend van Spriel wrote:
Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops")
it is possible to initiate a device coredump from user-space. This
patch adds support for it adding the .coredump() driver callback.
As there is no longer a need to initiate it through debugfs remove
that code.

Signed-off-by: Arend van Spriel <arend.vanspr...@broadcom.com>
  drivers/net/wireless/marvell/mwifiex/debugfs.c | 31 +-------------------------
  drivers/net/wireless/marvell/mwifiex/pcie.c    | 19 ++++++++++++++--
  drivers/net/wireless/marvell/mwifiex/sdio.c    | 13 +++++++++++
  drivers/net/wireless/marvell/mwifiex/usb.c     | 14 ++++++++++++
  4 files changed, 45 insertions(+), 32 deletions(-)

The documentation doesn't really say [1], but is the coredump supposed
to happen synchronously? Because the mwifiex implementation is
asynchronous, whereas it looks like the brcmfmac one is synchronous.

Well, that depends on the eye of the beholder I guess. From user-space perspective it is asynchronous regardless. A write access to the coredump sysfs file eventually results in a uevent when the devcoredump entry is created, ie. after driver has made a dev_coredump API call. Whether the driver does that synchronously or asynchronously is irrelevant as far as user-space is concerned.


[1] In fact, the ABI documentation really just describes kernel
internals, rather than documenting any user-facing details, from what I
can tell.

You are right. Clearly I did not reach the end my learning curve here. I assumed referring to the existing dev_coredump facility was sufficient, but maybe it is worth a patch to be more explicit and mention the uevent behavior. Also dev_coredump facility may be disabled upon which the trigger will have no effect in sysfs. In the kernel the data passed by the driver is simply freed by dev_coredump facility.


Reply via email to