From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753103AbcIIQQp (ORCPT ); Fri, 9 Sep 2016 12:16:45 -0400 Received: from mga07.intel.com ([134.134.136.100]:7615 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751830AbcIIQQo (ORCPT ); Fri, 9 Sep 2016 12:16:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,305,1470726000"; d="scan'208";a="758864459" Message-ID: <1473437439.11323.188.camel@linux.intel.com> Subject: Re: Regulator probe From: Andy Shevchenko To: Mark Brown Cc: "linux-kernel@vger.kernel.org" , "Hunter, Adrian" Date: Fri, 09 Sep 2016 19:10:39 +0300 In-Reply-To: <20160909152952.GS27946@sirena.org.uk> References: <1472741623.4887.482.camel@linux.intel.com> <20160901153836.GI5967@sirena.org.uk> <1472746516.4887.489.camel@linux.intel.com> <20160901170215.GJ5967@sirena.org.uk> <1473091312.11323.20.camel@linux.intel.com> <20160906102407.GF3950@sirena.org.uk> <1473258241.11323.83.camel@linux.intel.com> <20160909121749.GR27946@sirena.org.uk> <1473425727.11323.144.camel@linux.intel.com> <20160909152952.GS27946@sirena.org.uk> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-09-09 at 16:29 +0100, Mark Brown wrote: > > Fixed regulator probe is deferred: > > > > > reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register > > regulator: -517 > > So the regulator probe *does* get deferred as expected... > > > > > But: > > sdhci-pci 0000:00:01.3: No vmmc regulator found > > > > > Code in sdhci driver is: > >         ret = mmc_regulator_get_supply(mmc); > >         if (ret == -EPROBE_DEFER) > >                 return ret; > > > > mmc_regulator_get_supply(): > > ... > >         mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc"); > >         mmc->supply.vqmmc = devm_regulator_get_optional(dev, > > "vqmmc"); > > ...and then we correctly report that the optional supply that isn't > mapped (as far as I remember) isn't there. But it *will be* soon there. Hmm... And the proper fix for this case is... (let's assume there will not be device tree solution in nearest future)? If I remove has_full_constraints() call I will get EPROBE_DEFER on all optional regulators IIRC. -- Andy Shevchenko Intel Finland Oy