From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 C9D1B25B305 for ; Sun, 16 Nov 2025 12:50:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763297404; cv=none; b=R0UlvMU4Vh/6N3O+NOMVexrUaRwnPaJ1F4rGkucBtchA+UZufUns3Y3ewx4lT6iiFRM07axsWJ0TIJOwsQWcRFPQkB9QH0iX5tQqznFVisrr4tPaYLLHELAs9ZJPm7l47Jsx0pNHUUtEyzU/AqABYULdoi34QjNkV3g1BTyvciY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763297404; c=relaxed/simple; bh=gx19Zcpd8CDYwPtKOoighCsasUF/1FspQKnjhc/ZnL8=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=FBTGHBUOmg9zInSh731ZZc+kZNPEE1wUoK2A480XKxTUM1M+RUl5nUPOao/IjVYPAAbAgiNcazxFwGCxrz2352+KRwCkg5p7HPO5aCN0pjfnRU/amJquYYoZ567dNjSmu1OHm5QbJa08LIZ9hI7+D8DVRrOwdwcVTSv1iUpmOM0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=GinTErf5; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="GinTErf5" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4779a4fc95aso5060825e9.1 for ; Sun, 16 Nov 2025 04:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1763297401; x=1763902201; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=gx19Zcpd8CDYwPtKOoighCsasUF/1FspQKnjhc/ZnL8=; b=GinTErf5fLa1znIuvRUTgMcM1tG1DFj5iD/HlPj13JUfYXEoenqVm0/B9qsMG6tlyY lyUqhbCbMUTS98bw8KokcwsQozwMfG5E6STgE252SnmreboSE2P8G7R+7ATwoMXo3Fib 4EEVKLPdQPt7qfSH3aM4uU7cSipLth126j6HTv41cR97bYR5PGxN/P1pj/IhrBXi9Dai kFo0EUhDbOfrB2/5lmeiyia0MC/QETYvB9CoolrkK/feeHpRasLCyW67m1ME0LlfdCsm nDZT9q1pE+BDemfNJQYhRZRnxOmcA93GxNCrb+vU9wWFfR0K6jAxuW1CzhAu7X2VeoLK 62nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763297401; x=1763902201; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gx19Zcpd8CDYwPtKOoighCsasUF/1FspQKnjhc/ZnL8=; b=Zxg1O9yVyPN9lDcP6plE8BuZcholA4Ncq099/MHteIlMDl1Q6/cNqUIAMECLCG3fFv VITFPUQQhcy2di3+FIyV004gXel2Kllz99Tsdq5SRoqCsbGlETdf+Ytd2MMB1uSRwX+3 ZODkxDrr6BmIHKL5Pd0Bkmmq92H1vTcqdci9jxtfuK73v+KxVIvNxlKDVCVnFkGwaxoC 2CmQljqofgdWWkNoGcsbgYMtfBiAkc4RvmtJmnMcsvKVGsrep4mHvq+cLwAbxNO158QR q8oVHGp8RWSKQgO6BRju0MCGjRoA73IJvFcn7fVn5N/FZ7uDGsrU9tAMJOAqP7yUwK19 XScw== X-Forwarded-Encrypted: i=1; AJvYcCWGgEYL9tfrhQnaxJmnBXAuVufZdSXDFr5S8iFJyBi1m8jlSpAOB4IlK9U8bM4WM+p67oCQcU43q1XQF84=@vger.kernel.org X-Gm-Message-State: AOJu0YxhDMWKljfDxZBSP4B9JY5lXhWg8cbVY64AkvxH2agmvXjiLFCA 9eX50BjyLEivq78YlDL7mpTvvrSWCpMg/Z3G+du3xAJ+rmqMDsREfykKx+XRk6zZgQA= X-Gm-Gg: ASbGncsYeoYrZZDPhMnSb6dKqO2c0gSlH5O8ML8Pr6n4Vr/IslLSs51Z1oiw/5pkviy zQXmL5GV4VyGZOAzPXzv55XAxrXT658PhC0Y+YHecM0+mEVCY3tTeDnoZu6Xn231GePaK4boIgt 70divZKYqJxnNZTvZ9qyi1g4YiPr5/T+F3P9Ty8qmGNriCj7Mh5ishnEV5mz3yJZ+a2s14EsCnA kWtlRz2b9LHu+fdugIJvSLhDTaQkOiVU9GbzmpRJj7J/buEZBr361TWbFj5ruXdPDdAB6+u8Dor p56v7Mj+pFTYQhQX54QLWAeo88h3IYDSzPvazY6xLcNvkWHt2cRg0mbBpDTlfEgtHfvKZkVjo3r ssjrysRzV6UJZqb6szC9JET8FgOhiMHsWOpoIjoTb/Nrh15EvP0iYVnvfDkAdHmUY1TYr/PmVk3 BonYM/pRiGrU4awcbbwMa4S39GcA== X-Google-Smtp-Source: AGHT+IEgM25ruVJqzrK8xcgzvUOa4umu05fH/BlFqcaH2LfSeCBEN0GdEDr4Mmb0LqjvXyPsvNFoCQ== X-Received: by 2002:a05:600d:486:20b0:471:793:e795 with SMTP id 5b1f17b1804b1-4778bf41181mr85683265e9.0.1763297401071; Sun, 16 Nov 2025 04:50:01 -0800 (PST) Received: from salami.lan ([212.129.81.71]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47787e2bcf9sm254128125e9.3.2025.11.16.04.49.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Nov 2025 04:50:00 -0800 (PST) Message-ID: <845ca29cf8af53bd3093d1dcbea64cc3e04432f2.camel@linaro.org> Subject: Re: [PATCH v3 09/20] mfd: sec: Add support for S2MPG11 PMIC via ACPM From: =?ISO-8859-1?Q?Andr=E9?= Draszik To: Mark Brown Cc: Lee Jones , Tudor Ambarus , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Liam Girdwood , Linus Walleij , Bartosz Golaszewski , Krzysztof Kozlowski , Peter Griffin , Will McVicker , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org Date: Sun, 16 Nov 2025 12:49:55 +0000 In-Reply-To: References: <20251103-s2mpg1x-regulators-v3-0-b8b96b79e058@linaro.org> <20251103-s2mpg1x-regulators-v3-9-b8b96b79e058@linaro.org> <20251113162534.GO1949330@google.com> <45ce203c03ec34631a0170baa7e4cf26c98b9cd3.camel@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-7 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Mark, On Sun, 2025-11-16 at 01:14 +0000, Mark Brown wrote: > On Fri, Nov 14, 2025 at 09:56:41PM +0000, Andr=C3=A9 Draszik wrote: >=20 > > I'm happy to use an alternative approach that can solve my problem, if = there > > is something that I have missed. I think the commit message for patch 8 > > describes the problem in better detail than this one. >=20 > The more normal thing would be to just register one child device for all > the regulators and then register them in a loop in the probe function of > that device. Thanks Mark, I'm aware of that, but that approach doesn't work as I hoped to have explained in the commit message in patch 8 in this series, I'll copy it below: --- snip --- Bucks can conceivably be used as supplies for LDOs, but currently it can be impossible to mark BUCKs as LDO supplies. This becomes particularly an issue with the upcoming support for the S2MPG11 PMIC. The typical use of the S2MPG10 PMIC is in combination with an S2MPG11 PMIC in a main/sub configuration. Bucks of one are usually used as supplies for LDOs of either itself or of the other: several S2MPG10 LDOs are consumers of various S2MPG10 bucks & S2MPG11 bucks, and several S2MPG11 LDOs are supplied by various S2MPG10 bucks & S2MPG11 bucks. So we have a circular dependency here - LDOs (and potentially also bucks) of one PMIC depend on bucks of the other. This means that if all S2MPG10 rails are handled by the same instance of the S2MPG10 regulator driver, probe of all rails will defer, because the supplies to the LDOs can not be resolved during probe. The same goes for S2MPG11. The result is that neither driver can probe successfully and probe will ultimately fail. In other words it's currently impossible to mark BUCKs as LDO supplies. Additionally, multiple (LDO-) rails may share the same (buck) supply rail and some of these LDOs might supply important consumers, e.g. RAM. To stay with RAM, if one of those consumers needs to defer probe before the rail supplying RAM has probed, the shared (buck) supply gets disabled and the whole system comes to a halt, since Linux hasn't seen the DDR-supplying rail yet, and hasn't had a chance to mark the buck rail as having another consumer. By splitting all rails into separate driver instances, the circular dependency is gone, each individual instance can probe when its supplies are ready. This approach also solves the multiple-consumers-on-one-rail issue during probe. The mfd_cell's ::id field is used to inform the regulator driver which regulator to instantiate. --- snap --- Does that explain the problem well enough? So unless I'm missing something, registering just one child device simply doesn't work, the rails have to be instantiated individually. One could register all bucks as one device, and then only the LDOs individually, but IMHO that approach would make it more convoluted, not simpler. Do you have any other suggestions? Cheers, Andre'