From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751419AbeAYRLY (ORCPT ); Thu, 25 Jan 2018 12:11:24 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:33804 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbeAYRLV (ORCPT ); Thu, 25 Jan 2018 12:11:21 -0500 X-Google-Smtp-Source: AH8x226GBsKnjQweieSrQ/cBu4E+OWBUSpVoB32guI96ISypzVjgdahFF808zNCUYYkDrilgkhtbSg== Subject: Re: [PATCH v3] ACPI: Force I2C to be selected as a built-in module To: Sinan Kaya , "Rafael J. Wysocki" Cc: ACPI Devel Maling List , Timur Tabi , Eric Auger , Mika Westerberg , Wolfram Sang , linux-i2c , "Rafael J. Wysocki" , Len Brown , open list , Andy Shevchenko References: <1516895011-17588-1-git-send-email-okaya@codeaurora.org> <4aee44cd-4eb0-162c-3dcc-fbf6255109ac@codeaurora.org> <8637b666-19ce-5382-adab-94a9382cf635@codeaurora.org> From: Hans de Goede Message-ID: <7c21566b-5cbe-4976-907c-c13110b3ba48@redhat.com> Date: Thu, 25 Jan 2018 18:11:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <8637b666-19ce-5382-adab-94a9382cf635@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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