Received-SPF: pass (google.com: domain of linux-kernel+bounces-40378-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 26 Jan 2024 17:51:53 +0100
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Sebastian Reichel <sre@kernel.org>, linux-kernel@vger.kernel.org,
	=?utf-8?B?U8O4cmVu?= Andersen <san@skov.dk>,
	Rob Herring <robh+dt@kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	kernel@pengutronix.de, linux-pm@vger.kernel.org,
	Zhang Rui <rui.zhang@intel.com>, Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: [PATCH v2 4/8] dt-bindings: power: reset: add bindings for NVMEM
 hardware storing PSCR Data
Message-ID: <20240126165153.GA468528@pengutronix.de>
References: <20240124122204.730370-1-o.rempel@pengutronix.de>
 <20240124122204.730370-5-o.rempel@pengutronix.de>
 <4e14b7c7-7f0a-437b-aa84-20fdc30a2361@linaro.org>
 <20240125171146.GC381737@pengutronix.de>
 <58d24ddc-4e8f-4932-ac37-c9a699d36425@linaro.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <58d24ddc-4e8f-4932-ac37-c9a699d36425@linaro.org>
User-Agent: Mutt/1.10.1 (2018-07-13)

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
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |