All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Jeff LaBundy <jeff@labundy.com>
Cc: Fei Shao <fshao@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 2/2] HID: i2c-hid: goodix: Add support for powered-in-suspend property
Date: Mon, 24 Apr 2023 11:16:10 -0700	[thread overview]
Message-ID: <CAD=FV=XnrSskS=0UKRGGPBxSnPYQtUkJeoBm44bDnwKVBHJLyA@mail.gmail.com> (raw)
In-Reply-To: <ZEX5tc2LSZoVswc2@nixie71>

Hi,

On Sun, Apr 23, 2023 at 8:38 PM Jeff LaBundy <jeff@labundy.com> wrote:
>
> > @@ -37,13 +38,34 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops)
> >               container_of(ops, struct i2c_hid_of_goodix, ops);
> >       int ret;
> >
> > -     ret = regulator_enable(ihid_goodix->vdd);
> > -     if (ret)
> > -             return ret;
> > -
> > -     ret = regulator_enable(ihid_goodix->vddio);
> > -     if (ret)
> > -             return ret;
> > +     /*
> > +      * This is to ensure that the reset GPIO will be asserted and the
> > +      * regulators will be enabled for all cases.
> > +      */
> > +     if (ihid_goodix->powered_in_suspend) {
> > +             /*
> > +              * This is not mandatory, but we assert reset here (instead of
> > +              * in power-down) to ensure that the device will have a clean
> > +              * state later on just like the normal scenarios would have.
> > +              *
> > +              * Also, since the regulators were not disabled in power-down,
> > +              * we don't need to enable them here.
> > +              */
> > +             gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
> > +     } else {
> > +             /*
> > +              * In this case, the reset is already asserted (either in
> > +              * probe or power-down).
> > +              * All we need is to enable the regulators.
> > +              */
> > +             ret = regulator_enable(ihid_goodix->vdd);
> > +             if (ret)
> > +                     return ret;
> > +
> > +             ret = regulator_enable(ihid_goodix->vddio);
> > +             if (ret)
> > +                     return ret;
> > +     }
>
> Please let me know in case I have misunderstood, but I don't see a need
> to change the regulator_enable/disable() logic if this property is set.
> If the regulators are truly always-on, the regulator core already knows
> what to do and we should not duplicate that logic here.
>
> Based on the alleged silicon erratum discussed in patch [1/2], it seems
> we only want to control the behavior of the reset GPIO. Therefore, only
> the calls to gpiod_set_value_cansleep() should be affected and the name
> of the property updated to reflect what it's actually doing.

This would be OK w/ me.

WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org>
To: Jeff LaBundy <jeff@labundy.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Stephen Kitt <steve@sk2.org>, Jiri Kosina <jikos@kernel.org>,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	linux-mediatek <linux-mediatek@lists.infradead.org>,
	linux-input@vger.kernel.org, Matthias Kaehlcke <mka@chromium.org>
Subject: Re: [PATCH 2/2] HID: i2c-hid: goodix: Add support for powered-in-suspend property
Date: Mon, 24 Apr 2023 11:16:10 -0700	[thread overview]
Message-ID: <CAD=FV=XnrSskS=0UKRGGPBxSnPYQtUkJeoBm44bDnwKVBHJLyA@mail.gmail.com> (raw)
In-Reply-To: <ZEX5tc2LSZoVswc2@nixie71>

Hi,

On Sun, Apr 23, 2023 at 8:38 PM Jeff LaBundy <jeff@labundy.com> wrote:
>
> > @@ -37,13 +38,34 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops)
> >               container_of(ops, struct i2c_hid_of_goodix, ops);
> >       int ret;
> >
> > -     ret = regulator_enable(ihid_goodix->vdd);
> > -     if (ret)
> > -             return ret;
> > -
> > -     ret = regulator_enable(ihid_goodix->vddio);
> > -     if (ret)
> > -             return ret;
> > +     /*
> > +      * This is to ensure that the reset GPIO will be asserted and the
> > +      * regulators will be enabled for all cases.
> > +      */
> > +     if (ihid_goodix->powered_in_suspend) {
> > +             /*
> > +              * This is not mandatory, but we assert reset here (instead of
> > +              * in power-down) to ensure that the device will have a clean
> > +              * state later on just like the normal scenarios would have.
> > +              *
> > +              * Also, since the regulators were not disabled in power-down,
> > +              * we don't need to enable them here.
> > +              */
> > +             gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
> > +     } else {
> > +             /*
> > +              * In this case, the reset is already asserted (either in
> > +              * probe or power-down).
> > +              * All we need is to enable the regulators.
> > +              */
> > +             ret = regulator_enable(ihid_goodix->vdd);
> > +             if (ret)
> > +                     return ret;
> > +
> > +             ret = regulator_enable(ihid_goodix->vddio);
> > +             if (ret)
> > +                     return ret;
> > +     }
>
> Please let me know in case I have misunderstood, but I don't see a need
> to change the regulator_enable/disable() logic if this property is set.
> If the regulators are truly always-on, the regulator core already knows
> what to do and we should not duplicate that logic here.
>
> Based on the alleged silicon erratum discussed in patch [1/2], it seems
> we only want to control the behavior of the reset GPIO. Therefore, only
> the calls to gpiod_set_value_cansleep() should be affected and the name
> of the property updated to reflect what it's actually doing.

This would be OK w/ me.


  reply	other threads:[~2023-04-24 18:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 12:49 [PATCH 0/2] Fix Goodix touchscreen power leakage for MT8186 boards Fei Shao
2023-04-18 12:49 ` Fei Shao
2023-04-18 12:49 ` [PATCH 1/2] dt-bindings: input: goodix: Add powered-in-suspend property Fei Shao
2023-04-18 12:49   ` Fei Shao
2023-04-18 14:18   ` Doug Anderson
2023-04-18 18:02   ` Matthias Brugger
2023-04-19  0:20   ` Jeff LaBundy
2023-04-19 10:44     ` Fei Shao
2023-04-19 14:38       ` Doug Anderson
2023-04-19 15:18         ` Jeff LaBundy
2023-04-19 15:18           ` Jeff LaBundy
2023-04-19 15:41           ` Doug Anderson
2023-04-19 15:41             ` Doug Anderson
2023-04-20  8:13             ` Fei Shao
2023-04-24  3:31               ` Jeff LaBundy
2023-04-24 18:14                 ` Doug Anderson
2023-04-24 18:14                   ` Doug Anderson
2023-04-25  8:34                   ` Fei Shao
2023-04-18 12:49 ` [PATCH 2/2] HID: i2c-hid: goodix: Add support for " Fei Shao
2023-04-18 12:49   ` Fei Shao
2023-04-18 14:22   ` Doug Anderson
2023-04-24  3:38   ` Jeff LaBundy
2023-04-24 18:16     ` Doug Anderson [this message]
2023-04-24 18:16       ` Doug Anderson
2023-04-25  8:36       ` 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='CAD=FV=XnrSskS=0UKRGGPBxSnPYQtUkJeoBm44bDnwKVBHJLyA@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=fshao@chromium.org \
    --cc=jeff@labundy.com \
    --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.