mvebu cpuidle and cpufreq branch handling for v3.17

Jason Cooper jason at lakedaemon.net
Fri Jul 18 16:07:40 PDT 2014


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.



More information about the linux-arm-kernel mailing list