From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423161AbcFHTDi (ORCPT ); Wed, 8 Jun 2016 15:03:38 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34880 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161583AbcFHTDf (ORCPT ); Wed, 8 Jun 2016 15:03:35 -0400 Date: Wed, 8 Jun 2016 14:03:33 -0500 From: Rob Herring To: Krzysztof Kozlowski Cc: hzpeterchen@gmail.com, Ulf Hansson , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , Javier Martinez Canillas , linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, linux-pm@vger.kernel.or, Alan Stern , linux-usb@vger.kernel.org, Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Kukjin Kim , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, Greg Kroah-Hartman , Bartlomiej Zolnierkiewicz Subject: Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property Message-ID: <20160608190333.GA5126@rob-hp-laptop> References: <1464768141-25420-1-git-send-email-k.kozlowski@samsung.com> <1464768141-25420-7-git-send-email-k.kozlowski@samsung.com> <20160603020218.GA19436@rob-hp-laptop> <575693DE.2010603@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <575693DE.2010603@samsung.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 07, 2016 at 11:29:02AM +0200, Krzysztof Kozlowski wrote: > On 06/03/2016 04:02 AM, Rob Herring wrote: > >> Optional properties: > >> - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted > >> @@ -16,6 +22,7 @@ Optional properties: > >> See ../clocks/clock-bindings.txt for details. > >> - clock-names : Must include the following entry: > >> "ext_clock" (External clock provided to the card). > >> +- ext-supply : External regulator supply > > > > What happens when there are 2 supplies? > > > > I'd prefer the name not be genericish and use the real supply names. > > Then the power seq code should just turn on all supplies it finds. If > > the order or timing to turn on matters, then sorry, no generic sequence. > > I think the generic part for regulators might be a problem. Regulator > API requires a name for the supply... it cannot get "something" or > "everything". That's the downside of variable property names... > The driver could attach itself to any kind of node (where power-sequence > property exists) so the supply name depends on the bindings of device > (not bindings of power sequence driver). > > The power sequence driver could however iterate over child properties > and get the names of all supplies. It is a little bit ugly... Yes. Like this, right? for_each_property_of_node(np, pp) { if (!strstr(pp->name, "-supply")) continue; // found supply } The uglyness can always be improved with a function to do this parsing. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: robh@kernel.org (Rob Herring) Date: Wed, 8 Jun 2016 14:03:33 -0500 Subject: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property In-Reply-To: <575693DE.2010603@samsung.com> References: <1464768141-25420-1-git-send-email-k.kozlowski@samsung.com> <1464768141-25420-7-git-send-email-k.kozlowski@samsung.com> <20160603020218.GA19436@rob-hp-laptop> <575693DE.2010603@samsung.com> Message-ID: <20160608190333.GA5126@rob-hp-laptop> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jun 07, 2016 at 11:29:02AM +0200, Krzysztof Kozlowski wrote: > On 06/03/2016 04:02 AM, Rob Herring wrote: > >> Optional properties: > >> - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted > >> @@ -16,6 +22,7 @@ Optional properties: > >> See ../clocks/clock-bindings.txt for details. > >> - clock-names : Must include the following entry: > >> "ext_clock" (External clock provided to the card). > >> +- ext-supply : External regulator supply > > > > What happens when there are 2 supplies? > > > > I'd prefer the name not be genericish and use the real supply names. > > Then the power seq code should just turn on all supplies it finds. If > > the order or timing to turn on matters, then sorry, no generic sequence. > > I think the generic part for regulators might be a problem. Regulator > API requires a name for the supply... it cannot get "something" or > "everything". That's the downside of variable property names... > The driver could attach itself to any kind of node (where power-sequence > property exists) so the supply name depends on the bindings of device > (not bindings of power sequence driver). > > The power sequence driver could however iterate over child properties > and get the names of all supplies. It is a little bit ugly... Yes. Like this, right? for_each_property_of_node(np, pp) { if (!strstr(pp->name, "-supply")) continue; // found supply } The uglyness can always be improved with a function to do this parsing. Rob