From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Doug Anderson <dianders@chromium.org>
Cc: "Jiri Kosina" <jkosina@suse.cz>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Hans de Goede" <hdegoede@redhat.com>,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
"Kai-Heng Feng" <kai.heng.feng@canonical.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Stephen Boyd" <swboyd@chromium.org>,
"Andrea Borgia" <andrea@borgia.bo.it>,
"Anson Huang" <Anson.Huang@nxp.com>,
"Bjorn Andersson" <bjorn.andersson@linaro.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Daniel Playfair Cal" <daniel.playfair.cal@gmail.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Guido Günther" <agx@sigxcpu.org>,
"Jiri Kosina" <jikos@kernel.org>, "Li Yang" <leoyang.li@nxp.com>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Max Krummenacher" <max.oss.09@gmail.com>,
"Michael Walle" <michael@walle.cc>,
"Pavel Balan" <admin@kryma.net>,
"Shawn Guo" <shawnguo@kernel.org>,
"Vinod Koul" <vkoul@kernel.org>, "Will Deacon" <will@kernel.org>,
"Xiaofei Tan" <tanxiaofei@huawei.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p
Date: Fri, 15 Jan 2021 15:58:20 +0100 [thread overview]
Message-ID: <f3add027-d732-0846-fa54-b3c51430b152@redhat.com> (raw)
In-Reply-To: <CAO-hwJ+Gz_yp_vn1prREvhcU=YqVatqd_Hp+95L5i2=bcwfhbA@mail.gmail.com>
Hi,
On Wed, Jan 13, 2021 at 8:35 PM Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>
> On Wed, Jan 13, 2021 at 5:05 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Wed, Jan 13, 2021 at 7:09 AM Benjamin Tissoires
> > <benjamin.tissoires@redhat.com> wrote:
> > >
> > > > I wanted to apply the series yesterday, but for these kinds of changes
> > > > I like giving it a spin on actual hardware. Turns out that my XPS-13
> > > > can not boot to v5.11-rc2, which makes testing the new branch slightly
> > > > more difficult.
> > > >
> > > > I'll give it a spin next week, but I think I should be able to land it for 5.12.
> > > >
> > > > Regarding the defconfig conflict, no worries, we can handle it with
> > > > Stephen and Linus.
> > > >
> > >
> > > After 2 full kernel bisects (I messed up the first because I am an
> > > idiot and inverted good and bad after the first reboot), I found my
> > > culprit, and I was able to test the series today.
> > >
> > > The series works fine regarding enumeration and removing of devices,
> > > but it prevents my system from being suspended. If I rmmod
> > > i2c-hid-acpi, suspend works fine, but if it is present, it immediately
> > > comes back, which makes me think that something must be wrong.
> > >
> > > I also just reverted the series and confirmed that suspend/resume now
> > > works, meaning that patch 1/4 needs to be checked.
> >
> > Can you give me any hints about what type of failure you're seeing?
> > Any logs? I don't have an ACPI system to test with...
>
> I don't have any logs, just that the system comes back up. There is a
> chance we are not powering the device down correctly, which triggers
> an IRQ and which puts the system back on.
>
> >
> > Is there any chance that some type of userspace / udev rule is getting
> > tripped up by the driver being renamed? We ran into something like
> > this recently on Chrome OS where we had a tool that was hardcoded to
> > look for "i2c-hid" and needed to be adapted to account for the new
> > driver name. Often userspace tweaks with wakeup rules based on driver
> > name...
>
> I don't think there is anything like that on a regular desktop.
>
> >
> > I'll go stare at the code now and see if anything jumps out.
> >
>
> Thanks, but don't spend too much time on it, unless something really
> jumps out. I'll debug that tomorrow. It's much easier with an actual
> device than by just looking at the code.
>
Well, that's weird. Now suspend resume works reliably even with your
series. It could just have been that the lid sensor was too close to a
magnet or something like that. Though while testing the old version of
i2c-hid, it was working... Such a mystery :)
Anyway, while trying to dig up that now-non-issue, I got the following patch
that you likely want to squash into 1/4:
---
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index 0f86060f01b4..dd6d9f74e7e7 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -31,7 +31,6 @@
struct i2c_hid_acpi {
struct i2chid_ops ops;
struct i2c_client *client;
- bool power_fixed;
};
static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
@@ -75,25 +74,6 @@ static int i2c_hid_acpi_get_descriptor(struct i2c_client *client)
return hid_descriptor_address;
}
-static int i2c_hid_acpi_power_up(struct i2chid_ops *ops)
-{
- struct i2c_hid_acpi *ihid_of =
- container_of(ops, struct i2c_hid_acpi, ops);
- struct device *dev = &ihid_of->client->dev;
- struct acpi_device *adev;
-
- /* Only need to call acpi_device_fix_up_power() the first time */
- if (ihid_of->power_fixed)
- return 0;
- ihid_of->power_fixed = true;
-
- adev = ACPI_COMPANION(dev);
- if (adev)
- acpi_device_fix_up_power(adev);
-
- return 0;
-}
-
static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
{
struct i2c_hid_acpi *ihid_of =
@@ -107,6 +87,7 @@ static int i2c_hid_acpi_probe(struct i2c_client *client,
{
struct device *dev = &client->dev;
struct i2c_hid_acpi *ihid_acpi;
+ struct acpi_device *adev;
u16 hid_descriptor_address;
int ret;
@@ -115,7 +96,6 @@ static int i2c_hid_acpi_probe(struct i2c_client *client,
return -ENOMEM;
ihid_acpi->client = client;
- ihid_acpi->ops.power_up = i2c_hid_acpi_power_up;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ret = i2c_hid_acpi_get_descriptor(client);
@@ -123,6 +103,10 @@ static int i2c_hid_acpi_probe(struct i2c_client *client,
return ret;
hid_descriptor_address = ret;
+ adev = ACPI_COMPANION(dev);
+ if (adev)
+ acpi_device_fix_up_power(adev);
+
if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
device_set_wakeup_capable(dev, true);
device_set_wakeup_enable(dev, false);
---
This allows to keep the powering ordering of the old i2c-hid module
(power up before setting device wakeup capable), and simplify the
not so obvious power_fixed field of struct i2c_hid_acpi.
(I can also send it as a followup on the series if you prefer).
Cheers,
Benjamin
next prev parent reply other threads:[~2021-01-15 15:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 22:24 [PATCH v8 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p Douglas Anderson
2020-12-11 22:24 ` [PATCH v8 3/4] dt-bindings: input: HID: i2c-hid: Introduce bindings for the Goodix GT7375P Douglas Anderson
2021-01-06 1:35 ` [PATCH v8 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p Doug Anderson
2021-01-08 17:52 ` Benjamin Tissoires
2021-01-13 15:08 ` Benjamin Tissoires
2021-01-13 15:58 ` Doug Anderson
2021-01-13 19:35 ` Benjamin Tissoires
2021-01-15 14:58 ` Benjamin Tissoires [this message]
2021-01-15 17:11 ` Doug Anderson
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=f3add027-d732-0846-fa54-b3c51430b152@redhat.com \
--to=benjamin.tissoires@redhat.com \
--cc=Anson.Huang@nxp.com \
--cc=admin@kryma.net \
--cc=agx@sigxcpu.org \
--cc=andrea@borgia.bo.it \
--cc=bjorn.andersson@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=daniel.playfair.cal@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=jikos@kernel.org \
--cc=jkosina@suse.cz \
--cc=kai.heng.feng@canonical.com \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=max.oss.09@gmail.com \
--cc=michael@walle.cc \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
--cc=swboyd@chromium.org \
--cc=tanxiaofei@huawei.com \
--cc=vkoul@kernel.org \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).