Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Gwendal Grignou <gwendal@chromium.org>
Cc: <jic23@kernel.org>, <tzungbi@kernel.org>, <linux-iio@vger.kernel.org>
Subject: Re: [PATCH v2] iio: cros_ec: Trace EC sensors command
Date: Fri, 17 Jan 2025 15:47:05 +0000	[thread overview]
Message-ID: <20250117154705.00006d32@huawei.com> (raw)
In-Reply-To: <20250117042059.778637-1-gwendal@chromium.org>

On Thu, 16 Jan 2025 20:20:59 -0800
Gwendal Grignou <gwendal@chromium.org> wrote:

> Add tracing for EC_CMD_MOTION_SENSE_CMD command:
> - decode the name of the subcommand
> - provide internal information for the most common sub-commands:
>   setting range, frequency, EC probing frequency, ...
> - display return status.
> 
> When enabled, the tracing output is similar to:
> /sys/kernel/debug/tracing # echo 1 > events/cros_ec/enable ; echo 1 > tracing_on ; cat trace_pipe | grep MOTIONSENSE_CMD_SENSOR_ODR
>  SensorDeviceImp-814     [003] .....   686.176782: cros_ec_motion_host_cmd: MOTIONSENSE_CMD_SENSOR_ODR, id: 1, data: 200000, result: 4, return: 12500
> 
> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
What this is missing is why?

I'm not against adding tracepoints in drivers, but some statement of
the usecase etc would be helpful. If it's debug only that makes
for different requirements than some tool is going to connect to
this stream.

Jonathan


> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index 9fc71a73caa12..075196ca804a1 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -23,6 +23,8 @@
>  #include <linux/platform_data/cros_ec_sensorhub.h>
>  #include <linux/platform_device.h>
>  
> +#include "cros_ec_sensors_trace.h"
> +
>  /*
>   * Hard coded to the first device to support sensor fifo.  The EC has a 2048
>   * byte fifo and will trigger an interrupt when fifo is 2/3 full.
> @@ -423,6 +425,7 @@ int cros_ec_motion_send_host_cmd(struct cros_ec_sensors_core_state *state,
>  	memcpy(state->msg->data, &state->param, sizeof(state->param));
>  
>  	ret = cros_ec_cmd_xfer_status(state->ec, state->msg);
> +	trace_cros_ec_motion_host_cmd(&state->param, (void *)state->msg->data, ret);

Can we cast to the right type rather than a void *?

>  	if (ret < 0)
>  		return ret;
>  



  reply	other threads:[~2025-01-17 15:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-17  4:20 [PATCH v2] iio: cros_ec: Trace EC sensors command Gwendal Grignou
2025-01-17 15:47 ` Jonathan Cameron [this message]
2025-01-17 23:02   ` Gwendal Grignou

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=20250117154705.00006d32@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=gwendal@chromium.org \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=tzungbi@kernel.org \
    /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