Hi Rob and Krzysztof, Following up on dt-schema PR #174 regarding the PSCRR framework. We are currently stuck in a maintainer deadlock regarding how this framework should bind to its NVMEM cell, and I need your consensus to proceed.
In the PR [1], Rob noted that /chosen only works if the OS standardizes the NVMEM values. If the values are platform-specific (requiring a mapping driver), Rob suggested creating a dedicated DT node akin to reboot-mode or nvmem-reboot-mode. However, in my earlier kernel patchsets [2] , Krzysztof explicitly NACKed a dedicated PSCRR DT node, stating that it represents "OS policy" and a software abstraction rather than physical hardware. Krzysztof suggested instantiating it via sysfs/modprobe. I attempted that in v11 , but Greg strongly rejected [3] the sysfs/module parameter approach as fragile and outdated for the driver core. We need a robust way to discover this cell during early boot across full power cuts. To break this catch-22, could you please agree on one of the following? - Option A (Dedicated DT node): Permit a dedicated pscrr-nvmem node (or a compatible string on a fixed-cell) as a valid firmware description contract, following the precedent of nvmem-reboot-mode. - Option B (/chosen property): Accept the /chosen phandle approach I am happy to implement whichever hardware/software binding pattern you both agree is correct for this edge case. Best Regards, Oleksij [1] https://github.com/devicetree-org/dt-schema/pull/174 [2] https://lore.kernel.org/all/[email protected]/ [3] https://lore.kernel.org/all/2025071631-henna-synthesis-9961@gregkh/ -- 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 |
