[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6700479.xPkgXUV5KL@vostro.rjw.lan>
Date: Fri, 25 Oct 2013 16:12:25 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
Patch Tracking <patches@...aro.org>,
"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 Resend 00/34] CPUFreq Cleanup Part III
On Friday, October 25, 2013 07:25:45 PM Viresh Kumar wrote:
> On 25 October 2013 18:26, Rafael J. Wysocki <rjw@...k.pl> wrote:
> > Having considered that a bit I think that I'd prefer one patch doing all of
> > these changes in one go (and with all applicable ACKs collected), one of the
> > reasons being that if it is necessary to revert that stuff, whatever the
> > reason, it will be much easier to do that with just one commit than with
> > 34 of them.
>
> With a similar reason I think the probability is more that a revert might
> be required for individual drivers as they may need to switch back to
> ->target() instead of ->target_index() and so keeping them separate
> might be better.
>
> In case we need to revert all patches due to some breakage, we can
> always do that in a single commit if required.
>
> What do you say?
If I need to revert the first patch, then I'll need to revert all of them.
Also, if you do the same change in multiple places it actually is easier
to handle it pretty much regardless of the angle you look at that from
if that's done in one patch. Please do that.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists