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

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
-- 
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 |