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

[Tony Lindgren]

* Tero Kristo <t-kristo at ti.com> [150309 05:56]:
> 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.

How about set it up in a way where it can be easily reverted later
on if there is need for that?
 
> 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.

If it's needed yeah.

Regards,

Tony