From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752142AbdBGAr2 (ORCPT ); Mon, 6 Feb 2017 19:47:28 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:34017 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164AbdBGAr1 (ORCPT ); Mon, 6 Feb 2017 19:47:27 -0500 Date: Mon, 6 Feb 2017 16:47:23 -0800 From: Dmitry Torokhov To: Bjorn Andersson Cc: Mark Brown , Liam Girdwood , linux-kernel@vger.kernel.org, Bjorn Andersson Subject: Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies Message-ID: <20170207004723.GA35854@dtor-ws> References: <20170203231619.8013-1-dmitry.torokhov@gmail.com> <20170203231619.8013-4-dmitry.torokhov@gmail.com> <20170207002118.GD27837@minitux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170207002118.GD27837@minitux> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 06, 2017 at 04:21:18PM -0800, Bjorn Andersson wrote: > On Fri 03 Feb 15:16 PST 2017, Dmitry Torokhov wrote: > > > Make it possible to use the bulk API with optional supplies, by allowing > > the consumer to marking supplies as optional in the regulator_bulk_data. > > > > Based on earlier patch by Bjorn Andersson > > > > Hi Dmitry, > > Rather than fixing my broken patch, I reverted it after talking to Mark. > This as I realized that I got things backwards. > > When a given component has an "optional" supply this can mean two > things: > 1) The component has a supply pin that is connected, but the kernel has > no information about what it's connected to (in essence a "broken" DT). > In this case regulator_get() will return a dummy regulator. > > 2) The component has a supply pin that might or not might be connected > and depending on this the component needs to be configured differently. > In this case you use regulator_get_optional() which will return an error > in the event that no supply is specified. Right, I'm after the case #2 and I believe there are cases, where, after configuring the chip based on the regulators available, we can continue handling (enabling and disabling) all regulators en-masse. It does simplify the code in certain cases (tlv320aic32x4 and sgtl5000, and I am sure other drivers, where configuration is "static"), but will not help for others (like Mark's MMC example, where optional regulator is managed actively - switching voltage, etc). Thanks. -- Dmitry