Linux-Next discussions
 help / color / mirror / Atom feed
* Re: linux-next: manual merge of the arm-soc tree with the arm tree
From: Russell King @ 2011-10-24 21:16 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: Stephen Rothwell, Arnd Bergmann, linux-next, linux-kernel,
	Nicolas Pitre
In-Reply-To: <20111024210952.GQ23421@pengutronix.de>

On Mon, Oct 24, 2011 at 11:09:52PM +0200, Sascha Hauer wrote:
> On Mon, Oct 24, 2011 at 09:30:41PM +0100, Russell King wrote:
> > On Tue, Oct 25, 2011 at 07:20:13AM +1100, Stephen Rothwell wrote:
> > > Hi Arnd,
> > > 
> > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > arch/arm/plat-mxc/include/mach/memory.h between commit c039bad00f21
> > > ("ARM: plat-mxc: remove mach/memory.h") from the arm tree and commits
> > > ae4fa7f66e54 ("ARM i.MX: allow to compile together ARMv4 and ARMv5 based
> > > SoCs") and 7409cd1cd554 ("ARM i.MX: allow to compile together all i.MX5
> > > based SoCs") from the arm-soc tree.
> > > 
> > > The former removed the file, so I did that.
> > 
> > Stephen - thanks.
> > 
> > ARM guys, we need to be smarter about this stuff - if we're consolidating
> > code across the ARM tree, committing changes to files which we're going
> > to remove really isn't a good idea.  It probably means something else has
> > changed elsewhere to accomodate the deletion of the file, which this
> > kind of resolution won't fix up.
> 
> In this case deleting the file is the correct solution. I removed some
> definitions of PLAT_PHYS_OFFSET which got unused due to "ARM i.MX: allow
> to compile together..." and Nicolas removed the need for PLAT_PHYS_OFFSET
> at all.

Ok, at least this one is trivial.  Thanks for the confirmation.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply

* Re: linux-next: manual merge of the arm-soc tree with the arm tree
From: Rob Herring @ 2011-10-24 21:08 UTC (permalink / raw)
  To: Russell King, Arnd Bergmann
  Cc: Stephen Rothwell, linux-next, linux-kernel, Marc Zyngier
In-Reply-To: <20111024204824.GB32545@flint.arm.linux.org.uk>

On 10/24/2011 03:48 PM, Russell King wrote:
> On Tue, Oct 25, 2011 at 07:39:46AM +1100, Stephen Rothwell wrote:
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> arch/arm/common/gic.c between commits 292b293ceef2 ("ARM: gic:
>> consolidate PPI handling") and 28af690a284d ("ARM: gic, local timers: use
>> the request_percpu_irq() interface") from the arm tree and commits
>> 2071a2a4b8ed ("ARM: gic: add irq_domain support") and e3f14d321b34 ("ARM:
>> gic: add OF based initialization") from the arm-soc tree.
>>
>> I hacked it up (almost certainly incorrectly - see below). Someone will
>> have to provide Linus with a fix for this.
> 
> Yes, this looks quite wrong:
> 
>> @@@ -332,29 -304,12 +325,22 @@@
>>   		writel_relaxed(0xffffffff, base + GIC_DIST_ENABLE_CLEAR + i * 4 / 32);
>>   
>>   	/*
>> - 	 * Limit number of interrupts registered to the platform maximum
>> - 	 */
>> - 	irq_limit = gic->irq_offset + gic_irqs;
>> - 	if (WARN_ON(irq_limit > NR_IRQS))
>> - 		irq_limit = NR_IRQS;
>> - 
>> - 	/*
>>   	 * Setup the Linux IRQ subsystem.
>>   	 */
>>  +	for (i = 0; i < nrppis; i++) {
>>  +		int ppi = i + ppi_base;
>>  +
>>  +		irq_set_percpu_devid(ppi);
>>  +		irq_set_chip_and_handler(ppi, &gic_chip,
>>  +					 handle_percpu_devid_irq);
>>  +		irq_set_chip_data(ppi, gic);
>>  +		set_irq_flags(ppi, IRQF_VALID | IRQF_NOAUTOEN);
>>  +	}
>>  +
>> - 	for (i = irq_start + nrppis; i < irq_limit; i++) {
>> - 		irq_set_chip_and_handler(i, &gic_chip, handle_fasteoi_irq);
>> - 		irq_set_chip_data(i, gic);
>> - 		set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
>> + 	irq_domain_for_each_irq(domain, i, irq) {
>> + 		irq_set_chip_and_handler(irq, &gic_chip, handle_fasteoi_irq);
>> + 		irq_set_chip_data(irq, gic);
>> + 		set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
>>   	}
>>   
>>   	writel_relaxed(1, base + GIC_DIST_CTRL);
> 
> We definitely need to sort this out before either tree gets pushed to
> Linus, otherwise we're going to end up annoying Linus... even if we
> provide a resolution.
> 
> I suspect I should've taken the GIC OF stuff via my tree...

Yes, as it turns out to be pretty dependent on your tree.

I'm testing the fix for this and will send a new pull request.

Rob

^ permalink raw reply

* Re: linux-next: manual merge of the arm-soc tree with the arm tree
From: Sascha Hauer @ 2011-10-24 21:09 UTC (permalink / raw)
  To: Russell King
  Cc: Stephen Rothwell, Arnd Bergmann, linux-next, linux-kernel,
	Nicolas Pitre
In-Reply-To: <20111024203041.GA32545@flint.arm.linux.org.uk>

On Mon, Oct 24, 2011 at 09:30:41PM +0100, Russell King wrote:
> On Tue, Oct 25, 2011 at 07:20:13AM +1100, Stephen Rothwell wrote:
> > Hi Arnd,
> > 
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > arch/arm/plat-mxc/include/mach/memory.h between commit c039bad00f21
> > ("ARM: plat-mxc: remove mach/memory.h") from the arm tree and commits
> > ae4fa7f66e54 ("ARM i.MX: allow to compile together ARMv4 and ARMv5 based
> > SoCs") and 7409cd1cd554 ("ARM i.MX: allow to compile together all i.MX5
> > based SoCs") from the arm-soc tree.
> > 
> > The former removed the file, so I did that.
> 
> Stephen - thanks.
> 
> ARM guys, we need to be smarter about this stuff - if we're consolidating
> code across the ARM tree, committing changes to files which we're going
> to remove really isn't a good idea.  It probably means something else has
> changed elsewhere to accomodate the deletion of the file, which this
> kind of resolution won't fix up.

In this case deleting the file is the correct solution. I removed some
definitions of PLAT_PHYS_OFFSET which got unused due to "ARM i.MX: allow
to compile together..." and Nicolas removed the need for PLAT_PHYS_OFFSET
at all.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply

* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2011-10-24 20:52 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-next, linux-kernel, Marc Zyngier, Russell King,
	Changhwan Youn

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Hi Arnd,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos4/mct.c between commit 28af690a284d ("ARM: gic, local
timers: use the request_percpu_irq() interface") from the arm tree and
commit 3a0622811292 ("ARM: EXYNOS4: Add support MCT PPI for EXYNOS4212")
from the arm-soc tree.

I hacked it up (probably incorrectly - see below and dropping the
local_timer_ack() change from the latter, since the former removed that
function).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-exynos4/mct.c
index 582b874,eb182f2..0000000
--- a/arch/arm/mach-exynos4/mct.c
+++ b/arch/arm/mach-exynos4/mct.c
@@@ -384,15 -400,17 +400,19 @@@ static void exynos4_mct_tick_init(struc
  
  	exynos4_mct_write(0x1, mct_tick[cpu].base + MCT_L_TCNTB_OFFSET);
  
- 	if (cpu == 0) {
- 		mct_tick0_event_irq.dev_id = &mct_tick[cpu];
- 		evt->irq = IRQ_MCT_L0;
- 		setup_irq(IRQ_MCT_L0, &mct_tick0_event_irq);
+ 	if (mct_int_type == MCT_INT_SPI) {
+ 		if (cpu == 0) {
+ 			mct_tick0_event_irq.dev_id = &mct_tick[cpu];
++			evt->irq = IRQ_MCT_L0;
+ 			setup_irq(IRQ_MCT_L0, &mct_tick0_event_irq);
+ 		} else {
+ 			mct_tick1_event_irq.dev_id = &mct_tick[cpu];
++			evt->irq = IRQ_MCT_L1;
+ 			setup_irq(IRQ_MCT_L1, &mct_tick1_event_irq);
+ 			irq_set_affinity(IRQ_MCT_L1, cpumask_of(1));
+ 		}
  	} else {
- 		mct_tick1_event_irq.dev_id = &mct_tick[cpu];
- 		evt->irq = IRQ_MCT_L1;
- 		setup_irq(IRQ_MCT_L1, &mct_tick1_event_irq);
- 		irq_set_affinity(IRQ_MCT_L1, cpumask_of(1));
+ 		gic_enable_ppi(IRQ_MCT_LOCALTIMER);
  	}
  }
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the arm-soc tree with the arm tree
From: Russell King @ 2011-10-24 20:51 UTC (permalink / raw)
  To: Stephen Rothwell, Thomas Glexiner
  Cc: Arnd Bergmann, linux-next, linux-kernel, Marc Zyngier,
	Changhwan Youn
In-Reply-To: <20111025074532.cc8cf0d5a9611ecc1246f46d@canb.auug.org.au>

On Tue, Oct 25, 2011 at 07:45:32AM +1100, Stephen Rothwell wrote:
> Hi Arnd,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-exynos4/include/mach/entry-macro.S between commit
> 292b293ceef2 ("ARM: gic: consolidate PPI handling") from the arm tree and
> commit 3a0622811292 ("ARM: EXYNOS4: Add support MCT PPI for EXYNOS4212")
> from the arm-soc tree.
> 
> Again, I hacked it up (again probably incorrectly - I kept both
> additions).

Argh, noooo, not another conflict.

It looks like merging the PPI stuff was a bad move (despite pressure from
tglx to do so.)  Unfortunately, it's in my published stable branch so it
can't be dropped.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply

* Re: linux-next: manual merge of the arm-soc tree with the arm tree
From: Russell King @ 2011-10-24 20:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Arnd Bergmann, linux-next, linux-kernel, Rob Herring,
	Marc Zyngier
In-Reply-To: <20111025073946.019dca49157f5835e1394084@canb.auug.org.au>

On Tue, Oct 25, 2011 at 07:39:46AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/common/gic.c between commits 292b293ceef2 ("ARM: gic:
> consolidate PPI handling") and 28af690a284d ("ARM: gic, local timers: use
> the request_percpu_irq() interface") from the arm tree and commits
> 2071a2a4b8ed ("ARM: gic: add irq_domain support") and e3f14d321b34 ("ARM:
> gic: add OF based initialization") from the arm-soc tree.
> 
> I hacked it up (almost certainly incorrectly - see below). Someone will
> have to provide Linus with a fix for this.

Yes, this looks quite wrong:

> @@@ -332,29 -304,12 +325,22 @@@
>   		writel_relaxed(0xffffffff, base + GIC_DIST_ENABLE_CLEAR + i * 4 / 32);
>   
>   	/*
> - 	 * Limit number of interrupts registered to the platform maximum
> - 	 */
> - 	irq_limit = gic->irq_offset + gic_irqs;
> - 	if (WARN_ON(irq_limit > NR_IRQS))
> - 		irq_limit = NR_IRQS;
> - 
> - 	/*
>   	 * Setup the Linux IRQ subsystem.
>   	 */
>  +	for (i = 0; i < nrppis; i++) {
>  +		int ppi = i + ppi_base;
>  +
>  +		irq_set_percpu_devid(ppi);
>  +		irq_set_chip_and_handler(ppi, &gic_chip,
>  +					 handle_percpu_devid_irq);
>  +		irq_set_chip_data(ppi, gic);
>  +		set_irq_flags(ppi, IRQF_VALID | IRQF_NOAUTOEN);
>  +	}
>  +
> - 	for (i = irq_start + nrppis; i < irq_limit; i++) {
> - 		irq_set_chip_and_handler(i, &gic_chip, handle_fasteoi_irq);
> - 		irq_set_chip_data(i, gic);
> - 		set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
> + 	irq_domain_for_each_irq(domain, i, irq) {
> + 		irq_set_chip_and_handler(irq, &gic_chip, handle_fasteoi_irq);
> + 		irq_set_chip_data(irq, gic);
> + 		set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
>   	}
>   
>   	writel_relaxed(1, base + GIC_DIST_CTRL);

We definitely need to sort this out before either tree gets pushed to
Linus, otherwise we're going to end up annoying Linus... even if we
provide a resolution.

I suspect I should've taken the GIC OF stuff via my tree...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply

* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2011-10-24 20:45 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-next, linux-kernel, Marc Zyngier, Russell King,
	Changhwan Youn

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

Hi Arnd,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos4/include/mach/entry-macro.S between commit
292b293ceef2 ("ARM: gic: consolidate PPI handling") from the arm tree and
commit 3a0622811292 ("ARM: EXYNOS4: Add support MCT PPI for EXYNOS4212")
from the arm-soc tree.

Again, I hacked it up (again probably incorrectly - I kept both
additions).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2011-10-24 20:39 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-next, linux-kernel, Rob Herring, Russell King, Marc Zyngier

[-- Attachment #1: Type: text/plain, Size: 3774 bytes --]

Hi Arnd,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/common/gic.c between commits 292b293ceef2 ("ARM: gic:
consolidate PPI handling") and 28af690a284d ("ARM: gic, local timers: use
the request_percpu_irq() interface") from the arm tree and commits
2071a2a4b8ed ("ARM: gic: add irq_domain support") and e3f14d321b34 ("ARM:
gic: add OF based initialization") from the arm-soc tree.

I hacked it up (almost certainly incorrectly - see below). Someone will
have to provide Linus with a fix for this.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/common/gic.c
index 016c1ae,65cf39d..0000000
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@@ -29,9 -29,10 +29,13 @@@
  #include <linux/cpu_pm.h>
  #include <linux/cpumask.h>
  #include <linux/io.h>
 +#include <linux/interrupt.h>
 +#include <linux/percpu.h>
 +#include <linux/slab.h>
+ #include <linux/of.h>
+ #include <linux/of_address.h>
+ #include <linux/of_irq.h>
+ #include <linux/irqdomain.h>
  
  #include <asm/irq.h>
  #include <asm/mach/irq.h>
@@@ -259,14 -259,14 +262,15 @@@ void __init gic_cascade_irq(unsigned in
  	irq_set_chained_handler(irq, gic_handle_cascade_irq);
  }
  
- static void __init gic_dist_init(struct gic_chip_data *gic,
- 	unsigned int irq_start)
+ static void __init gic_dist_init(struct gic_chip_data *gic)
  {
- 	unsigned int gic_irqs, irq_limit, i;
+ 	unsigned int i, irq;
  	u32 cpumask;
+ 	unsigned int gic_irqs = gic->gic_irqs;
+ 	struct irq_domain *domain = &gic->domain;
  	void __iomem *base = gic->dist_base;
  	u32 cpu = 0;
 +	u32 nrppis = 0, ppi_base = 0;
  
  #ifdef CONFIG_SMP
  	cpu = cpu_logical_map(smp_processor_id());
@@@ -279,34 -279,6 +283,23 @@@
  	writel_relaxed(0, base + GIC_DIST_CTRL);
  
  	/*
- 	 * Find out how many interrupts are supported.
- 	 * The GIC only supports up to 1020 interrupt sources.
- 	 */
- 	gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
- 	gic_irqs = (gic_irqs + 1) * 32;
- 	if (gic_irqs > 1020)
- 		gic_irqs = 1020;
- 
- 	gic->gic_irqs = gic_irqs;
- 
- 	/*
 +	 * Nobody would be insane enough to use PPIs on a secondary
 +	 * GIC, right?
 +	 */
 +	if (gic == &gic_data[0]) {
 +		nrppis = (32 - irq_start) & 31;
 +
 +		/* The GIC only supports up to 16 PPIs. */
 +		if (nrppis > 16)
 +			BUG();
 +
 +		ppi_base = gic->irq_offset + 32 - nrppis;
 +	}
 +
 +	pr_info("Configuring GIC with %d sources (%d PPIs)\n",
 +		gic_irqs, (gic == &gic_data[0]) ? nrppis : 0);
 +
 +	/*
  	 * Set all global interrupts to be level triggered, active low.
  	 */
  	for (i = 32; i < gic_irqs; i += 16)
@@@ -332,29 -304,12 +325,22 @@@
  		writel_relaxed(0xffffffff, base + GIC_DIST_ENABLE_CLEAR + i * 4 / 32);
  
  	/*
- 	 * Limit number of interrupts registered to the platform maximum
- 	 */
- 	irq_limit = gic->irq_offset + gic_irqs;
- 	if (WARN_ON(irq_limit > NR_IRQS))
- 		irq_limit = NR_IRQS;
- 
- 	/*
  	 * Setup the Linux IRQ subsystem.
  	 */
 +	for (i = 0; i < nrppis; i++) {
 +		int ppi = i + ppi_base;
 +
 +		irq_set_percpu_devid(ppi);
 +		irq_set_chip_and_handler(ppi, &gic_chip,
 +					 handle_percpu_devid_irq);
 +		irq_set_chip_data(ppi, gic);
 +		set_irq_flags(ppi, IRQF_VALID | IRQF_NOAUTOEN);
 +	}
 +
- 	for (i = irq_start + nrppis; i < irq_limit; i++) {
- 		irq_set_chip_and_handler(i, &gic_chip, handle_fasteoi_irq);
- 		irq_set_chip_data(i, gic);
- 		set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
+ 	irq_domain_for_each_irq(domain, i, irq) {
+ 		irq_set_chip_and_handler(irq, &gic_chip, handle_fasteoi_irq);
+ 		irq_set_chip_data(irq, gic);
+ 		set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
  	}
  
  	writel_relaxed(1, base + GIC_DIST_CTRL);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the arm-soc tree with the arm tree
From: Russell King @ 2011-10-24 20:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Arnd Bergmann, linux-next, linux-kernel, Nicolas Pitre,
	Sascha Hauer
In-Reply-To: <20111025072013.1824cfd24495819777ad2660@canb.auug.org.au>

On Tue, Oct 25, 2011 at 07:20:13AM +1100, Stephen Rothwell wrote:
> Hi Arnd,
> 
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/plat-mxc/include/mach/memory.h between commit c039bad00f21
> ("ARM: plat-mxc: remove mach/memory.h") from the arm tree and commits
> ae4fa7f66e54 ("ARM i.MX: allow to compile together ARMv4 and ARMv5 based
> SoCs") and 7409cd1cd554 ("ARM i.MX: allow to compile together all i.MX5
> based SoCs") from the arm-soc tree.
> 
> The former removed the file, so I did that.

Stephen - thanks.

ARM guys, we need to be smarter about this stuff - if we're consolidating
code across the ARM tree, committing changes to files which we're going
to remove really isn't a good idea.  It probably means something else has
changed elsewhere to accomodate the deletion of the file, which this
kind of resolution won't fix up.

It's a recipe for creating unnecessary build failures when these trees
get merged together.

It probably means that those two commits need to be postponed and
updated for the changes already queued by other people.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply

* linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2011-10-24 20:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-next, linux-kernel, Russell King, Nicolas Pitre,
	Sascha Hauer

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

Hi Arnd,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/plat-mxc/include/mach/memory.h between commit c039bad00f21
("ARM: plat-mxc: remove mach/memory.h") from the arm tree and commits
ae4fa7f66e54 ("ARM i.MX: allow to compile together ARMv4 and ARMv5 based
SoCs") and 7409cd1cd554 ("ARM i.MX: allow to compile together all i.MX5
based SoCs") from the arm-soc tree.

The former removed the file, so I did that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: failed to import the device-mapper quilt series
From: Alasdair G Kergon @ 2011-10-24 19:22 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20111025061010.26d2b727559242a5d188918e@canb.auug.org.au>

On Tue, Oct 25, 2011 at 06:10:10AM +1100, Stephen Rothwell wrote:
> And indeed, this file does not exist even though this patch is trying to
> patch it (not create it).

Hmmm.  Yes, that patch is corrupted.  I'll regenerate it.

Alasdair

^ permalink raw reply

* linux-next: failed to import the device-mapper quilt series
From: Stephen Rothwell @ 2011-10-24 19:10 UTC (permalink / raw)
  To: Alasdair G Kergon; +Cc: linux-next, LKML

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

Hi Alasdair,

Importing the device-mapper tree today gave this error:

$ git am ../quilt/device-mapper/dm-add-persistent-data-library.patch
Applying: The persistent-data library offers a re-usable framework for the storage
error: drivers/md/persistent-data/dm-space-map-common.c: does not exist in index
Patch failed at 0001 The persistent-data library offers a re-usable framework for the storage

And indeed, this file does not exist even though this patch is trying to
patch it (not create it).

I will use the device-mapper tree from next-20111014 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: Bluetooth tree url change
From: Stephen Rothwell @ 2011-10-24  9:58 UTC (permalink / raw)
  To: Gustavo Padovan; +Cc: linux-next
In-Reply-To: <20111020025727.GA3077@joana>

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

Hi Gustavo,

On Thu, 20 Oct 2011 00:57:27 -0200 Gustavo Padovan <padovan@profusion.mobi> wrote:
>
> The bluetooth-next tree now has a new url, I drop the "-2.6" suffix when I
> moved back to kernel.org
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next.git

OK, I have switched to this now.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: currently missing kernel devel trees
From: Stephen Rothwell @ 2011-10-24  9:50 UTC (permalink / raw)
  To: Wim Van Sebroeck; +Cc: LKML, linux-next, Linus, Andrew Morton
In-Reply-To: <20111016211102.GA15720@infomag.iguana.be>

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Hi Wim,

On Sun, 16 Oct 2011 23:11:02 +0200 Wim Van Sebroeck <wim@iguana.be> wrote:
>
> ...
> > watchdog
> ...
> 
> Untill I have the time to do something new could you use the following tree and branch:
> 
> git://www.linux-watchdog.org/linux-watchdog.git linux-next
> 
> I started filling it with 5 patches allready, but still need to add some others in the next day.

OK, I have switched to using this.  Please let me know if/when you switch
back to kernel.org.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: currently missing kernel devel trees
From: Stephen Rothwell @ 2011-10-24  9:38 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: LKML, linux-next, Linus, Andrew Morton
In-Reply-To: <CAMjpGUe+jgnpB4pPhSBV=zYgNSUTzWYa2_KmPuWhjZw_6zjLMw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

Hi Mike,

On Sat, 15 Oct 2011 13:57:11 -0400 Mike Frysinger <vapier.adi@gmail.com> wrote:
>
> On Thu, Oct 13, 2011 at 23:25, Mike Frysinger wrote:
> > On Thu, Oct 13, 2011 at 02:43, Stephen Rothwell wrote:
> >> blackfin
> >
> > i was waiting for hpa to get back to me so i could get my repo enabled
> > again on git.kernel.org ... but maybe that'll take until/post LKS ?
> 
> ah, got my info today.  this tree should be alive again for you to merge in.

Thanks, looks good.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: build failure after merge of the final tree (sparc, ptrace trees related)
From: Stephen Rothwell @ 2011-10-24  9:36 UTC (permalink / raw)
  To: Oleg Nesterov; +Cc: David Miller, linux-next, linux-kernel, matt.fleming, tj
In-Reply-To: <20111014190950.GA10791@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Hi Oleg,

On Fri, 14 Oct 2011 21:09:50 +0200 Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 10/14, David Miller wrote:
> >
> > Now you guys are creating conflicts against those fixed up patches in
> > another non-sparc tree, and adding new kinds of build failures as
> > well.
> >
> > This doesn't work.
> 
> Sorry David and Stephen.
> 
> Stephen, could you please temporary remove ptrace from linux-next?

OK, I have removed it until you tell me otherwise.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: currently missing kernel devel trees
From: Stephen Rothwell @ 2011-10-24  9:20 UTC (permalink / raw)
  To: Phillip Lougher; +Cc: LKML, linux-next, Linus, Andrew Morton
In-Reply-To: <CAB3woddd=1Ps8HR4SPAOQxoxCnGLFDrjRN6KPJUFkpzmACXf4w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

Hi Phillip,

On Fri, 14 Oct 2011 02:03:18 +0100 Phillip Lougher <phillip.lougher@gmail.com> wrote:
>
> > squashfs
> 
> git://gitorious.org/squashfs-linux-next/squashfs-linux-next.git master

I have swu=itched to that, thanks.  Please let me know if/when you switch
back to kernel.org.

> I don't have anything queued up at the moment, though...

I get one commit today (presumably added since you sent this email).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Updated target-pending.git branches for linux-next
From: Nicholas A. Bellinger @ 2011-10-24  6:05 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, target-devel, Christoph Hellwig

Hi Stephen,

The target-pending.git tree is now back on kernel.org, and as before
the following branch is used as 'for-next' updates to existing
drivers/target/ code:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next

I've also added another branch that is being used for new target modules
being merged in the next development cycle:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next-merge

If you would be so kind, please go ahead and add the second entry as well
into your linux-next daily builds.

Thank you,

--nab

^ permalink raw reply

* Bluetooth tree url change
From: Gustavo Padovan @ 2011-10-20  2:57 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next

Hi Stephen,

The bluetooth-next tree now has a new url, I drop the "-2.6" suffix when I
moved back to kernel.org

git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next.git

Thanks for your work!

	Gustavo

^ permalink raw reply

* Re: linux-next: import of rr series failed
From: Rusty Russell @ 2011-10-18 23:51 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20111014103638.accaae53bac0e74da3c787bd@canb.auug.org.au>

On Fri, 14 Oct 2011 10:36:38 +1100, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
Non-text part: multipart/signed
> Hi Rusty,
> 
> Importing the rr series today I got this error:
> 
> $ git am ../quilt/rr/virtio:dont_add_config_to_list_for_per_vq_vector.patch
> Patch format detection failed.
> 
> I added a From line to the top using the address from the first SOB line.

Weird, don't know how that slipped through my checking script :(

Fixed up now, thanks.

Rusty.

^ permalink raw reply

* Re: [PATCH -next] infiniband: fix printk format in hw/nes_cm.c
From: Roland Dreier @ 2011-10-17 21:18 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, Andrew Morton, Faisal Latif,
	Linux RDMA, Sean Hefty, Hal Rosenstock
In-Reply-To: <4E976147.9030000@xenotime.net>

Thanks, rolled this into the offending commit.

^ permalink raw reply

* Re: currently missing kernel devel trees
From: Wim Van Sebroeck @ 2011-10-16 21:11 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: LKML, linux-next, Linus, Andrew Morton
In-Reply-To: <20111013174358.b20fedb97c7b53db2ba82ff6@canb.auug.org.au>

Hi Stephen,

> With the mrege window approaching (sometime) I thought I would see how
> many of the 200 odd trees that are included in linux-next are actually
> currently inaccessible.  The list below (of 63 trees) is a couple of days
> out of date.  These are the trees that were hosted on git.kernel.org that
> have not popped up anywhere else (or, at least I have not been informed
> is they have) nor been resurrected on kernel.org.
> 
> Some of these may be no longer useful (please tell me).  Some may have no
> commits for v3.2.  But I bet that at leaset some do.
> 
...
> watchdog
...

Untill I have the time to do something new could you use the following tree and branch:

git://www.linux-watchdog.org/linux-watchdog.git linux-next

I started filling it with 5 patches allready, but still need to add some others in the next day.

Kind regards,
Wim.

^ permalink raw reply

* Re: currently missing kernel devel trees
From: Mike Frysinger @ 2011-10-15 17:57 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: LKML, linux-next, Linus, Andrew Morton
In-Reply-To: <CAMjpGUcdTj2XBxMX9v7dY4ATPjCtU9xj+xXvj3D5Ma2gsMA8Ww@mail.gmail.com>

On Thu, Oct 13, 2011 at 23:25, Mike Frysinger wrote:
> On Thu, Oct 13, 2011 at 02:43, Stephen Rothwell wrote:
>> blackfin
>
> i was waiting for hpa to get back to me so i could get my repo enabled
> again on git.kernel.org ... but maybe that'll take until/post LKS ?

ah, got my info today.  this tree should be alive again for you to merge in.
-mike

^ permalink raw reply

* Re: linux-next: build failure after merge of the final tree (sparc, ptrace trees related)
From: Oleg Nesterov @ 2011-10-14 19:09 UTC (permalink / raw)
  To: David Miller, Stephen Rothwell; +Cc: linux-next, linux-kernel, matt.fleming, tj
In-Reply-To: <20111014.035459.2238341687770152474.davem@davemloft.net>

On 10/14, David Miller wrote:
>
> Now you guys are creating conflicts against those fixed up patches in
> another non-sparc tree, and adding new kinds of build failures as
> well.
>
> This doesn't work.

Sorry David and Stephen.

Stephen, could you please temporary remove ptrace from linux-next?

I'll send you another email once I fix the conflicts, can't do this
right now.

Oleg.

^ permalink raw reply

* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
From: Randy Dunlap @ 2011-10-14 17:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, LKML, linux-ide@vger.kernel.org, Anton Vorontsov
In-Reply-To: <4E94A920.40503@xenotime.net>

On 10/11/2011 01:37 PM, Randy Dunlap wrote:
> On 10/11/11 02:11, Stephen Rothwell wrote:
>> Hi all,
>>
>> The linux-next tree is now available from
>> git://github.com/sfrothwell/linux-next.git as a temporary measure while
>> the kernel.org servers are unavailable.
>>
>> It may also turn up on git.kernel.org (depending on the mirroring).  The
>> patch set is still absent, however.
>>
>> Changes since 20111007:
>>
>> Removed tree: ide (at the maintainer's request)
> 
> 
> drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)


[adding Author: Anton]

Build error still present in linux-next of 20111014.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox