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]

Message-ID: <8637b666-19ce-5382-adab-94a9382cf635@codeaurora.org>
Date:   Thu, 25 Jan 2018 12:07:10 -0500
From:   Sinan Kaya <okaya@...eaurora.org>
To:     "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>,
        Hans de Goede <hdegoede@...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

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.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.