lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2305231510270.29760@cbobk.fhfr.pm>
Date:   Tue, 23 May 2023 15:11:11 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Doug Anderson <dianders@...omium.org>
cc:     Fei Shao <fshao@...omium.org>, Jeff LaBundy <jeff@...undy.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-mediatek <linux-mediatek@...ts.infradead.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Stephen Kitt <steve@....org>, devicetree@...r.kernel.org,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/2] Fix Goodix touchscreen power leakage for MT8186
 boards

On Fri, 19 May 2023, Doug Anderson wrote:

> > These changes are based on the series in [1], which modified the
> > i2c-hid-of-goodix driver and removed the workaround for a power leakage
> > issue, so the issue revisits on Mediatek MT8186 boards (Steelix).
> >
> > The root cause is that the touchscreen can be powered in different ways
> > depending on the hardware designs, and it's not as easy to come up with
> > a solution that is both simple and elegant for all the known designs.
> >
> > To address the issue, I ended up adding a new boolean property for the
> > driver so that we can control the power up/down sequence depending on
> > that.
> >
> > Adding a new property might not be the cleanest approach for this, but
> > at least the intention would be easy enough to understand, and it
> > introduces relatively small change to the code and fully preserves the
> > original control flow.
> > I hope this is something acceptable, and I'm open to any better
> > approaches.
> >
> > [1] https://lore.kernel.org/all/20230207024816.525938-1-dianders@chromium.org/
> >
> > Changes in v4:
> > - Minor coding style improvement
> >
> > Changes in v3:
> > - In power-down, only skip the GPIO but not the regulator calls if the
> >   flag is set
> >
> > Changes in v2:
> > - Use a more accurate property name and with "goodix," prefix.
> > - Do not change the regulator_enable logic during power-up.
> >
> > Fei Shao (2):
> >   dt-bindings: input: goodix: Add "goodix,no-reset-during-suspend"
> >     property
> >   HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend"
> >     property
> >
> >  .../bindings/input/goodix,gt7375p.yaml           |  9 +++++++++
> >  drivers/hid/i2c-hid/i2c-hid-of-goodix.c          | 16 +++++++++++++++-
> >  2 files changed, 24 insertions(+), 1 deletion(-)
> 
> Just double-checking if there is any work needed on this series. I
> think it's ready to land but I wanted to double-check.

I don't think I've been CCed on the dt-binding part (patch 1/2 I guess). 
Has it been Acked? If so, I will happily take it through hid.git, but 
please send it my way.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ