Dear Detlev Zundel,
In message m28w44gx6a.fsf@ohwell.denx.de you wrote:
Even though its pretty descriptive - for the sake of consistency I recommend to omit the "_mhz" part.
I know that I will mutter a not so nice remark every time I use the variable and am forced to look up the documentation for a single setenv command instead of typing 4 more characters.
I understand what you mean, but then - have a guess on how many "*clk" and "*clock" symbols we use in U-Boot, and how many in Linux - and how many of these use a unit suffix?
Actually I also think that using MHz as unit is broken by design - keep in mind that we use Hz basicly everywhere else, and for a reason.
I still remember the days of "clocks_in_mhz" and the waste of time it produced - maybe this is why I continue to raise this concern.
Note that the Linux kernel changed this interface from MHz to Hz by then!
Where would be the problem? In this case, we are talking about an environment variable; here we are using a string representation of (more or less) arbitrary size.
If we really shoould see CPU clocks way beyond 4 GHz one day, the code needs to deal with htat in an appropriate way - but even if you decide to operate in a MHz unit internally, you can still use Hz at the interface.
As long as all other clocks are specified in Hz, I strongly recommend to do the same here, too.
Can we agree on "cpumaxclk" ?
If nobody else shares my concerncs this sounds good.
Thinking again about this, I actually tend to prefer
"maxcpuclk"
:-)
Best regards,
Wolfgang Denk