| Message ID | 20190611123101.25264-1-ckeepax@opensource.cirrus.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | I2C IRQ Probe Improvements | expand |
On Tue, Jun 11, 2019 at 01:30:54PM +0100, Charles Keepax 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. Thank you! This one looks good. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Thanks, > Charles > > See previous discussions: > - https://lkml.org/lkml/2019/2/15/989 > - https://www.spinics.net/lists/linux-i2c/msg39541.html > > Charles Keepax (7): > i2c: core: Allow whole core to use i2c_dev_irq_from_resources > i2c: acpi: Use available IRQ helper functions > i2c: acpi: Factor out getting the IRQ from ACPI > i2c: core: Make i2c_acpi_get_irq available to the rest of the I2C core > i2c: core: Move ACPI IRQ handling to probe time > i2c: core: Move ACPI gpio IRQ handling into i2c_acpi_get_irq > i2c: core: Tidy up handling of init_irq > > drivers/i2c/i2c-core-acpi.c | 58 ++++++++++++++++++++++++++++++++------------- > drivers/i2c/i2c-core-base.c | 11 +++++---- > drivers/i2c/i2c-core.h | 9 +++++++ > 3 files changed, 56 insertions(+), 22 deletions(-) > > -- > 2.11.0 >
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. Cheers, Benjamin > > Thanks, > Charles > > See previous discussions: > - https://lkml.org/lkml/2019/2/15/989 > - https://www.spinics.net/lists/linux-i2c/msg39541.html > > Charles Keepax (7): > i2c: core: Allow whole core to use i2c_dev_irq_from_resources > i2c: acpi: Use available IRQ helper functions > i2c: acpi: Factor out getting the IRQ from ACPI > i2c: core: Make i2c_acpi_get_irq available to the rest of the I2C core > i2c: core: Move ACPI IRQ handling to probe time > i2c: core: Move ACPI gpio IRQ handling into i2c_acpi_get_irq > i2c: core: Tidy up handling of init_irq > > drivers/i2c/i2c-core-acpi.c | 58 ++++++++++++++++++++++++++++++++------------- > drivers/i2c/i2c-core-base.c | 11 +++++---- > drivers/i2c/i2c-core.h | 9 +++++++ > 3 files changed, 56 insertions(+), 22 deletions(-) > > -- > 2.11.0 >
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
On Tue, Jun 11, 2019 at 5:29 PM Charles Keepax <ckeepax@opensource.cirrus.com> wrote: > > 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; > } > Unfortunately, this doesn't solve the issue. The problem is either in 4/7 or 5/7 (4/7 doesn't boot AFAICT). (chasing multiple rabbits at the same time, so hard to get to the bottom of it) Cheers, Benjamin > There was some earlier discussion about which device was suitable > for this call. > > Thanks, > Charles