From: Jason Cooper <jason@lakedaemon.net>
To: Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
Kevin Hilman <khilman@linaro.org>,
arm@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>,
Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>,
linux-pm@vger.kernel.org
Subject: mvebu cpuidle and cpufreq branch handling for v3.17
Date: Fri, 18 Jul 2014 19:07:40 -0400 [thread overview]
Message-ID: <20140718230740.GR24496@titan.lakedaemon.net> (raw)
Arnd, Olof, Kevin,
I have two branches with the remaining mvebu SoC changes for v3.17.
They are mvebu/soc-cpuidle and mvebu/soc-cpufreq. Each branch is
slightly problematic because both contain changes to their respective
code in drivers/. To send the driver changes through the appropriate
subsystems would be a garish nightmare of branch on branch on branch.
Thankfully, the changes are isolated to drivers only mvebu uses, so
keeping it all together should cause minimal, if any, conflicts.
I've requested Acks from the appropriate maintainers but as it's summer
I'm not confident that we'll receive those Acks in time for the arm-soc
cutoff (-rc6 -ish).
As I see it, I could send arm-soc two topic branch pull requests, which
arm-soc would keep out separate on the remote chance of an objection.
Or, I could wait for the Acks (the code has already been in -next for
several days), merge it into mvebu/soc, and send a, most likely, late
pull request for it.
Which would you guys prefer?
The cpuidle branch and ML link:
git://git.infradead.org/linux-mvebu.git mvebu/soc-cpuidle
https://lkml.kernel.org/r/1404913221-17343-1-git-send-email-thomas.petazzoni@free-electrons.com
The cpufreq branch and ML link:
git://git.infradead.org/linux-mvebu.git mvebu/soc-cpufreq
https://lkml.kernel.org/r/1404920715-19834-1-git-send-email-thomas.petazzoni@free-electrons.com
thx,
Jason.
next reply other threads:[~2014-07-18 23:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-18 23:07 Jason Cooper [this message]
2014-07-18 23:51 ` mvebu cpuidle and cpufreq branch handling for v3.17 Rafael J. Wysocki
2014-07-18 23:36 ` Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140718230740.GR24496@titan.lakedaemon.net \
--to=jason@lakedaemon.net \
--cc=andrew@lunn.ch \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=daniel.lezcano@linaro.org \
--cc=gregory.clement@free-electrons.com \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rjw@rjwysocki.net \
--cc=sebastian.hesselbarth@googlemail.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox