All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff LaBundy <jeff@labundy.com>
To: Fei Shao <fshao@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek <linux-mediatek@lists.infradead.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jiri Kosina <jikos@kernel.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Stephen Kitt <steve@sk2.org>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend" property
Date: Wed, 26 Apr 2023 20:07:57 -0500	[thread overview]
Message-ID: <ZEnK7bQkl+fkcHkb@nixie71> (raw)
In-Reply-To: <20230426144423.2820826-3-fshao@chromium.org>

Hi Fei,

On Wed, Apr 26, 2023 at 10:44:22PM +0800, Fei Shao wrote:
> In the beginning, commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the
> reset line to true state of the regulator") introduced a change to tie
> the reset line of the Goodix touchscreen to the state of the regulator
> to fix a power leakage issue in suspend.
> 
> After some time, the change was deemed unnecessary and was reverted in
> commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to
> the regulator") due to difficulties in managing regulator notifiers for
> designs like Evoker, which provides a second power rail to touchscreen.
> 
> However, the revert caused a power regression on another Chromebook
> device Steelix in the field, which has a dedicated always-on regulator
> for touchscreen and was covered by the workaround in the first commit.
> 
> To address both cases, this patch adds the support for the new
> "goodix,no-reset-during-suspend" property in the driver:
> - When set to true, the driver does not assert the reset GPIO during
>   power-down.
>   Instead, the GPIO will be asserted during power-up to ensure the
>   touchscreen always has a clean start and consistent behavior after
>   resuming.
>   This is for designs with a dedicated always-on regulator.
> - When set to false or unset, the driver uses the original control flow
>   and asserts GPIO and disables regulators normally.
>   This is for the two-regulator and shared-regulator designs.
> 
> Signed-off-by: Fei Shao <fshao@chromium.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>

Great work; one tiny nit below. If you do not agree with it or have found
precedent that suggests it is OK, feel free to ignore it. Either way:

Reviewed-by: Jeff LaBundy <jeff@labundy.com>

> 
> ---
> 
> Changes in v3:
> - In power-down, only skip the GPIO but not the regulator calls if the
>   flag is set
> 
> Changes in v2:
> - Do not change the regulator_enable logic during power-up.
> 
>  drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
> index 0060e3dcd775..3ed365b50432 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
> @@ -28,6 +28,7 @@ struct i2c_hid_of_goodix {
>  	struct regulator *vdd;
>  	struct regulator *vddio;
>  	struct gpio_desc *reset_gpio;
> +	bool no_reset_during_suspend;
>  	const struct goodix_i2c_hid_timing_data *timings;
>  };
>  
> @@ -37,6 +38,14 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops)
>  		container_of(ops, struct i2c_hid_of_goodix, ops);
>  	int ret;
>  
> +	if (ihid_goodix->no_reset_during_suspend) {
> +		/*
> +		 * We assert reset GPIO here (instead of during power-down) to
> +		 * ensure the device will have a clean state after powering up,
> +		 * just like the normal scenarios will have.
> +		 */
> +		gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
> +	}

I don't think curly braces are technically required here, as there is only
one statement within the conditional despite the comments making it appear
otherwise. Maybe this would work too:

	/* ... */
	if (...)
		gpiod_set_value_cansleep(...);

Again however, I do not feel strongly about this.

>  	ret = regulator_enable(ihid_goodix->vdd);
>  	if (ret)
>  		return ret;
> @@ -60,7 +69,9 @@ static void goodix_i2c_hid_power_down(struct i2chid_ops *ops)
>  	struct i2c_hid_of_goodix *ihid_goodix =
>  		container_of(ops, struct i2c_hid_of_goodix, ops);
>  
> -	gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
> +	if (!ihid_goodix->no_reset_during_suspend)
> +		gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
> +
>  	regulator_disable(ihid_goodix->vddio);
>  	regulator_disable(ihid_goodix->vdd);
>  }
> @@ -91,6 +102,9 @@ static int i2c_hid_of_goodix_probe(struct i2c_client *client)
>  	if (IS_ERR(ihid_goodix->vddio))
>  		return PTR_ERR(ihid_goodix->vddio);
>  
> +	ihid_goodix->no_reset_during_suspend =
> +		of_property_read_bool(client->dev.of_node, "goodix,no-reset-during-suspend");
> +
>  	ihid_goodix->timings = device_get_match_data(&client->dev);
>  
>  	return i2c_hid_core_probe(client, &ihid_goodix->ops, 0x0001, 0);
> -- 
> 2.40.1.495.gc816e09b53d-goog
> 

Kind regards,
Jeff LaBundy

  parent reply	other threads:[~2023-04-27  1:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26 14:44 [PATCH v3 0/2] Fix Goodix touchscreen power leakage for MT8186 boards Fei Shao
2023-04-26 14:44 ` Fei Shao
2023-04-26 14:44 ` [PATCH v3 1/2] dt-bindings: input: goodix: Add "goodix,no-reset-during-suspend" property Fei Shao
2023-04-26 14:44   ` Fei Shao
2023-04-27  1:01   ` Jeff LaBundy
2023-04-26 14:44 ` [PATCH v3 2/2] HID: i2c-hid: goodix: Add support for " Fei Shao
2023-04-26 14:44   ` Fei Shao
2023-04-26 16:39   ` Doug Anderson
2023-04-27  1:07   ` Jeff LaBundy [this message]
2023-04-27  3:45     ` Fei Shao

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=ZEnK7bQkl+fkcHkb@nixie71 \
    --to=jeff@labundy.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=fshao@chromium.org \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=mka@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=steve@sk2.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.