Re: [PATCH v11 0/7] Introduction of PSCR Framework and Related Components

[Faruque Ansari]

Hi Oleksij,

On 29-Jun-26 5:11 PM, Oleksij Rempel wrote:
> Hi Faruque,
>
> On Mon, Jun 29, 2026 at 04:44:18PM +0530, Faruque Ansari wrote:
> > On 29-Jun-26 4:40 PM, Faruque Ansari wrote:
> > > Hi Oleksij,
> > >
> > > > Hello all,
> > > >
> > > > This patch series introduces the Power State Change Reasons Recording
> > > > (PSCRR) framework and its related components into the kernel. The PSCR
> > > > framework is designed for systems where traditional methods of storing
> > > > power state change reasons, like PMICs or watchdogs, are inadequate. It
> > > > provides a structured way to store reasons for system shutdowns and
> > > > reboots, such as under-voltage or software-triggered events, in
> > > > non-volatile hardware storage.
> > > >
> > > > These changes are critical for systems requiring detailed postmortem
> > > > analysis and where immediate power-down scenarios limit traditional
> > > > storage options. The framework also assists bootloaders and early-stage
> > > > system components in making informed recovery decisions.
> > >
> > > Just wanted to understand rational behind creating this new framework
> > > (PSCRR) for
> > > reboot reason recording and not considering extending the existing
> > > nvmem-reboot
> > > framework ? As, this framework already provides a way to represent nvmem
> > > cell in
> > > the DT and the driver as well can discover it. Would it be correct if
> > > nvmem-reboot
> > > driver itself is extended with the features which this framework provides ?
> > >
> > > or was there any other reason you decided to create a new framework ?
>
> There are two main reasons:
> - nvmem-reboot - Tells the reboot target - What should system do after
>    reboot. This frameworks is collecting information - why we
>    rebooted/booted in the first place.
> - System may have more then one recorder or source of information. Non
>    of it provides full picture. This framework should provide easier
>    access to different providers. For example:
>    - SoC tells PoR
>    - PMIC tells PoR
>    - Watchdog tells nothing
>    - nvmem storage - tells under-voltage.
>
>    All of them provide own opinion on what is happened. Evaluation or
>    prioritisation should not be done in the kernel
>
> So far i struggled with DT, but may be i need to put it to the side for
> now to go forward?
>
> Best Regards,
> Oleksij



Thank You for sharing your rational behind and idea behind this 
framework !
IMO it would be better to have a single framework to represent 
all the reboot reasons of a system and not just the reboot 
reasons caused because of errors
Ex capturing reboot reasons like ota, bootloader,recovery etc ... 
currently nvmem reboot driver does not expose a sysfs/ABI which 
user app can use to infer reboot reason ...
Also, it would be extend this framework to also support firmware 
triggered reboot reasons  ...
Do you have any plan to extend this framework to support 
userspace triggered reboot reasons as well like bootloader, 
recovery, ota etc ?
And also extend the framework to support vendor specific reboot 
reasons which can be triggered by firmware  ?

We can co-work to extend this framework  ?

On representating nvmem cell to the framework  - if not DT what 
is your plan to represent it ?
How would framework discover the nvmem cell if its not DT based ?

Thanks,
Faruque Ansari