Devicetree
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: Linu Cherian <lcherian@marvell.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, sgoutham@marvell.com,
	gcherian@marvell.com, Anil Kumar Reddy <areddy3@marvell.com>,
	Tanmay Jagdale <tanmay@marvell.com>,
	mike.leach@linaro.org, leo.yan@linaro.org
Subject: Re: [PATCH v7 5/7] coresight: tmc: Add support for reading crash data
Date: Fri, 12 Apr 2024 11:05:31 +0100	[thread overview]
Message-ID: <d707430f-00ee-4427-a9e4-6e42bc5b6aa9@arm.com> (raw)
In-Reply-To: <20240307033625.325058-6-lcherian@marvell.com>



On 07/03/2024 03:36, Linu Cherian wrote:
> * Introduce a new mode CS_MODE_READ_CRASHDATA for reading trace
>   captured in previous crash/watchdog reset.
> 
> * Add special device files for reading ETR/ETF crash data.
> 
> * User can read the crash data as below
> 
>   For example, for reading crash data from tmc_etf sink
> 
>   #dd if=/dev/crash_tmc_etfXX of=~/cstrace.bin
> 
> Signed-off-by: Anil Kumar Reddy <areddy3@marvell.com>
> Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
> Signed-off-by: Linu Cherian <lcherian@marvell.com>
> ---
> Changelog from v6:
> * Removed read_prevboot flag in sysfs
> * Added special device files for reading crashdata 
> * Renamed CS mode READ_PREVBOOT to READ_CRASHDATA 
> * Setting the READ_CRASHDATA mode is done as part of file open.
> 

[...]

> @@ -619,6 +740,19 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
>  		coresight_unregister(drvdata->csdev);
>  	else
>  		pm_runtime_put(&adev->dev);
> +
> +	if (!is_tmc_reserved_region_valid(dev))
> +		goto out;
> +
> +	drvdata->crashdev.name =
> +		devm_kasprintf(dev, GFP_KERNEL, "%s_%s", "crash", desc.name);
> +	drvdata->crashdev.minor = MISC_DYNAMIC_MINOR;
> +	drvdata->crashdev.fops = &tmc_crashdata_fops;
> +	ret = misc_register(&drvdata->crashdev);
> +	if (ret)
> +		pr_err("%s: Failed to setup dev interface for crashdata\n",
> +		       desc.name);
> +

Is this all optional after the is_tmc_reserved_region_valid()? Skipping
to out seems to be more like an error condition, but in this case it's
not? Having it like this makes it more difficult to add extra steps to
the probe function. You could move it to a function and flip the
condition which would be clearer:

   if (is_tmc_reserved_region_valid(dev))
      register_crash_dev_interface(drvdata);


>  out:
>  	return ret;
>  }

[...]

>  
> +static int tmc_etr_setup_crashdata_buf(struct tmc_drvdata *drvdata)
> +{
> +	int rc = 0;
> +	u64 trace_addr;
> +	struct etr_buf *etr_buf;
> +	struct etr_flat_buf *resrv_buf;
> +	struct tmc_crash_metadata *mdata;
> +	struct device *dev = &drvdata->csdev->dev;
> +
> +	mdata = drvdata->crash_mdata.vaddr;
> +
> +	etr_buf = kzalloc(sizeof(*etr_buf), GFP_ATOMIC);
> +	if (!etr_buf) {
> +		rc = -ENOMEM;
> +		goto out;
> +	}
> +	etr_buf->size = drvdata->crash_tbuf.size;
> +
> +	resrv_buf = kzalloc(sizeof(*resrv_buf), GFP_ATOMIC);
> +	if (!resrv_buf) {
> +		rc = -ENOMEM;
> +		goto rmem_err;
> +	}
> +
> +	/*
> +	 * Buffer address given by metadata for retrieval of trace data
> +	 * from previous boot is expected to be same as the reserved
> +	 * trace buffer memory region provided through DTS
> +	 */
> +	if (is_tmc_reserved_region_valid(dev->parent)
> +	    && (drvdata->crash_tbuf.paddr == mdata->trc_paddr))
> +		resrv_buf->vaddr = drvdata->crash_tbuf.vaddr;
> +	else {
> +		dev_dbg(dev, "Trace buffer address of previous boot invalid\n");
> +		rc = -EINVAL;
> +		goto map_err;
> +	}
> +
> +	resrv_buf->size = etr_buf->size;
> +	resrv_buf->dev = &drvdata->csdev->dev;
> +	etr_buf->hwaddr = trace_addr;

trace_addr is uninitialised at this point. If you pull the latest
coresight branch we enabled some extra compiler warnings which catch this.

I assume it's supposed to be mdata->trc_paddr?

Is there some kind of test that could be added that could have caught
this? Maybe skip the full reboot flow but just enable the feature and
see if we can read from the buffer.

Or even just toggling the mode on and off via sysfs. We're running the
Perf and kselftests on Juno internally so I can add a reserved region to
the Juno DT and make sure this stays working.



  reply	other threads:[~2024-04-12 10:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07  3:36 [PATCH v7 0/7] Coresight for Kernel panic and watchdog reset Linu Cherian
2024-03-07  3:36 ` [PATCH v7 1/7] dt-bindings: arm: coresight-tmc: Add "memory-region" property Linu Cherian
2024-03-07  3:36 ` [PATCH v7 2/7] coresight: tmc-etr: Add support to use reserved trace memory Linu Cherian
2024-04-12  9:57   ` James Clark
2024-04-14 10:09     ` [EXTERNAL] " Linu Cherian
2024-03-07  3:36 ` [PATCH v7 3/7] coresight: core: Add provision for panic callbacks Linu Cherian
2024-03-07  3:36 ` [PATCH v7 4/7] coresight: tmc: Enable panic sync handling Linu Cherian
2024-03-07  3:36 ` [PATCH v7 5/7] coresight: tmc: Add support for reading crash data Linu Cherian
2024-04-12 10:05   ` James Clark [this message]
2024-04-15  4:01     ` [EXTERNAL] " Linu Cherian
2024-04-15  9:28       ` James Clark
2024-04-21  2:49         ` Linu Cherian
2024-04-22  8:18           ` James Clark
2024-04-25  2:07             ` [EXTERNAL] " Linu Cherian
2024-04-25  9:32               ` James Clark
2024-03-07  3:36 ` [PATCH v7 6/7] coresight: tmc: Stop trace capture on FlIn Linu Cherian
2024-03-07  3:36 ` [PATCH v7 7/7] coresight: config: Add preloaded configuration Linu Cherian
2024-04-09  0:10 ` [PATCH v7 0/7] Coresight for Kernel panic and watchdog reset Linu Cherian
2024-04-09  9:28   ` James Clark

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=d707430f-00ee-4427-a9e4-6e42bc5b6aa9@arm.com \
    --to=james.clark@arm.com \
    --cc=areddy3@marvell.com \
    --cc=conor+dt@kernel.org \
    --cc=coresight@lists.linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gcherian@marvell.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lcherian@marvell.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=sgoutham@marvell.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tanmay@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox