From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
<mika.westerberg@linux.intel.com>,
Jarkko Nikula <jarkko.nikula@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Linux I2C <linux-i2c@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>,
Jim Broadus <jbroadus@gmail.com>, <patches@opensource.cirrus.com>
Subject: Re: [PATCH v4 0/7] I2C IRQ Probe Improvements
Date: Tue, 11 Jun 2019 16:28:33 +0100 [thread overview]
Message-ID: <20190611152833.GR28362@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <CAO-hwJ+qSXwZ-5sAiZ55-r_PXp9pvnE1XEaE_v3SBnxzQQNH4g@mail.gmail.com>
On Tue, Jun 11, 2019 at 05:16:58PM +0200, Benjamin Tissoires wrote:
> On Tue, Jun 11, 2019 at 2:31 PM Charles Keepax
> <ckeepax@opensource.cirrus.com> wrote:
> >
> > This series attempts to align as much IRQ handling into the
> > probe path as possible. Note that I don't have a great setup
> > for testing these patches so they are mostly just build tested
> > and need careful review and testing before any of them are
> > merged.
> >
> > The series brings the ACPI path inline with the way the device
> > tree path handles the IRQ entirely at probe time. However,
> > it still leaves any IRQ specified through the board_info as
> > being handled at device time. In that case we need to cache
> > something from the board_info until probe time, which leaves
> > any alternative solution with something basically the same as
> > the current handling although perhaps caching more stuff.
>
> Hmm, I still haven't pinpointed the issue, but I wanted to give a test
> of the series and I have:
> [ 5.511806] i2c_hid i2c-DLL075B:01: HID over i2c has not been
> provided an Int IRQ
> [ 5.511825] i2c_hid: probe of i2c-DLL075B:01 failed with error -22
>
> So it seems that there is something wrong happening when fetching the
> IRQ and providing it to i2c-hid.
>
> That was on a Dell XPS 9360.
>
> Bisecting is starting.
>
I have a sneaking suspision, does this diff fix it:
diff --git a/drivers/i2c/i2c-core-acpi.c
b/drivers/i2c/i2c-core-acpi.c
index 57be6342ba508..a90b05a269c36 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -169,7 +169,7 @@ int i2c_acpi_get_irq(struct i2c_client *client)
acpi_dev_free_resource_list(&resource_list);
if (irq == -ENOENT)
- irq = acpi_dev_gpio_irq_get(adev, 0);
+ irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(&client->dev), 0);
return irq;
}
There was some earlier discussion about which device was suitable
for this call.
Thanks,
Charles
WARNING: multiple messages have this Message-ID (diff)
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
mika.westerberg@linux.intel.com,
Jarkko Nikula <jarkko.nikula@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Linux I2C <linux-i2c@vger.kernel.org>,
linux-acpi@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
Jim Broadus <jbroadus@gmail.com>,
patches@opensource.cirrus.com
Subject: Re: [PATCH v4 0/7] I2C IRQ Probe Improvements
Date: Tue, 11 Jun 2019 16:28:33 +0100 [thread overview]
Message-ID: <20190611152833.GR28362@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <CAO-hwJ+qSXwZ-5sAiZ55-r_PXp9pvnE1XEaE_v3SBnxzQQNH4g@mail.gmail.com>
On Tue, Jun 11, 2019 at 05:16:58PM +0200, Benjamin Tissoires wrote:
> On Tue, Jun 11, 2019 at 2:31 PM Charles Keepax
> <ckeepax@opensource.cirrus.com> wrote:
> >
> > This series attempts to align as much IRQ handling into the
> > probe path as possible. Note that I don't have a great setup
> > for testing these patches so they are mostly just build tested
> > and need careful review and testing before any of them are
> > merged.
> >
> > The series brings the ACPI path inline with the way the device
> > tree path handles the IRQ entirely at probe time. However,
> > it still leaves any IRQ specified through the board_info as
> > being handled at device time. In that case we need to cache
> > something from the board_info until probe time, which leaves
> > any alternative solution with something basically the same as
> > the current handling although perhaps caching more stuff.
>
> Hmm, I still haven't pinpointed the issue, but I wanted to give a test
> of the series and I have:
> [ 5.511806] i2c_hid i2c-DLL075B:01: HID over i2c has not been
> provided an Int IRQ
> [ 5.511825] i2c_hid: probe of i2c-DLL075B:01 failed with error -22
>
> So it seems that there is something wrong happening when fetching the
> IRQ and providing it to i2c-hid.
>
> That was on a Dell XPS 9360.
>
> Bisecting is starting.
>
I have a sneaking suspision, does this diff fix it:
diff --git a/drivers/i2c/i2c-core-acpi.c
b/drivers/i2c/i2c-core-acpi.c
index 57be6342ba508..a90b05a269c36 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -169,7 +169,7 @@ int i2c_acpi_get_irq(struct i2c_client *client)
acpi_dev_free_resource_list(&resource_list);
if (irq == -ENOENT)
- irq = acpi_dev_gpio_irq_get(adev, 0);
+ irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(&client->dev), 0);
return irq;
}
There was some earlier discussion about which device was suitable
for this call.
Thanks,
Charles
next prev parent reply other threads:[~2019-06-11 15:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 12:30 [PATCH v4 0/7] I2C IRQ Probe Improvements Charles Keepax
2019-06-11 12:30 ` Charles Keepax
2019-06-11 12:30 ` [PATCH v4 1/7] i2c: core: Allow whole core to use i2c_dev_irq_from_resources Charles Keepax
2019-06-11 12:30 ` Charles Keepax
2019-06-11 12:30 ` [PATCH v4 2/7] i2c: acpi: Use available IRQ helper functions Charles Keepax
2019-06-11 12:30 ` Charles Keepax
2019-06-11 12:47 ` Andy Shevchenko
2019-06-11 12:30 ` [PATCH v4 3/7] i2c: acpi: Factor out getting the IRQ from ACPI Charles Keepax
2019-06-11 12:30 ` Charles Keepax
2019-06-11 12:30 ` [PATCH v4 4/7] i2c: core: Make i2c_acpi_get_irq available to the rest of the I2C core Charles Keepax
2019-06-11 12:30 ` Charles Keepax
2019-06-12 7:20 ` Mika Westerberg
2019-06-12 15:11 ` Benjamin Tissoires
2019-06-12 15:27 ` Mika Westerberg
2019-06-13 8:48 ` Charles Keepax
2019-06-13 8:48 ` Charles Keepax
2019-06-13 9:32 ` Benjamin Tissoires
2019-06-13 15:06 ` Charles Keepax
2019-06-13 15:06 ` Charles Keepax
2019-06-11 12:30 ` [PATCH v4 5/7] i2c: core: Move ACPI IRQ handling to probe time Charles Keepax
2019-06-11 12:30 ` Charles Keepax
2019-06-11 12:31 ` [PATCH v4 6/7] i2c: core: Move ACPI gpio IRQ handling into i2c_acpi_get_irq Charles Keepax
2019-06-11 12:31 ` Charles Keepax
2019-06-11 12:31 ` [PATCH v4 7/7] i2c: core: Tidy up handling of init_irq Charles Keepax
2019-06-11 12:31 ` Charles Keepax
2019-06-11 12:51 ` [PATCH v4 0/7] I2C IRQ Probe Improvements Andy Shevchenko
2019-06-11 15:16 ` Benjamin Tissoires
2019-06-11 15:28 ` Charles Keepax [this message]
2019-06-11 15:28 ` Charles Keepax
2019-06-12 15:13 ` Benjamin Tissoires
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=20190611152833.GR28362@ediswmail.ad.cirrus.com \
--to=ckeepax@opensource.cirrus.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jarkko.nikula@linux.intel.com \
--cc=jbroadus@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=patches@opensource.cirrus.com \
--cc=wsa@the-dreams.de \
/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.