From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH 11/24] ARM: OMAP2+: clock: remove support for legacy mpurate command line param Date: Mon, 9 Mar 2015 08:24:54 -0700 Message-ID: <20150309152453.GF5264@atomide.com> References: <1425644939-3232-1-git-send-email-t-kristo@ti.com> <1425644939-3232-12-git-send-email-t-kristo@ti.com> <20150306153254.GK13520@atomide.com> <54F9D160.7010708@ti.com> <20150306162516.GN13520@atomide.com> <54FD6306.4050109@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from muru.com ([72.249.23.125]:35856 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750930AbbCIPaF (ORCPT ); Mon, 9 Mar 2015 11:30:05 -0400 Content-Disposition: inline In-Reply-To: <54FD6306.4050109@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tero Kristo Cc: paul@pwsan.com, linux-omap@vger.kernel.org, mturquette@linaro.org, linux-arm-kernel@lists.infradead.org * Tero Kristo [150309 05:56]: > On 03/06/2015 06:25 PM, Tony Lindgren wrote: > >* Tero Kristo [150306 08:10]: > >>On 03/06/2015 05:32 PM, Tony Lindgren wrote: > >>>* Tero Kristo [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