linux-kernel - Re: [PATCH v4 0/7] I2C IRQ Probe Improvements

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAO-hwJKvxWktLOH4cpmUZEWrm3aPsazGe4Oo3eGSMdvQXZV4-w@mail.gmail.com>
Date:   Wed, 12 Jun 2019 17:13:29 +0200
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Charles Keepax <ckeepax@...nsource.cirrus.com>
Cc:     Wolfram Sang <wsa@...-dreams.de>, mika.westerberg@...ux.intel.com,
        Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        linux-acpi@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
        Jim Broadus <jbroadus@...il.com>, patches@...nsource.cirrus.com
Subject: Re: [PATCH v4 0/7] I2C IRQ Probe Improvements

On Tue, Jun 11, 2019 at 5:29 PM Charles Keepax
<ckeepax@...nsource.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@...nsource.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