* [PATCH 1/2] [POWERPC] mpc5200: Fix Kconfig dependancies on MPC5200 FEC device driver
From: Grant Likely @ 2007-10-31 6:28 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
When not building an arch/powerpc kernel, the mpc5200 FEC driver depends
on some symbols which are not defined (BESTCOMM & BESTCOMM_FEC).
This patch flips around the dependancy logic so that it cannot be
selected unless BESTCOMM_FEC is selected first. Kconfig stops
complaining this way.
Also, the driver only works for arch/powerpc (not arch/ppc) anyway so
it should depend on PPC_MERGE also.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/Kconfig | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 867cb73..5f800a6 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1883,9 +1883,7 @@ config FEC2
config FEC_MPC52xx
tristate "MPC52xx FEC driver"
- depends on PPC_MPC52xx
- select PPC_BESTCOMM
- select PPC_BESTCOMM_FEC
+ depends on PPC_MERGE && PPC_MPC52xx && PPC_BESTCOMM_FEC
select CRC32
select PHYLIB
---help---
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] Fix region size check in mpc5200 FEC driver
From: Grant Likely @ 2007-10-31 6:28 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
In-Reply-To: <20071031062842.7966.99739.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Driver shouldn't complain if the register range is larger than what
it expects. This works around failures with some device trees.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/fec_mpc52xx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index fc1cf0b..a8a0ee2 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -879,9 +879,9 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
"Error while parsing device node resource\n" );
return rv;
}
- if ((mem.end - mem.start + 1) != sizeof(struct mpc52xx_fec)) {
+ if ((mem.end - mem.start + 1) < sizeof(struct mpc52xx_fec)) {
printk(KERN_ERR DRIVER_NAME
- " - invalid resource size (%lx != %x), check mpc52xx_devices.c\n",
+ " - invalid resource size (%lx < %x), check mpc52xx_devices.c\n",
(unsigned long)(mem.end - mem.start + 1), sizeof(struct mpc52xx_fec));
return -EINVAL;
}
^ permalink raw reply related
* Re: ring on PowerPC
From: Wang, Baojun @ 2007-10-31 6:12 UTC (permalink / raw)
To: linuxppc-embedded, Bai Shuwei
In-Reply-To: <393807697.25590@lzu.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
On Wednesday 31 October 2007 13:05:16, Bai Shuwei wrote：
> Hi, everyone
> As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> And now I want to know wether there is a simple mechanism on the PowerPC
> architecture? thx all!
>
> best regards!
>
> Buroc
powerpc has a machine state register(MSR), bit MSR_PR present the current
privilege level, if msr & MSR_PR, then it's from user space, otherwise(msr &
MSR_PR == 0) it's kernel space.
besides, the linux implementation only use ring0 and ring3 under i386, ring0
is highest(kernel space), ring3 is lowest (userspace)
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Deal with 44x virtually tagged icache
From: Benjamin Herrenschmidt @ 2007-10-31 5:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
The 44x family has an interesting "feature" which is a virtually
tagged instruction cache (yuck !). So far, we haven't dealt with
it properly, which means we've been mostly lucky or people didn't
report the problems, unless people have been running custom patches
in their distro...
This is an attempt at fixing it properly. I chose to do it by
setting a global flag whenever we change a PTE that was previously
marked executable, and flush the entire instruction cache upon
return to user space when that happens.
This is a bit heavy handed, but it's hard to do more fine grained
flushes as the icbi instruction, on those processor, for some very
strange reasons (since the cache is virtually mapped) still requires
a valid TLB entry for reading in the target address space, which
isn't something I want to deal with.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This version fixes the double iccci noticed by josh and does
arch/ppc (untested).
arch/powerpc/kernel/entry_32.S | 23 +++++++++++++++++++++++
arch/powerpc/kernel/misc_32.S | 9 +++++++++
arch/powerpc/mm/44x_mmu.c | 1 +
arch/ppc/kernel/entry.S | 23 +++++++++++++++++++++++
arch/ppc/kernel/misc.S | 9 +++++++++
arch/ppc/mm/44x_mmu.c | 1 +
include/asm-powerpc/pgtable-ppc32.h | 13 +++++++++++++
7 files changed, 79 insertions(+)
Index: linux-work/arch/powerpc/kernel/entry_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/entry_32.S 2007-10-15 11:19:35.000000000 +1000
+++ linux-work/arch/powerpc/kernel/entry_32.S 2007-10-31 10:40:45.000000000 +1100
@@ -244,6 +244,13 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ bne- 2f
+1:
+#endif /* CONFIG_44x */
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -258,6 +265,12 @@ syscall_exit_cont:
mtspr SPRN_SRR1,r8
SYNC
RFI
+#ifdef CONFIG_44x
+2: li r7,0
+ iccci r0,r0
+ stw r7,icache_44x_need_flush@l(r4)
+ b 1b
+#endif /* CONFIG_44x */
66: li r3,-ENOSYS
b ret_from_syscall
@@ -683,6 +696,16 @@ resume_kernel:
/* interrupts are hard-disabled at this point */
restore:
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ beq+ 1f
+ li r6,0
+ iccci r0,r0
+ stw r6,icache_44x_need_flush@l(r4)
+1:
+#endif /* CONFIG_44x */
lwz r0,GPR0(r1)
lwz r2,GPR2(r1)
REST_4GPRS(3, r1)
Index: linux-work/arch/powerpc/mm/44x_mmu.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/44x_mmu.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/powerpc/mm/44x_mmu.c 2007-10-30 15:30:50.000000000 +1100
@@ -35,6 +35,7 @@
*/
unsigned int tlb_44x_index; /* = 0 */
unsigned int tlb_44x_hwater = PPC44x_TLB_SIZE - 1 - PPC44x_EARLY_TLBS;
+int icache_44x_need_flush;
/*
* "Pins" a 256MB TLB entry in AS0 for kernel lowmem
Index: linux-work/include/asm-powerpc/pgtable-ppc32.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pgtable-ppc32.h 2007-09-28 11:42:10.000000000 +1000
+++ linux-work/include/asm-powerpc/pgtable-ppc32.h 2007-10-30 15:30:50.000000000 +1100
@@ -11,6 +11,11 @@
extern unsigned long va_to_phys(unsigned long address);
extern pte_t *va_to_pte(unsigned long address);
extern unsigned long ioremap_bot, ioremap_base;
+
+#ifdef CONFIG_44x
+extern int icache_44x_need_flush;
+#endif
+
#endif /* __ASSEMBLY__ */
/*
@@ -562,6 +567,10 @@ static inline unsigned long pte_update(p
: "=&r" (old), "=&r" (tmp), "=m" (*p)
: "r" (p), "r" (clr), "r" (set), "m" (*p)
: "cc" );
+#ifdef CONFIG_44x
+ if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC))
+ icache_44x_need_flush = 1;
+#endif
return old;
}
#else
@@ -582,6 +591,10 @@ static inline unsigned long long pte_upd
: "=&r" (old), "=&r" (tmp), "=m" (*p)
: "r" (p), "r" ((unsigned long)(p) + 4), "r" (clr), "r" (set), "m" (*p)
: "cc" );
+#ifdef CONFIG_44x
+ if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC))
+ icache_44x_need_flush = 1;
+#endif
return old;
}
#endif
Index: linux-work/arch/powerpc/kernel/misc_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-10-30 15:15:03.000000000 +1100
+++ linux-work/arch/powerpc/kernel/misc_32.S 2007-10-30 15:30:50.000000000 +1100
@@ -543,12 +543,21 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_I
addi r3,r3,L1_CACHE_BYTES
bdnz 0b
sync
+#ifndef CONFIG_44x
+ /* We don't flush the icache on 44x. Those have a virtual icache
+ * and we don't have access to the virtual address here (it's
+ * not the page vaddr but where it's mapped in user space). The
+ * flushing of the icache on these is handled elsewhere, when
+ * a change in the address space occurs, before returning to
+ * user space
+ */
mtctr r4
1: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 1b
sync
isync
+#endif /* CONFIG_44x */
blr
/*
Index: linux-work/arch/ppc/kernel/entry.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/entry.S 2007-10-31 10:39:32.000000000 +1100
+++ linux-work/arch/ppc/kernel/entry.S 2007-10-31 10:40:46.000000000 +1100
@@ -244,6 +244,13 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ bne- 2f
+1:
+#endif /* CONFIG_44x */
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -258,6 +265,12 @@ syscall_exit_cont:
mtspr SPRN_SRR1,r8
SYNC
RFI
+#ifdef CONFIG_44x
+2: li r7,0
+ iccci r0,r0
+ stw r7,icache_44x_need_flush@l(r4)
+ b 1b
+#endif /* CONFIG_44x */
66: li r3,-ENOSYS
b ret_from_syscall
@@ -679,6 +692,16 @@ resume_kernel:
/* interrupts are hard-disabled at this point */
restore:
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ beq+ 1f
+ li r6,0
+ iccci r0,r0
+ stw r6,icache_44x_need_flush@l(r4)
+1:
+#endif /* CONFIG_44x */
lwz r0,GPR0(r1)
lwz r2,GPR2(r1)
REST_4GPRS(3, r1)
Index: linux-work/arch/ppc/kernel/misc.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/misc.S 2007-10-31 10:41:21.000000000 +1100
+++ linux-work/arch/ppc/kernel/misc.S 2007-10-31 10:43:06.000000000 +1100
@@ -499,12 +499,21 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_I
addi r3,r3,L1_CACHE_BYTES
bdnz 0b
sync
+#ifndef CONFIG_44x
+ /* We don't flush the icache on 44x. Those have a virtual icache
+ * and we don't have access to the virtual address here (it's
+ * not the page vaddr but where it's mapped in user space). The
+ * flushing of the icache on these is handled elsewhere, when
+ * a change in the address space occurs, before returning to
+ * user space
+ */
mtctr r4
1: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 1b
sync
isync
+#endif /* CONFIG_44x */
blr
/*
Index: linux-work/arch/ppc/mm/44x_mmu.c
===================================================================
--- linux-work.orig/arch/ppc/mm/44x_mmu.c 2007-10-31 10:39:04.000000000 +1100
+++ linux-work/arch/ppc/mm/44x_mmu.c 2007-10-31 10:39:15.000000000 +1100
@@ -61,6 +61,7 @@ extern char etext[], _stext[];
*/
unsigned int tlb_44x_index = 0;
unsigned int tlb_44x_hwater = 62;
+int icache_44x_need_flush;
/*
* "Pins" a 256MB TLB entry in AS0 for kernel lowmem
^ permalink raw reply
* Re: ring on PowerPC
From: Benjamin Herrenschmidt @ 2007-10-31 5:36 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <fa686aa40710302218s3dfe4d42red589fc5692e4c1@mail.gmail.com>
On Tue, 2007-10-30 at 23:18 -0600, Grant Likely wrote:
> On 10/30/07, Bai Shuwei <baishuwei@gmail.com> wrote:
> > Hi, everyone
> > As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> > 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> > And now I want to know wether there is a simple mechanism on the PowerPC
> > architecture? thx all!
>
> Powerpc has 2 privilege levels; user and supervisor. The kernel runs
> in supervisor mode, and user-space runs in user mode.
To be complete here, some implementations have 3 :-) Don't forget
hypervisor mode !
Ben.
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: KAMEZAWA Hiroyuki @ 2007-10-31 5:34 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-mm, Paul Mackerras, anton, Badari Pulavarty, linuxppc-dev
In-Reply-To: <20071031142846.aef9c545.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 31 Oct 2007 14:28:46 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch. (just say "System Ram" is not for memory hotplug.)
>
If I remember correctly, System RAM is for kdump (to know which memory should
be dumped.) Then, memory-hotadd/remove has to modify it anyway.
Thanks,
-Kame
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: KAMEZAWA Hiroyuki @ 2007-10-31 5:28 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <1193771951.8904.22.camel@dyn9047017100.beaverton.ibm.com>
On Tue, 30 Oct 2007 11:19:11 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> Hi KAME,
>
> As I mentioned while ago, ppc64 does not export information about
> "system RAM" in /proc/iomem. Looking at the code and usage
> scenerios I am not sure what its really serving. Could you
> explain what its purpose & how the range can be invalid ?
>
Hm, I added walk_memory_resource() for hot-add, at first.
Size of memory section is fixed and just depend on architecture, but
any machine can have any memory-hole within continuous memory-section-size
range of physical memory. Then we have to detect which page can be
target of online_page() and which are leaved as Reserved.
ioresource was good structure for remembering "which memory is conventional
memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
when I posted patch. (just say "System Ram" is not for memory hotplug.)
I used walk_memory_resource() again in memory hotremove.
(If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add.
than our ia64 box.
In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some
"for firmware" area in newly-added node.)
> At least on ppc64, all the memory ranges we get passed comes from
> /sysfs memblock information and they are guaranteed to match
> device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
> and it will be part of the /proc/device-tree entry. Since we do
> "online" or "offline" to /sysfs entries to add/remove pages -
> these ranges are guaranteed to be valid.
>
ok.
> Since this check is redundant for ppc64, I propose following patch.
> Is this acceptable ? If some one really really wants, I can code
> up this to walk lmb or /proc/device-tree and verify the range &
> adjust the entries for overlap (I don't see how that can happen).
>
ok. If ppc64 guarantees "there is no memory hole in section", please try.
I have no objection.
I just would like to ask to add some text to explain
"ppc64 doesn't need to care memory hole in a section."
Thanks,
-Kame
^ permalink raw reply
* Re: ring on PowerPC
From: Grant Likely @ 2007-10-31 5:18 UTC (permalink / raw)
To: Bai Shuwei; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <f3566d60710302205g2dd867bbk8a3494ceeda569f0@mail.gmail.com>
On 10/30/07, Bai Shuwei <baishuwei@gmail.com> wrote:
> Hi, everyone
> As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> And now I want to know wether there is a simple mechanism on the PowerPC
> architecture? thx all!
Powerpc has 2 privilege levels; user and supervisor. The kernel runs
in supervisor mode, and user-space runs in user mode.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* ring on PowerPC
From: Bai Shuwei @ 2007-10-31 5:05 UTC (permalink / raw)
To: linuxppc-embedded, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
Hi, everyone
As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
3) and the linux kernel run in the ring 0 and user program in the ring 3.
And now I want to know wether there is a simple mechanism on the PowerPC
architecture? thx all!
best regards!
Buroc
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 675 bytes --]
^ permalink raw reply
* Re: [0/2] Embed a copy of dtc in the kernel source
From: David Gibson @ 2007-10-31 4:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <DFBF9FAC-012A-47C6-9EC0-CDD365F67A97@kernel.crashing.org>
On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote:
>
> On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
>
> > These two patches are a respin of my previous patch to merge a copy of
> > dtc into the kernel tree, so that kernel builds no longer depend on an
> > externally installed copy of dtc.
> >
> > This respin embeds a newer revision of dtc, and incorporates Sam
> > Ravnborg's preferred approach to Makefile integration. Also, since so
> > many people whinged about it last time, I've split the patch into two
> > parts, the first is the too-large-for-the-list patch just verbatim
> > adding files and the second has the changes to existing kernel files
> > to build and use the embedded code.
>
> What about doing part of this via git-submodule?
Uh.. where do I find out what that does? My version of git (Ubuntu
gutsy) doesn't seem to know anything about it...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [0/2] Embed a copy of dtc in the kernel source
From: Kumar Gala @ 2007-10-31 4:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
> These two patches are a respin of my previous patch to merge a copy of
> dtc into the kernel tree, so that kernel builds no longer depend on an
> externally installed copy of dtc.
>
> This respin embeds a newer revision of dtc, and incorporates Sam
> Ravnborg's preferred approach to Makefile integration. Also, since so
> many people whinged about it last time, I've split the patch into two
> parts, the first is the too-large-for-the-list patch just verbatim
> adding files and the second has the changes to existing kernel files
> to build and use the embedded code.
What about doing part of this via git-submodule?
- k
^ permalink raw reply
* [2/2] Use embedded dtc in kernel builds
From: David Gibson @ 2007-10-31 3:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
This patch alters the kernel makefiles to build dtc from the sources
embedded in the previous patch. It also changes the
arch/powerpc/boot/wrapper script to use the embedded dtc, rather than
expecting a copy of dtc already installed on the system.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/boot/Makefile 2007-10-22 13:55:49.000000000 +1000
+++ working-2.6/arch/powerpc/boot/Makefile 2007-10-31 14:02:40.000000000 +1100
@@ -108,17 +108,52 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-
$(obj)/wrapper.a: $(obj-wlib) FORCE
$(call if_changed,bootar)
-hostprogs-y := addnote addRamDisk hack-coff mktree
+hostprogs-y := addnote addRamDisk hack-coff mktree dtc
targets += $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds
wrapper :=$(srctree)/$(src)/wrapper
-wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
+wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \
$(wrapper) FORCE
#############
+# Bits for building dtc
+# DTC_GENPARSER := 1 # Uncomment to rebuild flex/bison output
+
+dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o
+dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
+dtc-objs := $(addprefix dtc-src/, $(dtc-objs))
+
+# prerequisites on generated files needs to be explicit
+$(obj)/dtc-src/dtc-parser.tab.o: $(obj)/dtc-src/dtc-parser.tab.c $(obj)/dtc-src/dtc-parser.tab.h
+$(obj)/dtc-src/dtc-lexer.lex.o: $(obj)/dtc-src/dtc-lexer.lex.c $(obj)/dtc-src/dtc-parser.tab.h
+
+HOSTCFLAGS += -I$(src)/dtc-src/
+
+targets += dtc-src/dtc-parser.tab.c
+targets += dtc-src/dtc-lexer.lex.c
+
+ifdef DTC_GENPARSER
+BISON = bison
+FLEX = flex
+
+quiet_cmd_bison = BISON $@
+ cmd_bison = $(BISON) -o$@ -d $<; cp $@ $@_shipped
+quiet_cmd_flex = FLEX $@
+ cmd_flex = $(FLEX) -o$@ $<; cp $@ $@_shipped
+
+$(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE
+ $(call if_changed,bison)
+
+$(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c
+
+$(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE
+ $(call if_changed,flex)
+endif
+
+#############
# Bits for building various flavours of zImage
ifneq ($(CROSS32_COMPILE),)
@@ -236,7 +271,7 @@ install: $(CONFIGURE) $(addprefix $(obj)
# anything not in $(targets)
clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.* \
- otheros.bld
+ otheros.bld $(dtc-clean-files)
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin
Index: working-2.6/arch/powerpc/boot/wrapper
===================================================================
--- working-2.6.orig/arch/powerpc/boot/wrapper 2007-10-22 13:55:50.000000000 +1000
+++ working-2.6/arch/powerpc/boot/wrapper 2007-10-31 14:02:40.000000000 +1100
@@ -111,7 +111,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+ $object/dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
fi
if [ -z "$kernel" ]; then
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [1/2] Merge dtc
From: David Gibson @ 2007-10-31 3:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
This very large patch incorporates a copy of dtc into the kernel
source, in arch/powerpc/boot/dtc-src. This patch only imports the dtc
sources verbatim, another patch coming to actually link it into the
kernel Makefiles and use the embedded copy of dtc for kernel builds.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Too big for this list. Full patch at:
http://ozlabs.org/~dgibson/home/merge-dtc.patch
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [0/2] Embed a copy of dtc in the kernel source
From: David Gibson @ 2007-10-31 3:24 UTC (permalink / raw)
To: linuxppc-dev
These two patches are a respin of my previous patch to merge a copy of
dtc into the kernel tree, so that kernel builds no longer depend on an
externally installed copy of dtc.
This respin embeds a newer revision of dtc, and incorporates Sam
Ravnborg's preferred approach to Makefile integration. Also, since so
many people whinged about it last time, I've split the patch into two
parts, the first is the too-large-for-the-list patch just verbatim
adding files and the second has the changes to existing kernel files
to build and use the embedded code.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
From: Stephen Rothwell @ 2007-10-31 3:11 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030165739.GA22126@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30 18:00:15.000000000 +0300
> +#include <linux/init.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/time.h>
> +#include <asm/uic.h>
> +#include <asm/of_platform.h>
You want <linux/of_platform.h>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: David Gibson @ 2007-10-31 2:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20071030210917.42cfb88b@vader.jdub.homelinux.org>
On Tue, Oct 30, 2007 at 09:09:17PM -0500, Josh Boyer wrote:
> On Tue, 30 Oct 2007 20:56:51 -0500
> Olof Johansson <olof@lixom.net> wrote:
>
> > On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > > PowerPC 440GRx Rainier DTS.
> > > [snip]
> > > > + SDRAM0: sdram {
> > > > + device_type = "memory-controller";
> > >
> > > How many times do we need to say it...
> > >
> > > Don't make up random device_type values. This does not belong here.
> >
> > Maybe there should be something like checkpatch.pl that warns about
> > these kinds of things so people can check for it without getting flamed
> > first. :-)
I'd be gentler; except that I know Valentine has been active on this
list recently, so has almost certainly seen similar comments before.
> That's actually a decent idea. We could even have this thing that
> takes DTS files and processes them... oh wait.
>
> So why can't we make a whitelist of "allowed" device_types in DTC and
> make it whine about anything outside of that?
Well, that sort of thing is the idea for dtc to check, when it has
checks enabled anyway. Getting it so that it doesn't have too many
false positives is the tricky bit, as we've seen with some of the
existing checks (where "too many" is "almost any").
Patches welcome...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports
From: Stephen Rothwell @ 2007-10-31 2:50 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1193760559.6244.25.camel@p60635-ste.ids.de>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Tue, 30 Oct 2007 17:09:19 +0100 Sergej Stepanov <Sergej.Stepanov@ids.de> wrote:
>
> static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
> struct device_node *np)
> {
> - struct resource res;
> + struct resource res[2];
Why not just reuse the same resource structure? You don't seem to need
them both at the same time.
> + if( !of_address_to_resource(np, 1, &res[1]))
> + {
> + bitbang->mdio.dir = ioremap(res[1].start, res[1].end - res[1].start + 1);
> + if (!bitbang->mdio.dir)
> + {
> + iounmap(bitbang->mdc.dir);
> + return -ENOMEM;
> + }
> + bitbang->mdio.dat = bitbang->mdio.dir + 4;
> + }
> + else{
Formatting:
if () {
} else {
}
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
No spaces after (, please. Here and elsewhere.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Merge dtc
From: David Gibson @ 2007-10-31 2:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: ppcdev, Paul Mackerras, Milton Miller
In-Reply-To: <20071019184249.GA32015@uranus.ravnborg.org>
On Fri, Oct 19, 2007 at 08:42:49PM +0200, Sam Ravnborg wrote:
> Hi David.
>
> > > Give me a day or two then I shall give it a try and see what I can
> > > do about it. I will use the previsous posted URL as basis if you do
> > > not tell me otherwise.
> >
> > Thank you. The previous URL should be fine, I've made no changes
> > since then.
>
> I decided to go for a kbuild specific version integrated
> in boot/Makefile.
> This is much more readable because this syntax is explicit.
> We do not favour 3 levels of variabls to avoid rewriting the same
> filename two times.
Well, yes, on consideration the substitutions in Makefile.dtc are a
bit over-involved. Although I still find describing its dozen or so
lines as unreadable when set next to the intricate wonders of Kbuild a
little... bemusing.
> I have tested the change only with a O=.. crosscompile build.
>
> I have tested the patch with and without DTC_GENPARSER=1.
> It does not rebuild if not needed and is OK with -j10 builds.
>
> Please consider this version in favour of your old version.
Ok. I'll use this version in my next spin; except for adding one
dependency you missed, and removing one which should never have been
there (unneccessary #include, which I've already fixed in dtc
upstream).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Josh Boyer @ 2007-10-31 2:09 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071031015651.GB19318@lixom.net>
On Tue, 30 Oct 2007 20:56:51 -0500
Olof Johansson <olof@lixom.net> wrote:
> On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > PowerPC 440GRx Rainier DTS.
> > [snip]
> > > + SDRAM0: sdram {
> > > + device_type = "memory-controller";
> >
> > How many times do we need to say it...
> >
> > Don't make up random device_type values. This does not belong here.
>
> Maybe there should be something like checkpatch.pl that warns about
> these kinds of things so people can check for it without getting flamed
> first. :-)
That's actually a decent idea. We could even have this thing that
takes DTS files and processes them... oh wait.
So why can't we make a whitelist of "allowed" device_types in DTC and
make it whine about anything outside of that?
josh
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Olof Johansson @ 2007-10-31 1:56 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20071030230805.GC2784@localhost.localdomain>
On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > PowerPC 440GRx Rainier DTS.
> [snip]
> > + SDRAM0: sdram {
> > + device_type = "memory-controller";
>
> How many times do we need to say it...
>
> Don't make up random device_type values. This does not belong here.
Maybe there should be something like checkpatch.pl that warns about
these kinds of things so people can check for it without getting flamed
first. :-)
Lots of people base their dts'es on other ones, so until the kernel has
bene clean a while, this will happen all the time. I'm saying "a while"
because people tend to base them on what's fresh when they do the work,
but it might take a few months between then and when they post, etc.
-Olof
^ permalink raw reply
* Re: [PATCH] [powerpc v2] update xmon slb code
From: Paul Mackerras @ 2007-10-31 1:42 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev
In-Reply-To: <20071030215037.12776.73871.stgit@farscape.rchland.ibm.com>
Will Schmidt writes:
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from power6 (1T segment support):
>
> 00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID=40004f7ca3 LLP bits:100
The "4" at the top of the VSID is actually the B (segment size) field,
isn't it? Shouldn't that get masked off, since you have already
printed the segment size separately?
Also, if you removed the "bits" text, it would just about fit into 80
columns. I think "LLP" is sufficient, the "bits" is redundant.
Apart from that it looks good.
Regards,
Paul,
^ permalink raw reply
* Re: PPC405GP Walnut irq patch
From: Josh Boyer @ 2007-10-31 1:40 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <4727A507.10309@harris.com>
On Tue, 30 Oct 2007 17:41:27 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:
> From: "Steven A. Falco" <sfalco@harris.com>
> To: linuxppc-dev@ozlabs.org
> Subject: Re: PPC405GP Walnut irq patch
> Date: Tue, 30 Oct 2007 17:41:27 -0400
> Sender: linuxppc-dev-bounces+jwboyer=gmail.com@ozlabs.org
> User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
>
> I realized that I should have done this from the root level. So here is
> the corrected patch.
>
> Signed-off-by: Steve Falco <sfalco at harris.com>
>
>
> Steven A. Falco wrote:
> > Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
> > the ethernet interrupts in the walnut.dts file doesn't match the
> > documentation. I discovered this when porting the BSP to a custom
> > board - the ethernet would not work. The attached patch corrects that.
> >
> > This is the first patch I am submitting, so please advise me if there
> > is anything I should do differently.
> >
> > Signed-off-by: Steve Falco <sfalco at harris.com>
> >
> >
>
> diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
> index 27bef06..dd65115 100644
> --- a/arch/powerpc/boot/dts/walnut.dts
> +++ b/arch/powerpc/boot/dts/walnut.dts
> @@ -67,7 +67,7 @@
> num-tx-chans = <2>;
> num-rx-chans = <1>;
> interrupt-parent = <&UIC0>;
> - interrupts = <a 4 b 4 c 4 d 4 e 4>;
> + interrupts = <b 4 c 4 a 4 d 4 e 4>;
> };
I fixed this part already. Seems your tree is slightly old.
>
> POB0: opb {
> @@ -117,7 +117,7 @@
> device_type = "network";
> compatible = "ibm,emac-405gp", "ibm,emac";
> interrupt-parent = <&UIC0>;
> - interrupts = <9 4 f 4>;
> + interrupts = <f 4 9 4>;
Could you redo the patch with just this bit and send it again?
josh
^ permalink raw reply
* Re: [PATCH] [powerpc v2] update xmon slb code
From: Olof Johansson @ 2007-10-31 1:26 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071030215037.12776.73871.stgit@farscape.rchland.ibm.com>
On Tue, Oct 30, 2007 at 04:50:39PM -0500, Will Schmidt wrote:
>
> [powerpc] update xmon slb code
>
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from power6 (1T segment support):
>
> 00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID=40004f7ca3 LLP bits:100
> 01 d000000008000000 4000eb71b0000400 1T ESID= d00000 VSID=4000eb71b0 LLP bits: 0
> 03 0000000008000000 0000628021c6ac80 256M ESID= 0 VSID= 628021c6a LLP bits: 0
> 04 00000f0008000000 400095c1e8000c80 1T ESID= f VSID=400095c1e8 LLP bits: 0
> 22 cf00000008000000 400011b260000500 1T ESID= cf0000 VSID=400011b260 LLP bits:100
> 62 0000040008000000 40005d488d000c80 1T ESID= 4 VSID=40005d488d LLP bits: 0
> 63 0000000018000000 0000633f90285c80 256M ESID= 1 VSID= 633f90285 LLP bits: 0
>
> sample output from power5 (notice the non-valid but non-zero entries)
>
> 00 c000000008000000 0000408f92c94500 256M ESID=c00000000 VSID= 408f92c94 LLP bits:100
> 01 d000000008000000 0000f09b89af5400 256M ESID=d00000000 VSID= f09b89af5 LLP bits: 0
> 03 0000000010000000 0000136eafb0bc80
> 11 0000000008000000 00005928811f2c80 256M ESID= 0 VSID= 5928811f2 LLP bits: 0
> 12 00000000f8000000 0000645ff8d87c80 256M ESID= f VSID= 645ff8d87 LLP bits: 0
> 13 0000000048000000 00005c263aa5ec80 256M ESID= 4 VSID= 5c263aa5e LLP bits: 0
> 14 0000000018000000 000059e7ef80dc80 256M ESID= 1 VSID= 59e7ef80d LLP bits: 0
> 15 0000000010000000 000059e7ef80dc80
>
> Tested on power5 and power6.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: Olof Johansson <olof@lixom.net>
This makes the output wider than 80 characters, but that's fine with me.
Thanks!
-Olof
^ permalink raw reply
* Re: [PATCH] [powerpc v2] update xmon slb code
From: Benjamin Herrenschmidt @ 2007-10-31 0:57 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071030215037.12776.73871.stgit@farscape.rchland.ibm.com>
On Tue, 2007-10-30 at 16:50 -0500, Will Schmidt wrote:
> [powerpc] update xmon slb code
>
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from power6 (1T segment support):
.../....
>
> Tested on power5 and power6.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> This version adds padding around the ESID and VSID fields, and the LLP bits
> are displayed too. (Per request from Olof and Ben).
> I'll try to follow up sometime later with code that will handle decoding page
> sizes. I dont have a testcase handy to properly exercise that yet. :-)
> ---
>
> arch/powerpc/xmon/xmon.c | 27 +++++++++++++++++++++------
> 1 files changed, 21 insertions(+), 6 deletions(-)
>
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 121b04d..93c26c3 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address, const char *mid,
> static void dump_slb(void)
> {
> int i;
> - unsigned long tmp;
> + unsigned long esid,vsid,valid;
> + unsigned long llp_bits;
>
> printf("SLB contents of cpu %x\n", smp_processor_id());
>
> for (i = 0; i < SLB_NUM_ENTRIES; i++) {
> - asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
> - printf("%02d %016lx ", i, tmp);
> -
> - asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
> - printf("%016lx\n", tmp);
> + asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
> + asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
> + valid = (esid & SLB_ESID_V);
> + if (valid | esid | vsid) {
> + printf("%02d %016lx %016lx", i, esid, vsid);
> + if (valid) {
> + llp_bits = vsid & SLB_VSID_LLP;
> + if (vsid & SLB_VSID_B_1T) {
> + printf(" 1T ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
> + GET_ESID_1T(esid),vsid >> SLB_VSID_SHIFT_1T,
> + llp_bits);
> + } else {
> + printf(" 256M ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
> + GET_ESID(esid),vsid >> SLB_VSID_SHIFT,
> + llp_bits);
> + }
> + } else
> + printf("\n");
> + }
> }
> }
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
From: Benjamin Herrenschmidt @ 2007-10-31 0:55 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071030185932.6368.7796.stgit@farscape.rchland.ibm.com>
On Tue, 2007-10-30 at 13:59 -0500, Will Schmidt wrote:
> [Powerpc] fix switch_slb handling of 1T ESID values
>
> Now that we have 1TB segment size support, we need to be using the
> GET_ESID_1T macro when comparing ESID values for pc,stack, and
> unmapped_base within switch_slb(). A new helper function called
> esids_match() contains the logic for deciding when to call GET_ESID
> and GET_ESID_1T.
>
> This also happens to fix a duplicate-slb-entry inspired machine-check
> exception I was seeing when trying to run java on a power6 partition.
>
> Tested on power6 and power5.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
>
> ---
>
> Just a bit of whitespace cosmetic touchup in this version, as suggested
> by Stephen Rothwell.
> ---
>
> arch/powerpc/mm/slb.c | 34 +++++++++++++++++++++++++++++++---
> 1 files changed, 31 insertions(+), 3 deletions(-)
>
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index bbd2c51..8cbbfab 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
> slb_flush_and_rebolt();
> }
>
> +/* Helper function to compare esids. There are four cases to handle.
> + * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
> + * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID compare.
> + * 3. The system is 1T capable, only one of the two addresses is > 1T. This is not a match.
> + * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T macro to compare.
> + */
> +static inline int esids_match(unsigned long addr1, unsigned long addr2)
> +{
> + int esid_1t_count;
> +
> + /* System is not 1T segment size capable. */
> + if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + esid_1t_count = (((addr1 >> SID_SHIFT_1T) != 0) +
> + ((addr2 >> SID_SHIFT_1T) != 0));
> +
> + /* both addresses are < 1T */
> + if (esid_1t_count == 0)
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + /* One address < 1T, the other > 1T. Not a match */
> + if (esid_1t_count == 1)
> + return 0;
> +
> + /* Both addresses are > 1T. */
> + return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
> +}
> +
> /* Flush all user entries from the segment table of the current processor. */
> void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> {
> @@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> return;
> slb_allocate(pc);
>
> - if (GET_ESID(pc) == GET_ESID(stack))
> + if (esids_match(pc,stack))
> return;
>
> if (is_kernel_addr(stack))
> return;
> slb_allocate(stack);
>
> - if ((GET_ESID(pc) == GET_ESID(unmapped_base))
> - || (GET_ESID(stack) == GET_ESID(unmapped_base)))
> + if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
> return;
>
> if (is_kernel_addr(unmapped_base))
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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