Re: MMIO and gcc re-ordering issue

[Haavard Skinnemoen]

Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > > I'm happy to say that __raw is purely about ordering and make them
> > > byteswap on powerpc tho (ie, make them little endian like the non-raw
> > > counterpart).  
> > 
> > That would break a lot of drivers.  
> 
> How many actually use __raw_ * ?

I do -- in all the drivers for on-chip peripherals that are shared
between AT91 ARM (LE) and AVR32 (BE). Since everything goes on inside
the chip, we must use LE accesses on ARM and BE accesses on AVR32.

Currently, this is the only interface I know that can do native-endian
accesses, so if you take it away, I'm gonna need an alternative
interface that doesn't do byteswapping.

Haavard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Still struggling with Xilinx GPIO...

[Guillaume Dargaud]

Hi John,

Try using channel 1. It may be set up where the first channel is 1 and not 
0.


Not sure what you mean...

I'm actually not clear how many devices I should have:

$ grep "GPIO.*BASEADDR" 
arch/ppc/platforms/4xx/xparameters/xparameters_ml405.h

#define XPAR_GPIO_0_BASEADDR XPAR_LEDS_4BIT_BASEADDR
#define XPAR_GPIO_1_BASEADDR XPAR_LEDS_POSITIONS_BASEADDR
#define XPAR_GPIO_2_BASEADDR XPAR_PUSH_BUTTONS_POSITION_BASEADDR

But depending on the examples I look at, they define either:

crw-rw-rw-1 root root  10, 185 May 26 13:49 xgpio
or:
crw-rw-rw-1 root root  10, 185 May 26 13:18 xgpio0
crw-rw-rw-1 root root  10, 186 May 26 13:18 xgpio1
crw-rw-rw-1 root root  10, 187 May 26 13:18 xgpio2

If that is the former, I see the code uses:
gpio_ioctl.chan=0;
And I guess that's what you are refering to, right ?

Putting 1 gives me a working program, but no LED lights up and the buttons 
are always shown at 0.

Putting 0 gives a nice core dump as in my previous msg.
Putting 2 locks up the system.

And... I don't see how the code manages to read/wite all 3 GPIOs with only 
two IOCTL calls. Shouldn't they be 3 different calls using different 
addresses ?!? Argh, this complete lack of documentation in maddening. Not 
everything can be understood from reading the source.


Thanks.
--
Guillaume Dargaud
http://www.gdargaud.net/


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

May I ask some questions?

[vencent2006]

 I am Michael from China.A few days ago, I was supposed to debug executable.elf 
with xmd while some problems happened.It said like that:
 xmd% dow executable.elf
 Failed to download ELF file
 
ERROR(1053):UNABLE TO READ ELF FILE.THE ELF FILE
MAYBE CORRUPTED
 :executable.elf
 
I wanna ask u to point out what causes this problem.
 
There is another question about "xparameters.h" and 
"xparameters_ml300.h". When I have generated BSP, there are two "xparameters.h" 
files in project which
 have the same name while different size(eg: one is 22k ,the other is 4k). 
Which one is the proper? 
And when I add "xparameters.h" and "xparameters_ml300.h" to the kernel, some 
compiling 
error occurs.
  eg:
arch/ppc/syslib/virtex_devices.c:116: error: 'XPAR_UARTNS550_0_CLOCK_FREQ_HZ' 
undeclared here (not in a function)
arch/ppc/syslib/virtex_devices.c:119: error: 'XPAR_UARTNS550_1_CLOCK_FREQ_HZ' 
undeclared here (not in a function)
 I don't understand where to define them and whether i need them or not.
  my eldk is:eldk/4.2/ppc-linux-x86
  using Xilinx EDK/ISE 9.1
  Linux 2.6.24
  
 
 
 
 

--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Still struggling with Xilinx GPIO...

[John Bonesio]

Hi Guillaume,

gpio_ioctl.chan = x;

That's what determines which gpio device gets used. Since using 1 at
least doesn't give you a core dump, I would guess that 1 is the correct
value to use there.

So the next thing to check is to make sure that the ioctl command codes
being used are right.

The only way I know how to do this is to look in the linux kernel source
for the gpio device. Try looking here:
linux/drivers/char/xilinx_gpio

Then you find the routine that is handling the ioctl commands. It'll
probably be called xgpio_ioctl. In this routine you'll see something
like:
switch(cmd) {
case XGPIO_IN:
...

The value for XGPIO_IN is defined in a header file (probably). The
header file might be called xgpio_ioctl.h.

So here's the key:
Make sure the value for XGPIO_IN used in the user application is the
same as the one used in the kernel.

At one point I had see a case where the values in the kernel had
changed, but the user application was still trying to use the old
values.

Hope this helps,

- John



On Wed, 2008-05-28 at 11:51 +0200, Guillaume Dargaud wrote:
> Hi John,
> 
> > Try using channel 1. It may be set up where the first channel is 1 and not 
> > 0.
> 
> Not sure what you mean...
> 
> I'm actually not clear how many devices I should have:
> 
> $ grep "GPIO.*BASEADDR" 
> arch/ppc/platforms/4xx/xparameters/xparameters_ml405.h
> #define XPAR_GPIO_0_BASEADDR XPAR_LEDS_4BIT_BASEADDR
> #define XPAR_GPIO_1_BASEADDR XPAR_LEDS_POSITIONS_BASEADDR
> #define XPAR_GPIO_2_BASEADDR XPAR_PUSH_BUTTONS_POSITION_BASEADDR
> 
> But depending on the examples I look at, they define either:
> 
> crw-rw-rw-1 root root  10, 185 May 26 13:49 xgpio
> or:
> crw-rw-rw-1 root root  10, 185 May 26 13:18 xgpio0
> crw-rw-rw-1 root root  10, 186 May 26 13:18 xgpio1
> crw-rw-rw-1 root root  10, 187 May 26 13:18 xgpio2
> 
> If that is the former, I see the code uses:
>  gpio_ioctl.chan=0;
> And I guess that's what you are refering to, right ?
> 
> Putting 1 gives me a working program, but no LED lights up and the buttons 
> are always shown at 0.
> Putting 0 gives a nice core dump as in my previous msg.
> Putting 2 locks up the system.
> 
> And... I don't see how the code manages to read/wite all 3 GPIOs with only 
> two IOCTL calls. Shouldn't they be 3 different calls using different 
> addresses ?!? Argh, this complete lack of documentation in maddening. Not 
> everything can be understood from reading the source.
> 
> Thanks.



John Bonesio
Commercial Linux Solutions
[EMAIL PROTECTED]
(408) 879-5569

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/3] [2.6.26] ehea: Add dependency to Kconfig

[Nathan Lynch]

Hello,

Hannes Hering wrote:
> The new ehea memory hot plug implementation depends on MEMORY_HOTPLUG.
> 
> Signed-off-by: Hannes Hering <[EMAIL PROTECTED]>
> ---
> 
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index f90a86b..181cd86 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2440,7 +2440,7 @@ config CHELSIO_T3
>  
>  config EHEA
>   tristate "eHEA Ethernet support"
> - depends on IBMEBUS && INET && SPARSEMEM
> + depends on IBMEBUS && INET && SPARSEMEM && MEMORY_HOTPLUG
>   select INET_LRO
>   ---help---
> This driver supports the IBM pSeries eHEA ethernet adapter.

I disagree with this change.

It makes it impossible to build the ehea driver without memory hotplug
enabled.  Presumably, this commit was intended to work around a build
break of this sort (with EHEA=m and MEMORY_HOTPLUG=n):

drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
drivers/net/ehea/ehea_qmr.c:635: error: implicit declaration of function 
'walk_memory_resource'

(some indication of this should have been in the commit message, btw)

I think this was the wrong way to fix the issue.  EHEA=m and
MEMORY_HOTPLUG=n is a valid configuration for machines I test.

Any thoughts on the following, which makes walk_memory_resource()
available regardless of MEMORY_HOTPLUG's setting?  I've tested it on a
JS22 (Power6 blade).

---

 arch/powerpc/mm/mem.c  |3 +--
 drivers/net/Kconfig|2 +-
 include/linux/memory_hotplug.h |   16 
 3 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index f67e118..51f82d8 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -151,6 +151,7 @@ out:
return ret;
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
+#endif /* CONFIG_MEMORY_HOTPLUG */
 
 /*
  * walk_memory_resource() needs to make sure there is no holes in a given
@@ -184,8 +185,6 @@ walk_memory_resource(unsigned long start_pfn, unsigned long 
nr_pages, void *arg,
 }
 EXPORT_SYMBOL_GPL(walk_memory_resource);
 
-#endif /* CONFIG_MEMORY_HOTPLUG */
-
 void show_mem(void)
 {
unsigned long total = 0, reserved = 0;
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index dd0ec9e..f4182cf 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2426,7 +2426,7 @@ config CHELSIO_T3
 
 config EHEA
tristate "eHEA Ethernet support"
-   depends on IBMEBUS && INET && SPARSEMEM && MEMORY_HOTPLUG
+   depends on IBMEBUS && INET && SPARSEMEM
select INET_LRO
---help---
  This driver supports the IBM pSeries eHEA ethernet adapter.
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 73e3586..ea9f5ad 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -77,14 +77,6 @@ extern int __add_pages(struct zone *zone, unsigned long 
start_pfn,
 extern int __remove_pages(struct zone *zone, unsigned long start_pfn,
unsigned long nr_pages);
 
-/*
- * Walk through all memory which is registered as resource.
- * arg is (start_pfn, nr_pages, private_arg_pointer)
- */
-extern int walk_memory_resource(unsigned long start_pfn,
-   unsigned long nr_pages, void *arg,
-   int (*func)(unsigned long, unsigned long, void *));
-
 #ifdef CONFIG_NUMA
 extern int memory_add_physaddr_to_nid(u64 start);
 #else
@@ -199,6 +191,14 @@ static inline void register_page_bootmem_info_node(struct 
pglist_data *pgdat)
 
 #endif /* ! CONFIG_MEMORY_HOTPLUG */
 
+/*
+ * Walk through all memory which is registered as resource.
+ * arg is (start_pfn, nr_pages, private_arg_pointer)
+ */
+extern int walk_memory_resource(unsigned long start_pfn,
+   unsigned long nr_pages, void *arg,
+   int (*func)(unsigned long, unsigned long, void *));
+
 extern int add_memory(int nid, u64 start, u64 size);
 extern int arch_add_memory(int nid, u64 start, u64 size);
 extern int remove_memory(u64 start, u64 size);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: PPC PReP link failure - copy_page, empty_zero_page

[Meelis Roos]

> > ERROR: "copy_page" [fs/fuse/fuse.ko] undefined!
> > ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined!
> 
> Try that patch at: http://patchwork.ozlabs.org/linuxppc/patch?id=18710
> 
> Fixes it for me.

Yes, this fixes it, thanks! Hopefully it is merged before 2.6.26.

-- 
Meelis Roos ([EMAIL PROTECTED])
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: JFFS2 FS not writeable

[Ron Madrid]

--- Scott Wood <[EMAIL PROTECTED]> wrote:
> You may want to try increasing the OR[SCY] field or
> other timing 
> parameters associated with the NAND flash.

So are you saying that when this happened in the past
it was a timing issue?  This change would need to
happen in u-boot correct?

Ron
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: JFFS2 FS not writeable

[Scott Wood]

Ron Madrid wrote:

--- Scott Wood <[EMAIL PROTECTED]> wrote:

You may want to try increasing the OR[SCY] field or
other timing 
parameters associated with the NAND flash.


So are you saying that when this happened in the past
it was a timing issue?  This change would need to
happen in u-boot correct?


Well, there was a bug that accidentally changed SCY from 1 to 0. :-P

U-boot would be the ideal place to fix it, but if you're only accessing 
the flash from Linux, it could be changed in platform code.


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 07/12] pcmcia: use linux/of_{device, platform}.h instead of asm

[Dominik Brodowski]

On Fri, May 23, 2008 at 04:31:08PM +1000, Stephen Rothwell wrote:
> 
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Acked-by: Dominik Brodowski <[EMAIL PROTECTED]>

I assume this is pushed upstream through -ppc?

Thanks,
Dominik
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Add support for binary includes.

[David Gibson]

On Tue, May 27, 2008 at 12:59:32PM -0500, Jon Loeliger wrote:
> Kumar Gala wrote:
>>
>> On Feb 25, 2008, at 6:39 PM, David Gibson wrote:
>>
>>> On Wed, Feb 20, 2008 at 01:19:41PM -0600, Scott Wood wrote:
 A property's data can be populated with a file's contents
 as follows:

 node {
 prop = /incbin/("path/to/data");
 };

 A subset of a file can be included by passing start and size parameters.
 For example, to include bytes 8 through 23:

 node {
 prop = /incbin/("path/to/data", 8, 16);
 };

 As with /include/, non-absolute paths are looked for in the directory
 of the source file that includes them.
>
> That issue was resolved, I believe.
>
>>> Well, while I discuss the syntax with Jon, here's some comments on the
>>> implementation.
>>
>> have we made any progress on the syntax?
>
> My last suggestions garnered a "I like that even less." response,
> so as far as I know, we're still waiting for a good proposal here.

A while back I sent out a spiel explaining more clearly why I didn't
like it, and where I thought we should go with this, but I don't think
anyone noticed it at the time.  I'll resend.

I started working towards a version of this I liked, but was
sidetracked by a combination of my own other work, and the fact that
Jon's been busy meaning there's a rather large lag on merging dtc
patches.

-- 
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Add support for binary includes.

[David Gibson]

On Thu, May 29, 2008 at 09:58:59AM +1000, David Gibson wrote:
> On Tue, May 27, 2008 at 12:59:32PM -0500, Jon Loeliger wrote:
> > Kumar Gala wrote:
> >>
> >> On Feb 25, 2008, at 6:39 PM, David Gibson wrote:
> >>
> >>> On Wed, Feb 20, 2008 at 01:19:41PM -0600, Scott Wood wrote:
>  A property's data can be populated with a file's contents
>  as follows:
> 
>  node {
>  prop = /incbin/("path/to/data");
>  };
> 
>  A subset of a file can be included by passing start and size parameters.
>  For example, to include bytes 8 through 23:
> 
>  node {
>  prop = /incbin/("path/to/data", 8, 16);
>  };
> 
>  As with /include/, non-absolute paths are looked for in the directory
>  of the source file that includes them.
> >
> > That issue was resolved, I believe.
> >
> >>> Well, while I discuss the syntax with Jon, here's some comments on the
> >>> implementation.
> >>
> >> have we made any progress on the syntax?
> >
> > My last suggestions garnered a "I like that even less." response,
> > so as far as I know, we're still waiting for a good proposal here.
> 
> A while back I sent out a spiel explaining more clearly why I didn't
> like it, and where I thought we should go with this, but I don't think
> anyone noticed it at the time.  I'll resend.

See
http://www.nabble.com/Re%3A--PATCH--Add-support-for-binary-includes.-p16149085.html

-- 
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: JFFS2 FS not writeable

[Ron Madrid]

So I found something that looks suspicious to me. 
This may not be a fsl_elbc_nand.c problem, but a more
general problem.

Shortly after mounting the root filesystem, which is a
jffs2 on a large page NAND device (my board is based
on the MPC8313) the kernel appears to read the device
starting just past the point defined by the 0x1985 . .
. markers in the jffs2 filesystem, through the end of
the device as defined by the dtb.  More specifically
in my device, the file system is approximately
0x20 and resides at 0x40 with the end of the
device being 0x200.  As it does this it is then
writing the oob data into these blocks (0x60 -
0x1fe).   The value that it was writing into the
first 4 bytes of the oob are 0xff198520.  This was
problematic as the 0x20 was being placed into the
large page NAND device bad block location (0x0). 
Given that there is a 0xff at the msb of the oob data,
could this possibly be a byte swapping issue?  I don't
see though how this could be a problem in the large
page NAND but not the small page NAND.  I verified
this by writing 0x in to the first 4 bytes of
the oob data to ensure that 0xff was written into the
bad block location.

In the function fsl_elbc_write_buf:
(*(unsigned int *)buf) = 0x;

I know that this isn't a fix, but I don't know where
this problem comes from and also I don't know the
exact flow of the NAND device processes.

I would be more than happy to investigate further and
provide a patch if someone could point me in the right
direction.

Let me know if I'm off base here, but I think this is
where my problem is.

Ron Madrid
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] POWERPC: Merge 32 and 64-bit dma code

[Mark Nelson]

On Fri, 23 May 2008 06:06:50 pm Mark Nelson wrote:
> On Thu, 1 May 2008 09:36:43 am Becky Bruce wrote:
> > 
> > I essentially adopt the 64-bit dma code, with some changes to support
> > 32-bit systems, including HIGHMEM.  dma functions on 32-bit are now
> > invoked via accessor functions which call the correct op for a device based
> > on archdata dma_ops.  Currently, this defaults to dma_direct_ops, but this
> > structure will make it easier to do iommu/swiotlb on 32-bit going
> > forward.
> > 
> > In addition, the dma_map/unmap_page functions are added to dma_ops on
> > HIGHMEM-enabled configs because we can't just fall back on map/unmap_single
> > when HIGHMEM is enabled.  Adding these to dma_ops makes it cleaner to
> > substitute different functionality once we have iommu/swiotlb support.
> > 
> > This code conflicts with the dma_attrs code that Mark Nelson just pushed.
> > At this point, I'm just looking for some review, and suggestions on how 
> > this code might be improved.  I'll uprev it to work with Mark's code once
> > that goes in.
> 
> The last patch of my series may be in question so it could end up that this
> patch makes it in first. It shouldn't be too hard to respin my patches after
> your merge so no worries there though.
> 
> > 
> > There will be other patches that precede this one - I plan to duplicate 
> > dma_mapping.h into include/asm-ppc to avoid breakage there.  There will 
> > also be a patch to rename dma_64.c to dma.c, and a series of patches to 
> > modify drivers that pass NULL dev pointers.
> > 
> > Dma experts, please review this when you can - I was a dma newbie 
> > until very recently, and the odds that I'm missing some subtlety 
> > in this merge are fairly high.
> > 
> 
> I'm far from a DMA expert but this all looks sane to me - I can't really
> comment on the 32bit side of things but I don't think it's going to break
> anything on 64bit (it compiles fine on cell and pseries).
> 
> I'll try and test boot it on Monday.

Not quite Monday, but it boots fine on the QS22 and QS21 Cell blades
and on a Power6 box.

Mark.

> 
> We should get BenH to look at it but he's travelling at the moment...
> 
> Mark.
> 
> > Cheers,
> > Becky
> > 
> >  ---
> >  arch/powerpc/kernel/Makefile  |4 +-
> >  arch/powerpc/kernel/dma_64.c  |   80 ++-
> >  arch/powerpc/kernel/pci-common.c  |   53 +
> >  arch/powerpc/kernel/pci_32.c  |7 ++
> >  arch/powerpc/kernel/pci_64.c  |   49 
> >  include/asm-powerpc/dma-mapping.h |  156 
> > +
> >  include/asm-powerpc/machdep.h |5 +-
> >  include/asm-powerpc/pci.h |   14 ++--
> >  8 files changed, 186 insertions(+), 182 deletions(-)
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] [POWERPC] Free a PTE bit on ppc64 with 64K pages

[Benjamin Herrenschmidt]

This patch frees a PTE bit when using 64K pages on ppc64. This is done
by getting rid of the separate _PAGE_HASHPTE bit. Instead, we just test
if any of the 16 sub-page bits is set. For non-combo pages (ie. real
64K pages), we set SUB0 and the location encoding in that field.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---

Please review and make sure I didn't miss something ... 

The freed bit is intended to be used as _PAGE_SPECIAL in order
to support fast get_user_pages().

Test booted with 64K pages on G5, power5 and power6

 arch/powerpc/mm/hash_low_64.S   |   12 ++--
 arch/powerpc/mm/hugetlbpage.c   |5 ++---
 include/asm-powerpc/pgtable-4k.h|2 ++
 include/asm-powerpc/pgtable-64k.h   |   18 --
 include/asm-powerpc/pgtable-ppc64.h |1 -
 5 files changed, 26 insertions(+), 12 deletions(-)

--- linux-work.orig/arch/powerpc/mm/hash_low_64.S   2008-05-29 
12:10:47.0 +1000
+++ linux-work/arch/powerpc/mm/hash_low_64.S2008-05-29 12:56:16.0 
+1000
@@ -388,7 +388,7 @@ _GLOBAL(__hash_page_4K)
 */
rlwinm  r30,r4,32-9+7,31-7,31-7 /* _PAGE_RW -> _PAGE_DIRTY */
or  r30,r30,r31
-   ori r30,r30,_PAGE_BUSY | _PAGE_ACCESSED | _PAGE_HASHPTE
+   ori r30,r30,_PAGE_BUSY | _PAGE_ACCESSED
orisr30,r30,[EMAIL PROTECTED]
/* Write the linux PTE atomically (setting busy) */
stdcx.  r30,0,r6
@@ -468,7 +468,7 @@ END_FTR_SECTION(CPU_FTR_NOEXECUTE|CPU_FT
 * go to out-of-line code to try to modify the HPTE. We look for
 * the bit at (1 >> (index + 32))
 */
-   andi.   r0,r31,_PAGE_HASHPTE
+   rldicl. r0,r31,64-12,48
li  r26,0   /* Default hidx */
beq htab_insert_pte
 
@@ -726,7 +726,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_CI_LARGE_P
 */
rlwinm  r30,r4,32-9+7,31-7,31-7 /* _PAGE_RW -> _PAGE_DIRTY */
or  r30,r30,r31
-   ori r30,r30,_PAGE_BUSY | _PAGE_ACCESSED | _PAGE_HASHPTE
+   ori r30,r30,_PAGE_BUSY | _PAGE_ACCESSED
/* Write the linux PTE atomically (setting busy) */
stdcx.  r30,0,r6
bne-1b
@@ -794,17 +794,17 @@ END_FTR_SECTION(CPU_FTR_NOEXECUTE|CPU_FT
/* Check if we may already be in the hashtable, in this case, we
 * go to out-of-line code to try to modify the HPTE
 */
-   andi.   r0,r31,_PAGE_HASHPTE
+   rldicl. r0,r31,64-12,48
bne ht64_modify_pte
 
 ht64_insert_pte:
/* Clear hpte bits in new pte (we also clear BUSY btw) and
-* add _PAGE_HASHPTE
+* add _PAGE_HPTE_SUB0
 */
lis r0,[EMAIL PROTECTED]
ori r0,r0,[EMAIL PROTECTED]
andcr30,r30,r0
-   ori r30,r30,_PAGE_HASHPTE
+   orisr30,r30,[EMAIL PROTECTED]
 
/* Phyical address in r5 */
rldicl  r5,r31,64-PTE_RPN_SHIFT,PTE_RPN_SHIFT
Index: linux-work/arch/powerpc/mm/hugetlbpage.c
===
--- linux-work.orig/arch/powerpc/mm/hugetlbpage.c   2008-05-29 
12:16:25.0 +1000
+++ linux-work/arch/powerpc/mm/hugetlbpage.c2008-05-29 12:18:51.0 
+1000
@@ -458,8 +458,7 @@ int hash_huge_page(struct mm_struct *mm,
old_pte = pte_val(*ptep);
if (old_pte & _PAGE_BUSY)
goto out;
-   new_pte = old_pte | _PAGE_BUSY |
-   _PAGE_ACCESSED | _PAGE_HASHPTE;
+   new_pte = old_pte | _PAGE_BUSY | _PAGE_ACCESSED;
} while(old_pte != __cmpxchg_u64((unsigned long *)ptep,
 old_pte, new_pte));
 
@@ -499,7 +498,7 @@ repeat:
  HPTES_PER_GROUP) & ~0x7UL;
 
/* clear HPTE slot informations in new PTE */
-   new_pte = (new_pte & ~_PAGE_HPTEFLAGS) | _PAGE_HASHPTE;
+   new_pte = (new_pte & ~_PAGE_HPTEFLAGS) | _PAGE_HUGE_HPTE;
 
/* Add in WIMG bits */
/* XXX We should store these in the pte */
Index: linux-work/include/asm-powerpc/pgtable-4k.h
===
--- linux-work.orig/include/asm-powerpc/pgtable-4k.h2008-05-29 
12:07:09.0 +1000
+++ linux-work/include/asm-powerpc/pgtable-4k.h 2008-05-29 12:17:36.0 
+1000
@@ -41,6 +41,8 @@
 #define PGDIR_MASK (~(PGDIR_SIZE-1))
 
 /* PTE bits */
+#define _PAGE_HASHPTE  0x0400 /* software: pte has an associated HPTE */
+#define _PAGE_HUGE_HPTE_PAGE_HASHPTE
 #define _PAGE_SECONDARY 0x8000 /* software: HPTE is in secondary group */
 #define _PAGE_GROUP_IX  0x7000 /* software: HPTE index within group */
 #define _PAGE_F_SECOND  _PAGE_SECONDARY
Index: linux-work/include/asm-powerpc/pgtable-64k.h
===
--- linux-work.orig/include/asm-powerpc/pgtable-64k.h   2008-05-29 
12:06:37.0 +1000
+++ 

[PATCH 1/6] Move code patching code into arch/powerpc/lib/code-patching.c

[Michael Ellerman]

We currently have a few routines for patching code in asm/system.h, because
they didn't fit anywhere else. I'd like to clean them up a little and add
some more, so first move them into a dedicated C file - they don't need to
be inlined.

While we're moving the code, drop create_function_call(), it's intended
caller never got merged and will be replaced in future with something
different.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/kernel/crash_dump.c  |1 +
 arch/powerpc/lib/Makefile |2 +
 arch/powerpc/lib/code-patching.c  |   33 
 arch/powerpc/platforms/86xx/mpc86xx_smp.c |1 +
 arch/powerpc/platforms/powermac/smp.c |1 +
 include/asm-powerpc/code-patching.h   |   25 +++
 include/asm-powerpc/system.h  |   48 -
 7 files changed, 63 insertions(+), 48 deletions(-)

diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 9ee3c52..35b9a66 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index c71d37d..305c7df 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -24,3 +24,5 @@ obj-$(CONFIG_SMP) += locks.o
 endif
 
 obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
+
+obj-y  += code-patching.o
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
new file mode 100644
index 000..7afae88
--- /dev/null
+++ b/arch/powerpc/lib/code-patching.c
@@ -0,0 +1,33 @@
+/*
+ *  Copyright 2008 Michael Ellerman, IBM Corporation.
+ *
+ *  This program is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU General Public License
+ *  as published by the Free Software Foundation; either version
+ *  2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+
+
+void create_instruction(unsigned long addr, unsigned int instr)
+{
+   unsigned int *p;
+   p  = (unsigned int *)addr;
+   *p = instr;
+   asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync" : : "r" (p));
+}
+
+void create_branch(unsigned long addr, unsigned long target, int flags)
+{
+   unsigned int instruction;
+
+   if (! (flags & BRANCH_ABSOLUTE))
+   target = target - addr;
+
+   /* Mask out the flags and target, so they don't step on each other. */
+   instruction = 0x4800 | (flags & 0x3) | (target & 0x03FC);
+
+   create_instruction(addr, instruction);
+}
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_smp.c 
b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
index ba55b0f..63f5585 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_smp.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/powerpc/platforms/powermac/smp.c 
b/arch/powerpc/platforms/powermac/smp.c
index cb2d894..bf202f7 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -36,6 +36,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/asm-powerpc/code-patching.h 
b/include/asm-powerpc/code-patching.h
new file mode 100644
index 000..0b91fdf
--- /dev/null
+++ b/include/asm-powerpc/code-patching.h
@@ -0,0 +1,25 @@
+#ifndef _ASM_POWERPC_CODE_PATCHING_H
+#define _ASM_POWERPC_CODE_PATCHING_H
+
+/*
+ * Copyright 2008, Michael Ellerman, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+/* Flags for create_branch:
+ * "b"   == create_branch(addr, target, 0);
+ * "ba"  == create_branch(addr, target, BRANCH_ABSOLUTE);
+ * "bl"  == create_branch(addr, target, BRANCH_SET_LINK);
+ * "bla" == create_branch(addr, target, BRANCH_ABSOLUTE | BRANCH_SET_LINK);
+ */
+#define BRANCH_SET_LINK0x1
+#define BRANCH_ABSOLUTE0x2
+
+extern void create_branch(unsigned long addr, unsigned long target, int flags);
+extern void create_instruction(unsigned long addr, unsigned int instr);
+
+#endif /* _ASM_POWERPC_CODE_PATCHING_H */
diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index df781ad..d141e48 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -519,54 +519,6 @@ extern void reloc_got2(unsigned long);
 
 #define PTRRELOC(x)((typeof(x)) add_reloc_offset((unsigned long)(x)))
 
-static inline void create_instruction(unsigned long addr, unsigned int instr)
-{
-   unsigned int *p;
-   p  = (unsigned int *)addr;
-   *p = instr;
-   asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync" : : "r" (p));

[PATCH 2/6] Allow create_branch() to return errors

[Michael Ellerman]

Currently create_branch() creates a branch instruction for you, and patches
it into the call site. In some circumstances it would be nice to be able to
create the instruction and patch it later, and also some code might want
to check for errors in the branch creation before doing the patching. A
future patch will change create_branch() to check for errors.

For callers that don't care, replace create_branch() with patch_branch(),
which just creates the branch and patches it directly.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/kernel/crash_dump.c  |4 ++--
 arch/powerpc/lib/code-patching.c  |   11 ---
 arch/powerpc/platforms/86xx/mpc86xx_smp.c |2 +-
 arch/powerpc/platforms/powermac/smp.c |2 +-
 include/asm-powerpc/code-patching.h   |5 +++--
 5 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 35b9a66..ee2dac5 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -42,8 +42,8 @@ static void __init create_trampoline(unsigned long addr)
 * branch to "addr" we jump to ("addr" + 32 MB). Although it requires
 * two instructions it doesn't require any registers.
 */
-   create_instruction(addr, 0x6000); /* nop */
-   create_branch(addr + 4, addr + PHYSICAL_START, 0);
+   patch_instruction(addr, 0x6000); /* nop */
+   patch_branch(addr + 4, addr + PHYSICAL_START, 0);
 }
 
 void __init setup_kdump_trampoline(void)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 7afae88..1391981 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -11,7 +11,7 @@
 #include 
 
 
-void create_instruction(unsigned long addr, unsigned int instr)
+void patch_instruction(unsigned long addr, unsigned int instr)
 {
unsigned int *p;
p  = (unsigned int *)addr;
@@ -19,7 +19,12 @@ void create_instruction(unsigned long addr, unsigned int 
instr)
asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync" : : "r" (p));
 }
 
-void create_branch(unsigned long addr, unsigned long target, int flags)
+void patch_branch(unsigned long addr, unsigned long target, int flags)
+{
+   patch_instruction(addr, create_branch(addr, target, flags));
+}
+
+unsigned int create_branch(unsigned long addr, unsigned long target, int flags)
 {
unsigned int instruction;
 
@@ -29,5 +34,5 @@ void create_branch(unsigned long addr, unsigned long target, 
int flags)
/* Mask out the flags and target, so they don't step on each other. */
instruction = 0x4800 | (flags & 0x3) | (target & 0x03FC);
 
-   create_instruction(addr, instruction);
+   return instruction;
 }
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_smp.c 
b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
index 63f5585..7c5ac68 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_smp.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
@@ -72,7 +72,7 @@ smp_86xx_kick_cpu(int nr)
 
/* Setup fake reset vector to call __secondary_start_mpc86xx. */
target = (unsigned long) __secondary_start_mpc86xx;
-   create_branch((unsigned long)vector, target, BRANCH_SET_LINK);
+   patch_branch((unsigned long)vector, target, BRANCH_SET_LINK);
 
/* Kick that CPU */
smp_86xx_release_core(nr);
diff --git a/arch/powerpc/platforms/powermac/smp.c 
b/arch/powerpc/platforms/powermac/smp.c
index bf202f7..ff483cb 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -805,7 +805,7 @@ static void __devinit smp_core99_kick_cpu(int nr)
 *   b __secondary_start_pmac_0 + nr*8 - KERNELBASE
 */
target = (unsigned long) __secondary_start_pmac_0 + nr * 8;
-   create_branch((unsigned long)vector, target, BRANCH_SET_LINK);
+   patch_branch((unsigned long)vector, target, BRANCH_SET_LINK);
 
/* Put some life in our friend */
pmac_call_feature(PMAC_FTR_RESET_CPU, NULL, nr, 0);
diff --git a/include/asm-powerpc/code-patching.h 
b/include/asm-powerpc/code-patching.h
index 0b91fdf..41ecae8 100644
--- a/include/asm-powerpc/code-patching.h
+++ b/include/asm-powerpc/code-patching.h
@@ -19,7 +19,8 @@
 #define BRANCH_SET_LINK0x1
 #define BRANCH_ABSOLUTE0x2
 
-extern void create_branch(unsigned long addr, unsigned long target, int flags);
-extern void create_instruction(unsigned long addr, unsigned int instr);
+unsigned int create_branch(unsigned long addr, unsigned long target, int 
flags);
+void patch_branch(unsigned long addr, unsigned long target, int flags);
+void patch_instruction(unsigned long addr, unsigned int instr);
 
 #endif /* _ASM_POWERPC_CODE_PATCHING_H */
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 3/6] Make create_branch() return errors if the branch target is too large

[Michael Ellerman]

If you pass a target value to create_branch() which is more than 32MB - 4,
or - 32MB away from the branch site, then it's impossible to create an
immediate branch. The current code doesn't check, which will lead to us
creating a branch to somewhere else - which is bad.

For code that cares to check we return 0, which is easy to check for, and
for code that doesn't at least we'll be creating an illegal instruction,
rather than a branch to some random address.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/lib/code-patching.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 1391981..2905c51 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -27,12 +27,18 @@ void patch_branch(unsigned long addr, unsigned long target, 
int flags)
 unsigned int create_branch(unsigned long addr, unsigned long target, int flags)
 {
unsigned int instruction;
+   long offset;
 
+   offset = target;
if (! (flags & BRANCH_ABSOLUTE))
-   target = target - addr;
+   offset = offset - addr;
+
+   /* Check we can represent the target in the instruction format */
+   if (offset < -0x200 || offset > 0x1fc || offset & 0x3)
+   return 0;
 
/* Mask out the flags and target, so they don't step on each other. */
-   instruction = 0x4800 | (flags & 0x3) | (target & 0x03FC);
+   instruction = 0x4800 | (flags & 0x3) | (offset & 0x03FC);
 
return instruction;
 }
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 4/6] Add ppc_function_entry() which gets the entry point for a function

[Michael Ellerman]

Because function pointers point to different things on 32-bit vs 64-bit,
add a macro that deals with dereferencing the OPD on 64-bit. The soon to
be merged ftrace wants this, as well as other code I am working on.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 include/asm-powerpc/code-patching.h |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/include/asm-powerpc/code-patching.h 
b/include/asm-powerpc/code-patching.h
index 41ecae8..0213a48 100644
--- a/include/asm-powerpc/code-patching.h
+++ b/include/asm-powerpc/code-patching.h
@@ -10,6 +10,8 @@
  * 2 of the License, or (at your option) any later version.
  */
 
+#include 
+
 /* Flags for create_branch:
  * "b"   == create_branch(addr, target, 0);
  * "ba"  == create_branch(addr, target, BRANCH_ABSOLUTE);
@@ -23,4 +25,18 @@ unsigned int create_branch(unsigned long addr, unsigned long 
target, int flags);
 void patch_branch(unsigned long addr, unsigned long target, int flags);
 void patch_instruction(unsigned long addr, unsigned int instr);
 
+static inline unsigned long ppc_function_entry(void *func)
+{
+#ifdef CONFIG_PPC64
+   /*
+* On PPC64 the function pointer actually points to the function's
+* descriptor. The first entry in the descriptor is the address
+* of the function text.
+*/
+   return ((func_descr_t *)func)->entry;
+#else
+   return (unsigned long)func;
+#endif
+}
+
 #endif /* _ASM_POWERPC_CODE_PATCHING_H */
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 5/6] Add tests for the code patching code, and introduce checking functions

[Michael Ellerman]

Some code I am working on wants to check that the code it's patching is
what it expects, so add three functions which check the passed instruction
to see what it is.

Add some tests for those routines, and also test the results of the existing
create_branch() function using the new routines.

It would be nice to have the test code enabled automatically for debug
kernels, but distros turn on DEBUG_KERNEL so we don't really have a config
symbol we can tie it off.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/Kconfig.debug  |5 +
 arch/powerpc/lib/code-patching.c|  140 +++
 include/asm-powerpc/code-patching.h |4 +
 3 files changed, 149 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index a7d24e6..dc58939 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -57,6 +57,11 @@ config KGDB
  debugger.  See  for more information.
  Unless you are intending to debug the kernel, say N here.
 
+config CODE_PATCHING_SELFTEST
+   bool "Run self-tests of the code-patching code."
+   depends on DEBUG_KERNEL
+   default n
+
 choice
prompt "Serial Port"
depends on KGDB
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 2905c51..13e29eb 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 
 
@@ -42,3 +43,142 @@ unsigned int create_branch(unsigned long addr, unsigned 
long target, int flags)
 
return instruction;
 }
+
+int instr_is_branch_iform(unsigned int instr)
+{
+   unsigned int opcode;
+
+   opcode = (instr >> 26) & 0x3F;
+
+   return opcode == 18;
+}
+
+int instr_is_bl(unsigned int instr)
+{
+   return instr_is_branch_iform(instr) &&
+  ((instr & BRANCH_SET_LINK) == 1) &&
+  ((instr & BRANCH_ABSOLUTE) == 0);
+}
+
+int instr_is_branch_to_addr(unsigned int *instr, unsigned long addr)
+{
+   signed long imm;
+
+   if (!instr_is_branch_iform(*instr))
+   return 0;
+
+   imm = *instr & 0x3FC;
+
+   /* If the top bit of the immediate value is set this is negative */
+   if (imm & 0x200)
+   imm -= 0x400;
+
+   if ((*instr & BRANCH_ABSOLUTE) == 0)
+   imm += (unsigned long)instr;
+
+   return (unsigned long)imm == addr;
+}
+
+#ifdef CONFIG_CODE_PATCHING_SELFTEST
+
+static void __init test_trampoline(void)
+{
+   asm ("nop;\n");
+}
+
+#define check(x)   \
+   if (!(x)) printk("code-patching: test failed at line %d\n", __LINE__);
+
+static int __init test_code_patching(void)
+{
+   unsigned long addr, dest;
+   unsigned int instr;
+
+   addr = (unsigned long)&instr;
+
+   printk(KERN_DEBUG "Running code patching self-tests ...\n");
+
+   /* The simplest case, branch to self, no flags */
+   check(instr_is_branch_iform(0x4800));
+   /* All bits of target set, and flags */
+   check(instr_is_branch_iform(0x4bff));
+   /* High bit of opcode set, which is wrong */
+   check(!instr_is_branch_iform(0xcbff));
+   /* Middle bits of opcode set, which is wrong */
+   check(!instr_is_branch_iform(0x7bff));
+
+   /* Simplest case, branch to self, with link */
+   check(instr_is_bl(0x4801));
+   /* All bits of targets set, and link */
+   check(instr_is_bl(0x4bfd));
+   /* Some bits of targets set, and link */
+   check(instr_is_bl(0x4bff00fd));
+   /* All bits of targets set, no flags, ie. link is false */
+   check(!instr_is_bl(0x4bfc));
+   /* Must be a valid branch to start with */
+   check(!instr_is_bl(0x7bfd));
+
+   /* Absolute branch to 0x100 */
+   instr = 0x48000103;
+   check(instr_is_branch_to_addr(&instr, 0x100));
+   /* Absolute branch to 0x420fc */
+   instr = 0x480420ff;
+   check(instr_is_branch_to_addr(&instr, 0x420fc));
+
+   /* Maximum positive relative branch, + 20MB - 4B */
+   instr = 0x49fc;
+   check(instr_is_branch_to_addr(&instr, addr + 0x1FC));
+
+   /* Smallest negative relative branch, - 4B */
+   instr = 0x4bfc;
+   check(instr_is_branch_to_addr(&instr, addr - 4));
+
+   /* Largest negative relative branch, - 32 MB */
+   instr = 0x4a00;
+   check(instr_is_branch_to_addr(&instr, addr - 0x200));
+
+
+   /* Branch to self, with link */
+   instr = create_branch(addr, addr, BRANCH_SET_LINK);
+   check(instr_is_branch_to_addr(&instr, addr));
+   check(instr_is_bl(instr));
+
+   /* Branch to self - 0x100, with link */
+   instr = create_branch(addr, addr - 0x100, BRANCH_SET_LINK);
+   check(instr_is_branch_to_addr(&instr, addr - 0x100));
+   check(instr_is_bl(instr));
+
+   /* Branch to self + 0x100, no li

[PATCH 6/6] Add PPC_NOP_INSTR, a hash define for the preferred nop instruction

[Michael Ellerman]

A bunch of code has hard-coded the value for a "nop" instruction, it
would be nice to have a #define for it.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/kernel/cputable.c  |3 ++-
 arch/powerpc/kernel/crash_dump.c|2 +-
 arch/powerpc/kernel/module_64.c |3 ++-
 include/asm-powerpc/code-patching.h |2 ++
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e44d553..887e190 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include   /* for PTRRELOC on ARCH=ppc */
 
@@ -1613,7 +1614,7 @@ void do_feature_fixups(unsigned long value, void 
*fixup_start, void *fixup_end)
pend = ((unsigned int *)fcur) + (fcur->end_off / 4);
 
for (p = pstart; p < pend; p++) {
-   *p = 0x6000u;
+   *p = PPC_NOP_INSTR;
asm volatile ("dcbst 0, %0" : : "r" (p));
}
asm volatile ("sync" : : : "memory");
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index ee2dac5..2f5e04f 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -42,7 +42,7 @@ static void __init create_trampoline(unsigned long addr)
 * branch to "addr" we jump to ("addr" + 32 MB). Although it requires
 * two instructions it doesn't require any registers.
 */
-   patch_instruction(addr, 0x6000); /* nop */
+   patch_instruction(addr, PPC_NOP_INSTR); /* nop */
patch_branch(addr + 4, addr + PHYSICAL_START, 0);
 }
 
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 3a82b02..d5e569a 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "setup.h"
@@ -346,7 +347,7 @@ static unsigned long stub_for_addr(Elf64_Shdr *sechdrs,
restore r2. */
 static int restore_r2(u32 *instruction, struct module *me)
 {
-   if (*instruction != 0x6000) {
+   if (*instruction != PPC_NOP_INSTR) {
printk("%s: Expect noop after relocate, got %08x\n",
   me->name, *instruction);
return 0;
diff --git a/include/asm-powerpc/code-patching.h 
b/include/asm-powerpc/code-patching.h
index 8b54373..f33d16e 100644
--- a/include/asm-powerpc/code-patching.h
+++ b/include/asm-powerpc/code-patching.h
@@ -12,6 +12,8 @@
 
 #include 
 
+#define PPC_NOP_INSTR  0x6000
+
 /* Flags for create_branch:
  * "b"   == create_branch(addr, target, 0);
  * "ba"  == create_branch(addr, target, BRANCH_ABSOLUTE);
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/6] Move code patching code into arch/powerpc/lib/code-patching.c

[Benjamin Herrenschmidt]

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote:
> We currently have a few routines for patching code in asm/system.h, because
> they didn't fit anywhere else. I'd like to clean them up a little and add
> some more, so first move them into a dedicated C file - they don't need to
> be inlined.
> 
> While we're moving the code, drop create_function_call(), it's intended
> caller never got merged and will be replaced in future with something
> different.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/6] Allow create_branch() to return errors

[Benjamin Herrenschmidt]

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote:
> Currently create_branch() creates a branch instruction for you, and patches
> it into the call site. In some circumstances it would be nice to be able to
> create the instruction and patch it later, and also some code might want
> to check for errors in the branch creation before doing the patching. A
> future patch will change create_branch() to check for errors.
> 
> For callers that don't care, replace create_branch() with patch_branch(),
> which just creates the branch and patches it directly.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/6] Make create_branch() return errors if the branch target is too large

[Benjamin Herrenschmidt]

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote:
> If you pass a target value to create_branch() which is more than 32MB - 4,
> or - 32MB away from the branch site, then it's impossible to create an
> immediate branch. The current code doesn't check, which will lead to us
> creating a branch to somewhere else - which is bad.
> 
> For code that cares to check we return 0, which is easy to check for, and
> for code that doesn't at least we'll be creating an illegal instruction,
> rather than a branch to some random address.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/6] Add ppc_function_entry() which gets the entry point for a function

[Benjamin Herrenschmidt]

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote:
> Because function pointers point to different things on 32-bit vs
> 64-bit,
> add a macro that deals with dereferencing the OPD on 64-bit. The soon
> to
> be merged ftrace wants this, as well as other code I am working on.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

Should we be smarter and also compare if the TOC pointer is the same
between the source and target and if not, warn loudly ?

Or we just don't care ?

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/6] Add ppc_function_entry() which gets the entry point for a function

[Michael Ellerman]

On Thu, 2008-05-29 at 16:37 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote:
> > Because function pointers point to different things on 32-bit vs
> > 64-bit,
> > add a macro that deals with dereferencing the OPD on 64-bit. The soon
> > to
> > be merged ftrace wants this, as well as other code I am working on.
> > 
> > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> 
> Should we be smarter and also compare if the TOC pointer is the same
> between the source and target and if not, warn loudly ?

> Or we just don't care ?

I think currently only the module loader worries about changing TOC
pointers, but perhaps we should think about it in other places too. What
do you do on 32-bit though?

Still, I think that would be a new separate macro, so this stands on its
own IMHO.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev