* Re: linux-next: sched tree build warning
From: Ingo Molnar @ 2008-12-22 7:04 UTC (permalink / raw)
To: Ken Chen, Paul Mackerras
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next
In-Reply-To: <b040c32a0812212249p45aba306tbb68a960b79cd0ee@mail.gmail.com>
* Ken Chen <kenchen@google.com> wrote:
> On Sun, Dec 21, 2008 at 8:22 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced this new
> > warning:
> >
> > fs/proc/base.c: In function 'proc_pid_schedstat':
> > fs/proc/base.c:352: warning: format '%llu' expects type 'long long unsigned int',
> > but argument 3 has type 'u64'
> >
> > Introduced by commit 9c2c48020ec0dd6ecd27e5a1298f73b40d85a595
> > ("schedstat: consolidate per-task cpu runtime stats").
>
> oh boy, this is the 2nd time that printing u64 bite me, I really need to
> get hold of a machine that is non-x86_64.
>
> Just saw Ingo's patch came in while I'm typing this email. Thank you
> Ingo for fixing this.
the real solution is something like the patch below. That generates new
(but harmless) warnings within the powerpc code but those are a one-off
effort to fix and are not reoccuring.
Cc:-ed Paul Mackerras - Paul, am i missing anything?
Ingo
--------------->
>From 3d835af97da5b6cb755ca4f8464f8e636cc321da Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 22 Dec 2008 08:02:06 +0100
Subject: [PATCH] powerpc: fix u64
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/powerpc/include/asm/types.h | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index c004c13..1cbfd7f 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -1,11 +1,7 @@
#ifndef _ASM_POWERPC_TYPES_H
#define _ASM_POWERPC_TYPES_H
-#ifdef __powerpc64__
-# include <asm-generic/int-l64.h>
-#else
-# include <asm-generic/int-ll64.h>
-#endif
+#include <asm-generic/int-ll64.h>
#ifndef __ASSEMBLY__
^ permalink raw reply related
* Re: linux-next: sched tree build warning
From: Stephen Rothwell @ 2008-12-22 7:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ken Chen, Paul Mackerras, Thomas Gleixner, H. Peter Anvin,
linux-next
In-Reply-To: <20081222070426.GD29160@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
Hi Ingo,
On Mon, 22 Dec 2008 08:04:26 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> the real solution is something like the patch below. That generates new
> (but harmless) warnings within the powerpc code but those are a one-off
> effort to fix and are not reoccuring.
>
> Cc:-ed Paul Mackerras - Paul, am i missing anything?
You mean besides the patches that fix all those warnings? :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] m68k: Kill several external declarations in source files (was: Re: linux-next: boot-params tree build failure)
From: Geert Uytterhoeven @ 2008-12-22 7:30 UTC (permalink / raw)
To: Rusty Russell
Cc: Stephen Rothwell, linux-next, Linux/m68k,
Linux Kernel Development
In-Reply-To: <200812220851.44880.rusty@rustcorp.com.au>
On Mon, 22 Dec 2008, Rusty Russell wrote:
> On Sunday 21 December 2008 21:42:44 Geert Uytterhoeven wrote:
> > Shall I cherry pick this into my for-next branch (breaking Rusty's changes),
> > or wait until the current linux-next has been merged by Linus (and maybe
> > postpone to .30)?
>
> Good q. I can take the just setup.c changes and roll them into the
> boot-params tree if you want?
Fine for me! Thx!
> ie. something like:
>
> Subject: m68k: Use asm/sections.h in kernel/setup.c
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Firmware patches for SCSI
From: Boaz Harrosh @ 2008-12-22 7:48 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Bottomley, Jaswinder Singh, linux-scsi, LKML, linux-next,
David Woodhouse
In-Reply-To: <20081222171904.b588da94.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi James,
>
> On Fri, 19 Dec 2008 15:53:51 -0500 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>> OK, then whatever tree contains them needs to eject them or be dropped
>> from linux-next.
>
> That is a problem for me and David. Do not let it concern you ... :-)
>
>>> So I am curious that should I resend these patches based on which git tree.
>> Yes please. For me it would be against scsi-misc ... for the other
>> drivers it would be their development tree. The simplest thing to do is
>> probably to rebase them all on top of linux-next (which contains all of
>> our trees) and then send them to the individual subsystem maintainer
>> lists.
>
> Please don't do that, please base each one on either Linus' tree or the
> appropriate maintainer's subsystem tree as linux-next is a moving
> target (for instance, if you had based the scsi ones on next-20081219,
> then the scsi tree was not included ...). Basing on Linus' tree should
> work in most cases as there are not to many conflicts caused by these
> patches (the tg3 one is the worst so basing that off the net tree is
> probably worth while).
>
I think what James meant is to rebase over linux-next when cutting the
patches in order to send them to the different maintainers over email.
In that case linux-next is perfect because you are sure none of the
patches will conflict with any maintainer and you do that all in one
place. Since you are not merging then linux-next volatility does not
matter.
My $0.017
Boaz
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Rusty Russell @ 2008-12-22 7:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Kay Sievers, Greg KH, Mark McLoughlin
In-Reply-To: <20081222173213.b7340f63.sfr@canb.auug.org.au>
On Monday 22 December 2008 17:02:13 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next merge of the rr tree got a conflict in
> drivers/virtio/virtio_pci.c between commit
> b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> allocate root device") from the driver-core tree and commits
> f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> replace bus_id with dev_name(), dev_set_name()") and
> ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> () function") from the rr tree.
>
> I fixed it up (see below) and can carry the fix as necessary. Mark, does
> this driver-core patch obsolete the second rr tree patch above?
This is not unexpected. Mark sent me those two, the others went to
Greg. I'm happy to ack them and send them on to Greg.
Thanks,
Rusty.
^ permalink raw reply
* [patch] powerpc: change u64/s64 to a long long integer type
From: Ingo Molnar @ 2008-12-22 8:03 UTC (permalink / raw)
To: Stephen Rothwell, linux-kernel
Cc: Ken Chen, Paul Mackerras, Thomas Gleixner, H. Peter Anvin,
linux-next
In-Reply-To: <20081222181932.5dd9514e.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Mon, 22 Dec 2008 08:04:26 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > the real solution is something like the patch below. That generates new
> > (but harmless) warnings within the powerpc code but those are a one-off
> > effort to fix and are not reoccuring.
> >
> > Cc:-ed Paul Mackerras - Paul, am i missing anything?
>
> You mean besides the patches that fix all those warnings? :-)
i thought you as a PowerPC person would be more suited to fix them than
me.
but it took me 30 minutes - much less than the total time just i had to
spend on similar issues in the past. So this patch will be a real
time-saver and it should have been done years ago.
Tested on ppc64-defconfig - i guess there's more to it but similarly
trivial.
Ingo
----------------------->
Subject: powerpc: change u64/s64 to a long long integer type
From: Ingo Molnar <mingo@elte.hu>
Date: Mon Dec 22 08:32:41 CET 2008
Convert arch/powerpc/ over to long long based u64:
-#ifdef __powerpc64__
-# include <asm-generic/int-l64.h>
-#else
-# include <asm-generic/int-ll64.h>
-#endif
+#include <asm-generic/int-ll64.h>
This will avoid reoccuring spurious warnings in core kernel code that
comes when people test on their own hardware. (i.e. x86 in ~98% of the
cases) This is what x86 uses and it generally helps keep 64-bit code
32-bit clean too.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/powerpc/include/asm/rtas.h | 2 -
arch/powerpc/include/asm/types.h | 6 ----
arch/powerpc/kernel/dma-iommu.c | 4 +-
arch/powerpc/kernel/iommu.c | 12 ++++----
arch/powerpc/kernel/lparcfg.c | 10 +++----
arch/powerpc/kernel/prom.c | 4 +-
arch/powerpc/kernel/prom_init.c | 2 -
arch/powerpc/kernel/setup_64.c | 6 ++--
arch/powerpc/mm/stab.c | 4 +-
arch/powerpc/oprofile/cell/vma_map.c | 2 -
arch/powerpc/oprofile/op_model_pa6t.c | 6 ++--
arch/powerpc/platforms/cell/beat_htab.c | 21 ++++++++-------
arch/powerpc/platforms/cell/beat_interrupt.c | 2 -
arch/powerpc/platforms/cell/beat_udbg.c | 4 +-
arch/powerpc/platforms/cell/celleb_scc_epci.c | 4 +-
arch/powerpc/platforms/cell/interrupt.c | 2 -
arch/powerpc/platforms/cell/io-workarounds.c | 2 -
arch/powerpc/platforms/cell/iommu.c | 6 ++--
arch/powerpc/platforms/cell/ras.c | 8 ++---
arch/powerpc/platforms/cell/spu_base.c | 8 ++---
arch/powerpc/platforms/cell/spu_callbacks.c | 2 -
arch/powerpc/platforms/iseries/iommu.c | 4 +-
arch/powerpc/platforms/pasemi/cpufreq.c | 2 -
arch/powerpc/platforms/pseries/iommu.c | 35 ++++++++++++--------------
arch/powerpc/sysdev/mpic.c | 2 -
drivers/char/hvc_beat.c | 4 +-
drivers/net/pasemi_mac.c | 6 ++--
drivers/pcmcia/electra_cf.c | 2 -
drivers/scsi/ibmvscsi/ibmvscsi.c | 12 ++++----
29 files changed, 90 insertions(+), 94 deletions(-)
Index: linux/arch/powerpc/include/asm/rtas.h
===================================================================
--- linux.orig/arch/powerpc/include/asm/rtas.h
+++ linux/arch/powerpc/include/asm/rtas.h
@@ -18,7 +18,7 @@
*/
#define RTAS_UNKNOWN_SERVICE (-1)
-#define RTAS_INSTANTIATE_MAX (1UL<<30) /* Don't instantiate rtas at/above this value */
+#define RTAS_INSTANTIATE_MAX (1ULL<<30) /* Don't instantiate rtas at/above this value */
/* Buffer size for ppc_rtas system call. */
#define RTAS_RMOBUF_MAX (64 * 1024)
Index: linux/arch/powerpc/include/asm/types.h
===================================================================
--- linux.orig/arch/powerpc/include/asm/types.h
+++ linux/arch/powerpc/include/asm/types.h
@@ -1,11 +1,7 @@
#ifndef _ASM_POWERPC_TYPES_H
#define _ASM_POWERPC_TYPES_H
-#ifdef __powerpc64__
-# include <asm-generic/int-l64.h>
-#else
-# include <asm-generic/int-ll64.h>
-#endif
+#include <asm-generic/int-ll64.h>
#ifndef __ASSEMBLY__
Index: linux/arch/powerpc/kernel/dma-iommu.c
===================================================================
--- linux.orig/arch/powerpc/kernel/dma-iommu.c
+++ linux/arch/powerpc/kernel/dma-iommu.c
@@ -79,10 +79,10 @@ static int dma_iommu_dma_supported(struc
"Warning: IOMMU offset too big for device mask\n");
if (tbl)
printk(KERN_INFO
- "mask: 0x%08lx, table offset: 0x%08lx\n",
+ "mask: 0x%08llx, table offset: 0x%08lx\n",
mask, tbl->it_offset);
else
- printk(KERN_INFO "mask: 0x%08lx, table unavailable\n",
+ printk(KERN_INFO "mask: 0x%08llx, table unavailable\n",
mask);
return 0;
} else
Index: linux/arch/powerpc/kernel/iommu.c
===================================================================
--- linux.orig/arch/powerpc/kernel/iommu.c
+++ linux/arch/powerpc/kernel/iommu.c
@@ -239,12 +239,12 @@ static void __iommu_free(struct iommu_ta
if (printk_ratelimit()) {
printk(KERN_INFO "iommu_free: invalid entry\n");
printk(KERN_INFO "\tentry = 0x%lx\n", entry);
- printk(KERN_INFO "\tdma_addr = 0x%lx\n", (u64)dma_addr);
- printk(KERN_INFO "\tTable = 0x%lx\n", (u64)tbl);
- printk(KERN_INFO "\tbus# = 0x%lx\n", (u64)tbl->it_busno);
- printk(KERN_INFO "\tsize = 0x%lx\n", (u64)tbl->it_size);
- printk(KERN_INFO "\tstartOff = 0x%lx\n", (u64)tbl->it_offset);
- printk(KERN_INFO "\tindex = 0x%lx\n", (u64)tbl->it_index);
+ printk(KERN_INFO "\tdma_addr = 0x%llx\n", (u64)dma_addr);
+ printk(KERN_INFO "\tTable = 0x%llx\n", (u64)tbl);
+ printk(KERN_INFO "\tbus# = 0x%llx\n", (u64)tbl->it_busno);
+ printk(KERN_INFO "\tsize = 0x%llx\n", (u64)tbl->it_size);
+ printk(KERN_INFO "\tstartOff = 0x%llx\n", (u64)tbl->it_offset);
+ printk(KERN_INFO "\tindex = 0x%llx\n", (u64)tbl->it_index);
WARN_ON(1);
}
return;
Index: linux/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux.orig/arch/powerpc/kernel/lparcfg.c
+++ linux/arch/powerpc/kernel/lparcfg.c
@@ -240,7 +240,7 @@ static void parse_ppp_data(struct seq_fi
if (rc)
return;
- seq_printf(m, "partition_entitled_capacity=%ld\n",
+ seq_printf(m, "partition_entitled_capacity=%lld\n",
ppp_data.entitlement);
seq_printf(m, "group=%d\n", ppp_data.group_num);
seq_printf(m, "system_active_processors=%d\n",
@@ -265,7 +265,7 @@ static void parse_ppp_data(struct seq_fi
ppp_data.unallocated_weight);
seq_printf(m, "capacity_weight=%d\n", ppp_data.weight);
seq_printf(m, "capped=%d\n", ppp_data.capped);
- seq_printf(m, "unallocated_capacity=%ld\n",
+ seq_printf(m, "unallocated_capacity=%lld\n",
ppp_data.unallocated_entitlement);
}
@@ -509,10 +509,10 @@ static ssize_t update_ppp(u64 *entitleme
} else
return -EINVAL;
- pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
+ pr_debug("%s: current_entitled = %llu, current_weight = %u\n",
__func__, ppp_data.entitlement, ppp_data.weight);
- pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
+ pr_debug("%s: new_entitled = %llu, new_weight = %u\n",
__func__, new_entitled, new_weight);
retval = plpar_hcall_norets(H_SET_PPP, new_entitled, new_weight);
@@ -558,7 +558,7 @@ static ssize_t update_mpp(u64 *entitleme
pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
__func__, mpp_data.entitled_mem, mpp_data.mem_weight);
- pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
+ pr_debug("%s: new_entitled = %llu, new_weight = %u\n",
__func__, new_entitled, new_weight);
rc = plpar_hcall_norets(H_SET_MPP, new_entitled, new_weight);
Index: linux/arch/powerpc/kernel/prom.c
===================================================================
--- linux.orig/arch/powerpc/kernel/prom.c
+++ linux/arch/powerpc/kernel/prom.c
@@ -824,11 +824,11 @@ static int __init early_init_dt_scan_cho
#endif
#ifdef CONFIG_KEXEC
- lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-base", NULL);
+ lprop = (unsigned long *)of_get_flat_dt_prop(node, "linux,crashkernel-base", NULL);
if (lprop)
crashk_res.start = *lprop;
- lprop = (u64*)of_get_flat_dt_prop(node, "linux,crashkernel-size", NULL);
+ lprop = (unsigned long *)of_get_flat_dt_prop(node, "linux,crashkernel-size", NULL);
if (lprop)
crashk_res.end = crashk_res.start + *lprop - 1;
#endif
Index: linux/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux.orig/arch/powerpc/kernel/prom_init.c
+++ linux/arch/powerpc/kernel/prom_init.c
@@ -1210,7 +1210,7 @@ static void __init prom_initialize_tce_t
/* Initialize the table to have a one-to-one mapping
* over the allocated size.
*/
- tce_entryp = (unsigned long *)base;
+ tce_entryp = (u64 *)base;
for (i = 0; i < (minsize >> 3) ;tce_entryp++, i++) {
tce_entry = (i << PAGE_SHIFT);
tce_entry |= 0x3;
Index: linux/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux.orig/arch/powerpc/kernel/setup_64.c
+++ linux/arch/powerpc/kernel/setup_64.c
@@ -433,8 +433,8 @@ void __init setup_system(void)
printk("Starting Linux PPC64 %s\n", init_utsname()->version);
printk("-----------------------------------------------------\n");
- printk("ppc64_pft_size = 0x%lx\n", ppc64_pft_size);
- printk("physicalMemorySize = 0x%lx\n", lmb_phys_mem_size());
+ printk("ppc64_pft_size = 0x%llx\n", ppc64_pft_size);
+ printk("physicalMemorySize = 0x%llx\n", lmb_phys_mem_size());
if (ppc64_caches.dline_size != 0x80)
printk("ppc64_caches.dcache_line_size = 0x%x\n",
ppc64_caches.dline_size);
@@ -492,7 +492,7 @@ static void __init emergency_stack_init(
* bringup, we need to get at them in real mode. This means they
* must also be within the RMO region.
*/
- limit = min(0x10000000UL, lmb.rmo_size);
+ limit = min(0x10000000ULL, lmb.rmo_size);
for_each_possible_cpu(i) {
unsigned long sp;
Index: linux/arch/powerpc/mm/stab.c
===================================================================
--- linux.orig/arch/powerpc/mm/stab.c
+++ linux/arch/powerpc/mm/stab.c
@@ -251,8 +251,8 @@ void __init stabs_alloc(void)
paca[cpu].stab_addr = newstab;
paca[cpu].stab_real = virt_to_abs(newstab);
- printk(KERN_INFO "Segment table for CPU %d at 0x%lx "
- "virtual, 0x%lx absolute\n",
+ printk(KERN_INFO "Segment table for CPU %d at 0x%llx "
+ "virtual, 0x%llx absolute\n",
cpu, paca[cpu].stab_addr, paca[cpu].stab_real);
}
}
Index: linux/arch/powerpc/oprofile/cell/vma_map.c
===================================================================
--- linux.orig/arch/powerpc/oprofile/cell/vma_map.c
+++ linux/arch/powerpc/oprofile/cell/vma_map.c
@@ -92,7 +92,7 @@ vma_map_add(struct vma_to_fileoffset_map
* A pointer to the first vma_map in the generated list
* of vma_maps is returned. */
struct vma_to_fileoffset_map *create_vma_map(const struct spu *aSpu,
- unsigned long __spu_elf_start)
+ u64 __spu_elf_start)
{
static const unsigned char expected[EI_PAD] = {
[EI_MAG0] = ELFMAG0,
Index: linux/arch/powerpc/oprofile/op_model_pa6t.c
===================================================================
--- linux.orig/arch/powerpc/oprofile/op_model_pa6t.c
+++ linux/arch/powerpc/oprofile/op_model_pa6t.c
@@ -132,7 +132,7 @@ static int pa6t_reg_setup(struct op_coun
for (pmc = 0; pmc < cur_cpu_spec->num_pmcs; pmc++) {
/* counters are 40 bit. Move to cputable at some point? */
reset_value[pmc] = (0x1UL << 39) - ctr[pmc].count;
- pr_debug("reset_value for pmc%u inited to 0x%lx\n",
+ pr_debug("reset_value for pmc%u inited to 0x%llx\n",
pmc, reset_value[pmc]);
}
@@ -177,7 +177,7 @@ static int pa6t_start(struct op_counter_
oprofile_running = 1;
- pr_debug("start on cpu %d, mmcr0 %lx\n", smp_processor_id(), mmcr0);
+ pr_debug("start on cpu %d, mmcr0 %llx\n", smp_processor_id(), mmcr0);
return 0;
}
@@ -193,7 +193,7 @@ static void pa6t_stop(void)
oprofile_running = 0;
- pr_debug("stop on cpu %d, mmcr0 %lx\n", smp_processor_id(), mmcr0);
+ pr_debug("stop on cpu %d, mmcr0 %llx\n", smp_processor_id(), mmcr0);
}
/* handle the perfmon overflow vector */
Index: linux/arch/powerpc/platforms/cell/beat_htab.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/beat_htab.c
+++ linux/arch/powerpc/platforms/cell/beat_htab.c
@@ -44,8 +44,8 @@ static DEFINE_SPINLOCK(beat_htab_lock);
static inline unsigned int beat_read_mask(unsigned hpte_group)
{
- unsigned long hpte_v[5];
unsigned long rmask = 0;
+ u64 hpte_v[5];
beat_read_htab_entries(0, hpte_group + 0, hpte_v);
if (!(hpte_v[0] & HPTE_V_BOLTED))
@@ -93,8 +93,7 @@ static long beat_lpar_hpte_insert(unsign
int psize, int ssize)
{
unsigned long lpar_rc;
- unsigned long slot;
- unsigned long hpte_v, hpte_r;
+ u64 hpte_v, hpte_r, slot;
/* same as iseries */
if (vflags & HPTE_V_SECONDARY)
@@ -153,8 +152,9 @@ static long beat_lpar_hpte_remove(unsign
static unsigned long beat_lpar_hpte_getword0(unsigned long slot)
{
- unsigned long dword0, dword[5];
+ unsigned long dword0;
unsigned long lpar_rc;
+ u64 dword[5];
lpar_rc = beat_read_htab_entries(0, slot & ~3UL, dword);
@@ -170,7 +170,7 @@ static void beat_lpar_hptab_clear(void)
unsigned long size_bytes = 1UL << ppc64_pft_size;
unsigned long hpte_count = size_bytes >> 4;
int i;
- unsigned long dummy0, dummy1;
+ u64 dummy0, dummy1;
/* TODO: Use bulk call */
for (i = 0; i < hpte_count; i++)
@@ -189,7 +189,8 @@ static long beat_lpar_hpte_updatepp(unsi
int psize, int ssize, int local)
{
unsigned long lpar_rc;
- unsigned long dummy0, dummy1, want_v;
+ u64 dummy0, dummy1;
+ unsigned long want_v;
want_v = hpte_encode_v(va, psize, MMU_SEGSIZE_256M);
@@ -255,7 +256,8 @@ static void beat_lpar_hpte_updateboltedp
unsigned long ea,
int psize, int ssize)
{
- unsigned long lpar_rc, slot, vsid, va, dummy0, dummy1;
+ unsigned long lpar_rc, slot, vsid, va;
+ u64 dummy0, dummy1;
vsid = get_kernel_vsid(ea, MMU_SEGSIZE_256M);
va = (vsid << 28) | (ea & 0x0fffffff);
@@ -276,7 +278,7 @@ static void beat_lpar_hpte_invalidate(un
{
unsigned long want_v;
unsigned long lpar_rc;
- unsigned long dummy1, dummy2;
+ u64 dummy1, dummy2;
unsigned long flags;
DBG_LOW(" inval : slot=%lx, va=%016lx, psize: %d, local: %d\n",
@@ -315,8 +317,7 @@ static long beat_lpar_hpte_insert_v3(uns
int psize, int ssize)
{
unsigned long lpar_rc;
- unsigned long slot;
- unsigned long hpte_v, hpte_r;
+ u64 hpte_v, hpte_r, slot;
/* same as iseries */
if (vflags & HPTE_V_SECONDARY)
Index: linux/arch/powerpc/platforms/cell/beat_interrupt.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/beat_interrupt.c
+++ linux/arch/powerpc/platforms/cell/beat_interrupt.c
@@ -99,7 +99,7 @@ static void beatic_end_irq(unsigned int
err = beat_downcount_of_interrupt(irq_plug);
if (err != 0) {
if ((err & 0xFFFFFFFF) != 0xFFFFFFF5) /* -11: wrong state */
- panic("Failed to downcount IRQ! Error = %16lx", err);
+ panic("Failed to downcount IRQ! Error = %16llx", err);
printk(KERN_ERR "IRQ over-downcounted, plug %d\n", irq_plug);
}
Index: linux/arch/powerpc/platforms/cell/beat_udbg.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/beat_udbg.c
+++ linux/arch/powerpc/platforms/cell/beat_udbg.c
@@ -40,8 +40,8 @@ static void udbg_putc_beat(char c)
}
/* Buffered chars getc */
-static long inbuflen;
-static long inbuf[2]; /* must be 2 longs */
+static u64 inbuflen;
+static u64 inbuf[2]; /* must be 2 longs */
static int udbg_getc_poll_beat(void)
{
Index: linux/arch/powerpc/platforms/cell/celleb_scc_epci.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/celleb_scc_epci.c
+++ linux/arch/powerpc/platforms/cell/celleb_scc_epci.c
@@ -405,7 +405,7 @@ static int __init celleb_setup_epci(stru
hose->cfg_addr = ioremap(r.start, (r.end - r.start + 1));
if (!hose->cfg_addr)
goto error;
- pr_debug("EPCI: cfg_addr map 0x%016lx->0x%016lx + 0x%016lx\n",
+ pr_debug("EPCI: cfg_addr map 0x%016llx->0x%016lx + 0x%016llx\n",
r.start, (unsigned long)hose->cfg_addr, (r.end - r.start + 1));
if (of_address_to_resource(node, 2, &r))
@@ -413,7 +413,7 @@ static int __init celleb_setup_epci(stru
hose->cfg_data = ioremap(r.start, (r.end - r.start + 1));
if (!hose->cfg_data)
goto error;
- pr_debug("EPCI: cfg_data map 0x%016lx->0x%016lx + 0x%016lx\n",
+ pr_debug("EPCI: cfg_data map 0x%016llx->0x%016lx + 0x%016llx\n",
r.start, (unsigned long)hose->cfg_data, (r.end - r.start + 1));
hose->ops = &celleb_epci_ops;
Index: linux/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linux/arch/powerpc/platforms/cell/interrupt.c
@@ -148,7 +148,7 @@ static unsigned int iic_get_irq(void)
iic = &__get_cpu_var(iic);
*(unsigned long *) &pending =
- in_be64((unsigned long __iomem *) &iic->regs->pending_destr);
+ in_be64((unsigned long long __iomem *) &iic->regs->pending_destr);
if (!(pending.flags & CBE_IIC_IRQ_VALID))
return NO_IRQ;
virq = irq_linear_revmap(iic_host, iic_pending_to_hwnum(pending));
Index: linux/arch/powerpc/platforms/cell/io-workarounds.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/io-workarounds.c
+++ linux/arch/powerpc/platforms/cell/io-workarounds.c
@@ -130,7 +130,7 @@ static const struct ppc_pci_io __devinit
};
-static void __iomem *iowa_ioremap(unsigned long addr, unsigned long size,
+static void __iomem *iowa_ioremap(phys_addr_t addr, unsigned long size,
unsigned long flags)
{
struct iowa_bus *bus;
Index: linux/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/iommu.c
+++ linux/arch/powerpc/platforms/cell/iommu.c
@@ -150,7 +150,7 @@ static int cbe_nr_iommus;
static void invalidate_tce_cache(struct cbe_iommu *iommu, unsigned long *pte,
long n_ptes)
{
- unsigned long __iomem *reg;
+ u64 __iomem *reg;
unsigned long val;
long n;
@@ -855,7 +855,7 @@ static int __init cell_iommu_init_disabl
*/
if (np && size < lmb_end_of_DRAM()) {
printk(KERN_WARNING "iommu: force-enabled, dma window"
- " (%ldMB) smaller than total memory (%ldMB)\n",
+ " (%ldMB) smaller than total memory (%lldMB)\n",
size >> 20, lmb_end_of_DRAM() >> 20);
return -ENODEV;
}
@@ -985,7 +985,7 @@ static void cell_dma_dev_setup_fixed(str
addr = cell_iommu_get_fixed_address(dev) + dma_iommu_fixed_base;
archdata->dma_data = (void *)addr;
- dev_dbg(dev, "iommu: fixed addr = %lx\n", addr);
+ dev_dbg(dev, "iommu: fixed addr = %llx\n", addr);
}
static void insert_16M_pte(unsigned long addr, unsigned long *ptab,
Index: linux/arch/powerpc/platforms/cell/ras.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/ras.c
+++ linux/arch/powerpc/platforms/cell/ras.c
@@ -38,16 +38,16 @@ static void dump_fir(int cpu)
/* Todo: do some nicer parsing of bits and based on them go down
* to other sub-units FIRs and not only IIC
*/
- printk(KERN_ERR "Global Checkstop FIR : 0x%016lx\n",
+ printk(KERN_ERR "Global Checkstop FIR : 0x%016llx\n",
in_be64(&pregs->checkstop_fir));
- printk(KERN_ERR "Global Recoverable FIR : 0x%016lx\n",
+ printk(KERN_ERR "Global Recoverable FIR : 0x%016llx\n",
in_be64(&pregs->checkstop_fir));
- printk(KERN_ERR "Global MachineCheck FIR : 0x%016lx\n",
+ printk(KERN_ERR "Global MachineCheck FIR : 0x%016llx\n",
in_be64(&pregs->spec_att_mchk_fir));
if (iregs == NULL)
return;
- printk(KERN_ERR "IOC FIR : 0x%016lx\n",
+ printk(KERN_ERR "IOC FIR : 0x%016llx\n",
in_be64(&iregs->ioc_fir));
}
Index: linux/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux/arch/powerpc/platforms/cell/spu_base.c
@@ -139,10 +139,10 @@ static void spu_restart_dma(struct spu *
{
struct spu_priv2 __iomem *priv2 = spu->priv2;
- if (!test_bit(SPU_CONTEXT_SWITCH_PENDING, &spu->flags))
+ if (!test_bit(SPU_CONTEXT_SWITCH_PENDING, (unsigned long *)&spu->flags))
out_be64(&priv2->mfc_control_RW, MFC_CNTL_RESTART_DMA_COMMAND);
else {
- set_bit(SPU_CONTEXT_FAULT_PENDING, &spu->flags);
+ set_bit(SPU_CONTEXT_FAULT_PENDING, (unsigned long *)&spu->flags);
mb();
}
}
@@ -151,7 +151,7 @@ static inline void spu_load_slb(struct s
{
struct spu_priv2 __iomem *priv2 = spu->priv2;
- pr_debug("%s: adding SLB[%d] 0x%016lx 0x%016lx\n",
+ pr_debug("%s: adding SLB[%d] 0x%016llx 0x%016llx\n",
__func__, slbe, slb->vsid, slb->esid);
out_be64(&priv2->slb_index_W, slbe);
@@ -221,7 +221,7 @@ static int __spu_trap_data_map(struct sp
{
int ret;
- pr_debug("%s, %lx, %lx\n", __func__, dsisr, ea);
+ pr_debug("%s, %llx, %lx\n", __func__, dsisr, ea);
/*
* Handle kernel space hash faults immediately. User hash
Index: linux/arch/powerpc/platforms/cell/spu_callbacks.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/spu_callbacks.c
+++ linux/arch/powerpc/platforms/cell/spu_callbacks.c
@@ -54,7 +54,7 @@ long spu_sys_callback(struct spu_syscall
long (*syscall)(u64 a1, u64 a2, u64 a3, u64 a4, u64 a5, u64 a6);
if (s->nr_ret >= ARRAY_SIZE(spu_syscall_table)) {
- pr_debug("%s: invalid syscall #%ld", __func__, s->nr_ret);
+ pr_debug("%s: invalid syscall #%lld", __func__, s->nr_ret);
return -ENOSYS;
}
Index: linux/arch/powerpc/platforms/iseries/iommu.c
===================================================================
--- linux.orig/arch/powerpc/platforms/iseries/iommu.c
+++ linux/arch/powerpc/platforms/iseries/iommu.c
@@ -66,7 +66,7 @@ static int tce_build_iSeries(struct iomm
rc = HvCallXm_setTce((u64)tbl->it_index, (u64)index, tce);
if (rc)
- panic("PCI_DMA: HvCallXm_setTce failed, Rc: 0x%lx\n",
+ panic("PCI_DMA: HvCallXm_setTce failed, Rc: 0x%llx\n",
rc);
index++;
uaddr += TCE_PAGE_SIZE;
@@ -81,7 +81,7 @@ static void tce_free_iSeries(struct iomm
while (npages--) {
rc = HvCallXm_setTce((u64)tbl->it_index, (u64)index, 0);
if (rc)
- panic("PCI_DMA: HvCallXm_setTce failed, Rc: 0x%lx\n",
+ panic("PCI_DMA: HvCallXm_setTce failed, Rc: 0x%llx\n",
rc);
index++;
}
Index: linux/arch/powerpc/platforms/pasemi/cpufreq.c
===================================================================
--- linux.orig/arch/powerpc/platforms/pasemi/cpufreq.c
+++ linux/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -112,7 +112,7 @@ static int get_gizmo_latency(void)
static void set_astate(int cpu, unsigned int astate)
{
- u64 flags;
+ unsigned long flags;
/* Return if called before init has run */
if (unlikely(!sdcasr_mapbase))
Index: linux/arch/powerpc/platforms/pseries/iommu.c
===================================================================
--- linux.orig/arch/powerpc/platforms/pseries/iommu.c
+++ linux/arch/powerpc/platforms/pseries/iommu.c
@@ -127,10 +127,10 @@ static int tce_build_pSeriesLP(struct io
}
if (rc && printk_ratelimit()) {
- printk("tce_build_pSeriesLP: plpar_tce_put failed. rc=%ld\n", rc);
- printk("\tindex = 0x%lx\n", (u64)tbl->it_index);
- printk("\ttcenum = 0x%lx\n", (u64)tcenum);
- printk("\ttce val = 0x%lx\n", tce );
+ printk("tce_build_pSeriesLP: plpar_tce_put failed. rc=%lld\n", rc);
+ printk("\tindex = 0x%llx\n", (u64)tbl->it_index);
+ printk("\ttcenum = 0x%llx\n", (u64)tcenum);
+ printk("\ttce val = 0x%llx\n", tce );
show_stack(current, (unsigned long *)__get_SP());
}
@@ -210,10 +210,10 @@ static int tce_buildmulti_pSeriesLP(stru
}
if (rc && printk_ratelimit()) {
- printk("tce_buildmulti_pSeriesLP: plpar_tce_put failed. rc=%ld\n", rc);
- printk("\tindex = 0x%lx\n", (u64)tbl->it_index);
- printk("\tnpages = 0x%lx\n", (u64)npages);
- printk("\ttce[0] val = 0x%lx\n", tcep[0]);
+ printk("tce_buildmulti_pSeriesLP: plpar_tce_put failed. rc=%lld\n", rc);
+ printk("\tindex = 0x%llx\n", (u64)tbl->it_index);
+ printk("\tnpages = 0x%llx\n", (u64)npages);
+ printk("\ttce[0] val = 0x%llx\n", tcep[0]);
show_stack(current, (unsigned long *)__get_SP());
}
return ret;
@@ -227,9 +227,9 @@ static void tce_free_pSeriesLP(struct io
rc = plpar_tce_put((u64)tbl->it_index, (u64)tcenum << 12, 0);
if (rc && printk_ratelimit()) {
- printk("tce_free_pSeriesLP: plpar_tce_put failed. rc=%ld\n", rc);
- printk("\tindex = 0x%lx\n", (u64)tbl->it_index);
- printk("\ttcenum = 0x%lx\n", (u64)tcenum);
+ printk("tce_free_pSeriesLP: plpar_tce_put failed. rc=%lld\n", rc);
+ printk("\tindex = 0x%llx\n", (u64)tbl->it_index);
+ printk("\ttcenum = 0x%llx\n", (u64)tcenum);
show_stack(current, (unsigned long *)__get_SP());
}
@@ -246,9 +246,9 @@ static void tce_freemulti_pSeriesLP(stru
if (rc && printk_ratelimit()) {
printk("tce_freemulti_pSeriesLP: plpar_tce_stuff failed\n");
- printk("\trc = %ld\n", rc);
- printk("\tindex = 0x%lx\n", (u64)tbl->it_index);
- printk("\tnpages = 0x%lx\n", (u64)npages);
+ printk("\trc = %lld\n", rc);
+ printk("\tindex = 0x%llx\n", (u64)tbl->it_index);
+ printk("\tnpages = 0x%llx\n", (u64)npages);
show_stack(current, (unsigned long *)__get_SP());
}
}
@@ -261,10 +261,9 @@ static unsigned long tce_get_pSeriesLP(s
rc = plpar_tce_get((u64)tbl->it_index, (u64)tcenum << 12, &tce_ret);
if (rc && printk_ratelimit()) {
- printk("tce_get_pSeriesLP: plpar_tce_get failed. rc=%ld\n",
- rc);
- printk("\tindex = 0x%lx\n", (u64)tbl->it_index);
- printk("\ttcenum = 0x%lx\n", (u64)tcenum);
+ printk("tce_get_pSeriesLP: plpar_tce_get failed. rc=%lld\n", rc);
+ printk("\tindex = 0x%llx\n", (u64)tbl->it_index);
+ printk("\ttcenum = 0x%llx\n", (u64)tcenum);
show_stack(current, (unsigned long *)__get_SP());
}
Index: linux/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux.orig/arch/powerpc/sysdev/mpic.c
+++ linux/arch/powerpc/sysdev/mpic.c
@@ -435,7 +435,7 @@ static void __init mpic_scan_ht_msi(stru
addr = addr | ((u64)readl(base + HT_MSI_ADDR_HI) << 32);
}
- printk(KERN_DEBUG "mpic: - HT:%02x.%x %s MSI mapping found @ 0x%lx\n",
+ printk(KERN_DEBUG "mpic: - HT:%02x.%x %s MSI mapping found @ 0x%llx\n",
PCI_SLOT(devfn), PCI_FUNC(devfn),
flags & HT_MSI_FLAGS_ENABLE ? "enabled" : "disabled", addr);
Index: linux/drivers/char/hvc_beat.c
===================================================================
--- linux.orig/drivers/char/hvc_beat.c
+++ linux/drivers/char/hvc_beat.c
@@ -44,7 +44,7 @@ static int hvc_beat_get_chars(uint32_t v
static unsigned char q[sizeof(unsigned long) * 2]
__attribute__((aligned(sizeof(unsigned long))));
static int qlen = 0;
- unsigned long got;
+ u64 got;
again:
if (qlen) {
@@ -63,7 +63,7 @@ again:
}
}
if (beat_get_term_char(vtermno, &got,
- ((unsigned long *)q), ((unsigned long *)q) + 1) == 0) {
+ ((u64 *)q), ((u64 *)q) + 1) == 0) {
qlen = got;
goto again;
}
Index: linux/drivers/net/pasemi_mac.c
===================================================================
--- linux.orig/drivers/net/pasemi_mac.c
+++ linux/drivers/net/pasemi_mac.c
@@ -712,7 +712,7 @@ static inline void pasemi_mac_rx_error(c
rcmdsta = read_dma_reg(PAS_DMA_RXINT_RCMDSTA(mac->dma_if));
ccmdsta = read_dma_reg(PAS_DMA_RXCHAN_CCMDSTA(chan->chno));
- printk(KERN_ERR "pasemi_mac: rx error. macrx %016lx, rx status %lx\n",
+ printk(KERN_ERR "pasemi_mac: rx error. macrx %016llx, rx status %llx\n",
macrx, *chan->status);
printk(KERN_ERR "pasemi_mac: rcmdsta %08x ccmdsta %08x\n",
@@ -730,8 +730,8 @@ static inline void pasemi_mac_tx_error(c
cmdsta = read_dma_reg(PAS_DMA_TXCHAN_TCMDSTA(chan->chno));
- printk(KERN_ERR "pasemi_mac: tx error. mactx 0x%016lx, "\
- "tx status 0x%016lx\n", mactx, *chan->status);
+ printk(KERN_ERR "pasemi_mac: tx error. mactx 0x%016llx, "\
+ "tx status 0x%016llx\n", mactx, *chan->status);
printk(KERN_ERR "pasemi_mac: tcmdsta 0x%08x\n", cmdsta);
}
Index: linux/drivers/pcmcia/electra_cf.c
===================================================================
--- linux.orig/drivers/pcmcia/electra_cf.c
+++ linux/drivers/pcmcia/electra_cf.c
@@ -297,7 +297,7 @@ static int __devinit electra_cf_probe(st
goto fail3;
}
- dev_info(device, "at mem 0x%lx io 0x%lx irq %d\n",
+ dev_info(device, "at mem 0x%lx io 0x%llx irq %d\n",
cf->mem_phys, io.start, cf->irq);
cf->active = 1;
Index: linux/drivers/scsi/ibmvscsi/ibmvscsi.c
===================================================================
--- linux.orig/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ linux/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -1060,7 +1060,7 @@ static int ibmvscsi_eh_abort_handler(str
}
sdev_printk(KERN_INFO, cmd->device,
- "aborting command. lun 0x%lx, tag 0x%lx\n",
+ "aborting command. lun 0x%llx, tag 0x%llx\n",
(((u64) lun) << 48), (u64) found_evt);
wait_for_completion(&evt->comp);
@@ -1081,7 +1081,7 @@ static int ibmvscsi_eh_abort_handler(str
if (rsp_rc) {
if (printk_ratelimit())
sdev_printk(KERN_WARNING, cmd->device,
- "abort code %d for task tag 0x%lx\n",
+ "abort code %d for task tag 0x%llx\n",
rsp_rc, tsk_mgmt->task_tag);
return FAILED;
}
@@ -1101,12 +1101,12 @@ static int ibmvscsi_eh_abort_handler(str
if (found_evt == NULL) {
spin_unlock_irqrestore(hostdata->host->host_lock, flags);
- sdev_printk(KERN_INFO, cmd->device, "aborted task tag 0x%lx completed\n",
+ sdev_printk(KERN_INFO, cmd->device, "aborted task tag 0x%llx completed\n",
tsk_mgmt->task_tag);
return SUCCESS;
}
- sdev_printk(KERN_INFO, cmd->device, "successfully aborted task tag 0x%lx\n",
+ sdev_printk(KERN_INFO, cmd->device, "successfully aborted task tag 0x%llx\n",
tsk_mgmt->task_tag);
cmd->result = (DID_ABORT << 16);
@@ -1181,7 +1181,7 @@ static int ibmvscsi_eh_device_reset_hand
return FAILED;
}
- sdev_printk(KERN_INFO, cmd->device, "resetting device. lun 0x%lx\n",
+ sdev_printk(KERN_INFO, cmd->device, "resetting device. lun 0x%llx\n",
(((u64) lun) << 48));
wait_for_completion(&evt->comp);
@@ -1202,7 +1202,7 @@ static int ibmvscsi_eh_device_reset_hand
if (rsp_rc) {
if (printk_ratelimit())
sdev_printk(KERN_WARNING, cmd->device,
- "reset code %d for task tag 0x%lx\n",
+ "reset code %d for task tag 0x%llx\n",
rsp_rc, tsk_mgmt->task_tag);
return FAILED;
}
^ permalink raw reply
* Re: linux-next: sched tree build warning
From: Paul Mackerras @ 2008-12-22 8:14 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ken Chen, Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
linux-next
In-Reply-To: <20081222070426.GD29160@elte.hu>
Ingo Molnar writes:
> the real solution is something like the patch below. That generates new
> (but harmless) warnings within the powerpc code but those are a one-off
> effort to fix and are not reoccuring.
>
> Cc:-ed Paul Mackerras - Paul, am i missing anything?
That does change the formal types of things exported to userland, and
hence technically breaks the ABI, which is why I am cautious about
this idea. Whether or not that causes real problems in practice I'm
not sure, but I would want to at least check with the glibc developers
first.
One solution to might be to use an #ifdef __KERNEL__ so that userland
still sees the long types but kernel code sees long longs.
Paul.
^ permalink raw reply
* Re: linux-next: sched tree build warning
From: Ingo Molnar @ 2008-12-22 8:18 UTC (permalink / raw)
To: Paul Mackerras
Cc: Ken Chen, Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
linux-next
In-Reply-To: <18767.19576.286910.148623@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> Ingo Molnar writes:
>
> > the real solution is something like the patch below. That generates new
> > (but harmless) warnings within the powerpc code but those are a one-off
> > effort to fix and are not reoccuring.
> >
> > Cc:-ed Paul Mackerras - Paul, am i missing anything?
>
> That does change the formal types of things exported to userland, and
> hence technically breaks the ABI, which is why I am cautious about this
> idea. Whether or not that causes real problems in practice I'm not
> sure, but I would want to at least check with the glibc developers
> first.
>
> One solution to might be to use an #ifdef __KERNEL__ so that userland
> still sees the long types but kernel code sees long longs.
which APIs do you mean exactly, could you give me an example please and
the type of breakage you suspect?
I cannot see how the binary representation could ever change from this.
(and that is all that an ABI is about - it is an application Binary
interface. I.e. there's no ABI breakage.)
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the rr tree
From: Mark McLoughlin @ 2008-12-22 8:45 UTC (permalink / raw)
To: Rusty Russell; +Cc: Stephen Rothwell, linux-next, Kay Sievers, Greg KH
In-Reply-To: <200812221828.33016.rusty@rustcorp.com.au>
Hi Stephen/Rusty,
On Mon, 2008-12-22 at 18:28 +1030, Rusty Russell wrote:
> On Monday 22 December 2008 17:02:13 Stephen Rothwell wrote:
> > Hi Rusty,
> >
> > Today's linux-next merge of the rr tree got a conflict in
> > drivers/virtio/virtio_pci.c between commit
> > b5146336e3bc3786712919e94106063036dae86b ("virtio: do not statically
> > allocate root device") from the driver-core tree and commits
> > f53dba3a1ea82dfb37f094a942ae74032413809f ("virtio: struct device -
> > replace bus_id with dev_name(), dev_set_name()") and
> > ab4e479d47ceac2fa5bebd5b99d27f01fe0e0c8b ("virtio: add PCI device release
> > () function") from the rr tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. Mark, does
> > this driver-core patch obsolete the second rr tree patch above?
The conflict resolution is correct.
> This is not unexpected. Mark sent me those two, the others went to
> Greg. I'm happy to ack them and send them on to Greg.
You could do that, or let Stephen carry the fixup or pull these bits
from Greg's tree into your before NEXT_PATCHES_START:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core/driver-core-add-root_device_register.patch
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/driver-core/virtio-do-not-statically-allocate-root-device.patch
Thanks,
Mark.
^ permalink raw reply
* Re: linux-next: sched tree build warning
From: Paul Mackerras @ 2008-12-22 9:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ken Chen, Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
linux-next
In-Reply-To: <20081222081811.GA10950@elte.hu>
Ingo Molnar writes:
> which APIs do you mean exactly, could you give me an example please and
> the type of breakage you suspect?
Any struct with a __u64 or __s64 in it that gets exported to userland
will have a different type signature with the change, hence has the
potential to cause compile warnings or errors on correct code
(e.g. warnings on printf's that use %ld to print an __s64 field on
ppc64). It's possible that C++ stuff will fail to link because of
mangled names coming out differently. And so on.
> I cannot see how the binary representation could ever change from this.
> (and that is all that an ABI is about - it is an application Binary
> interface. I.e. there's no ABI breakage.)
Yes, the bits are the same, but that doesn't mean the types are the
same. And we do export type definitions.
I once wanted to change the ppc32 size_t definition from unsigned int
to unsigned long to match up with ppc64. That caused more pain than
it was worth because of exactly this issue (and also because gcc has
fixed ideas about size_t) so I abandoned it. That's why I'm cautious
about changing user-visible types. I'm not saying we can't do it, I'm
saying we shouldn't do it unilaterally.
Paul.
^ permalink raw reply
* Re: linux-next: sched tree build warning
From: Ingo Molnar @ 2008-12-22 10:53 UTC (permalink / raw)
To: Paul Mackerras
Cc: Ken Chen, Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
linux-next
In-Reply-To: <18767.24943.183634.866661@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> > I cannot see how the binary representation could ever change from
> > this. (and that is all that an ABI is about - it is an application
> > Binary interface. I.e. there's no ABI breakage.)
>
> Yes, the bits are the same, but that doesn't mean the types are the
> same. And we do export type definitions.
>
> I once wanted to change the ppc32 size_t definition from unsigned int to
> unsigned long to match up with ppc64. That caused more pain than it was
> worth because of exactly this issue (and also because gcc has fixed
> ideas about size_t) so I abandoned it. That's why I'm cautious about
> changing user-visible types. I'm not saying we can't do it, I'm saying
> we shouldn't do it unilaterally.
okay, so what's the timeline to double check those details and to get this
fix upstream?
Ingo
^ permalink raw reply
* Re: linux-next: sched tree build warning
From: Paul Mackerras @ 2008-12-22 12:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ken Chen, Stephen Rothwell, Thomas Gleixner, H. Peter Anvin,
linux-next
In-Reply-To: <20081222105357.GA21776@elte.hu>
Ingo Molnar writes:
> okay, so what's the timeline to double check those details and to get this
> fix upstream?
Dunno - I have sent a query to our glibc guys, but it is vacation
season, which may delay things...
Paul.
^ permalink raw reply
* linux-next: driver-core tree build failure
From: Stephen Rothwell @ 2008-12-22 12:59 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Mark McLoughlin
Hi Greg,
Today's linux-next build (powerpc allnoconfig) failed like this:
drivers/base/core.c: In function '__root_device_register':
drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
root_device_register()"). This needs to cope with !CONFIG_MODULES (where
struct module is not defined).
I applied the following patch but only for today because it is too hard
to revert the above patch ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 Dec 2008 23:50:56 +1100
Subject: [PATCH] driver core: fix root_device_register for not CONFIG_MODULES
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/base/core.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6fbdd8b..aa93980 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1273,6 +1273,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
return ERR_PTR(err);
}
+#ifdef CONFIG_MODULE
if (owner) {
struct module_kobject *mk = &owner->mkobj;
@@ -1283,6 +1284,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
}
root->owner = owner;
}
+#endif
return &root->dev;
}
--
1.6.0.5
^ permalink raw reply related
* linux-next: kvm tree build failure
From: Stephen Rothwell @ 2008-12-22 13:25 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-next, Jan Kiszka, Hollis Blanchard
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Hi Avi,
Today's linux-next build (powerpc ppc44x_config) failed like this:
arch/powerpc/kvm/44x.c: In function 'kvmppc_core_load_guest_debugstate':
arch/powerpc/kvm/44x.c:58: warning: initialization from incompatible pointer type
arch/powerpc/kvm/44x.c:75: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:76: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:79: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:80: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:83: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:84: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:87: error: 'struct kvm_guest_debug' has no member named 'bp'
arch/powerpc/kvm/44x.c:88: error: 'struct kvm_guest_debug' has no member named 'bp'
Probably caused by commit 6968f31a2163f8fcf26ea8775c44d7e5be54d622 ("KVM:
Remove old kvm_guest_debug structs") so I have reverted the kvm tree for
today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: scsi-post-merge tree build failure
From: Stephen Rothwell @ 2008-12-22 14:25 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
Cc: linux-next, Kumar Gala
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
Hi Paul, Ben,
Today's linux-next build (powerpc ppc44x_config) failed like this:
arch/powerpc/kvm/powerpc.c: In function 'kvm_arch_vcpu_put':
arch/powerpc/kvm/powerpc.c:333: error: implicit declaration of function '_tlbil_all'
Probably caused by commit 2a4aca1144394653269720ffbb5a325a77abd5fa
("powerpc/mm: Split low level tlb invalidate for nohash processors").
Reverting just that commit was too difficult, so I have reverted the
powerpc tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: no linux-next for Dec 22
From: Stephen Rothwell @ 2008-12-22 14:32 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
Hi all,
There will be no release for Dec 22. Too much has gone badly. Hopefully
tomorrow with some of today's reported problems fixed, it will go better.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Mark McLoughlin @ 2008-12-22 14:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next
In-Reply-To: <20081222235936.5971ad15.sfr@canb.auug.org.au>
On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next build (powerpc allnoconfig) failed like this:
>
> drivers/base/core.c: In function '__root_device_register':
> drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
>
> Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> root_device_register()"). This needs to cope with !CONFIG_MODULES (where
> struct module is not defined).
Ouch, my bad.
> I applied the following patch but only for today because it is too hard
> to revert the above patch ...
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 22 Dec 2008 23:50:56 +1100
> Subject: [PATCH] driver core: fix root_device_register for not CONFIG_MODULES
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/base/core.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 6fbdd8b..aa93980 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1273,6 +1273,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> return ERR_PTR(err);
> }
>
> +#ifdef CONFIG_MODULE
> if (owner) {
> struct module_kobject *mk = &owner->mkobj;
>
> @@ -1283,6 +1284,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> }
> root->owner = owner;
> }
> +#endif
Yep, looks correct to me ...
Thanks,
Mark.
^ permalink raw reply
* Re: linux-next: scsi-post-merge tree build failure
From: Stephen Rothwell @ 2008-12-22 14:51 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
Cc: linux-next, Kumar Gala
In-Reply-To: <20081223012545.5b1e7f5e.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 150 bytes --]
I meant the powerpc tree, of course ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Firmware patches for SCSI
From: James Bottomley @ 2008-12-22 15:01 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Stephen Rothwell, Jaswinder Singh, linux-scsi, LKML, linux-next,
David Woodhouse
In-Reply-To: <494F4656.6010109@panasas.com>
On Mon, 2008-12-22 at 09:48 +0200, Boaz Harrosh wrote:
> Stephen Rothwell wrote:
> > Hi James,
> >
> > On Fri, 19 Dec 2008 15:53:51 -0500 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >> OK, then whatever tree contains them needs to eject them or be dropped
> >> from linux-next.
> >
> > That is a problem for me and David. Do not let it concern you ... :-)
> >
> >>> So I am curious that should I resend these patches based on which git tree.
> >> Yes please. For me it would be against scsi-misc ... for the other
> >> drivers it would be their development tree. The simplest thing to do is
> >> probably to rebase them all on top of linux-next (which contains all of
> >> our trees) and then send them to the individual subsystem maintainer
> >> lists.
> >
> > Please don't do that, please base each one on either Linus' tree or the
> > appropriate maintainer's subsystem tree as linux-next is a moving
> > target (for instance, if you had based the scsi ones on next-20081219,
> > then the scsi tree was not included ...). Basing on Linus' tree should
> > work in most cases as there are not to many conflicts caused by these
> > patches (the tg3 one is the worst so basing that off the net tree is
> > probably worth while).
> >
>
> I think what James meant is to rebase over linux-next when cutting the
> patches in order to send them to the different maintainers over email.
> In that case linux-next is perfect because you are sure none of the
> patches will conflict with any maintainer and you do that all in one
> place. Since you are not merging then linux-next volatility does not
> matter.
Yes, that's precisely what I meant, thanks!
The point is that it's hard to work out where all the maintainer trees
are, and git makes rebasing an easy exercise, so you just prepare your
patch set against one version of linux-next ... you can rebase it to
future versions as much as you like until you're ready with
git-send-email to send off the patch sets. Linux-next is only useless
as a base for an upstream git tree; it makes a good work ground for a
volatile one that's essentially only holding patches for onward
transmission (as patches not as a git tree).
I suppose the caveat is that you have to be intimately familiar with how
git rebase works, so this course of action isn't for the faint of heart.
James
^ permalink raw reply
* Re: Firmware patches for SCSI
From: Stephen Rothwell @ 2008-12-22 15:28 UTC (permalink / raw)
To: James Bottomley
Cc: Boaz Harrosh, Jaswinder Singh, linux-scsi, LKML, linux-next,
David Woodhouse
In-Reply-To: <1229958063.3345.3.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
On Mon, 22 Dec 2008 09:01:03 -0600 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Mon, 2008-12-22 at 09:48 +0200, Boaz Harrosh wrote:
> >
> > I think what James meant is to rebase over linux-next when cutting the
> > patches in order to send them to the different maintainers over email.
> > In that case linux-next is perfect because you are sure none of the
> > patches will conflict with any maintainer and you do that all in one
> > place. Since you are not merging then linux-next volatility does not
> > matter.
Unless there are conflict resolutions in the linux-next tree (and there
are a few) that involve the files in the generated patch. In that case
the patch may not apply cleanly to any of the individual trees.
> The point is that it's hard to work out where all the maintainer trees
Hopefully you can glean that information from the MAINTAINERS file or the
Trees file in any linux-next tree (available via git-web if not from the
tree itself).
Just pointing out the possible problems ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Inaky Perez-Gonzalez @ 2008-12-22 17:26 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, Greg KH, linux-next
In-Reply-To: <20081222064542.GA24252@uranus.ravnborg.org>
On Sunday 21 December 2008, Sam Ravnborg wrote:
> On Mon, Dec 22, 2008 at 01:42:21PM +1100, Stephen Rothwell wrote:
> > (Just cc'ing Sam)
> >
> > On Sun, 21 Dec 2008 17:31:10 -0800 Greg KH <greg@kroah.com> wrote:
> > > On Mon, Dec 22, 2008 at 11:33:35AM +1100, Stephen Rothwell wrote:
> > > > Hi Greg,
> > > >
> > > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > >
> > > > x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No such
> > > > file or directory
> > > >
> > > > I reverted commit 66aa675719ab82a03a66b75210fd40be6541f8fb ("wimax:
> > > > Makefile, Kconfig and docbook linkage for the stack") just to make
> > > > the build work.
> > >
> > > Inaky, any ideas? This really looks like a build system error that I
> > > ran into with the staging tree in the past. I had to add a "dummy"
> > > file to the empty directory to get it to build properly.
> > >
> > > I tried to duplicate the problem with a sample patch, but never could
> > > :(
>
> Incidentally I sent some review comments to said patch yesterday
> but missed this one.
>
> We have:
> diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
> new file mode 100644
> index 0000000..bda9430
> --- /dev/null
> +++ b/drivers/net/wimax/Makefile
> @@ -0,0 +1,2 @@
> +
> +obj-$(CONFIG_WIMAX_I2400M) += i2400m/
>
>
>
> But the problem here is that because we do not even pretend to
> build some files in this dir thus kbuild does not create build-in.o
>
> The fix is a bit ugly but simple. Add a dummy statement to
> the drivers/net/wimax/Makefile like this:
>
> # force kbuild to create built-in.o
> obj- := dummy.o
ops -- ok, I will. I guess I have to add this in all the similar ones, right?
Greg, do you want a new patch series or just another patch on top?
--
Inaky
^ permalink raw reply
* Re: linux-next: usb tree build failure
From: Sam Ravnborg @ 2008-12-22 17:53 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Stephen Rothwell, Greg KH, linux-next
In-Reply-To: <200812220926.43784.inaky@linux.intel.com>
On Mon, Dec 22, 2008 at 09:26:43AM -0800, Inaky Perez-Gonzalez wrote:
> On Sunday 21 December 2008, Sam Ravnborg wrote:
> > On Mon, Dec 22, 2008 at 01:42:21PM +1100, Stephen Rothwell wrote:
> > > (Just cc'ing Sam)
> > >
> > > On Sun, 21 Dec 2008 17:31:10 -0800 Greg KH <greg@kroah.com> wrote:
> > > > On Mon, Dec 22, 2008 at 11:33:35AM +1100, Stephen Rothwell wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > > >
> > > > > x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No such
> > > > > file or directory
> > > > >
> > > > > I reverted commit 66aa675719ab82a03a66b75210fd40be6541f8fb ("wimax:
> > > > > Makefile, Kconfig and docbook linkage for the stack") just to make
> > > > > the build work.
> > > >
> > > > Inaky, any ideas? This really looks like a build system error that I
> > > > ran into with the staging tree in the past. I had to add a "dummy"
> > > > file to the empty directory to get it to build properly.
> > > >
> > > > I tried to duplicate the problem with a sample patch, but never could
> > > > :(
> >
> > Incidentally I sent some review comments to said patch yesterday
> > but missed this one.
> >
> > We have:
> > diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
> > new file mode 100644
> > index 0000000..bda9430
> > --- /dev/null
> > +++ b/drivers/net/wimax/Makefile
> > @@ -0,0 +1,2 @@
> > +
> > +obj-$(CONFIG_WIMAX_I2400M) += i2400m/
> >
> >
> >
> > But the problem here is that because we do not even pretend to
> > build some files in this dir thus kbuild does not create build-in.o
> >
> > The fix is a bit ugly but simple. Add a dummy statement to
> > the drivers/net/wimax/Makefile like this:
> >
> > # force kbuild to create built-in.o
> > obj- := dummy.o
>
> ops -- ok, I will. I guess I have to add this in all the similar ones, right?
You need this in all cases where you have a Makefile that
only specify sub directories. I assume this is the only Makefile
where you have this.
Sam
^ permalink raw reply
* Re: linux-next: scsi-post-merge tree build failure
From: Benjamin Herrenschmidt @ 2008-12-22 20:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Mackerras, linuxppc-dev, linux-next, Kumar Gala,
Hollis Blanchard
In-Reply-To: <20081223012545.5b1e7f5e.sfr@canb.auug.org.au>
On Tue, 2008-12-23 at 01:25 +1100, Stephen Rothwell wrote:
> Hi Paul, Ben,
>
> Today's linux-next build (powerpc ppc44x_config) failed like this:
>
> arch/powerpc/kvm/powerpc.c: In function 'kvm_arch_vcpu_put':
> arch/powerpc/kvm/powerpc.c:333: error: implicit declaration of function '_tlbil_all'
>
> Probably caused by commit 2a4aca1144394653269720ffbb5a325a77abd5fa
> ("powerpc/mm: Split low level tlb invalidate for nohash processors").
> Reverting just that commit was too difficult, so I have reverted the
> powerpc tree for today.
You can't revert that without reverting my whole series.
Adding a #include ../mm/mmu_decl.h to the kvm code should fix it for
now.
I need to talk to hollis about the right way to do that stuff in
the long run but it might be it... those _tlbil things are low level
stuff that aren't supposed to be used by the outside world which is
why I moved the declarations there, but KVM is also low level :-)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Hollis Blanchard @ 2008-12-22 21:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Avi Kivity, linux-next, Kumar Gala
In-Reply-To: <1229922804.13001.84.camel@pasglop>
On Mon, 2008-12-22 at 16:13 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> >
> > The former patch changes the _tlbia() to _tlbil_all() in
> > kvm_arch_vcpu_put(). The latter restructures this code.
> >
> > I don't know enough to fix this up, so for today I have merely used the
> > kvm tree version. Please come up with something better (if needed) and I
> > can use that as a merge resolution.
>
> Hollis, can you have a look ? I suspect whatever is in the kvm tree is
> ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
> which don't exist anymore for nohash...
I've stopped calling _tlbia() in KVM, so I think the easiest solution
would be to drop the KVM part of your patch, Ben.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree
From: Benjamin Herrenschmidt @ 2008-12-22 21:41 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Stephen Rothwell, Avi Kivity, linux-next, Kumar Gala
In-Reply-To: <1229981967.7181.5.camel@localhost.localdomain>
On Mon, 2008-12-22 at 15:39 -0600, Hollis Blanchard wrote:
> On Mon, 2008-12-22 at 16:13 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2008-12-22 at 14:52 +1100, Stephen Rothwell wrote:
> > >
> > > The former patch changes the _tlbia() to _tlbil_all() in
> > > kvm_arch_vcpu_put(). The latter restructures this code.
> > >
> > > I don't know enough to fix this up, so for today I have merely used the
> > > kvm tree version. Please come up with something better (if needed) and I
> > > can use that as a merge resolution.
> >
> > Hollis, can you have a look ? I suspect whatever is in the kvm tree is
> > ok, provided it doesn't use the old names such as _tlbia() or _tlbie()
> > which don't exist anymore for nohash...
>
> I've stopped calling _tlbia() in KVM, so I think the easiest solution
> would be to drop the KVM part of your patch, Ben.
Patch is in Paulus -next already so we'll have to do a manual resolve.
Also, you'll need to include ../mm/mmu_decl.h to get to _tlbil_* ..
sorry about that.
Cheers,
Ben.
^ 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