No subject

the maximum speed reachable using cpufreq"

> As far as I understand you, it is a maximum frequency, correct?  The
> absolute limit is given by the labeling of individual parts - but for
> whatever reason - maybe the user also wants to influence that.

The user does not "influence" this rating. Do you call it influenced by
user because there is an environment variable to set this? The way
the patch is written it can also be specified in the board configuration
header file. The environment variable is just a convenience option. The
expectation is that the user will rebuild U-Boot based on which silicon
he is using so he doesn't have to set the environment variable at all.

So, the user is just "configuring" the software according to the
hardware. There no user "influence" on the silicon speed grade.

>  So why
> not call it "maximum operating frequency"?

Yes, that's a correct description. Where do you want to call it such?

> If you really do have to pass the informatino to the kernel (why does no
> other SoC in ARM use such a aconcept yet?  How do they handle multiple
> frequencies?) and because I'm not too familiar with the ATAGs (flat
> device trees are far superior), let's see what the current Linux kernel
> declares.  [Studying the code] Ah, in arch/avr32/include/asm/setup.h
> someone came up with the idea to create a generic ATAG_CLOCK tag.  That
> does look promising - it scales, i.e. one can specify multiple "clocks"
> (i.e. core, bus, whatever) and it uses long long so it will not overflow
> in the near future.
>
> Why not reuse such an existing concept which matches your usage much
> better (arch/arm/include/asm/setup.h comments ATAG_REVISION as "board
> revision")?

Note again that we are not trying to pass information regarding the
current clock speed here. We are passing information regarding a silicon
characteristic. The DA850 kernel reads the system registers directly to
find out the clock speed. Even in the avr32 platform this ATAG is unused.