[PATCH 11/24] ARM: OMAP2+: clock: remove support for legacy mpurate command line param

[Tero Kristo]

On 03/06/2015 06:25 PM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo at ti.com> [150306 08:10]:
>> On 03/06/2015 05:32 PM, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo at ti.com> [150306 04:29]:
>>>> The legacy support is wrong and dangerous, as it doesn't take any
>>>> OPPs into account and does not scale voltages. Switching mpurate should
>>>> be handled through cpufreq.
>>>
>>> Hmm I wonder if some systems actually rely on the mpurate cmdline
>>> parameter. If this cannot be fixed properly, you should at least
>>> print an error here.
>>
>> Yea, I was kind of worried about this comment. We have also an option of
>> doing this through clock driver, but I was hesitant of doing this either.
>> Isn't having a global kernel option like this frowned upon anyway? I believe
>> this piece of init code gets executed on every board on multiarch kernel.
>
> Well the option has been there probably for 10 years already so we
> can't just drop it like that. Chances are it's unused though, so I
> suggest you just print out a warning for it.
>
> It's called from omap_arch_initcall which checks for soc_is_omap()
> so that's not an issue. But when moving the code, you naturally
> need to check the moved code initcall usage.

This patch is not really needed for the set itself btw, it can just be 
dropped if you feel it actually is used by someone. Reverting it from 
the set just causes a minor merge conflict and you can't remove two of 
the otherwise empty clock files.

You could also just move the code over to clock.c maybe, merge these and 
do a soc type check to reach the same behaviour.

-Tero