linux-kernel - Re: [PATCH v3] ACPI: Force I2C to be selected as a built-in module

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]

Date:   Thu, 25 Jan 2018 18:11:18 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Sinan Kaya <okaya@...eaurora.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Timur Tabi <timur@...eaurora.org>,
        Eric Auger <eric.auger@...hat.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Wolfram Sang <wsa@...-dreams.de>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v3] ACPI: Force I2C to be selected as a built-in module

Hi,

On 25-01-18 18:07, Sinan Kaya wrote:
> On 1/25/2018 11:57 AM, Rafael J. Wysocki wrote:
>>> That was the original patch. Folks are saying that it breaks some systems.
>>>
>>> Conversation is here:
>>>
>>> https://patchwork.kernel.org/patch/10142425/
>> Couldn't that be addressed by preventing the I2C module from being
>> unloaded in the relevant cases?
>>
> 
> Maybe, I'll let Andy And Hans speak for themselves. It is not my code.
> 
> I listed the spec behavior and expectation from the OS in the link above.
> Apparently, Linux isn't playing nice.
> 
> Hans is also raising a concern about driver load order that is not being
> handled well between the I2C driver, its sub modules like PMIC and the ACPI support.
> 
> "Lets pretend that all DSTDs are perfect and that some device described in ACPI
> has a _PS0 method which uses an opregion to turn on some regulator powering
> the device through i2c, but only if the _REG method for that opregion has
> been called. So now lets say that the driver for this device loads and
> tries to bind before the i2c-module has loaded. Before the driver's probe
> method gets called the driver-core will call _PS0 to power-up the device,
> which is a nop (*). Then the drivers probe function tries to talk to the
> device, but fails as the device is not powered, so it returns with -ENODEV."
> 
> I'd think that driver would return -EPROBE_DEFER in order to wait until its
> dependencies come in place. Maybe, driver was not designed for this.

The driver is not aware of any power-management done by ACPI, so the driver
cannot return -EPROBE_DEFER.

Regards,

Hans