LKML Archive on
 help / color / Atom feed
From: Bjorn Andersson <>
To: Sibi Sankar <>
Subject: Re: [PATCH v2] remoteproc: Introduce prepare/unprepare ops for rproc coredump
Date: Mon, 28 May 2018 22:05:23 -0700
Message-ID: <20180529050523.GG2259@tuxbook-pro> (raw)
In-Reply-To: <>

On Mon 21 May 11:45 PDT 2018, Sibi Sankar wrote:

> In some occasions the remoteproc device might need to
> prepare some hardware before the coredump can be performed
> and cleanup the state afterwards.
> Q6V5 modem requires the mba to be loaded before the
> coredump and some cleanup of the resources afterwards.

This describes two different changes, so please put it in two+ patches.

> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index dfdaede9139e..010819e01279 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -333,6 +333,8 @@ struct firmware;
>   * @kick:	kick a virtqueue (virtqueue id given as a parameter)
>   * @da_to_va:	optional platform hook to perform address translations
>   * @load_rsc_table:	load resource table from firmware image
> + * @prepare_coredump:	prepare function, called before coredump
> + * @unprepare_coredump:	unprepare function, called post coredump

I believe there will be other cases where we will need driver-specific
logic to extract the memory content of the segments, e.g. through custom
hardware sequences or non-mmio reads.

To support this I think we should extend the struct rproc_dump_segment
to carry an optional "dump" function that if specified will be used
instead of the memcpy in rproc_coredump(). Drivers can then for each
segment specify this function, if needed.

Through some restructuring in the msa driver and your patch you should
be able to implement this using such a mechanism instead - and it would
be useful to these other cases as well.

PS. I hope we can get away from some of the conditionals in your patch
through some restructuring of the code.


  parent reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 18:45 Sibi Sankar
2018-05-22 10:39 ` kbuild test robot
2018-05-29  5:05 ` Bjorn Andersson [this message]
2018-05-29 14:06   ` Sibi S

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180529050523.GG2259@tuxbook-pro \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox