<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next">
    <title>gmane.linux.kernel.next</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22628"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22627"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22625"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22624"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22622"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22621"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22620"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22619"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22618"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22617"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22616"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22615"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22614"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22613"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22612"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22611"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22610"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22609"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22608"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.kernel.next/22607"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22628">
    <title>Re: [patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22628</link>
    <description>&lt;pre&gt;

The reason we're selecting things from the users is that multi-level
selects have never seemed to be terribly robust, they've been a
noticable source of breakage with this sort of randconfig stuff in the
past which is painful and annoying, especially given the strange fixes
that tend to come from randconfig reports.

That said a "select X if Y" construct doesn't ever seem to have this
problem...  I'm just sending a patch doing that now.
&lt;/pre&gt;</description>
    <dc:creator>Mark Brown</dc:creator>
    <dc:date>2012-05-23T09:32:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22627">
    <title>[SOLUTION]  linux-next: build failure after merge of the mfd tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22627</link>
    <description>&lt;pre&gt;Hi Samuel,

This should sort you out.

The old code protected under 'AB8500_I2C_CORE' depended on 'MFD_DB8500_PRCMU'.

From: Lee Jones &amp;lt;lee.jones&amp;lt; at &amp;gt;linaro.org&amp;gt;
Date: Wed, 23 May 2012 10:08:51 +0100
Subject: [PATCH] MFD: Assign MFD_DB8500_PRCMU dependency for building ab8500-core

A recent move to eliminate excess historical baggage from ab8500 core
code resulting in errors when building with x86_64 allmodconfig:

In file included from drivers/mfd/ab8500-core.c:21:0:
include/linux/mfd/dbx500-prcmu.h:614:19: error: redefinition of 'prcmu_abb_read'
include/linux/mfd/db8500-prcmu.h:673:19: note: previous definition of 'prcmu_abb_read' was here
include/linux/mfd/dbx500-prcmu.h:619:19: error: redefinition of 'prcmu_abb_write'
include/linux/mfd/db8500-prcmu.h:678:19: note: previous definition of 'prcmu_abb_write' was here
include/linux/mfd/dbx500-prcmu.h:630:19: error: redefinition of 'prcmu_config_clkout'
include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_config_clkout' was here
include/lin&lt;/pre&gt;</description>
    <dc:creator>Lee Jones</dc:creator>
    <dc:date>2012-05-23T09:22:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22625">
    <title>linux-next: Tree for May 23</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22625</link>
    <description>&lt;pre&gt;Hi all,

Changes since 20120522:

New tree: signal

With the merge window open, conflicts are moving from tree to tree.

The i386 defconfig build is still broken.

The nfs tree lost its conflict.

The rr tree gained a conflict against Linus' tree.

The mmc tree lost its conflict.

The mfd tree gained a conflict against Linus' tree and still has its build
failure so I used the version from next-20120511.

The security tree lost its conflicts.

The watchdog tree lost its conflict but gained a build failure for which
I applied a patch.

The trivial tree lost a conflict.

The edac tree lost its conflict.

The tip tree lost a conflict.

The usb tree lost its conflicts.

The staging tree lost its conflicts.

The char-misc tree lost its conflict.

The arm-soc tree lost lots of conflicts.

The signal tree gained a conflict against the tip tree.

The akpm tree lost several patches to the new signal tree.

----------------------------------------------------------------------------

I have created today's linux-next t&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T07:07:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22624">
    <title>[patch -linus] regmap: REMAP_IRQ should select IRQ_DOMAIN itself</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22624</link>
    <description>&lt;pre&gt;

This brekage has already made it to Linus and doesn't only affect i386.  
It happens because CONFIG_MFD_PALMAS doesn't select CONFIG_IRQ_DOMAIN like 
the rest of the options that were patched in 4af8be67fd99 ("regmap: 
Convert regmap_irq to use irq_domain").  This is the only remaining 
Kconfig entry that selects CONFIG_REGMAP_IRQ and misses CONFIG_IRQ_DOMAIN.


regmap: REMAP_IRQ should select IRQ_DOMAIN itself

CONFIG_REGMAP_IRQ relies on CONFIG_IRQ_DOMAIN since 4af8be67fd99 ("regmap: 
Convert regmap_irq to use irq_domain").

Instead of ensuring all options that select REGMAP_IRQ also select 
IRQ_DOMAIN, just make the former select the latter itself.

Cc: Mark Brown &amp;lt;broonie&amp;lt; at &amp;gt;opensource.wolfsonmicro.com&amp;gt;
Reported-by: Randy Dunlap &amp;lt;rdunlap&amp;lt; at &amp;gt;xenotime.net&amp;gt;
Signed-off-by: David Rientjes &amp;lt;rientjes&amp;lt; at &amp;gt;google.com&amp;gt;
---
 drivers/base/regmap/Kconfig |    1 +
 drivers/mfd/Kconfig         |    3 ---
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
---&lt;/pre&gt;</description>
    <dc:creator>David Rientjes</dc:creator>
    <dc:date>2012-05-23T06:57:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22622">
    <title>Re: linux-next: manual merge of the usb tree with the v4l-dvb tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22622</link>
    <description>&lt;pre&gt;
This looks correct, thanks.

greg k-h
&lt;/pre&gt;</description>
    <dc:creator>Greg KH</dc:creator>
    <dc:date>2012-05-23T06:22:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22621">
    <title>linux-next: manual merge of the signal tree with the tip tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22621</link>
    <description>&lt;pre&gt;Hi Al,

Today's linux-next merge of the signal tree got a conflict in
arch/um/Kconfig.common between commit 875c9d09b5a6 ("um: Use generic time
config") from the tip tree and commit 985a94a96d29 ("um: Remove
CONFIG_IRQ_RELEASE_METHOD") from the signal tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T06:02:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22620">
    <title>Re: linux-next: manual merge of the watchdog tree with the mfd tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22620</link>
    <description>&lt;pre&gt;Hi Sam,

Since %04llx with a typecast to u64 is the way to go (Thanks Stephen and Randy)...


Can you carry Randy's patch/fix (since it fixes the change introduced by the iTCO_wdt mfd patch)?
If not then I will apply the patch later on once the iTCO_wdt mfd patch is mainstream.

Kind regards,
Wim.

&lt;/pre&gt;</description>
    <dc:creator>Wim Van Sebroeck</dc:creator>
    <dc:date>2012-05-23T05:44:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22619">
    <title>Re: signal.git</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22619</link>
    <description>&lt;pre&gt;Hi Al,

On Wed, 23 May 2012 06:22:35 +0100 Al Viro &amp;lt;viro&amp;lt; at &amp;gt;ZenIV.linux.org.uk&amp;gt; wrote:

OK, since a lot of this has been in Andrew's patch series for a while, I
will add this tree today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T05:30:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22618">
    <title>signal.git</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22618</link>
    <description>&lt;pre&gt;Sorry for not having done that earlier; the tree is at
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal #for-next.
No non-trivial conflicts with akpm-base - only arch/*/Kconfig ones
coming from mainline.  A _lot_ of duplicates with akpm - 20 commits
from Matt and Oleg are all cherry-picked from there.

I've included the recent uml.git pull request in there -
it's not in -next (and probably ought to be) and this time it
has a lot to do with the stuff being dealt with here.

I hope to get task_work_add() series through that tree,
once all prereqs are there; I'll send heads-up before doing that,
since those patches are currently in akpm's patchset (and unfortunately
they do need a bunch of commits not in there to get them working on
all architectures - some of those prereqs are in this branch, some
will need to be moved to it from signal.git#master)
&lt;/pre&gt;</description>
    <dc:creator>Al Viro</dc:creator>
    <dc:date>2012-05-23T05:22:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22617">
    <title>[patch] sched, numa: Allocate node_queue on any node for offline nodes</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22617</link>
    <description>&lt;pre&gt;struct node_queue must be allocated with NUMA_NO_NODE for nodes that are 
not (yet) online, otherwise the page allocator has a bad zonelist and 
results in an early crash.

Tested-by: Stephen Rothwell &amp;lt;sfr&amp;lt; at &amp;gt;canb.auug.org.au&amp;gt;
Signed-off-by: David Rientjes &amp;lt;rientjes&amp;lt; at &amp;gt;google.com&amp;gt;
---
 kernel/sched/numa.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/sched/numa.c b/kernel/sched/numa.c
--- a/kernel/sched/numa.c
+++ b/kernel/sched/numa.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -885,7 +885,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static __init int numa_init(void)
 
 for_each_node(node) {
 struct node_queue *nq = kmalloc_node(sizeof(*nq),
-GFP_KERNEL | __GFP_ZERO, node);
+GFP_KERNEL | __GFP_ZERO,
+node_online(node) ? node : NUMA_NO_NODE);
 BUG_ON(!nq);
 
 spin_lock_init(&amp;amp;nq-&amp;gt;lock);
&lt;/pre&gt;</description>
    <dc:creator>David Rientjes</dc:creator>
    <dc:date>2012-05-23T04:17:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22616">
    <title>Re: linux-next: triage for May 22, 2012</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22616</link>
    <description>&lt;pre&gt;Hi Paul,

On Tue, 22 May 2012 21:04:57 -0400 Paul Gortmaker &amp;lt;paul.gortmaker&amp;lt; at &amp;gt;windriver.com&amp;gt; wrote:

A bad merge in my tree - will be fixed today.


Ditto

&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T03:08:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22615">
    <title>linux-next: manual merge of the mfd tree with Linus' tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22615</link>
    <description>&lt;pre&gt;Hi Samuel,

Today's linux-next merge of the mfd tree got a conflict in
drivers/mfd/Makefile between commits dece3709b71a ("mfd/db5500-prcmu:
delete DB5500 PRCMU support") and 72fb92200d6c ("mfd/ab5500: delete
AB5500 support") from Linus' tree and commit d28f1db8187d ("mfd: Remove
confusing ab8500-i2c file and merge into ab8500-core") from the mfd tree.

I fixed it up (see below) and can carry the fix as necessary.
&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T03:01:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22614">
    <title>linux-next: bad merge in the block tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22614</link>
    <description>&lt;pre&gt;Hi Jens,

Commit 21731057017b ("Merge branch 'for-3.5/drivers' into for-next") has
left a conflict marker in Documentation/feature-removal-schedule.txt ...

&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T02:35:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22613">
    <title>Re: [PATCH] x86: auto poll/interrupt mode switch for CMC to stop CMC storm</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22613</link>
    <description>&lt;pre&gt;于 2012/5/23 10:30, Chen Gong 写道:

Oops, I send it to wrong LKML address. I will send this patch again.
&lt;/pre&gt;</description>
    <dc:creator>Chen Gong</dc:creator>
    <dc:date>2012-05-23T02:30:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22612">
    <title>[PATCH] x86: auto poll/interrupt mode switch for CMC to stop CMC storm</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22612</link>
    <description>&lt;pre&gt;This idea is inspired from IA64 implementation. It is like
NAPI for network stack. When CMCI is too many to handle,
this interrupt can be disabled and then poll mode will take
over the events handle. When no more events happen in the
system, CMC interrupt can be enabled automatically.

Signed-off-by: Chen Gong &amp;lt;gong.chen&amp;lt; at &amp;gt;linux.intel.com&amp;gt;
---
 arch/x86/kernel/cpu/mcheck/mce.c |   83 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 81 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index d086a09..6334f0d 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -92,6 +92,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static char*mce_helper_argv[2] = { mce_helper, NULL };
 
 static DECLARE_WAIT_QUEUE_HEAD(mce_chrdev_wait);
 
+static DEFINE_PER_CPU(struct timer_list, mce_timer);
 static DEFINE_PER_CPU(struct mce, mces_seen);
 static intcpu_missing;
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -100,8 +101,28 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; DEFINE_PER_CPU(mce_banks_t, mce_poll_banks) = {
 [0 ... BITS_TO_LONGS(MAX_NR_&lt;/pre&gt;</description>
    <dc:creator>Chen Gong</dc:creator>
    <dc:date>2012-05-23T02:30:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22611">
    <title>linux-next: manual merge of the rr tree with Linus' tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22611</link>
    <description>&lt;pre&gt;Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
Documentation/virtual/virtio-spec.txt between commit 33950c6e2269
("virtio: update documentation to v0.9.5 of spec") from Linus' tree and
commit e26259736de5 ("virtio: update documentation to v0.9.4 of spec")
from the rr tree.

I just used the version from Linus' tree.
&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T02:15:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22610">
    <title>Re: linux-next: build failure after merge of the final tree</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22610</link>
    <description>&lt;pre&gt;Hi Dave,

On Tue, 22 May 2012 15:05:25 -0400 (EDT) David Miller &amp;lt;davem&amp;lt; at &amp;gt;davemloft.net&amp;gt; wrote:

I bisected it down to my merge of the tip tree (commit 26b38c5887 in
next-20120522).  I only enable GENERIC_CLOCKEVENTS for sparc64 - I missed
a subtle interaction between commit 62f082830d63 ("sparc32: generic
clockevent support") from the sparc-next tree and commit ded1cc5cfc3b
("sparc: Use: generic time config") from the tip tree.

I will fix this up in linux-next today.  Sorry for the noise.
&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2012-05-23T02:08:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22609">
    <title>linux-next: triage for May 22, 2012</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22609</link>
    <description>&lt;pre&gt;With the merge window open, it is as good a time as any to catch up on
the failures in linux-next.  Please have a look to see if any of these
build failures might be related to your commits.

---------------------

New breakage since last report:

ARM:netx_defconfig (mach-netx/fb.c: redefinition of 'clk_disable')

ARM:u8500_defconfig (No rule to make `arch/arm/mach-ux500/pins.o')

ARM:imx_v4_v5_defconfig (video/mx2_camera.c: 'pixfmt' undeclared)

ARM:tegra_defconfig  (tegra-smmu.c: implicit decl 'of_get_dma_window')

blackfin: (implicit declaration of function 'UART_PUT_CLK')

ia64: (kernel/sched/numa.c: initializer element is not constant)

sh4: (kernel/process.c:23: implicit decl of function 'unlazy_fpu')


Randconfig fails that may or may not be new (by their very nature):
i386: include/asm/uaccess_32.h: call to 'copy_from_user_overflow'
declared with attribute error: copy_from_user() buffer size
is not provably correct [fs/binfmt_misc.o] Error 1


Builds that are fixed since last report:
ARM&lt;/pre&gt;</description>
    <dc:creator>Paul Gortmaker</dc:creator>
    <dc:date>2012-05-23T01:04:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22608">
    <title>Re: Bad ux500 merge fix leads to linux-next failure</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22608</link>
    <description>&lt;pre&gt;Hi,

Yeah, there was some confusion earlier, and I noticed that when
staging the branches for Linus last night. I'll rebuild for-next
tonight and take care of it then, thanks for the reminder!


-Olof

On Tue, May 22, 2012 at 5:03 PM, Paul Gortmaker
&amp;lt;paul.gortmaker&amp;lt; at &amp;gt;windriver.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Olof Johansson</dc:creator>
    <dc:date>2012-05-23T00:10:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22607">
    <title>Bad ux500 merge fix leads to linux-next failure</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22607</link>
    <description>&lt;pre&gt;Hi Olof,

This change:

-                                  id.o usb.o timer.o
+                                  id.o pins.o usb.o timer.o

breaks the u8500_defconfig as follows:

make[2]: *** No rule to make target `arch/arm/mach-ux500/pins.o', needed
by `arch/arm/mach-ux500/built-in.o'.  Stop.
make[1]: *** [arch/arm/mach-ux500/] Error 2
make: *** [sub-make] Error 2

A bisect shows the following:
  
cda6f4d8cae969e08e6662573b538db73191873b is the first bad commit
commit cda6f4d8cae969e08e6662573b538db73191873b
Author: Olof Johansson &amp;lt;olof&amp;lt; at &amp;gt;lixom.net&amp;gt;
Date:   Wed May 16 14:47:24 2012 -0700

    ARM: ux500: fix mismerge in for-next

    Signed-off-by: Olof Johansson &amp;lt;olof&amp;lt; at &amp;gt;lixom.net&amp;gt;

:040000 040000 abc42227f7daa6a7ff6153e0908add25ffb38a54
45d2618822e6075aea188089191791091c2e5c38 M      arch
bisect run success

The linux-next fail is here:
http://kisskb.ellerman.id.au/kisskb/buildresult/6348609/

Can you have a look please?

Thanks,
Paul.
&lt;/pre&gt;</description>
    <dc:creator>Paul Gortmaker</dc:creator>
    <dc:date>2012-05-23T00:03:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.kernel.next/22606">
    <title>"clk: add non CONFIG_HAVE_CLK routines" commit</title>
    <link>http://permalink.gmane.org/gmane.linux.kernel.next/22606</link>
    <description>&lt;pre&gt;Hi Viresh,

The above listed commit, in linux-next as:

commit ebbf0cb5d39cc3e22ef4c425475e76b7f45027de

    "clk: add non CONFIG_HAVE_CLK routines"

shows up as failures in the netx_defconfig, since there
are duplicate stub functions between your changes and the
file below:

  arch/arm/mach-netx/fb.c:72:6: error: redefinition of 'clk_disable'
  include/linux/clk.h:299:51: note: previous definition of 'clk_disable' was here
  arch/arm/mach-netx/fb.c:76:5: error: redefinition of 'clk_set_rate'
  include/linux/clk.h:306:50: note: previous definition of 'clk_set_rate' was here
  arch/arm/mach-netx/fb.c:81:5: error: redefinition of 'clk_enable'
  include/linux/clk.h:294:50: note: previous definition of 'clk_enable' was here
  arch/arm/mach-netx/fb.c:86:13: error: redefinition of 'clk_get'
  include/linux/clk.h:280:58: note: previous definition of 'clk_get' was here
  arch/arm/mach-netx/fb.c:91:6: error: redefinition of 'clk_put'
  include/linux/clk.h:290:51: note: previous definition of 'clk_put' was here
  make&lt;/pre&gt;</description>
    <dc:creator>Paul Gortmaker</dc:creator>
    <dc:date>2012-05-22T23:46:22</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.kernel.next">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.kernel.next</link>
  </textinput>
</rdf:RDF>

