From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 55CBD3914ED for ; Thu, 8 Oct 2026 11:44:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.67.36.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791459842; cv=none; b=TPYWJFuVgZrGhExAGyaVzAsv7/76tRt2Pa71R8mjpqjeewkJmNxkQ56clzbrbSvpUCciVMJ51SRQP1qJCCSXRdbATnD3ja8+ZVjjqs7imnbRywccV4bxCJawWsa0OcZ66cJHORSX7bIP47J6gLI0IdFpNA+noMWwAUrISFK0ikA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791459842; c=relaxed/simple; bh=jUPxCUFc3aTBCASOlFZdGH03w0fcbvkjqzP15izyvIg=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type; b=fzXfw1HICnhQYt96RdZwpMczQHJwcMCYKWOv3cZB1Z32jvw+sLngUJpy4HhpCO1MuHJ0mx1p5qk2Gf7+fJd11Fg0tNiVlHzeZpr48IkBOBBHpHAxGys+Pa/0pj+Gv9yhU2Vxn+i8LdXJgHuB1Wmxt9KyAvZpQrwRZP6CflzgiEw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.net; spf=pass smtp.mailfrom=posteo.net; dkim=pass (2048-bit key) header.d=posteo.net header.i=@posteo.net header.b=cphJCRxP; arc=none smtp.client-ip=185.67.36.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=posteo.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=posteo.net header.i=@posteo.net header.b="cphJCRxP" Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 69367240027 for ; Thu, 8 Oct 2026 13:43:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=1984.8680eb; t=1791459837; bh=QA4a4/0qY83QQNCueloKQP2TPYFXj/uUC4YZjubeRHI=; h=MIME-Version:Date:From:To:Cc:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:From; b=cphJCRxPquv5vT62es7asTSu3dFCCXplZYii8lZ1hCkMRsOjSLW87+8ufdG+M/0Te U77+zlgHzBFXs7bzLELYs5Hp/k/QjycwA8tSEovzyqs2Byf8Uwsc4XxZ9ZPLM8IHK1 1Kz+qiNz476D8JBmGKgMrEgT6f5cueC9F5nM7Qfcpl/rCmrZ100V53qNPo6OK+mWwV uhKb3ln48oZabYtOmktnob0Fwc76oNKZLtbqfyBhNp7eUVQ5WrfjwA+s3m51fWfD85 lBh1u5mx2ynlyO4J1jZYQWGzPM8O8YrKRcyUyQBC2D4JymDlHvQLc0vrxBvFdjuQt+ sqQjdTruvD2pw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4j0p6h1JRTz6ty0; Thu, 8 Oct 2026 13:43:55 +0200 (CEST) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Thu, 08 Oct 2026 11:43:56 +0000 From: mateusz.nowicki@posteo.net To: Patrick DELAUNAY Cc: Alexandre Torgue , Maxime Coquelin , Rob Herring , Krzysztof Kozlowski , Conor Dooley , devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: dts: st: mark main supplies always-on on stm32mp257f-dk In-Reply-To: References: <20261004112421.47158-1-mateusz.nowicki@posteo.net> Message-ID: <1baaa8cb024104ee6d201d55467f6718@posteo.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Patrick, On 07.10.2026 11:22, Patrick DELAUNAY wrote: > For STMicroelectronics boards, the STPMIC always-on regulator are > managed on SCMI server side in OP-TEE. >=20 > So no need to manage this constraint in Linux device tree. >=20 > This always-on=C2=A0 regulator are exposed only for information or to be > used are supply for some IP. Thanks, that makes sense. OP-TEE keeps these rails on no matter what Linux asks for, and the board keeps running fine. The part I found confusing is what Linux reports. Since nothing in Linux uses these regulators, the regulator core turns them off about 30 seconds after boot: [ 31.713597] v1v8: disabling [ 31.716454] v3v3: disabling The SCMI call succeeds, so from then on regulator_summary shows vddcore, v1v8 and v3v3 with a use count of 0, as if they were off. In reality they are still powered. With regulator-always-on, what Linux shows matches the hardware. Would you still prefer to keep it out of the board DT? If so, I'm happy to drop the patch. Thanks, Mateusz