linux-kernel - Re: [PATCH v2 4/8] dt-bindings: power: reset: add bindings for NVMEM hardware storing PSCR Data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58d24ddc-4e8f-4932-ac37-c9a699d36425@linaro.org>
Date: Fri, 26 Jan 2024 10:03:51 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Sebastian Reichel <sre@...nel.org>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, kernel@...gutronix.de,
 linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui <rui.zhang@...el.com>,
 Lukasz Luba <lukasz.luba@....com>, linux-pm@...r.kernel.org,
 devicetree@...r.kernel.org, Søren Andersen <san@...v.dk>
Subject: Re: [PATCH v2 4/8] dt-bindings: power: reset: add bindings for NVMEM
 hardware storing PSCR Data

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