From patchwork Fri Jan 3 21:13:05 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kory Maincent X-Patchwork-Id: 13925938 X-Patchwork-Delegate: kuba@kernel.org Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC32C1BDA91; Fri, 3 Jan 2025 21:14:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.199 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735938861; cv=none; b=f1VpLj2STguYs720jw3F+5BGVwlrvCzcaTE/O/x0i6m/ypJBQ9lepjyRdFHhWPZ3xI6zXrj0rnsA5FWuhjyNbeynwMw1eHpO8a1FXrOuY+Tok1vi05x+kNpgVAjRx8VIDxTGpxK1ljYBKBB17sFtXZE5RaVP2AlENstQFsoyTv4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735938861; c=relaxed/simple; bh=PC4FJ1L2BSzbjvbggFgME9yTsHVyK93CyP/SQ26vnK0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=RRCo2gYLws2el+HTmPg21Wi/EX30EsHm6F5/M5LFhHpRW0DeKneXgRgrNtfcS7Z1hGKe9CpW01jxeh+JET96DjsQFdo/3J2Jrl6ebpi7dx53FXYDLZY+hNdPophFaKReu0wTBSf/lww+CRNqiKsCgAGBBEZ/qRtQd5xII15BWUI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=an1TztFx; arc=none smtp.client-ip=217.70.183.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="an1TztFx" Received: by mail.gandi.net (Postfix) with ESMTPSA id E76F8FF806; Fri, 3 Jan 2025 21:14:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1735938857; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nBikdrLrEW5eXXG7XnWc4AqnVNGcoitDQANYv+yb5E4=; b=an1TztFxFzVrX+0cibpPxRMPwY/kWwR3YjhZD4nuYR5MIfveaWlNCnN6RBoiitppPOtEWD 5kc1fT2fYf4TKdGMTo8rPkWNNfMUxbfIzlG+Q34KuY7rmG2WilTSvNOZ7BBWn+kX+WvA1J oMu1wDKgDf++Rq5G6dXtrBNetJdYBvoT4tntwXlyaWOqIDlU3KgZtvy6dKJ1WPITeflk6K D96plz5FUVPXcz1yFB6MMdpFyg5TKTVQr7djetZrRowSKDEVE1cqfgCbfxwTALvzzlTvf2 fT+aisv5lQmo9EnNwv8FG7BdcSOg2MfEixzANx8P7AvTgurJoMmLe41N7XQy1w== From: Kory Maincent Date: Fri, 03 Jan 2025 22:13:05 +0100 Subject: [PATCH net-next v4 16/27] regulator: core: Resolve supply using of_node from regulator_config Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20250103-feature_poe_port_prio-v4-16-dc91a3c0c187@bootlin.com> References: <20250103-feature_poe_port_prio-v4-0-dc91a3c0c187@bootlin.com> In-Reply-To: <20250103-feature_poe_port_prio-v4-0-dc91a3c0c187@bootlin.com> To: Andrew Lunn , Oleksij Rempel , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , Donald Hunter , Rob Herring , Andrew Lunn , Simon Horman , Heiner Kallweit , Russell King , Liam Girdwood , Mark Brown , Krzysztof Kozlowski , Conor Dooley Cc: Thomas Petazzoni , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-doc@vger.kernel.org, Kyle Swenson , Dent Project , kernel@pengutronix.de, Maxime Chevallier , devicetree@vger.kernel.org, Kory Maincent X-Mailer: b4 0.15-dev-8cb71 X-GND-Sasl: kory.maincent@bootlin.com X-Patchwork-Delegate: kuba@kernel.org From: Kory Maincent (Dent Project) Previously, the regulator core resolved its supply only from the parent device or its children, ignoring the of_node specified in the regulator_config structure. This behavior causes issues in scenarios where multiple regulator devices are registered for components described as children of a controller, each with their own specific regulator supply. For instance, in a PSE controller with multiple PIs (Power Interfaces), each PI may have a distinct regulator supply. However, the regulator core would incorrectly use the PSE controller node or its first child to look up the regulator supply, rather than the node specified by the regulator_config->of_node for the PI. This update modifies the behavior to prioritize the of_node in regulator_config for resolving the supply. This ensures correct resolution of the power supply for each device. If no supply is found in the provided of_node, the core falls back to searching within the parent device as before. Reviewed-by: Oleksij Rempel Signed-off-by: Kory Maincent --- It is weird that it wasn't seen before, maybe there was not any case were it can't find the supply_name from the parent device. Changes in v4: - Remove dev.of_node double check. Changes in v3: - New patch --- drivers/regulator/core.c | 39 ++++++++++++++++++++++++++++----------- 1 file changed, 28 insertions(+), 11 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 8cb948a91e60..c092b78c5f12 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1936,6 +1936,20 @@ static struct regulator_dev *regulator_lookup_by_name(const char *name) return dev ? dev_to_rdev(dev) : NULL; } +static struct regulator_dev *regulator_dt_lookup(struct device *dev, + const char *supply) +{ + struct regulator_dev *r = NULL; + + if (dev_of_node(dev)) { + r = of_regulator_dev_lookup(dev, dev_of_node(dev), supply); + if (PTR_ERR(r) == -ENODEV) + r = NULL; + } + + return r; +} + /** * regulator_dev_lookup - lookup a regulator device. * @dev: device for regulator "consumer". @@ -1960,16 +1974,9 @@ static struct regulator_dev *regulator_dev_lookup(struct device *dev, regulator_supply_alias(&dev, &supply); /* first do a dt based lookup */ - if (dev_of_node(dev)) { - r = of_regulator_dev_lookup(dev, dev_of_node(dev), supply); - if (!IS_ERR(r)) - return r; - if (PTR_ERR(r) == -EPROBE_DEFER) - return r; - - if (PTR_ERR(r) == -ENODEV) - r = NULL; - } + r = regulator_dt_lookup(dev, supply); + if (r) + return r; /* if not found, try doing it non-dt way */ if (dev) @@ -2015,7 +2022,17 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) if (rdev->supply) return 0; - r = regulator_dev_lookup(dev, rdev->supply_name); + /* first do a dt based lookup on the node described in the virtual + * device. + */ + r = regulator_dt_lookup(&rdev->dev, rdev->supply_name); + + /* If regulator not found use usual search path in the parent + * device. + */ + if (!r) + r = regulator_dev_lookup(dev, rdev->supply_name); + if (IS_ERR(r)) { ret = PTR_ERR(r);