From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753442AbcD0Pw6 (ORCPT ); Wed, 27 Apr 2016 11:52:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58019 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751550AbcD0Pw4 (ORCPT ); Wed, 27 Apr 2016 11:52:56 -0400 Subject: Re: [PATCH 1/2] regulator: core: Allow use of "status = disabled" in regulator dts nodes To: Maxime Ripard , Mark Brown References: <1461765825-15915-1-git-send-email-hdegoede@redhat.com> <1461765825-15915-2-git-send-email-hdegoede@redhat.com> <20160427142432.GR3217@sirena.org.uk> <20160427143711.GT3217@sirena.org.uk> <20160427150108.GU3217@sirena.org.uk> <20160427155009.GB17159@lukather> Cc: Liam Girdwood , Chen-Yu Tsai , Linux Kernel Mailing List From: Hans de Goede Message-ID: <780af88d-a14a-f527-fe0a-1bb50cddc216@redhat.com> Date: Wed, 27 Apr 2016 17:52:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160427155009.GB17159@lukather> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 27 Apr 2016 15:52:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 27-04-16 17:50, Maxime Ripard wrote: > Hi Mark, > > On Wed, Apr 27, 2016 at 04:01:08PM +0100, Mark Brown wrote: >> On Wed, Apr 27, 2016 at 04:40:05PM +0200, Hans de Goede wrote: >> >>> Or, since regulator_of_get_init_data uses for_each_available_child_of_node >>> which checks the "status" value we can actually already use >>> "status=disabled" cool. So this simply already works :) >> >> To repeat you really shouldn't have *any* DT nodes for regulators that >> aren't in use, there should be nothing to put in their nodes. If >> there's anything there that's a sign that your DT has problems. > > How should we deal with regulators that are on by default but are not > used in the system then? I think we've already solved that one, we do list them, thereby giving the regulator core permission to touch them and then let the regulator core turn them off for us. Regards, Hans