Re: PATCH - update TSC freq when cpufreq changes it

Max Laier wrote:
> On Tuesday 27 February 2007 23:16, Nate Lawson wrote:
>> Attached is a patch that uses eventhandlers to update the TSC freq.
>> This is important because DELAY() uses TSC directly (on i386 and amd64)
>> but the rate calculated at boot changes if cpufreq is in use.
>>
>> It maintains current behavior that cpufreq transitions are denied if
>> TSC is the active timecounter.  The API is that there is a pre and post
>> transition eventhandler that is called by the cpufreq core.  The pre
>> handler is passed the next state (including freq, power, etc.) and can
>> store a non-zero status value in the output arg to indicate it wants to
>> reject the transition.  The post handler also is passed the next state
>> and the result of the transition (0 on success).
> 
> Any reason for passing the result to the post handler in by reference - 
> other than being able to re-use the same function type as in the pre 
> handler?  API-wise this seems to be a mistake as one consumer could mess 
> up the result for the rest and the variable name "error" in the INVOKE 
> also suggests that this could be used to report back.

Yes, the main gaol was to reuse the function.  Plus I thought in the
future there might be some conceivable need to revoke a change after it
had occurred ("oops! change right back!").  We wouldn't need to change
an API to allow that.

Unless there's a real problem with it, I'd like to keep that ability in
the API.  To make it clear though, I should probably assign error to
some tmp var and pass that in to cpufreq_post_change handlers so it has
no effect if the user overwrites it.

-- 
Nate