[v2,4/8] dt-bindings: power: reset: add bindings for NVMEM hardware storing PSCR Data
Message ID | 20240124122204.730370-5-o.rempel@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-36964-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2553:b0:103:945f:af90 with SMTP id p19csp949962dyi; Wed, 24 Jan 2024 04:23:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IE3/gAw7Ts87OBW+cxavS6/OwwYDrQoFXfaSICl64xvJFHAQBbmUsuOraBLvF8tnXm28Ebb X-Received: by 2002:a05:6214:2248:b0:685:d0cc:2968 with SMTP id c8-20020a056214224800b00685d0cc2968mr3005434qvc.98.1706099006096; Wed, 24 Jan 2024 04:23:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706099006; cv=pass; d=google.com; s=arc-20160816; b=zrOwe5HhWNZOnYr5h5X5ROXiTfsUlCkr8r0n+2R99lvtPTSG2OTlYTA8LhcvE+SgfI nNML64cxPOmT+5xV/jrxbMF0eL49wX2fmepPG7YysAEnG8HBTv+RuAdg9NCwrMStAj1K DyXe4Ct8AQBOaXSjyrBSANHjEW8khyh0OA3F/BEe9eTwzSuAYGtJDgaC9c9JDsblNpoT w7XBpfcOt1+72/yltHBHAV6d5o3yaxM/JVWvGcXK5pMv8nUOdBDex0UuXuNQ/JR5Bim1 6tMlEo0rOt5MWeHsnZY7K1s0sce+l+WpCMnoBD3goK52P4/omME12yKpP9eYHz+Uljef g0Sg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=MCo+mJx8B736yFIbMduNCBjdP1mfg7iqcGmcucw70hE=; fh=cTOyeHIiotxFveWD397Up69SLR8Dqpy9YboYIfW0A00=; b=hhC1GGQ0AC/TLndnTqVUxjLqu1grykcyyDMoTg7C5xlPkGTQhWNTZyhvB4HXDfqC+O dkDabaiJESPeAI13Gjqe6KnXZrtUyqVbvZFe1KuJeaWsZNjiX2NarklUb6BUvGM93pd7 wzTNVjq7BjPaYifmGcQN4eoGIyB0EzpGCA8opVQwYInfeadPAFustfmVs5xiYeB2/XmK XRxLSkZWpr8TfoJToXOIxuNnhil8pfxpwnEuy18GzJOGl+6LS2mEMKcr4ZtmVbMP9U1g 1sxiHz9O98pUzIkvjGFwUnpPXErq9pkNqFqIYqH48oMtEEglOwhLLsRWt2vpfsz20HUh 04GQ== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=pengutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-36964-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36964-ouuuleilei=gmail.com@vger.kernel.org" Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id d19-20020a0caa13000000b00680503d5c6bsi10291293qvb.149.2024.01.24.04.23.25 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 04:23:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-36964-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=pengutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-36964-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36964-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id DEC601C219D0 for <ouuuleilei@gmail.com>; Wed, 24 Jan 2024 12:23:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 255A364CF1; Wed, 24 Jan 2024 12:22:30 +0000 (UTC) Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (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 1AACD6310F for <linux-kernel@vger.kernel.org>; Wed, 24 Jan 2024 12:22:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706098947; cv=none; b=RlWAvz3ipUFSdlG9EOe+fO3eGIVtgVYeiRyhI3ePO8420z1EV7Pb9KL9PUWIVyJLug4iFBoTH9bOnA6up7U/KM5MV1Q0DtRxS5RgJ8wqyK7ajEm2366xrZo7aJ/Y5+I1hkCDQPbfiG05TVP9T7TRVuUG0Imp1IfNQhqsFfPzL0U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706098947; c=relaxed/simple; bh=HHxbDfRuHjBw0BBMrvLJdWgyYMSpJ3v1+tlxqNpDDsA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=eJMuNV5ZVOlNShni0bhb5XVBfNcqKS7MObi8eQUe7lvTmw6upHQhhdbHJh/YETMF22ovrJtVen9QGJprRWcfVbSEyckSaUvskBa8EtA5jiN4QEi3fLK25VEATbnBbfFUaG9TmEsL8dn9kaDxXWswC+QB5ksgM7WX0iI4gzSA6oU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ore@pengutronix.de>) id 1rScGd-0007o8-1C; Wed, 24 Jan 2024 13:22:07 +0100 Received: from [2a0a:edc0:0:1101:1d::ac] (helo=dude04.red.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <ore@pengutronix.de>) id 1rScGc-0023Ze-1P; Wed, 24 Jan 2024 13:22:06 +0100 Received: from ore by dude04.red.stw.pengutronix.de with local (Exim 4.96) (envelope-from <ore@pengutronix.de>) id 1rScGb-00341O-34; Wed, 24 Jan 2024 13:22:05 +0100 From: Oleksij Rempel <o.rempel@pengutronix.de> To: Sebastian Reichel <sre@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Oleksij Rempel <o.rempel@pengutronix.de>, kernel@pengutronix.de, linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, Zhang Rui <rui.zhang@intel.com>, Lukasz Luba <lukasz.luba@arm.com>, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, =?utf-8?q?S=C3=B8ren_Andersen?= <san@skov.dk> Subject: [PATCH v2 4/8] dt-bindings: power: reset: add bindings for NVMEM hardware storing PSCR Data Date: Wed, 24 Jan 2024 13:22:00 +0100 Message-Id: <20240124122204.730370-5-o.rempel@pengutronix.de> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240124122204.730370-1-o.rempel@pengutronix.de> References: <20240124122204.730370-1-o.rempel@pengutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788974471649273266 X-GMAIL-MSGID: 1788974471649273266 |
Series |
Introduction of PSCR Framework and Related Components
|
|
Commit Message
Oleksij Rempel
Jan. 24, 2024, 12:22 p.m. UTC
Add device tree bindings that describe hardware implementations of
Non-Volatile Memory (NVMEM) used for storing Power State Change Reasons
(PSCR).
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
.../bindings/power/reset/pscrr-nvmem.yaml | 53 +++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml
Comments
On 24/01/2024 13:22, Oleksij Rempel wrote: > Add device tree bindings that describe hardware implementations of > Non-Volatile Memory (NVMEM) used for storing Power State Change Reasons > (PSCR). A nit, subject: drop second/last, redundant "bindings for". The "dt-bindings" prefix is already stating that these are bindings. See also: https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18 > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> > --- > .../bindings/power/reset/pscrr-nvmem.yaml | 53 +++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml > > diff --git a/Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml b/Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml > new file mode 100644 > index 000000000000..779920dea283 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml > @@ -0,0 +1,53 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/power/reset/pscrr-nvmem.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Generic NVMEM Power State Change Reason Recorder > + > +maintainers: > + - Oleksij Rempel <o.rempel@pengutronix.de> > + > +description: This binding describes the Non-Volatile Memory (NVMEM) hardware Same comment and also: describe the hardware, not the binding. s/This binding describes/something useful/ > + that stores Power State Change Reasons (PSCR). > + > +allOf: > + - $ref: pscrr.yaml# > + > +properties: > + compatible: > + const: pscrr-nvmem > + So that's a driver :/. Maybe Rob will like it, but it's a no from me. Please come up with something really suiting DEVICES, not DRIVERS. > + nvmem-cells: > + description: | Do not need '|' unless you need to preserve formatting. > + A phandle pointing to the nvmem-cells node where the power state change > + reasons are stored. > + maxItems: 1 > + Best regards, Krzysztof
On Thu, Jan 25, 2024 at 11:57:18AM +0100, Krzysztof Kozlowski wrote: > On 24/01/2024 13:22, Oleksij Rempel wrote: > > Add device tree bindings that describe hardware implementations of > > Non-Volatile Memory (NVMEM) used for storing Power State Change Reasons > > (PSCR). > > + that stores Power State Change Reasons (PSCR). > > + > > +allOf: > > + - $ref: pscrr.yaml# > > + > > +properties: > > + compatible: > > + const: pscrr-nvmem > > + > > So that's a driver :/. Maybe Rob will like it, but it's a no from me. > Please come up with something really suiting DEVICES, not DRIVERS. If I understand your distinction between 'DEVICES' and 'DRIVERS' correctly, 'DEVICES' in the device tree context are meant to represent physical hardware components, while 'DRIVERS' refer to software abstractions of these components. However, there are numerous device tree instances, like software-based implementations for SPI, I2C, or GPIO, which could also be interpreted as 'DRIVERS' in the context of your email. Similarly, the binding for PSCRR represents functionality not fully implemented in hardware but supported by the hardware component of NVMEM, akin to how ramoops or other functionalities are represented. If I'm misunderstanding your distinction between 'DEVICES' and 'DRIVERS', please clarify with an example of how a proper binding should be implemented for a case like this. Regards, Oleksij
On 25/01/2024 18:11, Oleksij Rempel wrote: > On Thu, Jan 25, 2024 at 11:57:18AM +0100, Krzysztof Kozlowski wrote: >> On 24/01/2024 13:22, Oleksij Rempel wrote: >>> Add device tree bindings that describe hardware implementations of >>> Non-Volatile Memory (NVMEM) used for storing Power State Change Reasons >>> (PSCR). >>> + that stores Power State Change Reasons (PSCR). >>> + >>> +allOf: >>> + - $ref: pscrr.yaml# >>> + >>> +properties: >>> + compatible: >>> + const: pscrr-nvmem >>> + >> >> So that's a driver :/. Maybe Rob will like it, but it's a no from me. >> Please come up with something really suiting DEVICES, not DRIVERS. > > If I understand your distinction between 'DEVICES' and 'DRIVERS' > correctly, 'DEVICES' in the device tree context are meant to represent > physical hardware components, while 'DRIVERS' refer to software Yes. > abstractions of these components. However, there are numerous device > tree instances, like software-based implementations for SPI, I2C, or > GPIO, which could also be interpreted as 'DRIVERS' in the context of True. Yet they are still for physical interfaces. There is no DTS having some virtual I2C for a board which does not have I2C. > your email. Similarly, the binding for PSCRR represents functionality not > fully implemented in hardware but supported by the hardware component of > NVMEM, akin to how ramoops or other functionalities are represented. You don't need a binding for your case. Instantiate it whatever you wish - modprobe for example - and configure through approved kernel interfaces - sysfs for example. Best regards, Krzysztof
On Fri, Jan 26, 2024 at 10:03:51AM +0100, Krzysztof Kozlowski wrote: > On 25/01/2024 18:11, Oleksij Rempel wrote: > > On Thu, Jan 25, 2024 at 11:57:18AM +0100, Krzysztof Kozlowski wrote: > >> On 24/01/2024 13:22, Oleksij Rempel wrote: > >>> Add device tree bindings that describe hardware implementations of > >>> Non-Volatile Memory (NVMEM) used for storing Power State Change Reasons > >>> (PSCR). > >>> + that stores Power State Change Reasons (PSCR). > >>> + > >>> +allOf: > >>> + - $ref: pscrr.yaml# > >>> + > >>> +properties: > >>> + compatible: > >>> + const: pscrr-nvmem > >>> + > >> > >> So that's a driver :/. Maybe Rob will like it, but it's a no from me. > >> Please come up with something really suiting DEVICES, not DRIVERS. > > > > If I understand your distinction between 'DEVICES' and 'DRIVERS' > > correctly, 'DEVICES' in the device tree context are meant to represent > > physical hardware components, while 'DRIVERS' refer to software > > Yes. > > > abstractions of these components. However, there are numerous device > > tree instances, like software-based implementations for SPI, I2C, or > > GPIO, which could also be interpreted as 'DRIVERS' in the context of > > True. Yet they are still for physical interfaces. There is no DTS having > some virtual I2C for a board which does not have I2C. > > > your email. Similarly, the binding for PSCRR represents functionality not > > fully implemented in hardware but supported by the hardware component of > > NVMEM, akin to how ramoops or other functionalities are represented. > > You don't need a binding for your case. Instantiate it whatever you wish > - modprobe for example - and configure through approved kernel > interfaces - sysfs for example. About using sysfs for the NVMEM cell, it won't work for my needs because I have to know about reboot events before the filesystem is ready. So, I'm thinking of using a boot parameter for the kernel. It would look like this: pscrr-nvmem.nvmem_cell_alias=nvmem-cell0. This way, I can set up the NVMEM cell right at the system's start. I'll need to use stable NVMEM cell names for this. Is it ok to introduce NVMEM cell aliases in the devicetree? Best Regards, Oleksij
On 26/01/2024 17:51, Oleksij Rempel wrote: > On Fri, Jan 26, 2024 at 10:03:51AM +0100, Krzysztof Kozlowski wrote: >> On 25/01/2024 18:11, Oleksij Rempel wrote: >>> On Thu, Jan 25, 2024 at 11:57:18AM +0100, Krzysztof Kozlowski wrote: >>>> On 24/01/2024 13:22, Oleksij Rempel wrote: >>>>> Add device tree bindings that describe hardware implementations of >>>>> Non-Volatile Memory (NVMEM) used for storing Power State Change Reasons >>>>> (PSCR). >>>>> + that stores Power State Change Reasons (PSCR). >>>>> + >>>>> +allOf: >>>>> + - $ref: pscrr.yaml# >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + const: pscrr-nvmem >>>>> + >>>> >>>> So that's a driver :/. Maybe Rob will like it, but it's a no from me. >>>> Please come up with something really suiting DEVICES, not DRIVERS. >>> >>> If I understand your distinction between 'DEVICES' and 'DRIVERS' >>> correctly, 'DEVICES' in the device tree context are meant to represent >>> physical hardware components, while 'DRIVERS' refer to software >> >> Yes. >> >>> abstractions of these components. However, there are numerous device >>> tree instances, like software-based implementations for SPI, I2C, or >>> GPIO, which could also be interpreted as 'DRIVERS' in the context of >> >> True. Yet they are still for physical interfaces. There is no DTS having >> some virtual I2C for a board which does not have I2C. >> >>> your email. Similarly, the binding for PSCRR represents functionality not >>> fully implemented in hardware but supported by the hardware component of >>> NVMEM, akin to how ramoops or other functionalities are represented. >> >> You don't need a binding for your case. Instantiate it whatever you wish >> - modprobe for example - and configure through approved kernel >> interfaces - sysfs for example. > > About using sysfs for the NVMEM cell, it won't work for my needs because > I have to know about reboot events before the filesystem is ready. So, initrd can configure it before mounting filesystem. > I'm thinking of using a boot parameter for the kernel. It would look > like this: pscrr-nvmem.nvmem_cell_alias=nvmem-cell0. This way, I can set > up the NVMEM cell right at the system's start. I'll need to use stable > NVMEM cell names for this. Is it ok to introduce NVMEM cell aliases in > the devicetree? In my opinion no, because the point of Devicetree is not to solve your system init problems. You add pure software node which should not be in your DTS for many reasons: it is not a hardware description and it is a software policy enforced on all users of DTS without actually consulting them. Also, this solution ignores ACPI systems. Developing a proper interface would work on ACPI as well. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml b/Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml new file mode 100644 index 000000000000..779920dea283 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/pscrr-nvmem.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/pscrr-nvmem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic NVMEM Power State Change Reason Recorder + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +description: This binding describes the Non-Volatile Memory (NVMEM) hardware + that stores Power State Change Reasons (PSCR). + +allOf: + - $ref: pscrr.yaml# + +properties: + compatible: + const: pscrr-nvmem + + nvmem-cells: + description: | + A phandle pointing to the nvmem-cells node where the power state change + reasons are stored. + maxItems: 1 + + nvmem-cell-names: + items: + - const: pscr + + pscr-under-voltage: true + pscr-over-current: true + pscr-regulator-failure: true + pscr-over-temperature: true + +required: + - compatible + - nvmem-cells + - nvmem-cell-names + +additionalProperties: false + +examples: + - | + power-state-change-reason { + compatible = "pscrr-nvmem"; + nvmem-cells = <&pscr_cell>; + nvmem-cell-names = "pscr"; + pscr-under-voltage = <1>; + pscr-over-temperature = <2>; + }; +...