* linux-next: manual merge of the tip tree with the cputime tree
From: Stephen Rothwell @ 2011-10-25 7:35 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Martin Schwidefsky, Michal Hocko
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in fs/proc/stat.c
between commit f6116715d1ba ("[S390] cputime: add sparse checking and
cleanup") from the cputime tree and commit a25cac5198d4 ("proc: Consider
NO_HZ when printing idle and iowait times") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc fs/proc/stat.c
index 566cd04,42b274d..0000000
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@@ -21,6 -22,35 +22,34 @@@
#define arch_idle_time(cpu) 0
#endif
+ static cputime64_t get_idle_time(int cpu)
+ {
+ u64 idle_time = get_cpu_idle_time_us(cpu, NULL);
+ cputime64_t idle;
+
+ if (idle_time == -1ULL) {
+ /* !NO_HZ so we can rely on cpustat.idle */
- idle = kstat_cpu(cpu).cpustat.idle;
- idle = cputime64_add(idle, arch_idle_time(cpu));
++ idle = kstat_cpu(cpu).cpustat.idle + arch_idle_time(cpu);
+ } else
+ idle = usecs_to_cputime(idle_time);
+
+ return idle;
+ }
+
+ static cputime64_t get_iowait_time(int cpu)
+ {
+ u64 iowait_time = get_cpu_iowait_time_us(cpu, NULL);
+ cputime64_t iowait;
+
+ if (iowait_time == -1ULL)
+ /* !NO_HZ so we can rely on cpustat.iowait */
+ iowait = kstat_cpu(cpu).cpustat.iowait;
+ else
+ iowait = usecs_to_cputime(iowait_time);
+
+ return iowait;
+ }
+
static int show_stat(struct seq_file *p, void *v)
{
int i, j;
@@@ -39,16 -69,17 +68,16 @@@
jif = boottime.tv_sec;
for_each_possible_cpu(i) {
- user = cputime64_add(user, kstat_cpu(i).cpustat.user);
- nice = cputime64_add(nice, kstat_cpu(i).cpustat.nice);
- system = cputime64_add(system, kstat_cpu(i).cpustat.system);
- idle = cputime64_add(idle, get_idle_time(i));
- iowait = cputime64_add(iowait, get_iowait_time(i));
- irq = cputime64_add(irq, kstat_cpu(i).cpustat.irq);
- softirq = cputime64_add(softirq, kstat_cpu(i).cpustat.softirq);
- steal = cputime64_add(steal, kstat_cpu(i).cpustat.steal);
- guest = cputime64_add(guest, kstat_cpu(i).cpustat.guest);
- guest_nice = cputime64_add(guest_nice,
- kstat_cpu(i).cpustat.guest_nice);
+ user += kstat_cpu(i).cpustat.user;
+ nice += kstat_cpu(i).cpustat.nice;
+ system += kstat_cpu(i).cpustat.system;
- idle += kstat_cpu(i).cpustat.idle + arch_idle_time(i);
- iowait += kstat_cpu(i).cpustat.iowait;
++ idle += get_idle_time(i);
++ iowait += get_iowait_time(i);
+ irq += kstat_cpu(i).cpustat.irq;
+ softirq += kstat_cpu(i).cpustat.softirq;
+ steal += kstat_cpu(i).cpustat.steal;
+ guest += kstat_cpu(i).cpustat.guest;
+ guest_nice += kstat_cpu(i).cpustat.guest_nice;
sum += kstat_cpu_irqs_sum(i);
sum += arch_irq_stat_cpu(i);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the pm tree with the s390 tree
From: Stephen Rothwell @ 2011-10-25 7:20 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-next, linux-kernel, Martin Schwidefsky, Heiko Carstens
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in
arch/s390/kernel/suspend.c between commit 4de2166b1804 ("[S390] sparse:
fix sparse warnings about missing prototypes") from the s390 tree and
commit 85055dd805f0 ("PM / Hibernate: Include storage keys in hibernation
image on s390") from the pm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/s390/kernel/suspend.c
index 4f0fd55,b6f9afe..0000000
--- a/arch/s390/kernel/suspend.c
+++ b/arch/s390/kernel/suspend.c
@@@ -7,7 -7,7 +7,8 @@@
*/
#include <linux/pfn.h>
+#include <linux/suspend.h>
+ #include <linux/mm.h>
#include <asm/system.h>
/*
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the scsi tree with the s390 tree
From: Martin Schwidefsky @ 2011-10-25 7:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Bottomley, linux-next, linux-kernel, Swen Schillig,
Steffen Maier, Jan Glauber, Heiko Carstens
In-Reply-To: <20111025171601.c2365840409d17df161ca8b5@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Tue, 25 Oct 2011 17:16:01 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the scsi tree got a conflict in
> drivers/s390/cio/qdio_main.c between commit 9c20b3dd8479 ("[S390] qdio:
> EQBS retry after CCQ 96") from the s390 tree and commit dfe5bb506172
> ("[SCSI] qdio: base support for hardware data router with zfcp") from the
> scsi tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Looks good. Thanks Stephen.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the bluetooth tree with Linus' tree
From: Stephen Rothwell @ 2011-10-25 6:25 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linux-next, linux-kernel, Paul Moore, David Miller, netdev,
Andrei Emeltchenko
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]
Hi Gustavo,
Today's linux-next merge of the bluetooth tree got a conflict in
net/bluetooth/l2cap_sock.c between commit 6230c9b4f895 ("bluetooth:
Properly clone LSM attributes to newly created child connections") from
Linus' tree and commit 15770b1ab974 ("Bluetooth: convert force_active
variable to flag in l2cap chan") from the bluetooth tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/bluetooth/l2cap_sock.c
index e829236,836d12e..0000000
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@@ -931,12 -944,7 +946,9 @@@ static void l2cap_sock_init(struct soc
chan->max_tx = pchan->max_tx;
chan->tx_win = pchan->tx_win;
chan->sec_level = pchan->sec_level;
- chan->role_switch = pchan->role_switch;
- chan->force_reliable = pchan->force_reliable;
- chan->flushable = pchan->flushable;
- chan->force_active = pchan->force_active;
+ chan->flags = pchan->flags;
+
+ security_sk_clone(parent, sk);
} else {
switch (sk->sk_type) {
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the scsi tree with the s390 tree
From: Stephen Rothwell @ 2011-10-25 6:16 UTC (permalink / raw)
To: James Bottomley
Cc: linux-next, linux-kernel, Swen Schillig, Steffen Maier,
Jan Glauber, Martin Schwidefsky, Heiko Carstens
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --]
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
drivers/s390/cio/qdio_main.c between commit 9c20b3dd8479 ("[S390] qdio:
EQBS retry after CCQ 96") from the s390 tree and commit dfe5bb506172
("[SCSI] qdio: base support for hardware data router with zfcp") from the
scsi tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/s390/cio/qdio_main.c
index a108e28,d2c1f1b..0000000
--- a/drivers/s390/cio/qdio_main.c
+++ b/drivers/s390/cio/qdio_main.c
@@@ -145,26 -151,16 +145,28 @@@ again
goto again;
}
- if (rc < 0) {
- DBF_ERROR("%4x EQBS ERROR", SCH_NO(q));
- DBF_ERROR("%3d%3d%2d", count, tmp_count, nr);
- q->handler(q->irq_ptr->cdev,
- QDIO_ERROR_ACTIVATE_CHECK_CONDITION,
- q->nr, q->first_to_kick, count,
- q->irq_ptr->int_parm);
- return 0;
+ if (rc == 2) {
+ BUG_ON(tmp_count == count);
+ qperf_inc(q, eqbs_partial);
+ DBF_DEV_EVENT(DBF_WARN, q->irq_ptr, "EQBS part:%02x",
+ tmp_count);
+ /*
+ * Retry once, if that fails bail out and process the
+ * extracted buffers before trying again.
+ */
+ if (!retried++)
+ goto again;
+ else
+ return count - tmp_count;
}
- return count - tmp_count;
+
+ DBF_ERROR("%4x EQBS ERROR", SCH_NO(q));
+ DBF_ERROR("%3d%3d%2d", count, tmp_count, nr);
- q->handler(q->irq_ptr->cdev, QDIO_ERROR_ACTIVATE_CHECK_CONDITION,
- 0, -1, -1, q->irq_ptr->int_parm);
++ q->handler(q->irq_ptr->cdev,
++ QDIO_ERROR_ACTIVATE_CHECK_CONDITION,
++ q->nr, q->first_to_kick, count,
++ q->irq_ptr->int_parm);
+ return 0;
}
/**
@@@ -207,12 -198,17 +209,12 @@@ again
qperf_inc(q, sqbs_partial);
goto again;
}
- if (rc < 0) {
- DBF_ERROR("%4x SQBS ERROR", SCH_NO(q));
- DBF_ERROR("%3d%3d%2d", count, tmp_count, nr);
- q->handler(q->irq_ptr->cdev,
- QDIO_ERROR_ACTIVATE_CHECK_CONDITION,
- q->nr, q->first_to_kick, count,
- q->irq_ptr->int_parm);
- return 0;
- }
- WARN_ON(tmp_count);
- return count - tmp_count;
+
+ DBF_ERROR("%4x SQBS ERROR", SCH_NO(q));
+ DBF_ERROR("%3d%3d%2d", count, tmp_count, nr);
+ q->handler(q->irq_ptr->cdev, QDIO_ERROR_ACTIVATE_CHECK_CONDITION,
- 0, -1, -1, q->irq_ptr->int_parm);
++ q->nr, q->first_to_kick, count, q->irq_ptr->int_parm);
+ return 0;
}
/* returns number of examined buffers and their common state in *state */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* kgdb-next temporarily moved to github
From: Jason Wessel @ 2011-10-24 22:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: lkml, linux-next, Andrew Morton
Stephen,
I have not been able to get my kernel.org account re-activated as of yet, so I need to move the public dev tree to a different location until that is resolved.
Can you please point the linux-next kgdb contribution to:
git://github.com/jwessel/linux-kgdb.git kgdb-next
Many thanks!
Jason.
^ permalink raw reply
* linux-next: manual merge of the libata tree with the at91 tree
From: Stephen Rothwell @ 2011-10-24 21:38 UTC (permalink / raw)
To: Jeff Garzik
Cc: linux-next, linux-kernel, Sergei Shtylyov,
Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
Hi Jeff,
Today's linux-next merge of the libata tree got a conflict in
drivers/ata/pata_at91.c between commit 9585cf300d98 ("ARM: at91/pata: use
gpio_is_valid to check the gpio") from the at91 tree and commit
8e3bfdb95ad7 ("pata_at91: call clk_put() on ata_host_activate() failure")
from the libata tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/ata/pata_at91.c
index 7822813,c6d1409..0000000
--- a/drivers/ata/pata_at91.c
+++ b/drivers/ata/pata_at91.c
@@@ -414,10 -414,13 +414,13 @@@ static int __devinit pata_at91_probe(st
host->private_data = info;
- return ata_host_activate(host, gpio_is_valid(irq) ? gpio_to_irq(irq) : 0,
- ret = ata_host_activate(host, irq ? gpio_to_irq(irq) : 0,
- irq ? ata_sff_interrupt : NULL,
++ ret = ata_host_activate(host, gpio_is_valid(irq) ? gpio_to_irq(irq) : 0,
+ gpio_is_valid(irq) ? ata_sff_interrupt : NULL,
irq_flags, &pata_at91_sht);
+ if (!ret)
+ return 0;
+
err_put:
clk_put(info->mck);
return ret;
[-- 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 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox