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
