public inbox for chrome-platform@lists.linux.dev
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Gwendal Grignou <gwendal@chromium.org>
Cc: tzungbi@kernel.org, linux-iio@vger.kernel.org,
	chrome-platform@lists.linux.dev, devicetree@vger.kernel.org
Subject: Re: [PATCH v3] iio: cros_ec_sensors: Flush when changing the FIFO timeout
Date: Sat, 12 Apr 2025 11:42:56 +0100	[thread overview]
Message-ID: <20250412114256.41602d67@jic23-huawei> (raw)
In-Reply-To: <20250408155619.2169189-1-gwendal@chromium.org>

On Tue,  8 Apr 2025 08:56:19 -0700
Gwendal Grignou <gwendal@chromium.org> wrote:

> |hwfifo_timeout| is used by the EC firmware only when new samples are
> available.
> When the timeout changes, espcially when the new timeout is shorter than
> the current one, send the samples waiting in the FIFO to the host.
> Inline the call to transmit |hwfifo_timeout| value to the firmware.
> 
> Now flush when a sensor is suspended (ODR set to 0) as well.
> 
> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Firstly.  Don't send a new version in reply to an old one.
In general the reasons for this are:
1 - it can get very confusing if a thread gets deeply nested.
2 - at least some well known kernel folk start at their most recent emails
    and work backwards when looking for what to review.  They will probably
    never get to your thread!

There may be other parts of the kernel that prefer this style, but most
do not and I've never had anyone 'ask' for it (as opposed to not object).

Various minor comments inline.

Thanks,
Jonathan

> ---
> Changes in v3:
> - Fix error detection when setting the sensor frequency
> 
> Changes in v2:
> - Fix sysfs attribute in commit message
> - Indicated the function to send the content of the attribute is now
>   inline.
> - Improve error detection when setting the sensor frequency and flusing
>   the FIFO.
>  .../cros_ec_sensors/cros_ec_sensors_core.c    | 50 ++++++++++++-------
>  1 file changed, 33 insertions(+), 17 deletions(-)
> 
> 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 b1abd6e16c4ba..67ffe88df7b23 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
> @@ -103,22 +103,6 @@ static void get_default_min_max_freq(enum motionsensor_type type,
>  	}
>  }
>  
> -static int cros_ec_sensor_set_ec_rate(struct cros_ec_sensors_core_state *st,
> -				      int rate)
> -{
> -	int ret;
> -
> -	if (rate > U16_MAX)
> -		rate = U16_MAX;
> -
> -	mutex_lock(&st->cmd_lock);
> -	st->param.cmd = MOTIONSENSE_CMD_EC_RATE;
> -	st->param.ec_rate.data = rate;
> -	ret = cros_ec_motion_send_host_cmd(st, 0);
> -	mutex_unlock(&st->cmd_lock);
> -	return ret;
> -}
> -
>  static ssize_t cros_ec_sensor_set_report_latency(struct device *dev,
>  						 struct device_attribute *attr,
>  						 const char *buf, size_t len)
> @@ -134,7 +118,25 @@ static ssize_t cros_ec_sensor_set_report_latency(struct device *dev,
>  
>  	/* EC rate is in ms. */
>  	latency = integer * 1000 + fract / 1000;
> -	ret = cros_ec_sensor_set_ec_rate(st, latency);
> +
> +	mutex_lock(&st->cmd_lock);
Maybe use cleanup.h and
	guard(mutex)(&st->cmd_lock);
mostly because it simplifies code and...
> +	st->param.cmd = MOTIONSENSE_CMD_EC_RATE;
> +	st->param.ec_rate.data = min(U16_MAX, latency);
> +	ret = cros_ec_motion_send_host_cmd(st, 0);
> +	mutex_unlock(&st->cmd_lock);

I'm not sure why you unlock briefly here?

> +	if (ret < 0)
> +		return ret;
> +
> +	/*
> +	 * Flush samples currently in the FIFO, especially when the new latency
> +	 * is shorter than the old one: new timeout value is only considered when
> +	 * there is a new sample available. It can take a while for a slow
> +	 * sensor.
> +	 */
> +	mutex_lock(&st->cmd_lock);
> +	st->param.cmd = MOTIONSENSE_CMD_FIFO_FLUSH;
> +	ret = cros_ec_motion_send_host_cmd(st, 0);
> +	mutex_unlock(&st->cmd_lock);
>  	if (ret < 0)
>  		return ret;
>  
> @@ -764,6 +766,8 @@ EXPORT_SYMBOL_GPL(cros_ec_sensors_capture);
>   * @mask:	specifies which values to be requested
>   *
>   * Return:	the type of value returned by the device
> + *
> + * cmd_lock mutex held.

Maybe true, but has that changed in a fashion that means this should
be in this fix patch rather than a follow up improving documentation?

>   */
>  int cros_ec_sensors_core_read(struct cros_ec_sensors_core_state *st,
>  			  struct iio_chan_spec const *chan,
> @@ -836,6 +840,8 @@ EXPORT_SYMBOL_GPL(cros_ec_sensors_core_read_avail);
>   * @mask:	specifies which values to write
>   *
>   * Return:	the type of value returned by the device
> + *
> + * cmd_lock mutex held.
As above.

>   */
>  int cros_ec_sensors_core_write(struct cros_ec_sensors_core_state *st,
>  			       struct iio_chan_spec const *chan,
> @@ -853,6 +859,16 @@ int cros_ec_sensors_core_write(struct cros_ec_sensors_core_state *st,
>  		st->param.sensor_odr.roundup = 1;
>  
>  		ret = cros_ec_motion_send_host_cmd(st, 0);
I'd rather see
		if (ret)
			break;
given local style.

Ideal would actually be to make this whole function do direct returns on error
as that is easier to follow in cases like this where there is no cleanup.
However that change doesn't belong in a fix. Something for another day!

> +
> +		/* Flush the FIFO in case we are stopping a sensor.
Comment syntax slightly wrong.

		/*
		 * Flush the FIFO

> +		 * If the FIFO has just been emptied, pending samples will be
> +		 * stuck until new samples are available. It will not happen
> +		 * when all the sensors are stopped.
> +		 */
> +		if (ret == 0 && frequency == 0) {

With the break above, only need to check frequency here.

> +			st->param.cmd = MOTIONSENSE_CMD_FIFO_FLUSH;
> +			ret = cros_ec_motion_send_host_cmd(st, 0);
> +		}
>  		break;
>  	default:
>  		ret = -EINVAL;


  parent reply	other threads:[~2025-04-12 10:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 16:48 [PATCH] drivers: iio: cros_ec_sensors: Flush changing the FIFO timeout Gwendal Grignou
2025-04-02  9:29 ` Tzung-Bi Shih
2025-04-08  5:50   ` Gwendal Grignou
2025-04-08  5:54     ` [PATCH v2] iio: cros_ec_sensors: Flush when " Gwendal Grignou
2025-04-08  7:59       ` Tzung-Bi Shih
2025-04-08 15:56         ` Gwendal Grignou
2025-04-08 15:56     ` [PATCH v3] " Gwendal Grignou
2025-04-09  1:19       ` Tzung-Bi Shih
2025-04-12 10:42       ` Jonathan Cameron [this message]
2025-04-23 22:05         ` 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=20250412114256.41602d67@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=devicetree@vger.kernel.org \
    --cc=gwendal@chromium.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