> >Hey Dmitry, > >Thanks for taking time to review the series. > >+ Devfreq maintainers to comment (I thought you already added >them by name) > > >Hey MyungJoo/Kyungmin/Chanwoo, > >Can you weigh in here? Does it make sense to add a new >class of devfreq devices that don't have governors >associated with them just for them to export a few >essential data to userspace? In this scenario the >scaling algorithm is in a SCP and we just start >them from the kernel. We do have ways to get the >current frequency of various buses but does this >warrant adding a new class of governor less devices? > >-Sibi If voltage/frequency is controlled by SCP (it's an SoC's internal hardware IP, right?), it's good to have a userspace governer with the driver not accepting updates from userspace. E.g., Let "target" callback not update the frequency value, or let "target" callback always return an error with a dev_err message that you don't accept frequency changes from userspace. Cheers, MyungJoo.
