(xen) stable/for-linus-3.4-tag-two (or three depending on your taste) for v3.4-rc0

Hey Linus,

I mentioned in the first git pull I would be sending another one after the cpu frequency tree was pulled and here it is:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.4-tag-two

However, I might have messed up a bit. The reason for this delay was that one patch ("xen/cpufreq: Disable the cpu frequency scaling drivers from loading") in my tree depended on ("provide disable_cpufreq() function to disable the API.") which was in the cpufreq tree. To not cause bisection issues (such as hitting on my patch without the dependency patch and getting a compile failure), I cherry-picked that specific patch into my branch from the cpufreq tree - and is part of the above mentioned tag.

So the problem is when I do the git pull against your latest, it doesn't apply the "provide .." but I still see it in the git shortlog!? Is that OK?

If that is not OK, I've done the unthinkable and created another branch (and yet another tag), which is based on your yesterday tree and is based off cf821923ba9aa0917165a12573bdd6dc0a354421. With that the shortlog does not include the "provide.." patch (obviously since that is the merge of the cpufreq tree).

So if you prefer to pull that one instead, please pull:

git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.4-tag-three

Either way, the git diff looks exactly the same.

Igor Mammedov (1):
xen: initialize platform-pci even if xen_emul_unplug=never

Jan Beulich (1):
xen/tmem: cleanup

Konrad Rzeszutek Wilk (6):
provide disable_cpufreq() function to disable the API. xen/cpufreq: Disable the cpu frequency scaling drivers from loading. xen/acpi-processor: Do not depend on CPU frequency scaling drivers. xen/acpi: Remove the WARN's as they just create noise. xen/smp: Fix bringup bug in AP code.
xen/acpi: Fix Kconfig dependency on CPU_FREQ

Stefano Stabellini (1):
xen: support pirq_eoi_map

 arch/x86/xen/setup.c             |    2 ++
 arch/x86/xen/smp.c               |    6 ++++++
 drivers/block/xen-blkfront.c     |    3 +++
 drivers/net/xen-netfront.c       |    4 ++++
 drivers/xen/Kconfig              |    5 ++---
 drivers/xen/events.c             |   26 +++++++++++++++++++++++---
 drivers/xen/platform-pci.c       |    5 -----
 drivers/xen/tmem.c               |   21 ++++++++-------------
 drivers/xen/xen-acpi-processor.c |    4 ++--
 include/xen/interface/physdev.h  |   21 +++++++++++++++++++++
 include/xen/tmem.h               |    6 +++++-
 11 files changed, 76 insertions(+), 27 deletions(-)

The fact that you see it in the shortlog just means that the commit is there. If you don't see it in the diff, it is because somebody else applied the *same* patch, but as a separate commit, so the merge will have just considered it a no-op.

It's not uncommon, and if it happens occasionally with duplicated patches that's fine. If it happens a *lot* that two people keep applying the same patch to their different branches, that implies that there's some workflow problem where people continually keep on stepping on each others toes, and that's a problem.

But the occasional "oops, that change was already in mainline" is fine.

Linus