* Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
From: David Gibson @ 2009-04-01 23:58 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20090401123029.GA31909@oksana.dev.rtsoft.ru>
On Wed, Apr 01, 2009 at 04:30:29PM +0400, Anton Vorontsov wrote:
> On Wed, Apr 01, 2009 at 10:09:55PM +1100, David Gibson wrote:
> > On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
> > > Hi David,
> > >
> > > this patch went out by mistake, sorry.
> > >
> > > David Gibson wrote:
> > > > On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
> > > >> Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
> > > >> ===================================================================
> > > >> --- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:24:38.078719288 +0200
> > > >> +++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:47:56.986720719 +0200
> > > >> @@ -52,6 +52,7 @@
> > > >> soc8544@e0000000 {
> > > >> #address-cells = <1>;
> > > >> #size-cells = <1>;
> > > >> + device_type = "soc";
> > > >
> > > > You should not be adding device_type to a new board's dts. You
> > > > *especially* shouldn't be doing that with no patch comment explaining
> > > > why.
> > >
> > > In the final patch I have removed the device_type = "soc", but it makes
> > > trouble as some mpc85xx rely on it.
> >
> > Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
> > don't see how something that affects "some mpc85xx" is relevant.
>
> Not some, but *all* mpc85xx. The thing is that U-Boot is searching
> for device_type = "soc" to fixup some properties (for example,
> bus-frequency) for all mpc85xx parts, so you can't easily remove
> the device_type w/o breaking boot for firmwares that customers have
> pre-programmed in their products.
I thought that was fixed in current u-boot versions.
> Note that upgrading firmware without JTAG is dangerous, so it's not
> an option to "force" everybody to upgrade their firmware just
> because we want to remove some cruft from the device tree.
I realise that, but again this is a *new board*, which presumably can
use an up-to-date u-boot version.
--
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 1/2] powerpc: i2c-mpc: preserve I2C clocking
From: David Gibson @ 2009-04-02 0:07 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <49D31A5D.8030204@grandegger.com>
On Wed, Apr 01, 2009 at 09:40:13AM +0200, Wolfgang Grandegger wrote:
> David Gibson wrote:
> > On Tue, Mar 31, 2009 at 02:43:39PM +0200, Wolfgang Grandegger wrote:
> >> The I2c node property "fsl,preserve-clocking" allows to overtake the
> >> clock settings from the boot loader and avoids the hard-coded setting.
> >
> > Hrm. This is dubious. The device tree should generally describe
> > hardware, not OS/driver behaviour which is what this appears to be
> > doing. There are exceptions, but you need to justify them.
>
> I think the purpose of this property is clear. How would you provide
> that functionality instead? I suggested that a "clock-frequency = <0>"
> property should do the trick but Grant preferred to be more
> explicit.
I'm not saying the meaning is unclear, I'm saying it's describing
something that the device tree isn't meant to describe. AFAICT it's
telling the driver what to do with the device, not a property of the
device itself.
Now, there are cases where it's acceptable to put this sort of
information in the device tree, because it's the least nasty available
solution (flash partition information for example). But you need to
justify it, if that's so.
--
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 next] powerpc: pseries/dtl.c should include asm/firmware.h
From: Michael Neuling @ 2009-04-02 0:34 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev, linux-next, jk, Stephen Rothwell
In-Reply-To: <49D3419E.7000005@in.ibm.com>
> randconfig build on powerpc failed with :
>=20
>=20
> arch/powerpc/platforms/pseries/dtl.c: In function =C2=91dtl_init=C2=92:
> arch/powerpc/platforms/pseries/dtl.c:238: error: implicit declaration of =
func
tion =C2=91firmware_has_feature=C2=92
> arch/powerpc/platforms/pseries/dtl.c:238: error: =C2=91FW_FEATURE_SPLPAR=
=C2=92 undeclared
(first use in this function)
> arch/powerpc/platforms/pseries/dtl.c:238: error: (Each undeclared identif=
ier=20
is reported only once
> arch/powerpc/platforms/pseries/dtl.c:238: error: for each function it app=
ears
in.)
>=20
> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> ---
It's great that you're sending patches to fix these issues but it's not
quite formatted as the maintainers like.
The patch needs to be included inline in the message, rather than as an
attachment. You can see it as an attachment here:
http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070122.html
.. as opposed to the required inline format like this patch:
http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070120.html
Adding a diffstat would also be nice.
Mikey
>=20
>=20
>=20
> --------------050404090408000502010008
> Content-Type: text/x-patch;
> name=3D"fix-dtl-build-break.patch"
> Content-Transfer-Encoding: 8bit
> Content-Disposition: inline;
> filename=3D"fix-dtl-build-break.patch"
>=20
> * Fixes the following build error
> *
> * arch/powerpc/platforms/pseries/dtl.c: In function =E2=80=98dtl_init=E2=
=80=99:
> * arch/powerpc/platforms/pseries/dtl.c:238:
> * error: implicit declaration of function =E2=80=98firmware_has_fea=
ture=E2=80=99
> * arch/powerpc/platforms/pseries/dtl.c:238:
> * error: =E2=80=98FW_FEATURE_SPLPAR=E2=80=99 undeclared (first use =
in this function)
> * arch/powerpc/platforms/pseries/dtl.c:238:
> * error: (Each undeclared identifier is reported only once
> * arch/powerpc/platforms/pseries/dtl.c:238:=20
> * error: for each function it appears in.)
>=20
> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> ---
>=20
> diff -Naurp a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platfor=
ms/p
series/dtl.c
> --- a/arch/powerpc/platforms/pseries/dtl.c 2009-04-01 15:46:59.000000000 +
0530
> +++ b/arch/powerpc/platforms/pseries/dtl.c 2009-04-01 15:47:58.000000000 +
0530
> @@ -25,6 +25,7 @@
> #include <asm/smp.h>
> #include <asm/system.h>
> #include <asm/uaccess.h>
> +#include <asm/firmware.h>
>=20=20
> #include "plpar_wrappers.h"
>=20=20
>=20
> --------------050404090408000502010008
> Content-Type: text/plain; charset=3D"us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> --------------050404090408000502010008--
>=20
^ permalink raw reply
* Re: issue at the beginning of kernel booting
From: Sauce.Cheng @ 2009-04-02 3:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090327161522.GA7809@ld0162-tx32.am.freescale.net>
thanks Scott
> Another thing that would generally be good is to keep replies on the
> list rather than taking it to private e-mail as soon as someone replies.
> Someone else may have something helpful to say based on your followup,
> or may have the same problem and be helped by the conclusion.
ok~ excuse for my mistake, thank you for your words. i will do it like you
say from now on. it surely be better.
> I don't see where you set up a BAT that covers 0xf0000000.
if i have to set up a BAT that cover 0xF0000000. i had a debug with LEDs
like that in u-boot code. everything is //normal. 0xF00000000 is the value
of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address
and //base //address of all internal regishters, isnt? you mean that if i
set BATs, i should not get the phy address like in the //front ?
> Do you have a correct fdt, that matches a platform that is enabled in
> your .config?
i think so, i used mpc8272ads_defconfig becasue my processor is mpc8272, i
got a mail before about modifying and //config fdt file mpc8272ads.dts. i
fixed up my file like that.
i tried
CONFIG_PPC_EARLY_DEBUG_CPM=y
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf00000008
how can i make sure CPM_ADDR, 0xf0000008 is default value
now it show as follow. i select smc1 as console. please check it and give me
some advice.
/ {
model = "MPC8272ADS";
compatible = "fsl,mpc8272ads";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8272@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <d#32>;
i-cache-line-size = <d#32>;
d-cache-size = <d#16384>;
i-cache-size = <d#16384>;
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <0 0>;
};
localbus@f0010100 {
compatible = "fsl,mpc8272-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 40>;
/* chengmo : modify by my own device */
ranges = <0 0 FFF00000 00080000 //CS0: Flahs 512k
2 0 00000000 02000000 //CS2: SDRAM 32M
>;
flash@0,0 {
compatible = "cfi-flash";
reg = <0 0 00080000>;
bank-width = <4>;
device-width = <1>; // 16 bits
};
PCI_PIC: interrupt-controller@3,0 {
compatible = "fsl,mpc8272ads-pci-pic",
"fsl,pq2ads-pci-pic";
#interrupt-cells = <1>;
interrupt-controller;
reg = <3 0 8>;
interrupt-parent = <&PIC>;
interrupts = <14 8>;
};
};
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
ranges = <00000000 f0000000 00053000>;
// Temporary -- will go away once kernel uses ranges for get_immrbase().
reg = <f0000000 00053000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
serial@11a82 {
device_type = "serial";
compatible = "fsl,mpc8272-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a82 20 87FC 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
PHY0: ethernet-phy@0 {
interrupt-parent = <&PIC>;
interrupts = <17 8>;
reg = <0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-phy@1 {
interrupt-parent = <&PIC>;
interrupts = <17 8>;
reg = <3>;
device_type = "ethernet-phy";
};
};
ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100 11390 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
};
};
chosen {
linux,stdout-path = "/soc/cpm/serial@11a82";
};
};
--
View this message in context: http://www.nabble.com/issue-at-the-beginning-of-kernel-booting-tp22741532p22840131.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Fix highmem build failure
From: Akinobu Mita @ 2009-04-02 3:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <1238621611-4844-1-git-send-email-galak@kernel.crashing.org>
On Wed, Apr 01, 2009 at 04:33:31PM -0500, Kumar Gala wrote:
> The following commit breaks PPC builds with CONFIG_HIGHMEM=y
>
> commit f4112de6b679d84bd9b9681c7504be7bdfb7c7d5
> Author: Akinobu Mita <akinobu.mita@gmail.com>
> Date: Tue Mar 31 15:23:25 2009 -0700
>
> mm: introduce debug_kmap_atomic
>
Thanks.
But the definition of debug_kmap_atomic() needs to be outside of
ifdef CONFIG_HIGHMEM. Because debug_kmap_atomic() is used without
CONFIG_HIGHMEM by kmap_atomic_prot_pfn() in arch/x86/mm/iomap_32.c
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -20,6 +20,19 @@ static inline void flush_kernel_dcache_page(struct page *page)
> #endif
>
> #ifdef CONFIG_HIGHMEM
> +#include <asm/kmap_types.h>
> +
> +#if defined(CONFIG_DEBUG_HIGHMEM) && defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
> +
> +void debug_kmap_atomic(enum km_type type);
> +
> +#else
> +
> +static inline void debug_kmap_atomic(enum km_type type)
> +{
> +}
> +
> +#endif
>
> #include <asm/highmem.h>
>
^ permalink raw reply
* [PATCH] powerpc: change giveup_fpu/altivec to disable VSX for current
From: Michael Neuling @ 2009-04-02 4:02 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
When we call giveup_fpu, we need to need to turn off VSX in current.
If we don't, on return to current it may execute a VSX instruction
(before the next FP), and not have it's register state refreshed
correctly from the thread_struct. Ditto for altivec.
This caused a bug where an unaligned lfs or stfs (which calls
giveup_fpu so it can use the FPRs) to return to userspace with FP off
but VSX on. Then if a VSX instruction is executed, before another FP
instruction, it will proceed without another exception and hence have
the incorrect register state for VSX registers 0-31.
lfs unaligned <- alignment exception turns FP off but leaves VSX on
VSX instruction <- no exception since VSX on, hence we get the
wrong VSX register values for VSX registers 0-31
(overlapping the FPRs)
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/fpu.S | 5 +++++
arch/powerpc/kernel/misc_64.S | 8 ++++++++
2 files changed, 13 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/fpu.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/fpu.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/fpu.S
@@ -145,6 +145,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
beq 1f
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r3,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_VSX
+BEGIN_FTR_SECTION
+ oris r3,r3,MSR_VSX@h
+END_FTR_SECTION_IFSET(CPU_FTR_VSX)
+#endif
andc r4,r4,r3 /* disable FP for previous task */
PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
1:
Index: linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/misc_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
@@ -495,7 +495,15 @@ _GLOBAL(giveup_altivec)
stvx vr0,r4,r3
beq 1f
ld r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+#ifdef CONFIG_VSX
+BEGIN_FTR_SECTION
+ lis r3,(MSR_VEC|MSR_VSX)@h
+FTR_SECTION_ELSE
+ lis r3,MSR_VEC@h
+ALT_FTR_SECTION_END_IFSET(CPU_FTR_VSX)
+#else
lis r3,MSR_VEC@h
+#endif
andc r4,r4,r3 /* disable FP for previous task */
std r4,_MSR-STACK_FRAME_OVERHEAD(r5)
1:
^ permalink raw reply
* Re: Problem with module_init?
From: Sean MacLennan @ 2009-04-02 4:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1238624683.17330.138.camel@pasglop>
On Thu, 02 Apr 2009 09:24:43 +1100
"Benjamin Herrenschmidt" <benh@kernel.crashing.org> wrote:
> I suspect I just screwed up the definition of PAGE_KERNEL_EXEC or
> something like that.
Yup, that is exactly what you did ;) You left out _PAGE_HWEXEC. The
following patch fixes the problem for me.
Cheers,
Sean
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index d9740e8..a84f248 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -167,7 +167,8 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
#endif
/* Make modules code happy. We don't set RO yet */
-#define PAGE_KERNEL_EXEC PAGE_KERNEL_X
+// #define PAGE_KERNEL_EXEC PAGE_KERNEL_X
+#define PAGE_KERNEL_EXEC __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW | _PAGE_EXEC | _PAGE_HWEXEC)
/* Advertise special mapping type for AGP */
#define PAGE_AGP (PAGE_KERNEL_NC)
^ permalink raw reply related
* Re: Problem with module_init?
From: Benjamin Herrenschmidt @ 2009-04-02 4:26 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090402000803.087600da@lappy.seanm.ca>
On Thu, 2009-04-02 at 00:08 -0400, Sean MacLennan wrote:
> On Thu, 02 Apr 2009 09:24:43 +1100
> "Benjamin Herrenschmidt" <benh@kernel.crashing.org> wrote:
>
> > I suspect I just screwed up the definition of PAGE_KERNEL_EXEC or
> > something like that.
>
> Yup, that is exactly what you did ;) You left out _PAGE_HWEXEC. The
> following patch fixes the problem for me.
The proper fix is for PAGE_KERNEL_X to have _PAGE_HWEXEC. I'll fix that.
Cheers,
Ben.
> Cheers,
> Sean
>
> diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
> index d9740e8..a84f248 100644
> --- a/arch/powerpc/include/asm/pte-common.h
> +++ b/arch/powerpc/include/asm/pte-common.h
> @@ -167,7 +167,8 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
> #endif
>
> /* Make modules code happy. We don't set RO yet */
> -#define PAGE_KERNEL_EXEC PAGE_KERNEL_X
> +// #define PAGE_KERNEL_EXEC PAGE_KERNEL_X
> +#define PAGE_KERNEL_EXEC __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW | _PAGE_EXEC | _PAGE_HWEXEC)
>
> /* Advertise special mapping type for AGP */
> #define PAGE_AGP (PAGE_KERNEL_NC)
^ permalink raw reply
* Re: Problem with module_init?
From: Sean MacLennan @ 2009-04-02 4:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1238646362.17330.186.camel@pasglop>
On Thu, 02 Apr 2009 15:26:02 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The proper fix is for PAGE_KERNEL_X to have _PAGE_HWEXEC. I'll fix
> that.
That may not be enough. I made that change (adding _PAGE_HWEXEC to
PAGE_KERNEL_X) and it works for some drivers, but I am still crashing in
one driver. Although, that *could* be unrelated bug.
Cheers,
Sean
^ permalink raw reply
* [PATCH v2] Fix highmem build failure
From: Kumar Gala @ 2009-04-02 4:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel, akinobu.mita
The following commit breaks PPC builds with CONFIG_HIGHMEM=y
commit f4112de6b679d84bd9b9681c7504be7bdfb7c7d5
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date: Tue Mar 31 15:23:25 2009 -0700
mm: introduce debug_kmap_atomic
We get:
CC init/main.o
In file included from include/linux/highmem.h:25,
from include/linux/pagemap.h:11,
from include/linux/mempolicy.h:63,
from init/main.c:53:
linux-2.6/arch/powerpc/include/asm/highmem.h: In function 'kmap_atomic_prot':
linux-2.6/arch/powerpc/include/asm/highmem.h:98: error: implicit declaration of function 'debug_kmap_atomic'
In file included from include/linux/pagemap.h:11,
from include/linux/mempolicy.h:63,
from init/main.c:53:
include/linux/highmem.h: At top level:
include/linux/highmem.h:196: warning: conflicting types for 'debug_kmap_atomic'
include/linux/highmem.h:196: error: static declaration of 'debug_kmap_atomic' follows non-static declaration
linux-2.6/include/asm/highmem.h:98: error: previous implicit declaration of 'debug_kmap_atomic' was here
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Should address Akinobu issues w/having this build properly on x86
- k
include/linux/highmem.h | 29 ++++++++++++++---------------
1 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 7ff5c55..1fcb712 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -19,8 +19,21 @@ static inline void flush_kernel_dcache_page(struct page *page)
}
#endif
-#ifdef CONFIG_HIGHMEM
+#include <asm/kmap_types.h>
+
+#if defined(CONFIG_DEBUG_HIGHMEM) && defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
+
+void debug_kmap_atomic(enum km_type type);
+
+#else
+static inline void debug_kmap_atomic(enum km_type type)
+{
+}
+
+#endif
+
+#ifdef CONFIG_HIGHMEM
#include <asm/highmem.h>
/* declarations for linux/mm/highmem.c */
@@ -44,8 +57,6 @@ static inline void *kmap(struct page *page)
#define kunmap(page) do { (void) (page); } while (0)
-#include <asm/kmap_types.h>
-
static inline void *kmap_atomic(struct page *page, enum km_type idx)
{
pagefault_disable();
@@ -187,16 +198,4 @@ static inline void copy_highpage(struct page *to, struct page *from)
kunmap_atomic(vto, KM_USER1);
}
-#if defined(CONFIG_DEBUG_HIGHMEM) && defined(CONFIG_TRACE_IRQFLAGS_SUPPORT)
-
-void debug_kmap_atomic(enum km_type type);
-
-#else
-
-static inline void debug_kmap_atomic(enum km_type type)
-{
-}
-
-#endif
-
#endif /* _LINUX_HIGHMEM_H */
--
1.5.6.6
^ permalink raw reply related
* Re: Problem with module_init?
From: Sean MacLennan @ 2009-04-02 4:51 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <20090402003905.317431e5@lappy.seanm.ca>
On Thu, 2 Apr 2009 00:39:05 -0400
"Sean MacLennan" <sean.maclennan@ottawa.kanatek.ca> wrote:
> Although, that *could* be unrelated bug.
It *is* an unrelated bug. dma_alloc_coherent now requires a device
where before it was optional. Carry on.
Cheers,
Sean
^ permalink raw reply
* Re: Problem with module_init?
From: Benjamin Herrenschmidt @ 2009-04-02 4:54 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090402005126.1b30dacd@lappy.seanm.ca>
On Thu, 2009-04-02 at 00:51 -0400, Sean MacLennan wrote:
> On Thu, 2 Apr 2009 00:39:05 -0400
> "Sean MacLennan" <sean.maclennan@ottawa.kanatek.ca> wrote:
>
> > Although, that *could* be unrelated bug.
>
> It *is* an unrelated bug. dma_alloc_coherent now requires a device
> where before it was optional. Carry on.
Right, that's new in .30
Cheers,
Ben.
> Cheers,
> Sean
^ permalink raw reply
* Please pull from 'next' branch (for 2.6.30)
From: Kumar Gala @ 2009-04-02 4:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
arch/powerpc/Kconfig | 1 +
arch/powerpc/boot/dts/ksi8560.dts | 4 ++--
arch/powerpc/boot/dts/sbc8548.dts | 4 ++--
arch/powerpc/boot/dts/sbc8560.dts | 4 ++--
arch/powerpc/boot/dts/stx_gp3_8560.dts | 4 ++--
arch/powerpc/boot/dts/tqm8540.dts | 4 ++--
arch/powerpc/boot/dts/tqm8541.dts | 4 ++--
arch/powerpc/boot/dts/tqm8555.dts | 4 ++--
arch/powerpc/boot/dts/tqm8560.dts | 4 ++--
include/linux/fsl_devices.h | 22 ----------------------
10 files changed, 17 insertions(+), 38 deletions(-)
Grant Likely (1):
powerpc: Remove unused symbols from fsl_devices.h
Josh Boyer (1):
powerpc: Make LOWMEM_CAM_NUM depend on FSL_BOOKE
Kumar Gala (1):
powerpc/85xx: Use fsl,mpc85.. as prefix for memory ctrl & l2-cache nodes
^ permalink raw reply
* Re: [PATCH] powerpc ptrace block-step
From: Benjamin Herrenschmidt @ 2009-04-02 5:26 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev, utrace-devel
In-Reply-To: <20090401215903.DE872FC3AB@magilla.sf.frob.com>
On Wed, 2009-04-01 at 14:59 -0700, Roland McGrath wrote:
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index c9c678f..d7692b8 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -135,7 +135,9 @@ do { \
> * These are defined as per linux/ptrace.h, which see.
> */
> #define arch_has_single_step() (1)
> +#define arch_has_block_step() (1)
The patch only implements it for "server/classic" processors, not BookE,
thus it should probably only advertise it for these :-)
Though it wouldn't be too hard to implement it for BookE using DBCR0:BRT
(Branch Taken debug event) though it might need some careful fixups such
as the one we have for single step regarding hitting exception entry
code.
Cheers,
Ben.
> extern void user_enable_single_step(struct task_struct *);
> +extern void user_enable_block_step(struct task_struct *);
> extern void user_disable_single_step(struct task_struct *);
>
> #endif /* __ASSEMBLY__ */
> @@ -288,4 +290,6 @@ extern void user_disable_single_step(struct task_struct *);
> #define PPC_PTRACE_PEEKUSR_3264 0x91
> #define PPC_PTRACE_POKEUSR_3264 0x90
>
> +#define PTRACE_SINGLEBLOCK 0x100 /* resume execution until next branch */
> +
> #endif /* _ASM_POWERPC_PTRACE_H */
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 3635be6..656fea2 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -707,12 +707,29 @@ void user_enable_single_step(struct task_struct *task)
> task->thread.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> regs->msr |= MSR_DE;
> #else
> + regs->msr &= ~MSR_BE;
> regs->msr |= MSR_SE;
> #endif
> }
> set_tsk_thread_flag(task, TIF_SINGLESTEP);
> }
>
> +void user_enable_block_step(struct task_struct *task)
> +{
> + struct pt_regs *regs = task->thread.regs;
> +
> + if (regs != NULL) {
> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> + task->thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
> + regs->msr |= MSR_DE;
> +#else
> + regs->msr &= ~MSR_SE;
> + regs->msr |= MSR_BE;
> +#endif
> + }
> + set_tsk_thread_flag(task, TIF_SINGLESTEP);
> +}
> +
> void user_disable_single_step(struct task_struct *task)
> {
> struct pt_regs *regs = task->thread.regs;
> @@ -729,7 +746,7 @@ void user_disable_single_step(struct task_struct *task)
> task->thread.dbcr0 &= ~(DBCR0_IC | DBCR0_IDM);
> regs->msr &= ~MSR_DE;
> #else
> - regs->msr &= ~MSR_SE;
> + regs->msr &= ~(MSR_SE | MSR_BE);
> #endif
> }
> clear_tsk_thread_flag(task, TIF_SINGLESTEP);
^ permalink raw reply
* Re: [Patch next] powerpc: pseries/dtl.c should include asm/firmware.h
From: Sachin Sant @ 2009-04-02 5:31 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, linux-next, jk, Stephen Rothwell
In-Reply-To: <25834.1238632443@neuling.org>
Michael Neuling wrote:
> It's great that you're sending patches to fix these issues but it's not
> quite formatted as the maintainers like.
>
> The patch needs to be included inline in the message, rather than as an
> attachment. You can see it as an attachment here:
> http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070122.html
> .. as opposed to the required inline format like this patch:
> http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070120.html
>
Yeah .. just being lazy. Moving from thunderbird to mutt have been
on my TODO list for a long time. I will use this as a trigger to
move to a different mail client. Thanks Mikey.
Regards
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* RE: /dev/random on PPC40EXr
From: Tirumala Reddy Marri @ 2009-04-02 5:59 UTC (permalink / raw)
To: Tirumala Reddy Marri, Felix Radensky, linuxppc-dev
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C071F4A5D@SDCEXCHANGE01.ad.amcc.com>
[-- Attachment #1.1: Type: text/plain, Size: 34402 bytes --]
Here I am copy pasting the files and also attaching.
--------------trng4xx.c-------------
/*******************************************************************************
*
* Copyright (c) 2008 Loc Ho <lho@amcc.com>
*
* 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.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*
* Detail Description:
* This file defines ioctl structures for the Linux CryptoAPI interface. It
* provides user space applications accesss into the Linux CryptoAPI
* functionalities.
*
* @file trng4xx.c
*
* This file provides access to the AMCC PPC4XX TRNG for Linux.
*
*******************************************************************************
*/
#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/hw_random.h>
#include <linux/interrupt.h>
#include <asm/of_platform.h>
#include <asm/io.h>
#include "trng4xx.h"
#define TRNG4XX_VER_STR "0.1"
#define PFX KBUILD_MODNAME ": "
struct trng4xx_dev {
struct resource res;
u32 irq;
volatile char __iomem *csr;
struct semaphore access_prot;
u32 datum;
};
struct hal_config {
struct of_device *ofdev;
};
static struct trng4xx_dev trng4xx_dev;
static int trng4xx_irq_handler(int irq, void * id);
static void trng4xx_chk_overflow(void);
int trng4xx_config_set(struct hal_config *cfg)
{
struct device_node *rng_np = cfg->ofdev->node;
int rc = 0;
rc = of_address_to_resource(rng_np, 0, &trng4xx_dev.res);
if (rc)
return -ENODEV;
trng4xx_dev.csr = ioremap(trng4xx_dev.res.start,
trng4xx_dev.res.end - trng4xx_dev.res.start + 1);
if (trng4xx_dev.csr == NULL) {
printk(KERN_ERR PFX "unable to ioremap 0x%02X_%08X size %d\n",
(u32) (trng4xx_dev.res.start >> 32),
(u32) trng4xx_dev.res.start,
(u32) (trng4xx_dev.res.end - trng4xx_dev.res.start + 1));
return -ENOMEM;
}
#if 0
printk("TRNG1 0x%02X_%08X size %d\n",
(u32) (trng4xx_dev.res.start >> 32),
(u32) trng4xx_dev.res.start,
(u32) (trng4xx_dev.res.end - trng4xx_dev.res.start + 1));
#endif
trng4xx_dev.irq = of_irq_to_resource(rng_np, 0, NULL);
printk ("TRNG IRQ = %d\n",trng4xx_dev.irq);
if (trng4xx_dev.irq == NO_IRQ) {
/* Un-map CSR */
iounmap(trng4xx_dev.csr);
trng4xx_dev.csr = NULL;
return -EINVAL;
}
return 0;
}
int trng4xx_pka_config_clear(void)
{
iounmap(trng4xx_dev.csr);
return 0;
}
inline int trng4xx_hw_read32(u32 reg_addr, u32 *data_val)
{
*data_val = in_be32((volatile unsigned __iomem *)
(trng4xx_dev.csr + reg_addr));
return 0;
}
inline int trng4xx_hw_write32(u32 reg_addr, u32 data_val)
{
out_be32((volatile unsigned __iomem *) (trng4xx_dev.csr + reg_addr),
data_val);
return 0;
}
int trng4xx_hw_init(void)
{
int rc;
rc = request_irq(trng4xx_dev.irq, trng4xx_irq_handler,
0, "TRNG", NULL);
if (rc != 0) {
printk(KERN_ERR PFX "failed to register interrupt IRQ %d\n",
trng4xx_dev.irq);
return rc;
}
return 0;
}
int trng4xx_hw_deinit(void)
{
free_irq(trng4xx_dev.irq, NULL);
return 0;
}
static int trng4xx_irq_handler(int irq, void * id)
{
/* TRNG Alarm Counter overflow */
trng4xx_chk_overflow();
return 0;
}
/*******************************************************************************
* TRNG Functions
*******************************************************************************
*/
static void trng4xx_chk_overflow(void)
{
/* TRNG Alarm Counter overflow */
int rc;
u32 val;
struct trng4xx_cfg {
u32 ring1_delay_sel : 3;
u32 ring2_delay_sel : 3;
u32 reset_cnt : 6;
} __attribute__((packed));
rc = trng4xx_hw_write32(TRNG4XX_ALARMCNT_ADDR, val);
if (rc != 0)
return;
if (val > 128) {
struct trng4xx_cfg *trng4xx_cfg;
/* Alarm count is half, reset it */
rc = trng4xx_hw_read32(TRNG4XX_CFG_ADDR, &val);
if (rc != 0)
return;
trng4xx_cfg = (struct trng4xx_cfg *) &val;
++trng4xx_cfg->ring1_delay_sel;
trng4xx_cfg->ring2_delay_sel = (~trng4xx_cfg->ring1_delay_sel) & 0x07;
rc = trng4xx_hw_write32(TRNG4XX_CFG_ADDR, val);
if (rc != 0)
return;
trng4xx_hw_write32(TRNG4XX_ALARMCNT_ADDR, 0x00000000);
if (rc != 0)
return;
}
}
int trng4xx_random(u32 *rand_val)
{
u32 val = 0;
int rc;
#define MAX_TRY 3
u16 try_cnt = 0;
down(&trng4xx_dev.access_prot);
do {
rc = trng4xx_hw_read32(TRNG4XX_STATUS_ADDR, &val);
if (rc != 0)
goto err;
} while((val & TRNG4XX_STATUS_BUSY) && ++try_cnt <= MAX_TRY);
if (val & TRNG4XX_STATUS_BUSY) {
rc = -EINPROGRESS;
goto err;
}
rc = trng4xx_hw_read32(TRNG4XX_OUTPUT_ADDR, rand_val);
err:
//printk("status busy\n");
up(&trng4xx_dev.access_prot);
return rc;
}
EXPORT_SYMBOL_GPL(trng4xx_random);
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25)
static int trng4xx_data_present(struct hwrng *rng)
#else
static int trng4xx_data_present(struct hwrng *rng, int wait)
#endif
{
struct trng4xx_dev *dev = (struct trng4xx_dev *) rng->priv;
int i;
u32 val;
printk("inside %s:\n", __FUNCTION__);
down(&trng4xx_dev.access_prot);
/* We should not take more than 200??? us */
for (i = 0; i < 20; i++) {
trng4xx_hw_read32(TRNG4XX_STATUS_ADDR, &val);
if (!(val & TRNG4XX_STATUS_BUSY)) {
trng4xx_hw_read32(TRNG4XX_OUTPUT_ADDR, &dev->datum);
break;
}
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25)
break;
#else
if (!wait)
break;
udelay(10);
#endif
}
up(&trng4xx_dev.access_prot);
return (val & TRNG4XX_STATUS_BUSY) ? 0 : 1;
}
static int trng4xx_data_read(struct hwrng *rng, u32 *data)
{
struct trng4xx_dev *dev = (struct trng4xx_dev *) rng->priv;
*data = dev->datum;
printk("data read = %u\n", *data);
return 0;
}
static int trng4xx_init(struct hwrng *rng)
{
return trng4xx_hw_init();
}
static void trng4xx_cleanup(struct hwrng *rng)
{
trng4xx_hw_deinit();
}
static struct hwrng trng4xx_func = {
.name = "ppc4xx-trng",
.init = trng4xx_init,
.cleanup = trng4xx_cleanup,
.data_present = trng4xx_data_present,
.data_read = trng4xx_data_read,
.priv = (unsigned long) &trng4xx_dev,
};
/*******************************************************************************
*
* Setup Driver with platform registration
*
*******************************************************************************
*/
static int __devinit trng4xx_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
struct hal_config hw_cfg;
int rc;
u32 value, value2;
u32 ctrl_val, control_value;
hw_cfg.ofdev = ofdev;
rc = trng4xx_config_set(&hw_cfg);
if (rc != 0)
return rc;
#if 1
printk( "AMCC 4xx TRNG v%s @0x%02X_%08X size %d IRQ %d\n",
TRNG4XX_VER_STR,
(u32) (trng4xx_dev.res.start >> 32),
(u32) trng4xx_dev.res.start,
(u32) (trng4xx_dev.res.end - trng4xx_dev.res.start + 1),
trng4xx_dev.irq);
#endif
init_MUTEX(&trng4xx_dev.access_prot);
rc = hwrng_register(&trng4xx_func);
if (rc) {
printk(KERN_ERR PFX
"AMCC 4xx TRNG registering failed error %d\n", rc);
goto err;
}
trng4xx_hw_read32(TRNG4XX_CNTL_ADDR, &ctrl_val);
//printk ("cntl value = 0x%x\n", ctrl_val);
value = ctrl_val | TRNG4XX_CNTL_TST_ALARM;
//printk ("value to write = 0x%x\n", value);
/*rc = trng4xx_hw_write32(TRNG4XX_CNTL_ADDR, value);
if (rc != 0)
printk ("ERROR: writing\n");
trng4xx_hw_read32(TRNG4XX_CNTL_ADDR, &control_value);
printk ("control value = 0x%x\n", control_value);*/
/*value = 0;
printk ("checking random value register\n");
rc = trng4xx_random (&value);
printk ("checking random value register\n");
rc = trng4xx_random (&value2);*/
return rc;
err:
trng4xx_pka_config_clear();
return rc;
}
static int __devexit trng4xx_remove(struct of_device *dev)
{
hwrng_unregister(&trng4xx_func);
trng4xx_pka_config_clear();
return 0;
}
static struct of_device_id trng4xx_match[] = {
{ .compatible = "ppc4xx-trng", },
{ .compatible = "amcc,ppc4xx-trng", },
{ },
};
static struct of_platform_driver trng4xx_driver = {
.name = "ppc4xx-trng",
.match_table = trng4xx_match,
.probe = trng4xx_probe,
.remove = trng4xx_remove,
};
static int __init mod_init(void)
{
printk("entered mod_init\n");
return of_register_platform_driver(&trng4xx_driver);
}
static void __exit mod_exit(void)
{
of_unregister_platform_driver(&trng4xx_driver);
}
module_init(mod_init);
module_exit(mod_exit);
MODULE_DESCRIPTION("AMCC 4xx True Random Number Generator");
MODULE_LICENSE("GPL");
------------trng4xx.h -------------------
/*******************************************************************************
*
* Copyright (c) 2008 Loc Ho <lho@amcc.com>
*
* 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.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*
* Detail Description:
* This file defines ioctl structures for the Linux CryptoAPI interface. It
* provides user space applications accesss into the Linux CryptoAPI
* functionalities.
*
* @file trng4xx.h
*
* This file provides access to the AMCC SoC TRNG.
*
*******************************************************************************
*/
#ifndef __TRNG4XX_H__
#define __TRNG4XX_H__
/*******************************************************************************
* TRNG Register and bit Definitions
*******************************************************************************
*/
/* Register TRNG4XX_STATUS bit definition */
#define TRNG4XX_STATUS_BUSY 0x00000001
/* Register TRNG4XX_CNTL bit definition */
#define TRNG4XX_CNTL_TST_RING_OUT 0x00000001
#define TRNG4XX_CNTL_TST_MODE 0x00000002
#define TRNG4XX_CNTL_TST_RUN 0x00000004
#define TRNG4XX_CNTL_TST_EN1 0x00000008
#define TRNG4XX_CNTL_TST_EN2 0x00000010
#define TRNG4XX_CNTL_DISABLE_ALARM 0x00000020
#define TRNG4XX_CNTL_CLOCK_ON 0x00000040
#define TRNG4XX_CNTL_SHORT_CYCLE 0x00000080
#define TRNG4XX_CNTL_TST_ALARM 0x00000100
#define TRNG4XX_CNTL_TST_LFSR 0x00000200
#define TRNG4XX_CNTL_RESET_LFSR 0x00000400
#define TRNG4XX_CNTL_BYPASS_TRNG 0x00000800
#define TRNG4XX_CNTL_POST_PROC_EN 0x00001000
/* Register TRNG4XX_CFG bit definition */
#define TRNG4XX_CFG_RING1_DELAY_SEL_SHIFT 0
#define TRNG4XX_CFG_RING1_DELAY_SEL_MASK (7)
#define TRNG4XX_CFG_RING2_DELAY_SEL_SHIFT 3
#define TRNG4XX_CFG_RING2_DELAY_SEL_MASK (7 << TRNG4XX_CFG_RING2_DELAY_SEL_SHIFT)
#define TRNG4XX_CFG_RESET_CNT_SHIFT 6
#define TRNG4XX_CFG_RESET_CNT_SHIFT_MASK (0x3F << TRNG4XX_CFG_RING2_DELAY_SEL_SHIFT)
/* TRNG Register definition */
#define TRNG4XX_OUTPUT_ADDR 0x0000
#define TRNG4XX_STATUS_ADDR 0x0004
#define TRNG4XX_CNTL_ADDR 0x0008
#define TRNG4XX_CFG_ADDR 0x000C
#define TRNG4XX_ALARMCNT_ADDR 0x0010
#define TRNG4XX_AREG_ADDR 0x0014
#define TRNG4XX_BREG_ADDR 0x0018
#define TRNG4XX_XREG_0_ADDR 0x001C
#define TRNG4XX_XREG_1_ADDR 0x0020
#define TRNG4XX_XREG_2_ADDR 0x0024
#define TRNG4XX_LFSR1_L_ADDR 0x0028
#define TRNG4XX_LFSR1_H_ADDR 0x002C
#define TRNG4XX_LFSR2_L_ADDR 0x0030
#define TRNG4XX_LFSR2_H_ADDR 0x0034
#define TRNG4XX_KEY0_L_ADDR 0x0038
#define TRNG4XX_KEY0_H_ADDR 0x003C
#define TRNG4XX_KEY1_L_ADDR 0x0040
#define TRNG4XX_KEY1_H_ADDR 0x0044
#define TRNG4XX_IV_L_ADDR 0x0048
#define TRNG4XX_IV_H_ADDR 0x004C
struct hal_config;
/**
* @brief This function MUSTs be called to initialize the HW
* access function.
* @param amcc_hal_cfg HW access configuration. If NULL,
* default will be used.
* @return PPRO_RC_OK or PPRO_RC_FATAL
* @note To load all access functions from HAL with default initial
* map address, pass a NULL as its parameter.
* @n To load all access functions from HAL with default runtime
* map address, initialize an amcc_hal_config_t struct
* with valid HAL signature and set
* amcc_hal_config->flags |= PPRO_HAL_FLAG_LOADINIT;
*
*******************************************************************************
*/
int trng4xx_config_set(struct hal_config *cfg);
/**
* @brief This function MUSTs be called to de-initialize the HW
* access function.
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
int trng4xx_config_clear(void);
/**
* @brief This functions reads from the TRNG registers.
* @param reg_addr Device register offset
* @param data_val An DWORD pointer to store the returned value
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
inline int trng4xx_hw_read32(u32 reg_addr, u32 *data_val);
/**
* @brief This functions writes to the TRNG registers.
* @param reg_addr Device register offset
* @param data_val An DWORD value to write
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
inline int trng4xx_hw_write32(u32 reg_addr, u32 data_val);
/**
* @brief This functions initializes the TRNG for operation.
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
int trng4xx_hw_init(void);
/**
* @brief This functions de-initializes the TRNG.
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
int trng4xx_hw_deinit(void);
/**
* @brief This functions retrieves an true random number.
* @param rand_val A pointer to a DWORD to store the value
* @return PPRO_RC_OK if successfull. PPRO_RC_EINPROGRESS if failed. This
* should not happen as this means the hardware still busy.
*
*******************************************************************************
*/
int trng4xx_random(u32 *rand_val);
#endif
------------------------- DTS file ---------------
/*
* Device Tree Source for AMCC Canyonlands (460EX)
*
* Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
*
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without
* any warranty of any kind, whether express or implied.
*/
/ {
#address-cells = <2>;
#size-cells = <1>;
model = "amcc,canyonlands";
compatible = "amcc,canyonlands";
dcr-parent = <&/cpus/cpu@0>;
aliases {
ethernet0 = &EMAC0;
ethernet1 = &EMAC1;
serial0 = &UART0;
serial1 = &UART1;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
model = "PowerPC,460EX";
reg = <0>;
clock-frequency = <0>; /* Filled in by U-Boot */
timebase-frequency = <0>; /* Filled in by U-Boot */
i-cache-line-size = <20>;
d-cache-line-size = <20>;
i-cache-size = <8000>;
d-cache-size = <8000>;
dcr-controller;
dcr-access-method = "native";
};
};
memory {
device_type = "memory";
reg = <0 0 0>; /* Filled in by U-Boot */
};
UIC0: interrupt-controller0 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <0>;
dcr-reg = <0c0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
};
UIC1: interrupt-controller1 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <1>;
dcr-reg = <0d0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <1e 4 1f 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
UIC2: interrupt-controller2 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <2>;
dcr-reg = <0e0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <a 4 b 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
UIC3: interrupt-controller3 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <3>;
dcr-reg = <0f0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <10 4 11 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
SDR0: sdr {
compatible = "ibm,sdr-460ex";
dcr-reg = <00e 002>;
};
CPR0: cpr {
compatible = "ibm,cpr-460ex";
dcr-reg = <00c 002>;
};
L2C0: l2c {
compatible = "ibm,l2-cache-460ex", "ibm,l2-cache";
dcr-reg = <20 8 /* Internal SRAM DCR's */
30 8>; /* L2 cache DCR's */
cache-line-size = <20>; /* 32 bytes */
cache-size = <40000>; /* L2, 256K */
interrupt-parent = <&UIC2>;
interrupts = <17 1>;
};
plb {
compatible = "ibm,plb-460ex", "ibm,plb4";
#address-cells = <2>;
#size-cells = <1>;
ranges;
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: sdram {
compatible = "ibm,sdram-460ex", "ibm,sdram-405gp";
dcr-reg = <010 2>;
};
MAL0: mcmal {
compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
dcr-reg = <180 62>;
num-tx-chans = <2>;
num-rx-chans = <10>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-parent = <&UIC2>;
interrupts = < /*TXEOB*/ 6 4
/*RXEOB*/ 7 4
/*SERR*/ 3 4
/*TXDE*/ 4 4
/*RXDE*/ 5 4>;
};
USB0: ehci@bffd0400 {
compatible = "ibm,usb-ehci-460ex", "usb-ehci";
interrupt-parent = <&UIC2>;
interrupts = <1d 4>;
reg = <4 bffd0400 90 4 bffd0490 70>;
};
USB1: usb@bffd0000 {
compatible = "ohci-le";
reg = <4 bffd0000 60>;
interrupt-parent = <&UIC2>;
interrupts = <1e 4>;
};
USBOTG0: usbotg@bff80000 {
compatible = "amcc,usb-otg-460ex";
reg = <4 bff80000 10000>;
interrupt-parent = <&USBOTG0>;
interrupts = <0 1 2>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </* USB-OTG */ 0 &UIC2 1c 4
/* HIGH-POWER */ 1 &UIC1 1a 8
/* DMA */ 2 &UIC0 c 4>;
interrupt-map-mask = <ffffffff>;
};
CRYPTO: crypto@180000 {
compatible = "amcc,ppc460ex-crypto", "amcc,ppc4xx-crypto";
reg = <4 00180000 84000>;
interrupt-parent = <&UIC0>;
interrupts = <1d 4>;
};
TRNG: trng@110000 {
device_type = "trng";
compatible = "ppc4xx-trng", "amcc, ppc4xx-trng";
reg = <4 00110000 100>;
interrupt-parent = <&UIC1>;
interrupts = <3 2>;
};
PKA: pka@114000 {
device_type = "pka";
compatible = "ppc4xx-pka", "amcc, ppc4xx-pka";
reg = <4 00114000 4000>;
interrupt-parent = <&UIC0>;
interrupts = <14 2>;
};
POB0: opb {
compatible = "ibm,opb-460ex", "ibm,opb";
#address-cells = <1>;
#size-cells = <1>;
ranges = <b0000000 4 b0000000 50000000>;
clock-frequency = <0>; /* Filled in by U-Boot */
EBC0: ebc {
compatible = "ibm,ebc-460ex", "ibm,ebc";
dcr-reg = <012 2>;
#address-cells = <2>;
#size-cells = <1>;
clock-frequency = <0>; /* Filled in by U-Boot */
/* ranges property is supplied by U-Boot */
interrupts = <6 4>;
interrupt-parent = <&UIC1>;
nor_flash@0,0 {
compatible = "amd,s29gl512n", "cfi-flash";
bank-width = <2>;
reg = <0 000000 4000000>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "kernel";
reg = <0 1e0000>;
};
partition@1e0000 {
label = "dtb";
reg = <1e0000 20000>;
};
partition@200000 {
label = "ramdisk";
reg = <200000 1400000>;
};
partition@1600000 {
label = "jffs2";
reg = <1600000 400000>;
};
partition@1a00000 {
label = "user";
reg = <1a00000 2560000>;
};
partition@3f60000 {
label = "env";
reg = <3f60000 40000>;
};
partition@3fa0000 {
label = "u-boot";
reg = <3fa0000 60000>;
};
};
};
UART0: serial@ef600300 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600300 8>;
virtual-reg = <ef600300>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC1>;
interrupts = <1 4>;
};
UART1: serial@ef600400 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600400 8>;
virtual-reg = <ef600400>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC0>;
interrupts = <1 4>;
};
UART2: serial@ef600500 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600500 8>;
virtual-reg = <ef600500>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC1>;
interrupts = <1d 4>;
};
UART3: serial@ef600600 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600600 8>;
virtual-reg = <ef600600>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC1>;
interrupts = <1e 4>;
};
IIC0: i2c@ef600700 {
compatible = "ibm,iic-460ex", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
#address-cells = <1>;
#size-cells = <0>;
rtc@68 {
compatible = "stm,m41t80";
reg = <68>;
};
};
IIC1: i2c@ef600800 {
compatible = "ibm,iic-460ex", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
interrupts = <3 4>;
};
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-460ex", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601500 {
compatible = "ibm,rgmii-460ex", "ibm,rgmii";
reg = <ef601500 8>;
has-mdio;
};
TAH0: emac-tah@ef601350 {
compatible = "ibm,tah-460ex", "ibm,tah";
reg = <ef601350 30>;
};
TAH1: emac-tah@ef601450 {
compatible = "ibm,tah-460ex", "ibm,tah";
reg = <ef601450 30>;
};
EMAC0: ethernet@ef600e00 {
device_type = "network";
compatible = "ibm,emac-460ex", "ibm,emac4";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 10 4
/*Wake*/ 1 &UIC2 14 4>;
reg = <ef600e00 70>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
phy-map = <00000000>;
rgmii-device = <&RGMII0>;
rgmii-channel = <0>;
tah-device = <&TAH0>;
tah-channel = <0>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
EMAC1: ethernet@ef600f00 {
device_type = "network";
compatible = "ibm,emac-460ex", "ibm,emac4";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 11 4
/*Wake*/ 1 &UIC2 15 4>;
reg = <ef600f00 70>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
mal-rx-channel = <8>;
cell-index = <1>;
max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
phy-map = <00000000>;
rgmii-device = <&RGMII0>;
rgmii-channel = <1>;
tah-device = <&TAH1>;
tah-channel = <1>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
mdio-device = <&EMAC0>;
};
};
PCIX0: pci@c0ec00000 {
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
compatible = "ibm,plb-pcix-460ex", "ibm,plb-pcix";
primary;
large-inbound-windows;
enable-msi-hole;
reg = <c 0ec00000 8 /* Config space access */
0 0 0 /* no IACK cycles */
c 0ed00000 4 /* Special cycles */
c 0ec80000 100 /* Internal registers */
c 0ec80100 fc>; /* Internal messaging registers */
/* Outbound ranges, one memory and one IO,
* later cannot be changed
*/
ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
01000000 0 00000000 0000000c 08000000 0 00010000>;
/* Inbound 2GB range starting at 0 */
dma-ranges = <42000000 0 0 0 0 0 80000000>;
/* This drives busses 0 to 0x3f */
bus-range = <0 3f>;
/* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
interrupt-map-mask = <0000 0 0 0>;
interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
};
PCIE0: pciex@d00000000 {
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
primary;
port = <0>; /* port number */
reg = <d 00000000 20000000 /* Config space access */
c 08010000 00001000>; /* Registers */
dcr-reg = <100 020>;
sdr-base = <300>;
/* Outbound ranges, one memory and one IO,
* later cannot be changed
*/
ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
01000000 0 00000000 0000000f 80000000 0 00010000>;
/* Inbound 2GB range starting at 0 */
dma-ranges = <42000000 0 0 0 0 0 80000000>;
/* This drives busses 40 to 0x7f */
bus-range = <40 7f>;
/* Legacy interrupts (note the weird polarity, the bridge seems
* to invert PCIe legacy interrupts).
* We are de-swizzling here because the numbers are actually for
* port of the root complex virtual P2P bridge. But I want
* to avoid putting a node for it in the tree, so the numbers
* below are basically de-swizzled numbers.
* The real slot is on idsel 0, so the swizzling is 1:1
*/
interrupt-map-mask = <0000 0 0 7>;
interrupt-map = <
0000 0 0 1 &UIC3 c 4 /* swizzled int A */
0000 0 0 2 &UIC3 d 4 /* swizzled int B */
0000 0 0 3 &UIC3 e 4 /* swizzled int C */
0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
};
PCIE1: pciex@d20000000 {
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
primary;
port = <1>; /* port number */
reg = <d 20000000 20000000 /* Config space access */
c 08011000 00001000>; /* Registers */
dcr-reg = <120 020>;
sdr-base = <340>;
/* Outbound ranges, one memory and one IO,
* later cannot be changed
*/
ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
01000000 0 00000000 0000000f 80010000 0 00010000>;
/* Inbound 2GB range starting at 0 */
dma-ranges = <42000000 0 0 0 0 0 80000000>;
/* This drives busses 80 to 0xbf */
bus-range = <80 bf>;
/* Legacy interrupts (note the weird polarity, the bridge seems
* to invert PCIe legacy interrupts).
* We are de-swizzling here because the numbers are actually for
* port of the root complex virtual P2P bridge. But I want
* to avoid putting a node for it in the tree, so the numbers
* below are basically de-swizzled numbers.
* The real slot is on idsel 0, so the swizzling is 1:1
*/
interrupt-map-mask = <0000 0 0 7>;
interrupt-map = <
0000 0 0 1 &UIC3 10 4 /* swizzled int A */
0000 0 0 2 &UIC3 11 4 /* swizzled int B */
0000 0 0 3 &UIC3 12 4 /* swizzled int C */
0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
};
};
};
-------------------- Kconfig ----------
#
# Hardware Random Number Generator (RNG) configuration
#
config HW_RANDOM
tristate "Hardware Random Number Generator Core support"
default m
---help---
Hardware Random Number Generator Core infrastructure.
To compile this driver as a module, choose M here: the
module will be called rng-core. This provides a device
that's usually called /dev/hw_random, and which exposes one
of possibly several hardware random number generators.
These hardware random number generators do not feed directly
into the kernel's random number generator. That is usually
handled by the "rngd" daemon. Documentation/hw_random.txt
has more information.
If unsure, say Y.
config HW_RANDOM_INTEL
tristate "Intel HW Random Number Generator support"
depends on HW_RANDOM && (X86 || IA64) && PCI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on Intel i8xx-based motherboards.
To compile this driver as a module, choose M here: the
module will be called intel-rng.
If unsure, say Y.
config HW_RANDOM_AMD
tristate "AMD HW Random Number Generator support"
depends on HW_RANDOM && X86 && PCI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on AMD 76x-based motherboards.
To compile this driver as a module, choose M here: the
module will be called amd-rng.
If unsure, say Y.
config HW_RANDOM_GEODE
tristate "AMD Geode HW Random Number Generator support"
depends on HW_RANDOM && X86_32 && PCI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on the AMD Geode LX.
To compile this driver as a module, choose M here: the
module will be called geode-rng.
If unsure, say Y.
config HW_RANDOM_VIA
tristate "VIA HW Random Number Generator support"
depends on HW_RANDOM && X86_32
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on VIA based motherboards.
To compile this driver as a module, choose M here: the
module will be called via-rng.
If unsure, say Y.
config HW_RANDOM_IXP4XX
tristate "Intel IXP4xx NPU HW Random Number Generator support"
depends on HW_RANDOM && ARCH_IXP4XX
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random
Number Generator hardware found on the Intel IXP4xx NPU.
To compile this driver as a module, choose M here: the
module will be called ixp4xx-rng.
If unsure, say Y.
config HW_RANDOM_OMAP
tristate "OMAP Random Number Generator support"
depends on HW_RANDOM && (ARCH_OMAP16XX || ARCH_OMAP24XX)
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on OMAP16xx and OMAP24xx multimedia
processors.
To compile this driver as a module, choose M here: the
module will be called omap-rng.
If unsure, say Y.
config HW_RANDOM_PASEMI
tristate "PA Semi HW Random Number Generator support"
depends on HW_RANDOM && PPC_PASEMI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on PA Semi PWRficient SoCs.
To compile this driver as a module, choose M here: the
module will be called pasemi-rng.
If unsure, say Y.
config HW_RANDOM_TRNG4xx
tristate "AMCC 4xx TRNG True Random Number Generator support"
depends on HW_RANDOM && PPC
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on PA Semi PWRficient SoCs.
To compile this driver as a module, choose M here: the
module will be called pasemi-rng.
If unsure, say Y.
----------------------------------------Makefile --------------------
#
# Makefile for HW Random Number Generator (RNG) device drivers.
#
obj-$(CONFIG_HW_RANDOM) += rng-core.o
rng-core-y := core.o
obj-$(CONFIG_HW_RANDOM_INTEL) += intel-rng.o
obj-$(CONFIG_HW_RANDOM_AMD) += amd-rng.o
obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
obj-$(CONFIG_HW_RANDOM_TRNG4xx) += trng4xx.o
________________________________
From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org on behalf of Tirumala Reddy Marri
Sent: Wed 4/1/2009 10:05 AM
To: Felix Radensky; linuxppc-dev@ozlabs.org
Subject: RE: /dev/random on PPC40EXr
There is PKA/TRNG driver for sure. Let me check if it was accepted in
opensource yet. Otherwise I will forward you the driver which may not be
there in opensource yet.
-----Original Message-----
From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org] On Behalf Of
Felix Radensky
Sent: Wednesday, April 01, 2009 5:00 AM
To: linuxppc-dev@ozlabs.org
Subject: /dev/random on PPC40EXr
Hi,
On my custom board based on 405EXr /dev/random produces no output
at all, and /dev/urandom is not random enough for our purposes. Saving
entropy pool between reboots doesn't help much.
What can be done to increase the entropy of the system ?
I was thinking of adding IRQF_SAMPLE_RANDOM to network driver,
but since not too many drivers implement it, I don't know whether
it's a good idea or not.
Is there any work in progress to develop hw_random driver for 4xx
TRNG ?
Thanks a lot.
Felix.
--
View this message in context:
http://www.nabble.com/-dev-random-on-PPC40EXr-tp22824979p22824979.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #1.2: Type: text/html, Size: 44512 bytes --]
[-- Attachment #2: trng4xx.c --]
[-- Type: text/plain, Size: 9136 bytes --]
/*******************************************************************************
*
* Copyright (c) 2008 Loc Ho <lho@amcc.com>
*
* 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.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*
* Detail Description:
* This file defines ioctl structures for the Linux CryptoAPI interface. It
* provides user space applications accesss into the Linux CryptoAPI
* functionalities.
*
* @file trng4xx.c
*
* This file provides access to the AMCC PPC4XX TRNG for Linux.
*
*******************************************************************************
*/
#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/hw_random.h>
#include <linux/interrupt.h>
#include <asm/of_platform.h>
#include <asm/io.h>
#include "trng4xx.h"
#define TRNG4XX_VER_STR "0.1"
#define PFX KBUILD_MODNAME ": "
struct trng4xx_dev {
struct resource res;
u32 irq;
volatile char __iomem *csr;
struct semaphore access_prot;
u32 datum;
};
struct hal_config {
struct of_device *ofdev;
};
static struct trng4xx_dev trng4xx_dev;
static int trng4xx_irq_handler(int irq, void * id);
static void trng4xx_chk_overflow(void);
int trng4xx_config_set(struct hal_config *cfg)
{
struct device_node *rng_np = cfg->ofdev->node;
int rc = 0;
rc = of_address_to_resource(rng_np, 0, &trng4xx_dev.res);
if (rc)
return -ENODEV;
trng4xx_dev.csr = ioremap(trng4xx_dev.res.start,
trng4xx_dev.res.end - trng4xx_dev.res.start + 1);
if (trng4xx_dev.csr == NULL) {
printk(KERN_ERR PFX "unable to ioremap 0x%02X_%08X size %d\n",
(u32) (trng4xx_dev.res.start >> 32),
(u32) trng4xx_dev.res.start,
(u32) (trng4xx_dev.res.end - trng4xx_dev.res.start + 1));
return -ENOMEM;
}
#if 0
printk("TRNG1 0x%02X_%08X size %d\n",
(u32) (trng4xx_dev.res.start >> 32),
(u32) trng4xx_dev.res.start,
(u32) (trng4xx_dev.res.end - trng4xx_dev.res.start + 1));
#endif
trng4xx_dev.irq = of_irq_to_resource(rng_np, 0, NULL);
printk ("TRNG IRQ = %d\n",trng4xx_dev.irq);
if (trng4xx_dev.irq == NO_IRQ) {
/* Un-map CSR */
iounmap(trng4xx_dev.csr);
trng4xx_dev.csr = NULL;
return -EINVAL;
}
return 0;
}
int trng4xx_pka_config_clear(void)
{
iounmap(trng4xx_dev.csr);
return 0;
}
inline int trng4xx_hw_read32(u32 reg_addr, u32 *data_val)
{
*data_val = in_be32((volatile unsigned __iomem *)
(trng4xx_dev.csr + reg_addr));
return 0;
}
inline int trng4xx_hw_write32(u32 reg_addr, u32 data_val)
{
out_be32((volatile unsigned __iomem *) (trng4xx_dev.csr + reg_addr),
data_val);
return 0;
}
int trng4xx_hw_init(void)
{
int rc;
rc = request_irq(trng4xx_dev.irq, trng4xx_irq_handler,
0, "TRNG", NULL);
if (rc != 0) {
printk(KERN_ERR PFX "failed to register interrupt IRQ %d\n",
trng4xx_dev.irq);
return rc;
}
return 0;
}
int trng4xx_hw_deinit(void)
{
free_irq(trng4xx_dev.irq, NULL);
return 0;
}
static int trng4xx_irq_handler(int irq, void * id)
{
/* TRNG Alarm Counter overflow */
trng4xx_chk_overflow();
return 0;
}
/*******************************************************************************
* TRNG Functions
*******************************************************************************
*/
static void trng4xx_chk_overflow(void)
{
/* TRNG Alarm Counter overflow */
int rc;
u32 val;
struct trng4xx_cfg {
u32 ring1_delay_sel : 3;
u32 ring2_delay_sel : 3;
u32 reset_cnt : 6;
} __attribute__((packed));
rc = trng4xx_hw_write32(TRNG4XX_ALARMCNT_ADDR, val);
if (rc != 0)
return;
if (val > 128) {
struct trng4xx_cfg *trng4xx_cfg;
/* Alarm count is half, reset it */
rc = trng4xx_hw_read32(TRNG4XX_CFG_ADDR, &val);
if (rc != 0)
return;
trng4xx_cfg = (struct trng4xx_cfg *) &val;
++trng4xx_cfg->ring1_delay_sel;
trng4xx_cfg->ring2_delay_sel = (~trng4xx_cfg->ring1_delay_sel) & 0x07;
rc = trng4xx_hw_write32(TRNG4XX_CFG_ADDR, val);
if (rc != 0)
return;
trng4xx_hw_write32(TRNG4XX_ALARMCNT_ADDR, 0x00000000);
if (rc != 0)
return;
}
}
int trng4xx_random(u32 *rand_val)
{
u32 val = 0;
int rc;
#define MAX_TRY 3
u16 try_cnt = 0;
down(&trng4xx_dev.access_prot);
do {
rc = trng4xx_hw_read32(TRNG4XX_STATUS_ADDR, &val);
if (rc != 0)
goto err;
} while((val & TRNG4XX_STATUS_BUSY) && ++try_cnt <= MAX_TRY);
if (val & TRNG4XX_STATUS_BUSY) {
rc = -EINPROGRESS;
goto err;
}
rc = trng4xx_hw_read32(TRNG4XX_OUTPUT_ADDR, rand_val);
err:
//printk("status busy\n");
up(&trng4xx_dev.access_prot);
return rc;
}
EXPORT_SYMBOL_GPL(trng4xx_random);
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25)
static int trng4xx_data_present(struct hwrng *rng)
#else
static int trng4xx_data_present(struct hwrng *rng, int wait)
#endif
{
struct trng4xx_dev *dev = (struct trng4xx_dev *) rng->priv;
int i;
u32 val;
printk("inside %s:\n", __FUNCTION__);
down(&trng4xx_dev.access_prot);
/* We should not take more than 200??? us */
for (i = 0; i < 20; i++) {
trng4xx_hw_read32(TRNG4XX_STATUS_ADDR, &val);
if (!(val & TRNG4XX_STATUS_BUSY)) {
trng4xx_hw_read32(TRNG4XX_OUTPUT_ADDR, &dev->datum);
break;
}
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25)
break;
#else
if (!wait)
break;
udelay(10);
#endif
}
up(&trng4xx_dev.access_prot);
return (val & TRNG4XX_STATUS_BUSY) ? 0 : 1;
}
static int trng4xx_data_read(struct hwrng *rng, u32 *data)
{
struct trng4xx_dev *dev = (struct trng4xx_dev *) rng->priv;
*data = dev->datum;
printk("data read = %u\n", *data);
return 0;
}
static int trng4xx_init(struct hwrng *rng)
{
return trng4xx_hw_init();
}
static void trng4xx_cleanup(struct hwrng *rng)
{
trng4xx_hw_deinit();
}
static struct hwrng trng4xx_func = {
.name = "ppc4xx-trng",
.init = trng4xx_init,
.cleanup = trng4xx_cleanup,
.data_present = trng4xx_data_present,
.data_read = trng4xx_data_read,
.priv = (unsigned long) &trng4xx_dev,
};
/*******************************************************************************
*
* Setup Driver with platform registration
*
*******************************************************************************
*/
static int __devinit trng4xx_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
struct hal_config hw_cfg;
int rc;
u32 value, value2;
u32 ctrl_val, control_value;
hw_cfg.ofdev = ofdev;
rc = trng4xx_config_set(&hw_cfg);
if (rc != 0)
return rc;
#if 1
printk( "AMCC 4xx TRNG v%s @0x%02X_%08X size %d IRQ %d\n",
TRNG4XX_VER_STR,
(u32) (trng4xx_dev.res.start >> 32),
(u32) trng4xx_dev.res.start,
(u32) (trng4xx_dev.res.end - trng4xx_dev.res.start + 1),
trng4xx_dev.irq);
#endif
init_MUTEX(&trng4xx_dev.access_prot);
rc = hwrng_register(&trng4xx_func);
if (rc) {
printk(KERN_ERR PFX
"AMCC 4xx TRNG registering failed error %d\n", rc);
goto err;
}
trng4xx_hw_read32(TRNG4XX_CNTL_ADDR, &ctrl_val);
//printk ("cntl value = 0x%x\n", ctrl_val);
value = ctrl_val | TRNG4XX_CNTL_TST_ALARM;
//printk ("value to write = 0x%x\n", value);
/*rc = trng4xx_hw_write32(TRNG4XX_CNTL_ADDR, value);
if (rc != 0)
printk ("ERROR: writing\n");
trng4xx_hw_read32(TRNG4XX_CNTL_ADDR, &control_value);
printk ("control value = 0x%x\n", control_value);*/
/*value = 0;
printk ("checking random value register\n");
rc = trng4xx_random (&value);
printk ("checking random value register\n");
rc = trng4xx_random (&value2);*/
return rc;
err:
trng4xx_pka_config_clear();
return rc;
}
static int __devexit trng4xx_remove(struct of_device *dev)
{
hwrng_unregister(&trng4xx_func);
trng4xx_pka_config_clear();
return 0;
}
static struct of_device_id trng4xx_match[] = {
{ .compatible = "ppc4xx-trng", },
{ .compatible = "amcc,ppc4xx-trng", },
{ },
};
static struct of_platform_driver trng4xx_driver = {
.name = "ppc4xx-trng",
.match_table = trng4xx_match,
.probe = trng4xx_probe,
.remove = trng4xx_remove,
};
static int __init mod_init(void)
{
printk("entered mod_init\n");
return of_register_platform_driver(&trng4xx_driver);
}
static void __exit mod_exit(void)
{
of_unregister_platform_driver(&trng4xx_driver);
}
module_init(mod_init);
module_exit(mod_exit);
MODULE_DESCRIPTION("AMCC 4xx True Random Number Generator");
MODULE_LICENSE("GPL");
[-- Attachment #3: trng4xx.h --]
[-- Type: text/plain, Size: 6112 bytes --]
/*******************************************************************************
*
* Copyright (c) 2008 Loc Ho <lho@amcc.com>
*
* 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.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*
* Detail Description:
* This file defines ioctl structures for the Linux CryptoAPI interface. It
* provides user space applications accesss into the Linux CryptoAPI
* functionalities.
*
* @file trng4xx.h
*
* This file provides access to the AMCC SoC TRNG.
*
*******************************************************************************
*/
#ifndef __TRNG4XX_H__
#define __TRNG4XX_H__
/*******************************************************************************
* TRNG Register and bit Definitions
*******************************************************************************
*/
/* Register TRNG4XX_STATUS bit definition */
#define TRNG4XX_STATUS_BUSY 0x00000001
/* Register TRNG4XX_CNTL bit definition */
#define TRNG4XX_CNTL_TST_RING_OUT 0x00000001
#define TRNG4XX_CNTL_TST_MODE 0x00000002
#define TRNG4XX_CNTL_TST_RUN 0x00000004
#define TRNG4XX_CNTL_TST_EN1 0x00000008
#define TRNG4XX_CNTL_TST_EN2 0x00000010
#define TRNG4XX_CNTL_DISABLE_ALARM 0x00000020
#define TRNG4XX_CNTL_CLOCK_ON 0x00000040
#define TRNG4XX_CNTL_SHORT_CYCLE 0x00000080
#define TRNG4XX_CNTL_TST_ALARM 0x00000100
#define TRNG4XX_CNTL_TST_LFSR 0x00000200
#define TRNG4XX_CNTL_RESET_LFSR 0x00000400
#define TRNG4XX_CNTL_BYPASS_TRNG 0x00000800
#define TRNG4XX_CNTL_POST_PROC_EN 0x00001000
/* Register TRNG4XX_CFG bit definition */
#define TRNG4XX_CFG_RING1_DELAY_SEL_SHIFT 0
#define TRNG4XX_CFG_RING1_DELAY_SEL_MASK (7)
#define TRNG4XX_CFG_RING2_DELAY_SEL_SHIFT 3
#define TRNG4XX_CFG_RING2_DELAY_SEL_MASK (7 << TRNG4XX_CFG_RING2_DELAY_SEL_SHIFT)
#define TRNG4XX_CFG_RESET_CNT_SHIFT 6
#define TRNG4XX_CFG_RESET_CNT_SHIFT_MASK (0x3F << TRNG4XX_CFG_RING2_DELAY_SEL_SHIFT)
/* TRNG Register definition */
#define TRNG4XX_OUTPUT_ADDR 0x0000
#define TRNG4XX_STATUS_ADDR 0x0004
#define TRNG4XX_CNTL_ADDR 0x0008
#define TRNG4XX_CFG_ADDR 0x000C
#define TRNG4XX_ALARMCNT_ADDR 0x0010
#define TRNG4XX_AREG_ADDR 0x0014
#define TRNG4XX_BREG_ADDR 0x0018
#define TRNG4XX_XREG_0_ADDR 0x001C
#define TRNG4XX_XREG_1_ADDR 0x0020
#define TRNG4XX_XREG_2_ADDR 0x0024
#define TRNG4XX_LFSR1_L_ADDR 0x0028
#define TRNG4XX_LFSR1_H_ADDR 0x002C
#define TRNG4XX_LFSR2_L_ADDR 0x0030
#define TRNG4XX_LFSR2_H_ADDR 0x0034
#define TRNG4XX_KEY0_L_ADDR 0x0038
#define TRNG4XX_KEY0_H_ADDR 0x003C
#define TRNG4XX_KEY1_L_ADDR 0x0040
#define TRNG4XX_KEY1_H_ADDR 0x0044
#define TRNG4XX_IV_L_ADDR 0x0048
#define TRNG4XX_IV_H_ADDR 0x004C
struct hal_config;
/**
* @brief This function MUSTs be called to initialize the HW
* access function.
* @param amcc_hal_cfg HW access configuration. If NULL,
* default will be used.
* @return PPRO_RC_OK or PPRO_RC_FATAL
* @note To load all access functions from HAL with default initial
* map address, pass a NULL as its parameter.
* @n To load all access functions from HAL with default runtime
* map address, initialize an amcc_hal_config_t struct
* with valid HAL signature and set
* amcc_hal_config->flags |= PPRO_HAL_FLAG_LOADINIT;
*
*******************************************************************************
*/
int trng4xx_config_set(struct hal_config *cfg);
/**
* @brief This function MUSTs be called to de-initialize the HW
* access function.
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
int trng4xx_config_clear(void);
/**
* @brief This functions reads from the TRNG registers.
* @param reg_addr Device register offset
* @param data_val An DWORD pointer to store the returned value
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
inline int trng4xx_hw_read32(u32 reg_addr, u32 *data_val);
/**
* @brief This functions writes to the TRNG registers.
* @param reg_addr Device register offset
* @param data_val An DWORD value to write
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
inline int trng4xx_hw_write32(u32 reg_addr, u32 data_val);
/**
* @brief This functions initializes the TRNG for operation.
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
int trng4xx_hw_init(void);
/**
* @brief This functions de-initializes the TRNG.
* @return PPRO_RC_OK or PPRO_RC_FATAL
*
*******************************************************************************
*/
int trng4xx_hw_deinit(void);
/**
* @brief This functions retrieves an true random number.
* @param rand_val A pointer to a DWORD to store the value
* @return PPRO_RC_OK if successfull. PPRO_RC_EINPROGRESS if failed. This
* should not happen as this means the hardware still busy.
*
*******************************************************************************
*/
int trng4xx_random(u32 *rand_val);
#endif
[-- Attachment #4: canyonlands.dts --]
[-- Type: application/octet-stream, Size: 13219 bytes --]
/*
* Device Tree Source for AMCC Canyonlands (460EX)
*
* Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
*
* This file is licensed under the terms of the GNU General Public
* License version 2. This program is licensed "as is" without
* any warranty of any kind, whether express or implied.
*/
/ {
#address-cells = <2>;
#size-cells = <1>;
model = "amcc,canyonlands";
compatible = "amcc,canyonlands";
dcr-parent = <&/cpus/cpu@0>;
aliases {
ethernet0 = &EMAC0;
ethernet1 = &EMAC1;
serial0 = &UART0;
serial1 = &UART1;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
model = "PowerPC,460EX";
reg = <0>;
clock-frequency = <0>; /* Filled in by U-Boot */
timebase-frequency = <0>; /* Filled in by U-Boot */
i-cache-line-size = <20>;
d-cache-line-size = <20>;
i-cache-size = <8000>;
d-cache-size = <8000>;
dcr-controller;
dcr-access-method = "native";
};
};
memory {
device_type = "memory";
reg = <0 0 0>; /* Filled in by U-Boot */
};
UIC0: interrupt-controller0 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <0>;
dcr-reg = <0c0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
};
UIC1: interrupt-controller1 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <1>;
dcr-reg = <0d0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <1e 4 1f 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
UIC2: interrupt-controller2 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <2>;
dcr-reg = <0e0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <a 4 b 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
UIC3: interrupt-controller3 {
compatible = "ibm,uic-460ex","ibm,uic";
interrupt-controller;
cell-index = <3>;
dcr-reg = <0f0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <10 4 11 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
SDR0: sdr {
compatible = "ibm,sdr-460ex";
dcr-reg = <00e 002>;
};
CPR0: cpr {
compatible = "ibm,cpr-460ex";
dcr-reg = <00c 002>;
};
L2C0: l2c {
compatible = "ibm,l2-cache-460ex", "ibm,l2-cache";
dcr-reg = <20 8 /* Internal SRAM DCR's */
30 8>; /* L2 cache DCR's */
cache-line-size = <20>; /* 32 bytes */
cache-size = <40000>; /* L2, 256K */
interrupt-parent = <&UIC2>;
interrupts = <17 1>;
};
plb {
compatible = "ibm,plb-460ex", "ibm,plb4";
#address-cells = <2>;
#size-cells = <1>;
ranges;
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: sdram {
compatible = "ibm,sdram-460ex", "ibm,sdram-405gp";
dcr-reg = <010 2>;
};
MAL0: mcmal {
compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
dcr-reg = <180 62>;
num-tx-chans = <2>;
num-rx-chans = <10>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-parent = <&UIC2>;
interrupts = < /*TXEOB*/ 6 4
/*RXEOB*/ 7 4
/*SERR*/ 3 4
/*TXDE*/ 4 4
/*RXDE*/ 5 4>;
};
USB0: ehci@bffd0400 {
compatible = "ibm,usb-ehci-460ex", "usb-ehci";
interrupt-parent = <&UIC2>;
interrupts = <1d 4>;
reg = <4 bffd0400 90 4 bffd0490 70>;
};
USB1: usb@bffd0000 {
compatible = "ohci-le";
reg = <4 bffd0000 60>;
interrupt-parent = <&UIC2>;
interrupts = <1e 4>;
};
USBOTG0: usbotg@bff80000 {
compatible = "amcc,usb-otg-460ex";
reg = <4 bff80000 10000>;
interrupt-parent = <&USBOTG0>;
interrupts = <0 1 2>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </* USB-OTG */ 0 &UIC2 1c 4
/* HIGH-POWER */ 1 &UIC1 1a 8
/* DMA */ 2 &UIC0 c 4>;
interrupt-map-mask = <ffffffff>;
};
CRYPTO: crypto@180000 {
compatible = "amcc,ppc460ex-crypto", "amcc,ppc4xx-crypto";
reg = <4 00180000 84000>;
interrupt-parent = <&UIC0>;
interrupts = <1d 4>;
};
TRNG: trng@110000 {
device_type = "trng";
compatible = "ppc4xx-trng", "amcc, ppc4xx-trng";
reg = <4 00110000 100>;
interrupt-parent = <&UIC1>;
interrupts = <3 2>;
};
PKA: pka@114000 {
device_type = "pka";
compatible = "ppc4xx-pka", "amcc, ppc4xx-pka";
reg = <4 00114000 4000>;
interrupt-parent = <&UIC0>;
interrupts = <14 2>;
};
POB0: opb {
compatible = "ibm,opb-460ex", "ibm,opb";
#address-cells = <1>;
#size-cells = <1>;
ranges = <b0000000 4 b0000000 50000000>;
clock-frequency = <0>; /* Filled in by U-Boot */
EBC0: ebc {
compatible = "ibm,ebc-460ex", "ibm,ebc";
dcr-reg = <012 2>;
#address-cells = <2>;
#size-cells = <1>;
clock-frequency = <0>; /* Filled in by U-Boot */
/* ranges property is supplied by U-Boot */
interrupts = <6 4>;
interrupt-parent = <&UIC1>;
nor_flash@0,0 {
compatible = "amd,s29gl512n", "cfi-flash";
bank-width = <2>;
reg = <0 000000 4000000>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "kernel";
reg = <0 1e0000>;
};
partition@1e0000 {
label = "dtb";
reg = <1e0000 20000>;
};
partition@200000 {
label = "ramdisk";
reg = <200000 1400000>;
};
partition@1600000 {
label = "jffs2";
reg = <1600000 400000>;
};
partition@1a00000 {
label = "user";
reg = <1a00000 2560000>;
};
partition@3f60000 {
label = "env";
reg = <3f60000 40000>;
};
partition@3fa0000 {
label = "u-boot";
reg = <3fa0000 60000>;
};
};
};
UART0: serial@ef600300 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600300 8>;
virtual-reg = <ef600300>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC1>;
interrupts = <1 4>;
};
UART1: serial@ef600400 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600400 8>;
virtual-reg = <ef600400>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC0>;
interrupts = <1 4>;
};
UART2: serial@ef600500 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600500 8>;
virtual-reg = <ef600500>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC1>;
interrupts = <1d 4>;
};
UART3: serial@ef600600 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600600 8>;
virtual-reg = <ef600600>;
clock-frequency = <0>; /* Filled in by U-Boot */
current-speed = <0>; /* Filled in by U-Boot */
interrupt-parent = <&UIC1>;
interrupts = <1e 4>;
};
IIC0: i2c@ef600700 {
compatible = "ibm,iic-460ex", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
#address-cells = <1>;
#size-cells = <0>;
rtc@68 {
compatible = "stm,m41t80";
reg = <68>;
};
};
IIC1: i2c@ef600800 {
compatible = "ibm,iic-460ex", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
interrupts = <3 4>;
};
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-460ex", "ibm,zmii";
reg = <ef600d00 c>;
};
RGMII0: emac-rgmii@ef601500 {
compatible = "ibm,rgmii-460ex", "ibm,rgmii";
reg = <ef601500 8>;
has-mdio;
};
TAH0: emac-tah@ef601350 {
compatible = "ibm,tah-460ex", "ibm,tah";
reg = <ef601350 30>;
};
TAH1: emac-tah@ef601450 {
compatible = "ibm,tah-460ex", "ibm,tah";
reg = <ef601450 30>;
};
EMAC0: ethernet@ef600e00 {
device_type = "network";
compatible = "ibm,emac-460ex", "ibm,emac4";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 10 4
/*Wake*/ 1 &UIC2 14 4>;
reg = <ef600e00 70>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
phy-map = <00000000>;
rgmii-device = <&RGMII0>;
rgmii-channel = <0>;
tah-device = <&TAH0>;
tah-channel = <0>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
EMAC1: ethernet@ef600f00 {
device_type = "network";
compatible = "ibm,emac-460ex", "ibm,emac4";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 11 4
/*Wake*/ 1 &UIC2 15 4>;
reg = <ef600f00 70>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
mal-rx-channel = <8>;
cell-index = <1>;
max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
phy-map = <00000000>;
rgmii-device = <&RGMII0>;
rgmii-channel = <1>;
tah-device = <&TAH1>;
tah-channel = <1>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
mdio-device = <&EMAC0>;
};
};
PCIX0: pci@c0ec00000 {
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
compatible = "ibm,plb-pcix-460ex", "ibm,plb-pcix";
primary;
large-inbound-windows;
enable-msi-hole;
reg = <c 0ec00000 8 /* Config space access */
0 0 0 /* no IACK cycles */
c 0ed00000 4 /* Special cycles */
c 0ec80000 100 /* Internal registers */
c 0ec80100 fc>; /* Internal messaging registers */
/* Outbound ranges, one memory and one IO,
* later cannot be changed
*/
ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
01000000 0 00000000 0000000c 08000000 0 00010000>;
/* Inbound 2GB range starting at 0 */
dma-ranges = <42000000 0 0 0 0 0 80000000>;
/* This drives busses 0 to 0x3f */
bus-range = <0 3f>;
/* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
interrupt-map-mask = <0000 0 0 0>;
interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
};
PCIE0: pciex@d00000000 {
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
primary;
port = <0>; /* port number */
reg = <d 00000000 20000000 /* Config space access */
c 08010000 00001000>; /* Registers */
dcr-reg = <100 020>;
sdr-base = <300>;
/* Outbound ranges, one memory and one IO,
* later cannot be changed
*/
ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
01000000 0 00000000 0000000f 80000000 0 00010000>;
/* Inbound 2GB range starting at 0 */
dma-ranges = <42000000 0 0 0 0 0 80000000>;
/* This drives busses 40 to 0x7f */
bus-range = <40 7f>;
/* Legacy interrupts (note the weird polarity, the bridge seems
* to invert PCIe legacy interrupts).
* We are de-swizzling here because the numbers are actually for
* port of the root complex virtual P2P bridge. But I want
* to avoid putting a node for it in the tree, so the numbers
* below are basically de-swizzled numbers.
* The real slot is on idsel 0, so the swizzling is 1:1
*/
interrupt-map-mask = <0000 0 0 7>;
interrupt-map = <
0000 0 0 1 &UIC3 c 4 /* swizzled int A */
0000 0 0 2 &UIC3 d 4 /* swizzled int B */
0000 0 0 3 &UIC3 e 4 /* swizzled int C */
0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
};
PCIE1: pciex@d20000000 {
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
primary;
port = <1>; /* port number */
reg = <d 20000000 20000000 /* Config space access */
c 08011000 00001000>; /* Registers */
dcr-reg = <120 020>;
sdr-base = <340>;
/* Outbound ranges, one memory and one IO,
* later cannot be changed
*/
ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
01000000 0 00000000 0000000f 80010000 0 00010000>;
/* Inbound 2GB range starting at 0 */
dma-ranges = <42000000 0 0 0 0 0 80000000>;
/* This drives busses 80 to 0xbf */
bus-range = <80 bf>;
/* Legacy interrupts (note the weird polarity, the bridge seems
* to invert PCIe legacy interrupts).
* We are de-swizzling here because the numbers are actually for
* port of the root complex virtual P2P bridge. But I want
* to avoid putting a node for it in the tree, so the numbers
* below are basically de-swizzled numbers.
* The real slot is on idsel 0, so the swizzling is 1:1
*/
interrupt-map-mask = <0000 0 0 7>;
interrupt-map = <
0000 0 0 1 &UIC3 10 4 /* swizzled int A */
0000 0 0 2 &UIC3 11 4 /* swizzled int B */
0000 0 0 3 &UIC3 12 4 /* swizzled int C */
0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
};
};
};
[-- Attachment #5: Kconfig --]
[-- Type: text/plain, Size: 3819 bytes --]
#
# Hardware Random Number Generator (RNG) configuration
#
config HW_RANDOM
tristate "Hardware Random Number Generator Core support"
default m
---help---
Hardware Random Number Generator Core infrastructure.
To compile this driver as a module, choose M here: the
module will be called rng-core. This provides a device
that's usually called /dev/hw_random, and which exposes one
of possibly several hardware random number generators.
These hardware random number generators do not feed directly
into the kernel's random number generator. That is usually
handled by the "rngd" daemon. Documentation/hw_random.txt
has more information.
If unsure, say Y.
config HW_RANDOM_INTEL
tristate "Intel HW Random Number Generator support"
depends on HW_RANDOM && (X86 || IA64) && PCI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on Intel i8xx-based motherboards.
To compile this driver as a module, choose M here: the
module will be called intel-rng.
If unsure, say Y.
config HW_RANDOM_AMD
tristate "AMD HW Random Number Generator support"
depends on HW_RANDOM && X86 && PCI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on AMD 76x-based motherboards.
To compile this driver as a module, choose M here: the
module will be called amd-rng.
If unsure, say Y.
config HW_RANDOM_GEODE
tristate "AMD Geode HW Random Number Generator support"
depends on HW_RANDOM && X86_32 && PCI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on the AMD Geode LX.
To compile this driver as a module, choose M here: the
module will be called geode-rng.
If unsure, say Y.
config HW_RANDOM_VIA
tristate "VIA HW Random Number Generator support"
depends on HW_RANDOM && X86_32
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on VIA based motherboards.
To compile this driver as a module, choose M here: the
module will be called via-rng.
If unsure, say Y.
config HW_RANDOM_IXP4XX
tristate "Intel IXP4xx NPU HW Random Number Generator support"
depends on HW_RANDOM && ARCH_IXP4XX
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random
Number Generator hardware found on the Intel IXP4xx NPU.
To compile this driver as a module, choose M here: the
module will be called ixp4xx-rng.
If unsure, say Y.
config HW_RANDOM_OMAP
tristate "OMAP Random Number Generator support"
depends on HW_RANDOM && (ARCH_OMAP16XX || ARCH_OMAP24XX)
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on OMAP16xx and OMAP24xx multimedia
processors.
To compile this driver as a module, choose M here: the
module will be called omap-rng.
If unsure, say Y.
config HW_RANDOM_PASEMI
tristate "PA Semi HW Random Number Generator support"
depends on HW_RANDOM && PPC_PASEMI
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on PA Semi PWRficient SoCs.
To compile this driver as a module, choose M here: the
module will be called pasemi-rng.
If unsure, say Y.
config HW_RANDOM_TRNG4xx
tristate "AMCC 4xx TRNG True Random Number Generator support"
depends on HW_RANDOM && PPC
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on PA Semi PWRficient SoCs.
To compile this driver as a module, choose M here: the
module will be called pasemi-rng.
If unsure, say Y.
[-- Attachment #6: Makefile --]
[-- Type: text/plain, Size: 482 bytes --]
#
# Makefile for HW Random Number Generator (RNG) device drivers.
#
obj-$(CONFIG_HW_RANDOM) += rng-core.o
rng-core-y := core.o
obj-$(CONFIG_HW_RANDOM_INTEL) += intel-rng.o
obj-$(CONFIG_HW_RANDOM_AMD) += amd-rng.o
obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
obj-$(CONFIG_HW_RANDOM_TRNG4xx) += trng4xx.o
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-04-02 6:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <D7365D0C-57B0-479C-9335-265620B8E5AE@kernel.crashing.org>
Hi Kumar,
Kumar Gala wrote:
>
> On Apr 1, 2009, at 8:10 AM, Wolfgang Grandegger wrote:
>
>> Grant Likely wrote:
>>> On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger
>>> <wg@grandegger.com> wrote:
>>>> Anton Vorontsov wrote:
>>>>> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
>>>>> [...]
>>>>>>>>>>> + soc8544@e0000000 {
>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>> + #size-cells = <1>;
>>>>>>>>>>> + device_type = "soc";
>>>>>>>>>> Drop device_type here too.
>>>>>>>>> Grrr, I just realized that removing the devices type "soc" has
>>>>>>>>> broken
>>>>>>>>> fsl_get_sys_freq(). See:
>>>>>>>>>
>>>>>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We need a quick fix and we could take the occasion to establish
>>>>>>>>> a common
>>>>>>>>> function for the MPC52xx as well, but it's not obvious to me
>>>>>>>>> how to find
>>>>>>>>> the SOC node without the device type property.
>>>>>>>> SoC node should have a compatible property, just like everything
>>>>>>>> else.
>>>>>>>>
>>>>>>>> compatible = "fsl,mpc8544-immr"; (immr == Internally Memory
>>>>>>>> Mapped Registers)
>>>>>>>>
>>>>>>>> Many other boards already do this.
>>>>>>> Yes, it does, but searching for the SOC node is not straight-forward
>>>>>>> because there is no common compatibility string but many
>>>>>>> CPU-specific
>>>>>>> compatibility strings, e.g. "fsl,mpc8560-immr", etc. Have I missed
>>>>>>> something?
>>>>>> Choose a new value ("fsl,mpc-immr" perhaps?), document exactly
>>>>>> what it
>>>>>> means, and add add it to the end of the compatible list.
>>>>> As Scott Wood once pointed out, IMMR does not exists for MPC85xx
>>>>> parts. There it's called CCSR.
>>>>>
>>>>> See this thread:
>>>>>
>>>>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
>>>>>
>>>>> I still think that
>>>>> "fsl,mpc83NN-immr", "fsl,soc", "simple-bus" for 83xx
>>>>> and
>>>>> "fsl,mpc85NN-ccsr", "fsl,soc", "simple-bus" for 85xx
>>>>>
>>>>> would be OK, at least to start with. We can always deprecate "fsl,soc"
>>>>> compatible in favour of something more elegant, but "fsl,soc"
>>>>> should be
>>>>> just fine to replace device_type = "soc".
>>>>>
>>>>> Also, there is another good thing about "fsl,soc" -- U-Boot already
>>>>> finds it for 83xx CPUs. ;-)
>>>> Ugh! I just realize the full impact of removing device type "soc". It
>>>> will break compatibility with U-Boot for many boards. Is it worth it?
>>>
>>> Yes, I know this. I'm not asking you to fix all the other boards, but
>>> make sure that it is not required for the new board.
>>
>> Hm, I'm confused, if we want to fix this issue we need first to
>>
>> - fix all functions in fsl_soc.c searching for the compatible string
>> "fsl,soc" instead of the device type "soc" (or both for backward
>> compatibility).
>>
>> - fix U-Boot to find the SOC node by looking for "fsl,soc" to insert the
>> proper bus-frequency, at least.
>>
>> That affects *all* boards using CONFIG_FSL_SOC and requires an
>> up-to-date version of U-Boot for new kernels :-(. If that is fixed, I
>> can remove the "device_type = "soc";" from socrates.dts (and may more),
>> but not right now. Or have I missed something?
>
> I presume the intent is not to break old u-boots w/new kernels, but to
> make it so new .dts don't require device_type = soc in them if using new
> kernels.
Socrates is a new board and it has no problem using an up-to-date
version of U-Boot. The socrates.dts file in your "next" tree already has
the "device_type = "soc" removed. We need to add "fsl,soc" to the
"compatible" property and update fsl_get_sys_freq(), etc. to search for
it as well. And U-Boot should use the same name to fixup the
frequencies. Are you already working on that issue? Should I provide
patches?
Wolfgang.
^ permalink raw reply
* Help with interrupts = <...> section of dtb file
From: Subodh Nijsure @ 2009-04-02 6:31 UTC (permalink / raw)
To: linuxppc-dev
SGVsbG8sCgpJIG5lZWQgc29tZSBoZWxwIGluIHVuZGVyc3RhbmRpbmcgdGhlIGludGVycnVwdHMg
PSA8Li4uPiBzZWN0aW9uIG9mIERUQiBmaWxlLgoKSSBoYXZlIHJlYWQgdGhlIERvY3VtZW50YXRp
b24vYm9vdGluZy13aXRob3V0LW9mLnR4dMKgIGFuZCBJIHVuZGVyc3RhbmQKdGhhdCBpbnRlcnJ1
cHRzID0gPEEgQj4gbWVhbnMgaW50ZXJydXB0IEEgYW5kIEIgaXMgImVudW0iIHRoYXQKaW5kaWNh
dGVzIGlmIGl0cyBhbiBlZGdlIG9yIGxldmVsIGludGVycnVwdC4KCkkgbmVlZCBiaXQgb2YgaGVs
cCBpbiBwYXJzaW5nIHRoZSBkZXNjcmlwdGlvbiBiZWxvdzoKCsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCBlbmV0MDogZXRoZXJuZXRAMjQwMDAgewoKwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjZWxsLWluZGV4ID0gPDA+OwoKwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkZXZpY2VfdHlwZSA9ICJuZXR3b3Jr
IjsKCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbW9kZWwg
PSAiZVRTRUMiOwoKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCBjb21wYXRpYmxlID0gImdpYW5mYXIiOwoKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCByZWcgPSA8MHgyNDAwMCAweDEwMDA+OwoKwqDCoMKgwqDCoMKgwqDC
oCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBsb2NhbC1tYWMtYWRkcmVzcyA9IFsgMDAg
MDAgMDAgMDAgMDAgMDAgXTsKCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgaW50ZXJydXB0cyA9IDwyOSAyIDMwIDIgMzQgMj47CgrCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGludGVycnVwdC1wYXJlbnQgPSA8Jm1waWM+
OwoKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwaHktaGFu
ZGxlID0gPCZwaHkwPjsKCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgcGh5LWNvbm5lY3Rpb24tdHlwZSA9ICJzZ21paSI7CgrCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgfTsKCklmIEkgZm9sbG93IHRoZSBpbnRlcnJ1cHRzIGRlc2NyaXB0aW9uIGFy
ZSB3ZSBzYXlpbmcgdGhhdCB0aGlzIGVUU0VDMQpvbiB0aGUgYm9hcmQgd2lsbCBnZW5lcmF0ZSBp
bnRlcnJ1cHQgMjksIDMwICYgMzQ/IFNob3VsZCBzZWUgdGhlbSBhcwpyZWdpc3RlcmVkIGludGVy
cnVwdHMgaW4gL3Byb2MvaW50ZXJydXB0PwoKSSB3b3VsZCByZWFsbHkgYXBwcmVjaWF0ZSBhbnkg
ZXhwbGFuYXRpb24gb3IgbGlua3MgdGhhdCBtaWdodCBleHBsYWluIHRoaXMuCgpSZWdhcmRzLAov
U3Vib2RoIE5panN1cmUK
^ permalink raw reply
* Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-04-02 6:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <fa686aa40904010655i73819214m795939e784889267@mail.gmail.com>
Grant Likely wrote:
> On Wed, Apr 1, 2009 at 7:41 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Grant Likely wrote:
>>> On Wed, Apr 1, 2009 at 1:51 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>>> Grant Likely wrote:
>>>>> The table definition is more verbose this way, but I think it results
>>>>> in more understandable and easier to extend code. It also adds lets
>>>>> the compiler do more type checking for you.
>>>> OK but I don't like the callback function to do the settings. We need
>>>> backward compatibility with old DTS files including the ugly "dfsrr"
>>>> property, right? Then it seems consequent to continue using i2c->flags
>>>> for that purpose and not to introduce another method. If we don't need
>>>> backward compatibility, we could drop the flags completely and just use
>>>> callback functions.
>>> I don't understand why you don't like it. It's an elegant solution
>>> and it simplifies the code somewhat. After grabbing the callback
>>> pointer the compatibility code can simply override it. But I won't
>>> belabor the point or oppose the patch if you stick with the flags
>>> pointer.
>> I changed my mind ;-). Have a look to PATCH v2 I sent out a few minutes ago.
>
> I saw and I like. :-)
>
>>> I've been thinking about this more. These tables are only ever going
>>> to be used by the i2c_mpc driver and so really they are a part of the
>>> i2c_mpc driver itself. Putting them into common code doesn't make any
>>> sense because it is not common code. I will not merge a patch that
>>> puts them into mpc5200 common code.
>> It's not common code, I agree. How about putting it into mpc52xx_i2c.c
>> and use:
>>
>> $ cat Makefile
>> obj-$(CONFIG_I2C_MPC) += mpc52xx_i2c.o
>>
>> Or it could be moved back to the i2c_mpc driver and we add stubs for the
>> functions to get the bus frequency, or use #ifdef's.
>
> I'm happy with either as long as it lives in the same directory as the
> i2c_mpc driver, and as long as the i2c maintainers are okay with it.
Ben, any preference here? See also below.
> Oh, and if you use a separate file it should be statically linked into
> the i2c_mpc module using the i2c_mpc-$(CONFIG_WHATEVER) trick. No
> EXPORT_SYMBOLS should be needed.
Yep, then we would have in "drivers/i2c/busses/Makefile"
obj-$(CONFIG_I2C_MPC) += i2c-mpc.o
i2c-mpc-y = i2c-mpc.o
i2c-mpc-$(CONFIG_FSL_SOC) += i2c-mpc-8xxx.o
i2c-mpc-$(CONFIG_PPC_52xx) += i2c-mpc-52xx.o
And a common include file i2c-mpc.h including the stubs for the arch
dependent functions. But we may get in trouble when we need support for
the MPC512x. I currently tend to add the FDR related code to an extra
file i2c-mpc-fdr.c, plus i2c-mpc.h and use the good old #ifdef's to
select the relevant code.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v2] Fix highmem build failure
From: Akinobu Mita @ 2009-04-02 7:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <1238647129-27417-1-git-send-email-galak@kernel.crashing.org>
Looks good. I tested it on x86_32.
^ permalink raw reply
* RE: USB drivers
From: Li Yang-R58472 @ 2009-04-02 7:03 UTC (permalink / raw)
To: ron_madrid, linuxppc-dev
In-Reply-To: <722080.36173.qm@web83502.mail.sp1.yahoo.com>
> I have a custom board based on the MPC8313ERDB and have=20
> communications capabilities over Ethernet using internet=20
> sockets. Basically, just data transfer from the host (my=20
> board) to a client (a PC). I want to be able to perform=20
> similar transactions across USB.
>=20
> I have done some cursory reading but am a little unclear on=20
> how I should approach this. Am I going to have to write a=20
> host driver for my custom board, and also write a gadget=20
> driver for any client machine? Also, since I am desiring to=20
> do simple data transfers only, which drivers could I use as a=20
> point of reference for my application?
>=20
> Thanks in advance for any tips and suggestions.
Linux has a g_ether gadget, which can simulate a ethernet tunnal over
USB. If you already have the communication code through ethernet, it
will be easier to make use of that gadget. However, it has more
overhead than pure usb transactions. The best way is like you said,
custom gadget driver and host driver.
- Leo
^ permalink raw reply
* Re: Help with interrupts = <...> section of dtb file
From: Subodh Nijsure @ 2009-04-02 7:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <2d43f95a0904012331u2cae68ft33ace018366b8f1@mail.gmail.com>
T24gV2VkLCBBcHIgMSwgMjAwOSBhdCAxMTozMSBQTSwgU3Vib2RoIE5panN1cmUKPHN1Ym9kaC5u
aWpzdXJlQGdtYWlsLmNvbT4gd3JvdGU6Cj4gSGVsbG8sCj4KPiBJIG5lZWQgc29tZSBoZWxwIGlu
IHVuZGVyc3RhbmRpbmcgdGhlIGludGVycnVwdHMgPSA8Li4uPiBzZWN0aW9uIG9mIERUQiBmaWxl
Lgo+Cj4gSSBoYXZlIHJlYWQgdGhlIERvY3VtZW50YXRpb24vYm9vdGluZy13aXRob3V0LW9mLnR4
dMKgIGFuZCBJIHVuZGVyc3RhbmQKPiB0aGF0IGludGVycnVwdHMgPSA8QSBCPiBtZWFucyBpbnRl
cnJ1cHQgQSBhbmQgQiBpcyAiZW51bSIgdGhhdAo+IGluZGljYXRlcyBpZiBpdHMgYW4gZWRnZSBv
ciBsZXZlbCBpbnRlcnJ1cHQuCj4KPiBJIG5lZWQgYml0IG9mIGhlbHAgaW4gcGFyc2luZyB0aGUg
ZGVzY3JpcHRpb24gYmVsb3c6Cj4KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZW5l
dDA6IGV0aGVybmV0QDI0MDAwIHsKPgo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgY2VsbC1pbmRleCA9IDwwPjsKPgo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZGV2aWNlX3R5cGUgPSAibmV0d29yayI7Cj4KPiDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG1vZGVsID0gImVU
U0VDIjsKPgo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
Y29tcGF0aWJsZSA9ICJnaWFuZmFyIjsKPgo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgcmVnID0gPDB4MjQwMDAgMHgxMDAwPjsKPgo+IMKgwqDCoMKgwqDC
oMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgbG9jYWwtbWFjLWFkZHJlc3MgPSBb
IDAwIDAwIDAwIDAwIDAwIDAwIF07Cj4KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIGludGVycnVwdHMgPSA8MjkgMiAzMCAyIDM0IDI+Owo+Cj4gwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpbnRlcnJ1cHQtcGFyZW50
ID0gPCZtcGljPjsKPgo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgcGh5LWhhbmRsZSA9IDwmcGh5MD47Cj4KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHBoeS1jb25uZWN0aW9uLXR5cGUgPSAic2dtaWkiOwo+Cj4g
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH07Cj4KPiBJZiBJIGZvbGxvdyB0aGUgaW50
ZXJydXB0cyBkZXNjcmlwdGlvbiBhcmUgd2Ugc2F5aW5nIHRoYXQgdGhpcyBlVFNFQzEKPiBvbiB0
aGUgYm9hcmQgd2lsbCBnZW5lcmF0ZSBpbnRlcnJ1cHQgMjksIDMwICYgMzQ/IFNob3VsZCBzZWUg
dGhlbSBhcwo+IHJlZ2lzdGVyZWQgaW50ZXJydXB0cyBpbiAvcHJvYy9pbnRlcnJ1cHQ/Cj4KCkFw
b2xvZ2llcyBhYm91dCB0aGlzIC0tCgphIGR1aCBtb21lbnQuICBldGgwIHdhcyBtYXJrZWQgYXMg
ZG93biBvbmNlIEkgYnJvdWdodCBpdCB1cCBJIGRvIHNlZQp0aG9zZSBpbnRlcnJ1cHRzIHJlZ2lz
dGVyZWQuLi4KCmNhdCAvcHJvYy9pbnRlcnJ1cHRzCiAgICAgICAgICAgQ1BVMCAgICAgICBDUFUx
CiAyOTogICAgICAgICAgMCAgICAgICAgICAwICAgT3BlblBJQyAgIExldmVsICAgICBlbmV0X3R4
CiAzMDogICAgICAgICAgMCAgICAgICAgICAwICAgT3BlblBJQyAgIExldmVsICAgICBlbmV0X3J4
CiAzNDogICAgICAgICAgMCAgICAgICAgICAwICAgT3BlblBJQyAgIExldmVsICAgICBlbmV0X2Vy
cm9yCgoKL1N1Ym9kaAo=
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Geert Uytterhoeven @ 2009-04-02 7:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Cell Broadband Engine OSS Development,
Arnd Bergmann
In-Reply-To: <1238583750.17330.125.camel@pasglop>
On Wed, 1 Apr 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote:
> > On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
> > > On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote:
> > > > PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI,
> > > > causing build failures if PCI is not set.
> > >
> > > Maybe it should only select it if PCI is enabled ? Is qpace using PCI ?
> >
> > No, QPACE does not have any PCI devices whatsoever.
>
> so something like select PPC_OF_PLATFORM_PCI if PCI would work you
> think ?
I gave it a try. Patch below.
But that is still not sufficient:
| arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to `pci_io_base'
due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
shouldn't be built when CONFIG_PCI=n?
As I don't have the hardware to test anyway, I'll give up.
diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
index 40e24c3..fa604b1 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -13,7 +13,7 @@ config PPC_CELL_COMMON
config PPC_CELL_NATIVE
bool
select PPC_CELL_COMMON
- select PPC_OF_PLATFORM_PCI
+ select PPC_OF_PLATFORM_PCI if PCI
select MPIC
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index 5930536..628b21f 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -81,6 +81,7 @@ static void cell_progress(char *s, unsigned short hex)
printk("*** %04x : %s\n", hex, s ? s : "");
}
+#ifdef CONFIG_PCI
static void cell_fixup_pcie_rootcomplex(struct pci_dev *dev)
{
struct pci_controller *hose;
@@ -141,6 +142,7 @@ static int __devinit cell_setup_phb(struct pci_controller *phb)
return 0;
}
+#endif /* CONFIG_PCI */
static int __init cell_publish_devices(void)
{
@@ -287,5 +289,7 @@ define_machine(cell) {
.calibrate_decr = generic_calibrate_decr,
.progress = cell_progress,
.init_IRQ = cell_init_irq,
+#ifdef CONFIG_PCI
.pci_setup_phb = cell_setup_phb,
+#endif
};
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply related
* Re: [PATCH 0/3] Series short description
From: David Miller @ 2009-04-02 7:57 UTC (permalink / raw)
To: grant.likely; +Cc: netdev, linuxppc-dev
In-Reply-To: <20090401060117.8641.32252.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Wed, 01 Apr 2009 00:16:46 -0600
> Here are the fec_mpc52xx patches which should be picked up for 2.6.29.
> Patch #1 fixes a dma related BUG_ON() discovered after the merge window
> opened. #2 & #3 were original a single patch posted prior to the merge
> window, but not having a s-o-b line from the original author held them up.
> In the end I rewrote it from scratch as two patches just so I can get
> them merged. #2 makes the driver use net_device_ops, and #3 fixes a NULL
> dereference.
>
> I've tested these patches on several MPC5200 platforms.
All applied, thanks Grant.
^ permalink raw reply
* Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
From: Michael Ellerman @ 2009-04-02 8:04 UTC (permalink / raw)
To: Chris Friesen; +Cc: peterz, linuxppc-dev, linux-kernel
In-Reply-To: <49D3F662.4050100@nortel.com>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> Resending due to lack of response to original post.
Hi Chris,
You'll probably get a more useful response on lkml. You CC'ed
linux-kernel-owner originally :)
> I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and
> was surprised when it failed. It turns out that at least on my ppc64 G5
> machine the offset value for the last entry is strange--it shows up as a
> 64-bit value even though the process itself is only 32-bit.
>
> This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I
> haven't yet tested anything else in between.
>
> [cfriesen@localhost cfriesen]$ cat /proc/self/maps
> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> 0fe70000-0ffbf000 r-xp 00000000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc0000-0ffc2000 r--p 00150000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
> 0ffd0000-0ffec000 r-xp 00000000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff0000-0fff1000 r--p 00020000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so
> 10000000-10004000 r-xp 00000000 08:03 917536 /bin/cat
> 10013000-10015000 rwxp 00003000 08:03 917536 /bin/cat
> 10015000-10036000 rwxp 10015000 00:00 0 [heap]
> f7deb000-f7feb000 r--p 00000000 08:03 2560322
> /usr/lib/locale/locale-archive
> f7feb000-f7fec000 rw-p f7feb000 00:00 0
> ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
>
> I'm at a loss to explain what's going on here. Anyone got any ideas?
It looks like for vmas that don't have a vm_file (like the stack),
vm_pgoff is basically "internal use" - and so can be > 32 bit.
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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