From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752861AbcD0ObK (ORCPT ); Wed, 27 Apr 2016 10:31:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44025 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752049AbcD0ObI (ORCPT ); Wed, 27 Apr 2016 10:31:08 -0400 Subject: Re: [PATCH 1/2] regulator: core: Allow use of "status = disabled" in regulator dts nodes To: 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> Cc: Liam Girdwood , Maxime Ripard , Chen-Yu Tsai , Linux Kernel Mailing List From: Hans de Goede Message-ID: Date: Wed, 27 Apr 2016 16:31:02 +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: <20160427142432.GR3217@sirena.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 27-04-16 16:24, Mark Brown wrote: > On Wed, Apr 27, 2016 at 04:03:44PM +0200, Hans de Goede wrote: > >> So if we want to use these pins as gpio pins we must not register >> a regulator for these pins at all, otherwise any gpio use (switching >> to input, or writing a value) gets undone when the regulator subsys >> disables unused regulators at the end of kernel-init. > > The regulator API should not touch any regulators that it doesn't have > permission to change the state for. All other regulators are strictly > read only. How do we give permission to change state ? Is omitting the dts node, and thus not returning a node / constrains from regulator_of_get_init_data enough for the regulator API to not have permission ? Is there any way to see this in sysfs ? >> This commits allows the use of "status = disabled" in regulator dts >> nodes and makes regulator_register return ENODEV when this is set. > > If the regulator can't be changed why is it in the DT in the first > place? The regulator is part of the pmic and the axp20x regulator driver registers all regulators on the pmic when the pmic-s mfd instantiated regulators-platform-device gets probed. We do use a whole bunch of the other regulators. This patch-set is an attempt to make the control more fine-grained then register all / no regulators by support status=disabled in the regulator nodes. But maybe I'm missing something and this is not necessary, see the earlier part of this reply. Regards, Hans