From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752784AbcIIREk (ORCPT <rfc822;w@1wt.eu>);
        Fri, 9 Sep 2016 13:04:40 -0400
Received: from mga06.intel.com ([134.134.136.31]:32312 "EHLO mga06.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752115AbcIIREj (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 9 Sep 2016 13:04:39 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.30,305,1470726000"; 
   d="scan'208";a="1027497889"
Message-ID: <1473440676.11323.219.camel@linux.intel.com>
Subject: Re: Regulator probe
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Hunter, Adrian" <adrian.hunter@intel.com>
Date: Fri, 09 Sep 2016 20:04:36 +0300
In-Reply-To: <20160909163824.GT27946@sirena.org.uk>
References: <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>
         <1473437439.11323.188.camel@linux.intel.com>
         <20160909163824.GT27946@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: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 2016-09-09 at 17:38 +0100, Mark Brown wrote:
> On Fri, Sep 09, 2016 at 07:10:39PM +0300, Andy Shevchenko wrote:
> > 
> > On Fri, 2016-09-09 at 16:29 +0100, Mark Brown wrote:
> 
> > 
> > > 
> > > ...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)?
> 
> To supply this particular mapping before you set full constraints.

Thanks for patience and explanation. I will look later how to achieve
this.

> 
> > 
> > If I remove has_full_constraints() call I will get EPROBE_DEFER on
> > all
> > optional regulators IIRC.
> 
> Yes.

Which basically means that's not a solution I'm trying to get.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy