linux-kernel - Re: [PATCH 4.10 012/167] mmc: sdhci-acpi: support deferred probe

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: <1490680291.2881.37.camel@intel.com>
Date:   Tue, 28 Mar 2017 13:51:31 +0800
From:   Zhang Rui <rui.zhang@...el.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andrey Utkin <andrey_utkin@...tmail.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Jonas Aaberg <cja@....net>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 4.10 012/167] mmc: sdhci-acpi: support deferred probe

On Mon, 2017-03-27 at 18:36 +0200, Greg Kroah-Hartman wrote:
> On Mon, Mar 27, 2017 at 10:40:23AM +0800, Zhang Rui wrote:
> > 
> > On Sun, 2017-03-26 at 12:26 +0100, Andrey Utkin wrote:
> > > 
> > > On Fri, Mar 10, 2017 at 10:07:35AM +0100, Greg Kroah-Hartman
> > > wrote:
> > > > 
> > > > 
> > > > 4.10-stable review patch.  If anyone has any objections, please
> > > > let
> > > > me know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Zhang Rui <rui.zhang@...el.com>
> > > > 
> > > > commit e28d6f048799acb0014491e6b74e580d84bd7916 upstream.
> > > > 
> > > > With commit 67bf5156edc4 ("gpio / ACPI: fix returned error from
> > > > acpi_dev_gpio_irq_get()"), mmc_gpiod_request_cd() returns
> > > > -EPROBE_DEFER if
> > > > GPIO is not ready when sdhci-acpi driver is probed, and sdhci-
> > > > acpi
> > > > driver
> > > > should be probed again later in this case.
> > > > 
> > > > This fixes an order issue when both GPIO and sdhci-acpi drivers
> > > > are
> > > > built
> > > > as modules.
> > > > 
> > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177101htt
> > > > ps://bugzilla.kernel.org/show_bug.cgi?id=177101
> > > > Tested-by: Jonas Aaberg <cja@....net>
> > > > Signed-off-by: Zhang Rui <rui.zhang@...el.com>
> > > > Acked-by: Adrian Hunter <adrian.hunter@...el.com>
> > > > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > > 
> > > > ---
> > > >  drivers/mmc/host/sdhci-acpi.c |    5 ++++-
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > 
> > > > --- a/drivers/mmc/host/sdhci-acpi.c
> > > > +++ b/drivers/mmc/host/sdhci-acpi.c
> > > > @@ -467,7 +467,10 @@ static int sdhci_acpi_probe(struct platf
> > > >  	if (sdhci_acpi_flag(c, SDHCI_ACPI_SD_CD)) {
> > > >  		bool v = sdhci_acpi_flag(c,
> > > > SDHCI_ACPI_SD_CD_OVERRIDE_LEVEL);
> > > >  
> > > > -		if (mmc_gpiod_request_cd(host->mmc, NULL, 0,
> > > > v, 0,
> > > > NULL)) {
> > > > +		err = mmc_gpiod_request_cd(host->mmc, NULL, 0,
> > > > v,
> > > > 0, NULL);
> > > > +		if (err) {
> > > > +			if (err == -EPROBE_DEFER)
> > > > +				goto err_free;
> > > >  			dev_warn(dev, "failed to setup card
> > > > detect
> > > > gpio\n");
> > > >  			c->use_runtime_pm = false;
> > > >  		}
> > > > 
> > > > 
> > > Regression reported: https://bugzilla.kernel.org/show_bug.cgi?id=
> > > 1948
> > > 71
> > > 
> > > Reverting this patch is said to fix the issue for 4.10.2.
> > thanks for raising the issue. Let's see check why it breaks in the
> > bugzilla report.
> Is this also broken in Linus's tree?
> 
Well, I think so.

Although it's still under debugging, the root cause of the problem
seems to be that, when mmc_gpiod_request_cd() returns -EPROBE_DEFER, it
means either the GPIO controller driver is not probed at the moment, OR
the GPIO controller driver is not available at all. The later case
 causes the problem like this because sdhci-acpi driver is made to wait
for the GPIO controller, in the patch above. 

This is not a problem for distro kernel when all the driver are built
as modules. And the problem should be fixed by enabling the GPIO
controller driver in kernel config.

thanks,
rui