On 7/28/22 02:20, Dmitry Baryshkov wrote: > On Thu, 28 Jul 2022 at 12:08, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: >> >> On Wed, Jul 27, 2022 at 11:09:01PM +0300, Dmitry Baryshkov wrote: >>> To ease debugging of PSCI supported features, add debugfs file called >>> 'psci' describing PSCI and SMC CC versions >> >> These 2 are for sure in the boot log. Having them is debugfs accessible >> via file system add not much value as we would hit issues quite early in >> the boot for most of the things related to PSCI. > > Yes, it was just to have all the information in a single place. > >>> enabled features and options. >>> >> >> We have psci_checker.c which does some minimal testing of PSCI. I prefer >> to add things to that rather than a debugfs as it is run during boot. IMO >> it is usual useful to debug things that cause boot issue most of the time. >> I am not against this so I will leave it to the maintainers. > > In my case I was not debugging the boot issues (which of course would > have required a different approach), but I was trying to understand > runtime capabilities, thus debugfs fits pretty well. > > Another point for the debugfs entry: most of the people run the kernel > with the psci_checker being turned off, but with debugfs being > enabled. If we are trying to narrow down firmware capabilities of the > random device, it is much easier to ask them to cat the dbeugfs file > rather than to rebuild the kernel. > Yes I would agree with both of those points, in fact, I would go one step further and add the ability to probe an arbitrary PSCI function ID, since deployed firmware typically go beyond the standard PSCI scope and implement a variety of custom extensions (at least we do). Thanks! -- Florian
