From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65C68350D44 for ; Wed, 28 Jan 2026 14:53:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769611990; cv=none; b=T0BQ2Q5z2qbn5HHf+6KJF01xAqh4KzlCSioP+962ex9s5uvC68LpcdQGM4huc9/OHntnKr1nLF27ZH1nvpuFY5yHRhi7ZX9hHoZNe7actWskjfgT6moQeIPXEpG5DRZpVT7NWK0CXLXEJskbQoGO4tX7KPHn7R7A00UFUORI3sU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769611990; c=relaxed/simple; bh=xv9s+K7w28yZvwvYmPs6K9uJJvb4PymXWZDgqXpzD5c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SoHtKpP6FYfzwFrLSgxCfk9C/skcIU5G79ZiBzo10lQMb4ogTF/K3qZiVh3KUHbqfoMqlQkOAoeiwaxRGSaKmIUNAIJknZdoWpZIJXC3Ic37BCgyVo2+pVzj3hRrtmENM0Rtz0mOa6MAIESgjTjlw0/ECJvPW/dJ5HABqIENycY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass (2048-bit key) header.d=riscstar-com.20230601.gappssmtp.com header.i=@riscstar-com.20230601.gappssmtp.com header.b=hEfdJYe8; arc=none smtp.client-ip=209.85.167.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=riscstar.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=riscstar-com.20230601.gappssmtp.com header.i=@riscstar-com.20230601.gappssmtp.com header.b="hEfdJYe8" Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-45f053b7b90so575110b6e.0 for ; Wed, 28 Jan 2026 06:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20230601.gappssmtp.com; s=20230601; t=1769611987; x=1770216787; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Qmii9fWK0qOIPGEwrFV10/Zom1WAYNaPXJlgvztgTOE=; b=hEfdJYe8u1GurSu1UQiM17YAnH4+NVQZ2m05K12XLQHWw/T7x05YS/Pgsis2KVRgVK VtxRY2jxGSfA5VO0f/ElOnIHFbqOX9p646gmOj57YjV0oDCQPw+Fhk0X236shfn0Wgor 9VDnQNyWavgxx3ROppPjhtsUw9dDsUGMMRXakPgTH+mj1YI7+i5MxVnPRTnRUgykX9Dj yztefcWZvhk3tHb/Y/XKbK/nh8NxGRIQihXqlHK05fZs/yeSbsTDRc+qhmn+BqS3zbGO TDuMh+NdOV9WOkJx/exdidF768wh9j+bU2q9Gq3FTkpEpcnCN6Q4GEEpALWjqSXycPm+ djfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769611987; x=1770216787; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qmii9fWK0qOIPGEwrFV10/Zom1WAYNaPXJlgvztgTOE=; b=vpSWrMUTAMdO2urLiRNCb66BO5ZBugf/tHwal59x9WXgOVQQiYPA3WM30ya40epv+f yAdYYhZEARHfdnFmTw/LNgC9dmQmHXgHJNWZcN5/x75GO4rI85DslFdz+t+/k2UFKoKr 1KgtRTwdcIEjc2JOms81y6jgIco3yjYV7Eu44kis1IfhcxKVXhE7ym/gQXMot2UGmjkt FWO1NJC/8//QMuxDymp+dP11basU4FH1DwQdlRWAJvYjAOzuL6grlO7ATl7AwMzsKr8T tlUCpIpcWLxeSudFDpiSwMHkuE75h3n7mWPVMG0OKJYYa3HKRC6WKPI4I1LHK1ENKJkZ Y1bA== X-Forwarded-Encrypted: i=1; AJvYcCUtaexGRqXzLXUOktBF8elUYHS09DxIIxPmZsLQDP0epVN+VyXAC2ngyQgfWRQRzgCCJFl/iCSR6ckbjlM=@vger.kernel.org X-Gm-Message-State: AOJu0YxmTfLX3ItwelGC3W4O7LtYGRXvtegsWecEEopD409gn+WD5QPG 7jh/9gybT4Zvs7j5NJ2Vq3pi4NI+N89k1le7DCFzMsfmX/7irK559UEcvy3yxEIIHtA= X-Gm-Gg: AZuq6aIJpLK5rSGLDQIIJPopVd5OvEXUFem6fd48K7j+PrCopRROcgyq2Bx9/t9Q8yr os+lNe0XCB+oxKrHE5fl6w6AJ77N/wCgqh7ixkbwXRKGVar4IfBo9y98fYYxtg9q8UKO0QaVckE H5d2U9wqsM7Wxzb9LOxwceHkmXYndzq/yHg81aC5mxF+gKkg6G43mSz2KTbp3Cl08lHDY4Xu3kN WOiiPVoLbT8vtgPWMZgk9XH1QAmsuHWshvr3U3ysxY742IEmQcN94AUkty3WhGBekmZ8idOKjtr dOuiu7HtkiDrYxG9w6EMYX3XdtHm+WY3hqgUxaeDtLKhGSRr+ma/fc7WepkW//A0M1SX9kwI1pU 6EJSWxdCuYsBYRX8pcE6/bluOwpqM04WT3+tpDvJ6UlL4TrHjDR2jmXiCasUhbdCyHPcotLzJQG 9aG1N7Q6dxAmzOklDMmG8PXvP48odAbiYmpNClcx4U6ZY9ZmG0pwqpVCxMgIHzNA== X-Received: by 2002:a05:6808:23cd:b0:45c:a28e:63a5 with SMTP id 5614622812f47-45efc49c5b9mr2979856b6e.9.1769611982108; Wed, 28 Jan 2026 06:53:02 -0800 (PST) Received: from [172.22.22.28] (c-75-72-117-212.hsd1.mn.comcast.net. [75.72.117.212]) by smtp.gmail.com with ESMTPSA id 5614622812f47-45f08fb3887sm1365549b6e.20.2026.01.28.06.53.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 06:53:01 -0800 (PST) Message-ID: <4817d35e-cbca-4b59-ac4b-5f47bde86077@riscstar.com> Date: Wed, 28 Jan 2026 08:53:00 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] regulator: spacemit-p1: Update supply names To: Guodong Xu Cc: Liam Girdwood , Mark Brown , Yixun Lan , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Troy Mitchell , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev, devicetree@vger.kernel.org References: <20260124-spacemit-p1-v2-0-2c86b06694ba@riscstar.com> <20260124-spacemit-p1-v2-3-2c86b06694ba@riscstar.com> <4395bea9-44d7-4f0f-81d6-c1e05976a308@riscstar.com> Content-Language: en-US From: Alex Elder In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/28/26 8:47 AM, Guodong Xu wrote: > Hi, Alex > > On Wed, Jan 28, 2026 at 9:29 PM Alex Elder wrote: >> >> On 1/23/26 6:20 PM, Guodong Xu wrote: >>> Update supply names to match the P1 PMIC's actual hardware pinout where >>> each buck has an individual VIN pin (vin1-vin6) and LDO groups have >>> dedicated input pins (aldoin, dldoin1, dldoin2). >>> >>> The supply is a board design decision and should not be hardcoded to any >>> existing power source. This allows boards to specify their actual power >>> tree topology in devicetree. >>> >>> Signed-off-by: Guodong Xu >> >> These are good changes but I have a suggestion on the way >> you define the DLDO descriptors. I might be mistaken but >> I think you should make this change. >> >> Aside from that: >> >> Reviewed-by: Alex Elder >> >>> --- >>> v2: No change. >>> --- >>> drivers/regulator/spacemit-p1.c | 25 ++++++++++++++----------- >>> 1 file changed, 14 insertions(+), 11 deletions(-) >>> >>> diff --git a/drivers/regulator/spacemit-p1.c b/drivers/regulator/spacemit-p1.c >>> index 2b585ba01a93..57e6e00a73fa 100644 >>> --- a/drivers/regulator/spacemit-p1.c >>> +++ b/drivers/regulator/spacemit-p1.c >>> @@ -87,13 +87,16 @@ static const struct linear_range p1_ldo_ranges[] = { >>> } >>> >>> #define P1_BUCK_DESC(_n) \ >>> - P1_REG_DESC(BUCK, buck, _n, "vin", 0x47, BUCK_MASK, 255, p1_buck_ranges) >>> + P1_REG_DESC(BUCK, buck, _n, "vin" #_n, 0x47, BUCK_MASK, 255, p1_buck_ranges) >> >> That was a simple change... >> >>> #define P1_ALDO_DESC(_n) \ >>> - P1_REG_DESC(ALDO, aldo, _n, "vin", 0x5b, LDO_MASK, 128, p1_ldo_ranges) >>> + P1_REG_DESC(ALDO, aldo, _n, "aldoin", 0x5b, LDO_MASK, 128, p1_ldo_ranges) >> >> As stated before, I believe the 128 should be 117 here. (If > > I will explain this in another email. > >> you change the earlier patch, make sure the change to 128 >> doesn't persist here.) Same comment for the DLDO regulators. >> >>> -#define P1_DLDO_DESC(_n) \ >>> - P1_REG_DESC(DLDO, dldo, _n, "buck5", 0x67, LDO_MASK, 128, p1_ldo_ranges) >>> +#define P1_DLDO1_DESC(_n) \ >>> + P1_REG_DESC(DLDO, dldo, _n, "dldoin1", 0x67, LDO_MASK, 128, p1_ldo_ranges) >> >> Why can't you use _n here like you did for P1_BUCK_DESC() above? > > The naming follows the P1 pinout definitions in the datasheet [1]. > > Unlike the BUCK regulators, which have individual input pins (e.g., > VIN3 for BUCK3), the DLDOs share power inputs. For example, DLDOIN1 (pin 17) > powers DLDO1 through DLDO4. DLDOIN2 provides power to DLDO5, 6 and 7. Ahh. I didn't notice that. There are two *groups* of DLDO regulators, and each group is fed by one or the other poer input. Now I get it. Thanks for the explanation. -Alex > Since there are no physical pins named dldoin3, etc., I can't use the _n index > for the supply name argument like I did for the BUCKs. > > Datasheet pin examples: > 8 VIN3 PWR Buck3 power input (1:1 mapping) > 17 DLDOIN1 PWR DLDO1~4 power input (1:Many mapping) > > Link: https://developer.spacemit.com/documentation?token=T1Btw2BdiiSlSXkAdibcoMetnag > [1] > > Best regards, > Guodong Xu > >> >>> + >>> +#define P1_DLDO2_DESC(_n) \ >>> + P1_REG_DESC(DLDO, dldo, _n, "dldoin2", 0x67, LDO_MASK, 128, p1_ldo_ranges) >> >> So this is generalizing the input, which is good. The use >> of "buck5" here was a Banana Pi BPI-F3 design and but it >> doesn't have to be that way. >> >>> static const struct regulator_desc p1_regulator_desc[] = { >>> P1_BUCK_DESC(1), >>> @@ -108,13 +111,13 @@ static const struct regulator_desc p1_regulator_desc[] = { >>> P1_ALDO_DESC(3), >>> P1_ALDO_DESC(4), >>> >>> - P1_DLDO_DESC(1), >>> - P1_DLDO_DESC(2), >>> - P1_DLDO_DESC(3), >>> - P1_DLDO_DESC(4), >>> - P1_DLDO_DESC(5), >>> - P1_DLDO_DESC(6), >>> - P1_DLDO_DESC(7), >>> + P1_DLDO1_DESC(1), >>> + P1_DLDO1_DESC(2), >>> + P1_DLDO1_DESC(3), >>> + P1_DLDO1_DESC(4), >>> + P1_DLDO2_DESC(5), >>> + P1_DLDO2_DESC(6), >>> + P1_DLDO2_DESC(7), >>> }; >>> >>> static int p1_regulator_probe(struct platform_device *pdev) >>> >>