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: <CAO-hwJ+qSXwZ-5sAiZ55-r_PXp9pvnE1XEaE_v3SBnxzQQNH4g@mail.gmail.com>
Date:   Tue, 11 Jun 2019 17:16:58 +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 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.

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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ