On Tue, Dec 17, 2024 at 09:57:26AM +0530, Viresh Kumar wrote: > On 16-12-24, 23:15, Beata Michalska wrote: > > My bad as I must have misinterpreted that message. Although I am not entirely > > sure why this might be unacceptable as it is not such uncommon approach to use > > signed int space to cover both: expected positive value as well as potential > > error code case failure. > > This part is fine. The problem is with handling frequency here. Signed int can > capture up to 2 GHz of freq, where as unsigned int can capture up to 4 GHz and > so we would really like to keep it at 4 GHz.. Right, though the arch_freq_get_on_cpu operates on kHz values. --- BR Beata > > Maybe we need to move to 64 bits for frequency at some point of time, but at > least we should try to not break it for now. > > > Enabling the new attribute for all is an option, tough not entirely compelling > > one as exposing a feature that is known not to be supported seems bit > > counterintuitive. On the other hand using cpufreq driver flags won't help much > > as the support for the new attrib is platform-specific, not driver-specific. > > -- > viresh
