From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 26E3FC433EF for ; Wed, 11 May 2022 08:04:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=X/4rYuguI5CRPPOErmTf4AYh30QCcuK4prPbfaAFBDg=; b=3VOmG/urVLhM2A KsBvSYR82rF2IQgTUbeqiKP4uIOrMQ7q9vpk2/xeCNCS9S92G4lbNq1yIpwoZjgIj5ZM3OpyCZxxZ 6dJfNbIuQtRssMm0pZPyn1CDQ910chjbomzJlSl7+YcT3BJIxj0c4NxY2wJ4cnMfM01BKGr0I1JQQ KunDZ1ONM1Q0RRBAXDO8XAZn4yxtLjcFFqS7hqz16SFFKvHuGEBdi/961Tbf6wuG2NcQMKHajYnVZ MofmdoQnjdQdFJtlqYkd5pWoiJuiyuN+GnmAgAR0LUI4bGscvapBBSMMY+5+ds3NDuVTUbn8/dcFp wVELk9w47BTTf0RKxlFg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nohJU-005nbp-6A; Wed, 11 May 2022 08:03:16 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nohJI-005nWq-Ju for linux-arm-kernel@lists.infradead.org; Wed, 11 May 2022 08:03:07 +0000 Received: by mail-wr1-x42f.google.com with SMTP id j25so747537wrc.9 for ; Wed, 11 May 2022 01:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=GcjkZzrLn6gMWk4BhtvbTNa6RAyAFLU8Gib10fMIL6M=; b=UFsCqPurNA77DAQgdLeQK8XeRTaY48TIY6s55owkQ/HgvOvfVLRQqmVns5XkEwBZm6 56SK0SRGUPqyFSHm6kzFsqS/WCSavHeFIJcunmiB8T6YQVsHAP976fuV0RDx1fancQkE pSz4Dy+7QjawQo5E9RZCzBbjfCovqAgf6SQnM4htoYjHzRGklIi+IRKyQ3Vq3sfQUUFj Ob5BtPJ9es4c7J1OqHqdFMkzvbg3vandDzGIcfssTWeB3TYQ7BdlOt4vC2SQ69owYueh YcwkeL249xYiu+DEr2CGR6yORYiafhfJr4LYTW0bAPJZE22e2aHtcWk3YZKi6NGCe6bD pUow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=GcjkZzrLn6gMWk4BhtvbTNa6RAyAFLU8Gib10fMIL6M=; b=qrprN4xDvQzhouw86pPaqxxl06RNaeXJBs4NoN2jIxx02BlJ2FsWykBPSOUKhwKCBt 1oG+u3isEB4VvOAuaxoXW7MfKai3oRgHfS9wstTYNXlC+jEwY/gqPKD2cLqbyuByR1y4 IienfigB3MXo681qEbDGl6A9uwf4uSlRD8G8oof303kZMpo9MtB2Qrat0RLWhMDbAkzo AuFtkcR0Nx7+bsPuu+Cg8dQ/KJtnVzJlib9Oa6/r1f4Z6zwZVzSx4yckl2EeShl+uk4X 2kfh52Ev1J+IuE0n56VrzJD63G1NKOZtnp9joLf+v9iZfJ1e7yEaebyM8nhL0Kl7gWdl joUQ== X-Gm-Message-State: AOAM533jQ4q7q0ktxr5jb9xuQUbhSe/aFJBgCT+Jb2JYvAZmIRQFMIjl qSmrrRD8A8RI5LNx1dCghownRA== X-Google-Smtp-Source: ABdhPJz141wwvjEmkFZHdaUgpw9RZwbK3CfA9t7e/8C9BiOzO9p9S/blepjTYOpKbso5uRqwI3xJxQ== X-Received: by 2002:a05:6000:1c09:b0:20c:b986:e593 with SMTP id ba9-20020a0560001c0900b0020cb986e593mr16089270wrb.170.1652256181310; Wed, 11 May 2022 01:03:01 -0700 (PDT) Received: from Red ([2a01:cb1d:3d5:a100:264b:feff:fe03:2806]) by smtp.googlemail.com with ESMTPSA id z15-20020a05600c220f00b00394538d039esm4602915wml.6.2022.05.11.01.02.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 May 2022 01:03:00 -0700 (PDT) Date: Wed, 11 May 2022 10:02:58 +0200 From: LABBE Corentin To: Mark Brown Cc: Andrew Lunn , alexandre.torgue@foss.st.com, calvin.johnson@oss.nxp.com, davem@davemloft.net, edumazet@google.com, hkallweit1@gmail.com, jernej.skrabec@gmail.com, joabreu@synopsys.com, krzysztof.kozlowski+dt@linaro.org, kuba@kernel.org, lgirdwood@gmail.com, linux@armlinux.org.uk, pabeni@redhat.com, peppe.cavallaro@st.com, robh+dt@kernel.org, samuel@sholland.org, wens@csie.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply Message-ID: References: <20220509074857.195302-1-clabbe@baylibre.com> <20220509074857.195302-4-clabbe@baylibre.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220511_010305_054709_C0DF41D5 X-CRM114-Status: GOOD ( 30.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Le Mon, May 09, 2022 at 05:56:34PM +0100, Mark Brown a =E9crit : > On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote: > = > > So we have a collection of regulators, varying in numbers between > > different PHYs, with different vendor names and purposes. In general, > > they all should be turned on. Yet we want them named so it is clear > > what is going on. > = > > Is there a generic solution here so that the phylib core can somehow > > enumerate them and turn them on, without actually knowing what they > > are called because they have vendor specific names in order to be > > clear what they are? > = > > There must be a solution to this, phylib cannot be the first subsystem > > to have this requirement, so if you could point to an example, that > > would be great. > = > No, it's not really come up much before - generally things with > regulator control that have generic drivers tend not to be sophisticated > enough to have more than one supply, or to be on an enumerable bus where > the power is part of the bus specification so have the power specified > as part of the bus. You'd need to extend the regulator bindings to > support parallel array of phandles and array of names properties like > clocks have as an option like you were asking for, which would doubtless > be fun for validation but is probably the thing here. Does you mean something like this: diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 1e54a833f2cf..404f5b874b59 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -351,6 +351,32 @@ static void regulator_lock_dependent(struct regulator_= dev *rdev, mutex_unlock(®ulator_list_mutex); } = +/** + * of_get_regulator_from_list - get a regulator device node based on suppl= y name + * from a DT regulators list + * @dev: Device pointer for the consumer (of regulator) device + * @supply: regulator supply name + * + * Extract the regulator device node corresponding to the supply name. + * returns the device node corresponding to the regulator if found, else + * returns NULL. + */ +static struct device_node *of_get_regulator_from_list(struct device *dev, + struct device_node *np, + const char *supply) +{ + int index, ret; + struct of_phandle_args regspec; + + index =3D of_property_match_string(np, "regulator-names", supply); + if (index >=3D 0) { + ret =3D of_parse_phandle_with_args(np, "regulators", NULL, index, ®sp= ec); + if (ret =3D=3D 0) + return regspec.np; + } + return NULL; +} + /** * of_get_child_regulator - get a child regulator device node * based on supply name @@ -362,17 +388,23 @@ static void regulator_lock_dependent(struct regulator= _dev *rdev, * returns the device node corresponding to the regulator if found, else * returns NULL. */ -static struct device_node *of_get_child_regulator(struct device_node *pare= nt, - const char *prop_name) +static struct device_node *of_get_child_regulator(struct device *dev, + struct device_node *parent, + const char *supply) { struct device_node *regnode =3D NULL; struct device_node *child =3D NULL; + char prop_name[64]; /* 64 is max size of property name */ = + snprintf(prop_name, 64, "%s-supply", supply); for_each_child_of_node(parent, child) { + regnode =3D of_get_regulator_from_list(dev, child, supply); + if (regnode) + return regnode; regnode =3D of_parse_phandle(child, prop_name, 0); = if (!regnode) { - regnode =3D of_get_child_regulator(child, prop_name); + regnode =3D of_get_child_regulator(dev, child, prop_name); if (regnode) goto err_node_put; } else { @@ -401,12 +433,15 @@ static struct device_node *of_get_regulator(struct de= vice *dev, const char *supp char prop_name[64]; /* 64 is max size of property name */ = dev_dbg(dev, "Looking up %s-supply from device tree\n", supply); + regnode =3D of_get_regulator_from_list(dev, dev->of_node, supply); + if (regnode) + return regnode; = snprintf(prop_name, 64, "%s-supply", supply); regnode =3D of_parse_phandle(dev->of_node, prop_name, 0); = if (!regnode) { - regnode =3D of_get_child_regulator(dev->of_node, prop_name); + regnode =3D of_get_child_regulator(dev, dev->of_node, supply); if (regnode) return regnode; = And then for our case, a regulator_get_bulk will be needed. Does I well understood what you mean ? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel