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