Hi Wolfgang,
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?
Sure - if one uses the canonical unit, then no suffix is needed. I never said anything else.
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!
Sure - still this left an impression on me ;)
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.
Yep, I know. I only stated that using Hz for such numbers for user changeable values probably will create a few "misentries" which will be somewhat hard to diagnose. If this is not a concern - I'll gladly go with the canonical unit.
As long as all other clocks are specified in Hz, I strongly recommend to do the same here, too.
Well sure - as always, it's a compromise. One should consider all the pros and cons and then _decide and document_. We are in complete accordance.
Can we agree on "cpumaxclk" ?
If nobody else shares my concerncs this sounds good.
Thinking again about this, I actually tend to prefer
"maxcpuclk"
:-)
Whatever - my concerns were not coupled to permutations ;)
Cheers Detlev