* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Albrecht Dreß @ 2010-07-08 20:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: David Woodhouse, Steve Deiters, linuxppc-dev
In-Reply-To: <DC489835-1F97-49DA-A00C-7D73D0EC0900@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
Am 08.07.10 21:30 schrieb(en) Segher Boessenkool:
>> Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept?
>
> There already is "device-width"; the drivers never should use any other access width unless they *know* that will work.
Hmm, unfortunately, it's usage is not clearly documented in mtd-physmap.txt, so I never thought of this parameter. And IMHO the problem goes further - basically *any* chip which is attached to the LPB can be affected by this problem, so it might be better to have a more general approach like a "chip select property".
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Scott Wood @ 2010-07-08 20:09 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Albrecht Dreß, Steve Deiters, linuxppc-dev, David Woodhouse
In-Reply-To: <DC489835-1F97-49DA-A00C-7D73D0EC0900@kernel.crashing.org>
On Thu, 8 Jul 2010 21:30:33 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > Actually, this is something which might need closer attention -
> > and maybe some support in the device tree indicating which read or
> > write width a device can accept?
>
> There already is "device-width"; the drivers never should use any
> other access width unless they *know* that will work.
Wouldn't you want to use "bank-width" instead? "device-width" might
not even work if, say, you've got two 8-bit chips interleaved, feeding
into a bus controller in 16-bit mode that only accepts 16-bit accesses.
It would be nice to have a device tree property that can specify that
all access widths supported by the CPU will work, though.
-Scott
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Marc Chidester @ 2010-07-08 19:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Lee Nipper
In-Reply-To: <20100708182455.GC28969@zod.rchland.ibm.com>
On Thu, Jul 8, 2010 at 2:24 PM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wro=
te:
> On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>> It looks like the Rev D version of the 405EX chip without security
>>> will be identified as a 405EXr, based on the values in the cpu_specs
>>> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
>>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>>> Rev D PVR value for the 405EX without security is 0x12911473, which
>>> would mask out to the EXr value.
>>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>With 405EX Rev D, we have noticed that we must reset our board
>>one time after the initial powerup to make the PVR read correctly.
>>
>>See this post:
>>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
>
> That is very very weird. =A0Have you seen that behavior on multiple Rev D=
CPUs
> or just one board or?
>
> The PVR value should never change, so if you have odd behavior I wonder i=
f the
> are silicon bugs in that revision. =A0Did you happen to ask AMCC about it=
?
>
> josh
>
Check the recent Errata for the chip on this issue.
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Segher Boessenkool @ 2010-07-08 19:30 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev, Steve Deiters, David Woodhouse
In-Reply-To: <1278614421.1801.0@antares>
> Actually, this is something which might need closer attention - and
> maybe some support in the device tree indicating which read or
> write width a device can accept?
There already is "device-width"; the drivers never should use any other
access width unless they *know* that will work.
Segher
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Lee Nipper @ 2010-07-08 19:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20100708182210.GB28969@zod.rchland.ibm.com>
On Thu, Jul 8, 2010 at 13:22, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote=
:
> On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
>>pvr_mask =3D 0xffff000f =A0?
>
> Have you tried that in a locally modified kernel? =A0If so, did it work? =
=A0If so,
> care to submit a patch? :)
>
I have not yet. I will prepare a patch.
Lee
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Lee Nipper @ 2010-07-08 18:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20100708182455.GC28969@zod.rchland.ibm.com>
On Thu, Jul 8, 2010 at 13:24, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote=
:
> On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>> It looks like the Rev D version of the 405EX chip without security
>>> will be identified as a 405EXr, based on the values in the cpu_specs
>>> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
>>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>>> Rev D PVR value for the 405EX without security is 0x12911473, which
>>> would mask out to the EXr value.
>>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>With 405EX Rev D, we have noticed that we must reset our board
>>one time after the initial powerup to make the PVR read correctly.
>>
>>See this post:
>>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
>
> That is very very weird. =A0Have you seen that behavior on multiple Rev D=
CPUs
> or just one board or?
>
Multiple Rev D CPUs. In fact, ALL of the samples we obtained behave this w=
ay.
> The PVR value should never change, so if you have odd behavior I wonder i=
f the
> are silicon bugs in that revision. =A0Did you happen to ask AMCC about it=
?
>
Yes, I did.
AMCC suggested doing an early one-time s/w reset to make the PVR read
"correctly" afterwards.
Since we only support one specific 405EX variety, we could do that.
However, on a generic u-boot, there is no way to know if a "correct"
PVR is read,
so that approach is not a solution.
I'm wondering if our power on reset circuitry is not entirely correct,
and it showed up with the Rev D part. I received no comments on my
original post
from other users of the 405EX, so I'm thinking it is a possible explanation=
.
Does anyone have a board with a 405EX Rev D ?
If so, does the PVR value match your processor chip after power up ?
Lee
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Albrecht Dreß @ 2010-07-08 18:40 UTC (permalink / raw)
To: Grant Likely; +Cc: David Woodhouse, Steve Deiters, linuxppc-dev
In-Reply-To: <AANLkTikP_ZrWddakihhslDHphEaDsW-IQY4C-lDoXEgm@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]
Am 08.07.10 17:22 schrieb(en) Grant Likely:
>> Just out of curiousity, what configuration might cause a byte-wise alignment not to work?
>
> Can't remember the register configuration, but I worked on one project where this was the case. In hindsight, it was probably a mis-configuration of the localbus CS for the particular device.
Not sure if you're thinking of this configuration, but if you attach a device in 16-bit mode (i.e. 16 data lines) to the LPB, byte writes simply don't work. I ran into that problem as I have a nvram attached this way to a 5200b. Using the device as mtd-ram with a jffs2 file system on it I also sometimes saw corruption after a write.
I had a patch for that last year, but it was actually badly crafted (see <http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072903.html>). I still use the mpc52xx_memcpy2lpb16() function somewhere in my current code which is actually an ugly hack (but it works...).
Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept?
Best, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Josh Boyer @ 2010-07-08 18:24 UTC (permalink / raw)
To: Lee Nipper; +Cc: linuxppc-dev
In-Reply-To: <AANLkTim8xuZSaDHyxRVqk63PTT66rrR8hUhEDeNzfmKD@mail.gmail.com>
On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
>> It looks like the Rev D version of the 405EX chip without security
>> will be identified as a 405EXr, based on the values in the cpu_specs
>> table. For 405EX/405EXr the pvr_mask is 0xffff0004 with the
>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>> Rev D PVR value for the 405EX without security is 0x12911473, which
>> would mask out to the EXr value.
>>
>> Is there an algorithm update needed or am I missing something?
>
>With 405EX Rev D, we have noticed that we must reset our board
>one time after the initial powerup to make the PVR read correctly.
>
>See this post:
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
That is very very weird. Have you seen that behavior on multiple Rev D CPUs
or just one board or?
The PVR value should never change, so if you have odd behavior I wonder if the
are silicon bugs in that revision. Did you happen to ask AMCC about it?
josh
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Josh Boyer @ 2010-07-08 18:22 UTC (permalink / raw)
To: Lee Nipper; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikCFgFZsAl0QLkZbI1Jbrh8v0d7gK9EVtqCe1QU@mail.gmail.com>
On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote:
>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
>> It looks like the Rev D version of the 405EX chip without security
>> will be identified as a 405EXr, based on the values in the cpu_specs
>> table.
>
>Yes, that is the case.
>The 405EX Rev D without security PVR matches an old 405EXr A/B with security,
>and hence the cpu_spec entries' pvr_mask values are no longer correct.
>
>> Is there an algorithm update needed or am I missing something?
>
>Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
>pvr_mask = 0xffff000f ?
Have you tried that in a locally modified kernel? If so, did it work? If so,
care to submit a patch? :)
josh
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Lee Nipper @ 2010-07-08 17:59 UTC (permalink / raw)
To: Marc Chidester; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikrUvEicL1DaeLz9Vr-lE_hkKZqJi_7qzERZMu8@mail.gmail.com>
On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
> It looks like the Rev D version of the 405EX chip without security
> will be identified as a 405EXr, based on the values in the cpu_specs
> table.
Yes, that is the case.
The 405EX Rev D without security PVR matches an old 405EXr A/B with security,
and hence the cpu_spec entries' pvr_mask values are no longer correct.
> Is there an algorithm update needed or am I missing something?
Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
pvr_mask = 0xffff000f ?
^ permalink raw reply
* [PATCH 3/3] powerpc/cpm1: Mark micropatch code/data static and __init
From: Anton Vorontsov @ 2010-07-08 17:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: LEROY Christophe, linuxppc-dev, Scott Wood
This saves runtime memory and fixes lots of sparse warnings like this:
CHECK arch/powerpc/sysdev/micropatch.c
arch/powerpc/sysdev/micropatch.c:27:6: warning: symbol 'patch_2000'
was not declared. Should it be static?
arch/powerpc/sysdev/micropatch.c:146:6: warning: symbol 'patch_2f00'
was not declared. Should it be static?
...
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/powerpc/include/asm/cpm1.h | 3 ++-
arch/powerpc/sysdev/micropatch.c | 18 +++++++++---------
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm1.h b/arch/powerpc/include/asm/cpm1.h
index 81b0119..bd07650 100644
--- a/arch/powerpc/include/asm/cpm1.h
+++ b/arch/powerpc/include/asm/cpm1.h
@@ -17,6 +17,7 @@
#ifndef __CPM1__
#define __CPM1__
+#include <linux/init.h>
#include <asm/8xx_immap.h>
#include <asm/ptrace.h>
#include <asm/cpm.h>
@@ -54,7 +55,7 @@ extern cpm8xx_t __iomem *cpmp; /* Pointer to comm processor */
extern void cpm_setbrg(uint brg, uint rate);
-extern void cpm_load_patch(cpm8xx_t *cp);
+extern void __init cpm_load_patch(cpm8xx_t *cp);
extern void cpm_reset(void);
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index 6c56ae9..c0bb76e 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -4,6 +4,7 @@
* also relocates SMC2, but this would require additional changes
* to uart.c, so I am holding off on that for a moment.
*/
+#include <linux/init.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/kernel.h>
@@ -25,7 +26,7 @@
#ifdef CONFIG_I2C_SPI_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x7FFFEFD9,
0x3FFD0000,
0x7FFB49F7,
@@ -144,7 +145,7 @@ uint patch_2000[] = {
0x5F8247F8
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x3E303430,
0x34343737,
0xABF7BF9B,
@@ -183,7 +184,7 @@ uint patch_2f00[] = {
#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x3fff0000,
0x3ffd0000,
0x3ffb0000,
@@ -506,7 +507,7 @@ uint patch_2000[] = {
0x6079e2bb
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x30303030,
0x3e3e3434,
0xabbf9b99,
@@ -573,7 +574,7 @@ uint patch_2f00[] = {
0xf22f3f23
};
-uint patch_2e00[] = {
+static uint patch_2e00[] __initdata = {
0x27eeeeee,
0xeeeeeeee,
0xeeeeeeee,
@@ -599,7 +600,7 @@ uint patch_2e00[] = {
#ifdef CONFIG_USB_SOF_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x7fff0000,
0x7ffd0000,
0x7ffb0000,
@@ -614,15 +615,14 @@ uint patch_2000[] = {
0x60750000
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x3030304c,
0xcab9e441,
0xa1aaf220
};
#endif
-void
-cpm_load_patch(cpm8xx_t *cp)
+void __init cpm_load_patch(cpm8xx_t *cp)
{
volatile uint *dp; /* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
--
1.7.0.5
^ permalink raw reply related
* [PATCH 2/3] powerpc/cpm1: Fix build with various CONFIG_*_UCODE_PATCH combinations
From: Anton Vorontsov @ 2010-07-08 17:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: LEROY Christophe, linuxppc-dev, Scott Wood
Warnings are treated as errors for arch/powerpc code, so build fails
with CONFIG_I2C_SPI_UCODE_PATCH=y:
CC arch/powerpc/sysdev/micropatch.o
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
And with CONFIG_USB_SOF_UCODE_PATCH=y:
CC arch/powerpc/sysdev/micropatch.o
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:629: warning: unused variable 'spp'
arch/powerpc/sysdev/micropatch.c:628: warning: unused variable 'iip'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
This patch fixes these issues by introducing proper #ifdefs.
Cc: <stable@kernel.org> [ .33, .34 ]
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/powerpc/sysdev/micropatch.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index 18080f3..6c56ae9 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -626,9 +626,14 @@ cpm_load_patch(cpm8xx_t *cp)
{
volatile uint *dp; /* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
+#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
+ defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
volatile iic_t *iip;
volatile struct spi_pram *spp;
+#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
volatile smc_uart_t *smp;
+#endif
+#endif
int i;
commproc = cp;
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/3] powerpc/cpm: Reintroduce global spi_pram struct (fixes build issue)
From: Anton Vorontsov @ 2010-07-08 17:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: LEROY Christophe, linuxppc-dev, Scott Wood
spi_t was removed in commit 644b2a680ccc51a9ec4d6beb12e9d47d2dee98e2
("powerpc/cpm: Remove SPI defines and spi structs"), the commit assumed
that spi_t isn't used anywhere outside of the spi_mpc8xxx driver. But
it appears that the struct is needed for micropatch code. So, let's
reintroduce the struct.
Fixes the following build issue:
CC arch/powerpc/sysdev/micropatch.o
micropatch.c: In function 'cpm_load_patch':
micropatch.c:629: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
micropatch.c:629: error: 'spp' undeclared (first use in this function)
micropatch.c:629: error: (Each undeclared identifier is reported only once
micropatch.c:629: error: for each function it appears in.)
Reported-by: LEROY Christophe <christophe.leroy@c-s.fr>
Reported-by: Tony Breeds <tony@bakeyournoodle.com>
Cc: <stable@kernel.org> [ .33, .34 ]
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/powerpc/include/asm/cpm.h | 24 ++++++++++++++++++++++++
arch/powerpc/sysdev/micropatch.c | 7 ++++---
drivers/spi/spi_mpc8xxx.c | 22 ----------------------
3 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
index 0835eb9..e50323f 100644
--- a/arch/powerpc/include/asm/cpm.h
+++ b/arch/powerpc/include/asm/cpm.h
@@ -7,6 +7,30 @@
#include <linux/of.h>
/*
+ * SPI Parameter RAM common to QE and CPM.
+ */
+struct spi_pram {
+ __be16 rbase; /* Rx Buffer descriptor base address */
+ __be16 tbase; /* Tx Buffer descriptor base address */
+ u8 rfcr; /* Rx function code */
+ u8 tfcr; /* Tx function code */
+ __be16 mrblr; /* Max receive buffer length */
+ __be32 rstate; /* Internal */
+ __be32 rdp; /* Internal */
+ __be16 rbptr; /* Internal */
+ __be16 rbc; /* Internal */
+ __be32 rxtmp; /* Internal */
+ __be32 tstate; /* Internal */
+ __be32 tdp; /* Internal */
+ __be16 tbptr; /* Internal */
+ __be16 tbc; /* Internal */
+ __be32 txtmp; /* Internal */
+ __be32 res; /* Tx temp. */
+ __be16 rpbase; /* Relocation pointer (CPM1 only) */
+ __be16 res1; /* Reserved */
+};
+
+/*
* USB Controller pram common to QE and CPM.
*/
struct usb_ctlr {
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index d8d6028..18080f3 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -16,6 +16,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/8xx_immap.h>
+#include <asm/cpm.h>
#include <asm/cpm1.h>
/*
@@ -626,7 +627,7 @@ cpm_load_patch(cpm8xx_t *cp)
volatile uint *dp; /* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
volatile iic_t *iip;
- volatile spi_t *spp;
+ volatile struct spi_pram *spp;
volatile smc_uart_t *smp;
int i;
@@ -668,8 +669,8 @@ cpm_load_patch(cpm8xx_t *cp)
/* Put SPI above the IIC, also 32-byte aligned.
*/
i = (RPBASE + sizeof(iic_t) + 31) & ~31;
- spp = (spi_t *)&commproc->cp_dparam[PROFF_SPI];
- spp->spi_rpbase = i;
+ spp = (struct spi_pram *)&commproc->cp_dparam[PROFF_SPI];
+ spp->rpbase = i;
# if defined(CONFIG_I2C_SPI_UCODE_PATCH)
commproc->cp_cpmcr1 = 0x802a;
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index ffa111a..97ab0a8 100644
--- a/drivers/spi/spi_mpc8xxx.c
+++ b/drivers/spi/spi_mpc8xxx.c
@@ -66,28 +66,6 @@ struct mpc8xxx_spi_reg {
__be32 receive;
};
-/* SPI Parameter RAM */
-struct spi_pram {
- __be16 rbase; /* Rx Buffer descriptor base address */
- __be16 tbase; /* Tx Buffer descriptor base address */
- u8 rfcr; /* Rx function code */
- u8 tfcr; /* Tx function code */
- __be16 mrblr; /* Max receive buffer length */
- __be32 rstate; /* Internal */
- __be32 rdp; /* Internal */
- __be16 rbptr; /* Internal */
- __be16 rbc; /* Internal */
- __be32 rxtmp; /* Internal */
- __be32 tstate; /* Internal */
- __be32 tdp; /* Internal */
- __be16 tbptr; /* Internal */
- __be16 tbc; /* Internal */
- __be32 txtmp; /* Internal */
- __be32 res; /* Tx temp. */
- __be16 rpbase; /* Relocation pointer (CPM1 only) */
- __be16 res1; /* Reserved */
-};
-
/* SPI Controller mode register definitions */
#define SPMODE_LOOP (1 << 30)
#define SPMODE_CI_INACTIVEHIGH (1 << 29)
--
1.7.0.5
^ permalink raw reply related
* Re: 2.6.34: arch/powerpc/sysdev/micropatch.c not compiling
From: Anton Vorontsov @ 2010-07-08 16:55 UTC (permalink / raw)
To: LEROY Christophe, linux-kernel, LinuxPPC-dev, Kumar Gala
In-Reply-To: <20100706000343.GE23985@ozlabs.org>
On Tue, Jul 06, 2010 at 10:03:43AM +1000, Tony Breeds wrote:
> On Mon, Jul 05, 2010 at 09:45:11AM +0200, LEROY Christophe wrote:
> > When activating micropatch option, the kernel does not compile.
>
> powerpc problems should alos CC linuxppc-dev.
>
> > It looks like a spi_t is not defined anywhere.
> >
> > CC arch/powerpc/sysdev/micropatch.o
> > arch/powerpc/sysdev/micropatch.c: In function ‘cpm_load_patch’:
> > arch/powerpc/sysdev/micropatch.c:629: erreur: expected ‘=’, ‘,’,
> > ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
[...]
> - spp = (spi_t *)&commproc->cp_dparam[PROFF_SPI];
> - spp->spi_rpbase = i;
> + smp = (smc_uart_t *)&commproc->cp_dparam[PROFF_SPI];
> + smp->smc_rpbase = i;
>
> # if defined(CONFIG_I2C_SPI_UCODE_PATCH)
> commproc->cp_cpmcr1 = 0x802a;
>
>
> Would help?
While this will fix the issue, I think this is not technically
correct (i.e. micropatching SPI controller via I2C pram struct,
even though the structs appear to be identical).
As the spi_param is needed outside of the SPI driver, we'd
better re-introduce the struct, I think.
I'll send some fixes for this and other issues in this file.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: 405EX Rev D mis-identification?
From: Lee Nipper @ 2010-07-08 16:01 UTC (permalink / raw)
To: Marc Chidester; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikrUvEicL1DaeLz9Vr-lE_hkKZqJi_7qzERZMu8@mail.gmail.com>
On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrot=
e:
> It looks like the Rev D version of the 405EX chip without security
> will be identified as a 405EXr, based on the values in the cpu_specs
> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
> Rev D PVR value for the 405EX without security is 0x12911473, which
> would mask out to the EXr value.
>
> Is there an algorithm update needed or am I missing something?
With 405EX Rev D, we have noticed that we must reset our board
one time after the initial powerup to make the PVR read correctly.
See this post:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Grant Likely @ 2010-07-08 15:22 UTC (permalink / raw)
To: Steve Deiters; +Cc: linuxppc-dev, David Woodhouse
In-Reply-To: <181804936ABC2349BE503168465576460F3D3E66@exchserver.basler.com>
On Thu, Jul 8, 2010 at 8:38 AM, Steve Deiters <SteveDeiters@basler.com> wro=
te:
>> -----Original Message-----
>> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
>> Behalf Of Grant Likely
>> Sent: Thursday, July 08, 2010 12:38 AM
>> To: Benjamin Herrenschmidt
>> Cc: Steve Deiters; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use
>> alternate memcpy for MPC512x and MPC52xx
>>
>> On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote:
>> >> These processors will corrupt data if accessing the local bus with
>> >> unaligned addresses. This version fixes the typical case
>> of copying
>> >> from Flash on the local bus by keeping the source address always
>> >> aligned.
>> >
>> > Shouldn't this be solved by using memcpy_to/fromio ?
>>
>> Maybe. =A0plain memcpy() access to anything localbus-attached
>> on the mpc5xxx is the wrong thing to do. =A0memcpy_to/fromio
>> might do the right thing; but the caller must understand the
>> limitations of the localplus bus. =A0The byte-wise alignment
>> that memcpy_to/fromio() does may not work (depending on
>> configuration).
>>
>> Steve, what code is doing a memcpy from flash?
>>
>> g.
>
> This was done in the JFFS2 code, in fs/jffs2/scan.c. =A0At least in one
> function, in jffs2_scan_dirent_node it was using memcpy on a localbus
> mapped structure. =A0I was getting JFFS2 filesystem corruption because of
> this. =A0In fact I first tried changing this to memcpy_fromio and it fixe=
d
> that particular problem. =A0I was concerned though that other places I wa=
s
> not aware of might be using memcpy from the localbus in a similar manner
> so I decided to just tweak the memcpy routine.
[cc'ing David Woodhouse]
Sounds to me like the right thing to do is to fix the jffs2 code.
> Just out of curiousity, what configuration might cause a byte-wise
> alignment not to work?
Can't remember the register configuration, but I worked on one project
where this was the case. In hindsight, it was probably a
mis-configuration of the localbus CS for the particular device.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* 405EX Rev D mis-identification?
From: Marc Chidester @ 2010-07-08 15:06 UTC (permalink / raw)
To: linuxppc-dev
It looks like the Rev D version of the 405EX chip without security
will be identified as a 405EXr, based on the values in the cpu_specs
table. For 405EX/405EXr the pvr_mask is 0xffff0004 with the
pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
Rev D PVR value for the 405EX without security is 0x12911473, which
would mask out to the EXr value.
Is there an algorithm update needed or am I missing something?
^ permalink raw reply
* HDLC driver for MPC885
From: LEROY Christophe @ 2010-07-08 14:38 UTC (permalink / raw)
To: LinuxPPC-dev
Hello,
I'm looking for an HDLC driver for the SCCs in MPC885 CPM.
Does anybody know where I could find such a driver for kernel 2.6.xx ?
Best regards
Christophe
^ permalink raw reply
* RE: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Steve Deiters @ 2010-07-08 14:38 UTC (permalink / raw)
To: Grant Likely, Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <AANLkTilNssNdEW3wBKfoUMbSQMFLywfFgGMb0F9XwKeG@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Thursday, July 08, 2010 12:38 AM
> To: Benjamin Herrenschmidt
> Cc: Steve Deiters; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use=20
> alternate memcpy for MPC512x and MPC52xx
>=20
> On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt=20
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote:
> >> These processors will corrupt data if accessing the local bus with=20
> >> unaligned addresses. This version fixes the typical case=20
> of copying=20
> >> from Flash on the local bus by keeping the source address always=20
> >> aligned.
> >
> > Shouldn't this be solved by using memcpy_to/fromio ?
>=20
> Maybe. plain memcpy() access to anything localbus-attached=20
> on the mpc5xxx is the wrong thing to do. memcpy_to/fromio=20
> might do the right thing; but the caller must understand the=20
> limitations of the localplus bus. The byte-wise alignment=20
> that memcpy_to/fromio() does may not work (depending on=20
> configuration).
>=20
> Steve, what code is doing a memcpy from flash?
>=20
> g.
This was done in the JFFS2 code, in fs/jffs2/scan.c. At least in one
function, in jffs2_scan_dirent_node it was using memcpy on a localbus
mapped structure. I was getting JFFS2 filesystem corruption because of
this. In fact I first tried changing this to memcpy_fromio and it fixed
that particular problem. I was concerned though that other places I was
not aware of might be using memcpy from the localbus in a similar manner
so I decided to just tweak the memcpy routine.
Just out of curiousity, what configuration might cause a byte-wise
alignment not to work?
^ permalink raw reply
* Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Matthew McClintock @ 2010-07-08 14:27 UTC (permalink / raw)
To: Milton Miller; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <20100708-mitltonm-msm-reply@mdm.bga.com>
On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
> On Wed, 07 Jul 2010 around 10:51:20 -0000 Matthew McClintock wrote:
> >
> > Fix sizes of variables so correct values are exported via /proc.
> > Cast variable in comparison to avoid compiler error.
> >
> > Signed-off-by: Matthew McClintock <msm@freescale.com>
> >
> >
> > - csize = min(csize, PAGE_SIZE);
> > + csize = min(csize, (size_t)PAGE_SIZE);
>
> no use min_t
Ok
>
> >
> > - if (pfn < max_pfn) {
> > + if ((min_low_pfn < pfn) && (pfn < max_pfn)) {
> > vaddr = __va(pfn << PAGE_SHIFT);
> > csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
> > } else {
> > diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> > index bb3d893..ec7f054 100644
> > --- a/arch/powerpc/kernel/machine_kexec.c
> > +++ b/arch/powerpc/kernel/machine_kexec.c
> > @@ -145,6 +145,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
> >
> > /* Values we need to export to the second kernel via the device tree. */
> > static unsigned long kernel_end;
> > +static unsigned long crashk_start;
> > static unsigned long crashk_size;
> >
> > static struct property kernel_end_prop = {
> > @@ -156,7 +157,7 @@ static struct property kernel_end_prop = {
> > static struct property crashk_base_prop = {
> > .name = "linux,crashkernel-base",
> > .length = sizeof(unsigned long),
> > - .value = &crashk_res.start,
> > + .value = &crashk_start,
> > };
> >
>
> This is wrong, its truncating the start and size.
>
> Change the variables to be physaddr_t and the length to be sizeof(physaddr_t).
>
> Since these properites only contain one variable, the number of cells
> can be inferred from the property size like we do for reading the initrd-size.
>
> Technically they should be an array of be32 but we can make that a comment.
I don't disagree but this can break kexec if phys_addr_t != unsigned
long. Also, doesn't the crash kernel have to live below 2GB so unsigned
long is always fine?
Will still change unless I hear otherwise.
>
> By the way, why does 32 bit care about the running kernel's size? aka
> linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks
> to copy the pages to their destination, but I thought ppc32 was using
> a relocatable copy routine. Are we missing the code to create
> temp ref tlbs on the fly for book 3E?
This is not really in this patch or did I miss something? Kexec uses
kernel-end just to add as a invalid region. Not crucial though for 32
bit.
>
> > static struct property crashk_size_prop = {
> > @@ -180,6 +181,7 @@ static void __init export_crashk_values(struct device_node *node)
> > prom_remove_property(node, prop);
> >
> > if (crashk_res.start != 0) {
> > + crashk_start = crashk_res.start;
> > prom_add_property(node, &crashk_base_prop);
> > crashk_size = crashk_res.end - crashk_res.start + 1;
> > prom_add_property(node, &crashk_size_prop);
>
> I guess we use the reuse of the resources varables, but such is
> common code vs userspace.
>
> milton
^ permalink raw reply
* [PATCH v2] spufs: use llseek in all file operations
From: Arnd Bergmann @ 2010-07-08 13:29 UTC (permalink / raw)
To: Jeremy Kerr
Cc: John Kacur, Frederic Weisbecker, linux-kernel, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <201007081502.37133.arnd@arndb.de>
The default for llseek is changing, so we need
explicit operations everywhere.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: linuxppc-dev@ozlabs.org
---
Same as previous version, but no longer breaking the existing llseek
operation in spufs_*box_info_fops. Pushed out to my bkl/llseek branch.
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 1a40da9..02f7b11 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -154,6 +154,7 @@ static const struct file_operations __fops = { \
.release = spufs_attr_release, \
.read = spufs_attr_read, \
.write = spufs_attr_write, \
+ .llseek = generic_file_llseek, \
};
@@ -521,6 +522,7 @@ static const struct file_operations spufs_cntl_fops = {
.release = spufs_cntl_release,
.read = simple_attr_read,
.write = simple_attr_write,
+ .llseek = generic_file_llseek,
.mmap = spufs_cntl_mmap,
};
@@ -714,6 +716,7 @@ static ssize_t spufs_mbox_read(struct file *file, char __user *buf,
static const struct file_operations spufs_mbox_fops = {
.open = spufs_pipe_open,
.read = spufs_mbox_read,
+ .llseek = no_llseek,
};
static ssize_t spufs_mbox_stat_read(struct file *file, char __user *buf,
@@ -743,6 +746,7 @@ static ssize_t spufs_mbox_stat_read(struct file *file, char __user *buf,
static const struct file_operations spufs_mbox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_mbox_stat_read,
+ .llseek = no_llseek,
};
/* low-level ibox access function */
@@ -863,6 +867,7 @@ static const struct file_operations spufs_ibox_fops = {
.read = spufs_ibox_read,
.poll = spufs_ibox_poll,
.fasync = spufs_ibox_fasync,
+ .llseek = no_llseek,
};
static ssize_t spufs_ibox_stat_read(struct file *file, char __user *buf,
@@ -890,6 +895,7 @@ static ssize_t spufs_ibox_stat_read(struct file *file, char __user *buf,
static const struct file_operations spufs_ibox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_ibox_stat_read,
+ .llseek = no_llseek,
};
/* low-level mailbox write */
@@ -1011,6 +1017,7 @@ static const struct file_operations spufs_wbox_fops = {
.write = spufs_wbox_write,
.poll = spufs_wbox_poll,
.fasync = spufs_wbox_fasync,
+ .llseek = no_llseek,
};
static ssize_t spufs_wbox_stat_read(struct file *file, char __user *buf,
@@ -1038,6 +1045,7 @@ static ssize_t spufs_wbox_stat_read(struct file *file, char __user *buf,
static const struct file_operations spufs_wbox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_wbox_stat_read,
+ .llseek = no_llseek,
};
static int spufs_signal1_open(struct inode *inode, struct file *file)
@@ -1166,6 +1174,7 @@ static const struct file_operations spufs_signal1_fops = {
.read = spufs_signal1_read,
.write = spufs_signal1_write,
.mmap = spufs_signal1_mmap,
+ .llseek = no_llseek,
};
static const struct file_operations spufs_signal1_nosched_fops = {
@@ -1173,6 +1182,7 @@ static const struct file_operations spufs_signal1_nosched_fops = {
.release = spufs_signal1_release,
.write = spufs_signal1_write,
.mmap = spufs_signal1_mmap,
+ .llseek = no_llseek,
};
static int spufs_signal2_open(struct inode *inode, struct file *file)
@@ -1305,6 +1315,7 @@ static const struct file_operations spufs_signal2_fops = {
.read = spufs_signal2_read,
.write = spufs_signal2_write,
.mmap = spufs_signal2_mmap,
+ .llseek = no_llseek,
};
static const struct file_operations spufs_signal2_nosched_fops = {
@@ -1312,6 +1323,7 @@ static const struct file_operations spufs_signal2_nosched_fops = {
.release = spufs_signal2_release,
.write = spufs_signal2_write,
.mmap = spufs_signal2_mmap,
+ .llseek = no_llseek,
};
/*
@@ -1451,6 +1463,7 @@ static const struct file_operations spufs_mss_fops = {
.open = spufs_mss_open,
.release = spufs_mss_release,
.mmap = spufs_mss_mmap,
+ .llseek = no_llseek,
};
static int
@@ -1508,6 +1521,7 @@ static const struct file_operations spufs_psmap_fops = {
.open = spufs_psmap_open,
.release = spufs_psmap_release,
.mmap = spufs_psmap_mmap,
+ .llseek = no_llseek,
};
@@ -1871,6 +1885,7 @@ static const struct file_operations spufs_mfc_fops = {
.fsync = spufs_mfc_fsync,
.fasync = spufs_mfc_fasync,
.mmap = spufs_mfc_mmap,
+ .llseek = no_llseek,
};
static int spufs_npc_set(void *data, u64 val)
@@ -2246,6 +2261,7 @@ static ssize_t spufs_dma_info_read(struct file *file, char __user *buf,
static const struct file_operations spufs_dma_info_fops = {
.open = spufs_info_open,
.read = spufs_dma_info_read,
+ .llseek = no_llseek,
};
static ssize_t __spufs_proxydma_info_read(struct spu_context *ctx,
@@ -2299,6 +2315,7 @@ static ssize_t spufs_proxydma_info_read(struct file *file, char __user *buf,
static const struct file_operations spufs_proxydma_info_fops = {
.open = spufs_info_open,
.read = spufs_proxydma_info_read,
+ .llseek = no_llseek,
};
static int spufs_show_tid(struct seq_file *s, void *private)
@@ -2585,6 +2602,7 @@ static const struct file_operations spufs_switch_log_fops = {
.read = spufs_switch_log_read,
.poll = spufs_switch_log_poll,
.release = spufs_switch_log_release,
+ .llseek = no_llseek,
};
/**
^ permalink raw reply related
* Re: [PATCH 06/18] spufs: use llseek in all file operations
From: Arnd Bergmann @ 2010-07-08 13:02 UTC (permalink / raw)
To: Jeremy Kerr
Cc: John Kacur, Frederic Weisbecker, linux-kernel, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <1278551728.28333.55.camel@pororo.lan>
On Thursday 08 July 2010, Jeremy Kerr wrote:
> > @@ -2151,7 +2166,7 @@ static ssize_t spufs_ibox_info_read(struct file *file, char __user *buf,
> > static const struct file_operations spufs_ibox_info_fops = {
> > .open = spufs_info_open,
> > .read = spufs_ibox_info_read,
> > - .llseek = generic_file_llseek,
> > + .llseek = no_llseek,
> > };
> >
> > static ssize_t __spufs_wbox_info_read(struct spu_context *ctx,
> > @@ -2194,7 +2209,7 @@ static ssize_t spufs_wbox_info_read(struct file *file, char __user *buf,
> > static const struct file_operations spufs_wbox_info_fops = {
> > .open = spufs_info_open,
> > .read = spufs_wbox_info_read,
> > - .llseek = generic_file_llseek,
> > + .llseek = no_llseek,
> > };
> >
>
> Why the change in behaviour for the mbox info files?
>
D'oh, that wasn't intentional. I guess what must have happened is that I first
added generic_file_llseek to all file_operations in spufs and then made up my
mind and chose what I thought was correct in each case, which broke these.
Of course, these *_info_fops should be seekable.
Arnd
^ permalink raw reply
* Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Kumar Gala @ 2010-07-08 12:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Matthew McClintock, linuxppc-dev, Milton Miller
In-Reply-To: <1278586190.28659.94.camel@pasglop>
On Jul 8, 2010, at 5:49 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
>> On Wed, 07 Jul 2010 around 10:51:20 -0000 Matthew McClintock wrote:
>>>
>>> Fix sizes of variables so correct values are exported via /proc.
>>> Cast variable in comparison to avoid compiler error.
>>>
>
> I'm afraid I already pulled that in. Please send a fixup patch.
>
> Cheers,
> Ben.
pulled into which tree?
- k
^ permalink raw reply
* Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Benjamin Herrenschmidt @ 2010-07-08 10:49 UTC (permalink / raw)
To: Milton Miller; +Cc: Matthew McClintock, kumar.gala, linuxppc-dev
In-Reply-To: <20100708-mitltonm-msm-reply@mdm.bga.com>
On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
> On Wed, 07 Jul 2010 around 10:51:20 -0000 Matthew McClintock wrote:
> >
> > Fix sizes of variables so correct values are exported via /proc.
> > Cast variable in comparison to avoid compiler error.
> >
I'm afraid I already pulled that in. Please send a fixup patch.
Cheers,
Ben.
> > Signed-off-by: Matthew McClintock <msm@freescale.com>
> >
> >
> > - csize = min(csize, PAGE_SIZE);
> > + csize = min(csize, (size_t)PAGE_SIZE);
>
> no use min_t
>
> >
> > - if (pfn < max_pfn) {
> > + if ((min_low_pfn < pfn) && (pfn < max_pfn)) {
> > vaddr = __va(pfn << PAGE_SHIFT);
> > csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
> > } else {
> > diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> > index bb3d893..ec7f054 100644
> > --- a/arch/powerpc/kernel/machine_kexec.c
> > +++ b/arch/powerpc/kernel/machine_kexec.c
> > @@ -145,6 +145,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
> >
> > /* Values we need to export to the second kernel via the device tree. */
> > static unsigned long kernel_end;
> > +static unsigned long crashk_start;
> > static unsigned long crashk_size;
> >
> > static struct property kernel_end_prop = {
> > @@ -156,7 +157,7 @@ static struct property kernel_end_prop = {
> > static struct property crashk_base_prop = {
> > .name = "linux,crashkernel-base",
> > .length = sizeof(unsigned long),
> > - .value = &crashk_res.start,
> > + .value = &crashk_start,
> > };
> >
>
> This is wrong, its truncating the start and size.
>
> Change the variables to be physaddr_t and the length to be sizeof(physaddr_t).
>
> Since these properites only contain one variable, the number of cells
> can be inferred from the property size like we do for reading the initrd-size.
>
> Technically they should be an array of be32 but we can make that a comment.
>
> By the way, why does 32 bit care about the running kernel's size? aka
> linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks
> to copy the pages to their destination, but I thought ppc32 was using
> a relocatable copy routine. Are we missing the code to create
> temp ref tlbs on the fly for book 3E?
>
> > static struct property crashk_size_prop = {
> > @@ -180,6 +181,7 @@ static void __init export_crashk_values(struct device_node *node)
> > prom_remove_property(node, prop);
> >
> > if (crashk_res.start != 0) {
> > + crashk_start = crashk_res.start;
> > prom_add_property(node, &crashk_base_prop);
> > crashk_size = crashk_res.end - crashk_res.start + 1;
> > prom_add_property(node, &crashk_size_prop);
>
> I guess we use the reuse of the resources varables, but such is
> common code vs userspace.
>
> milton
^ permalink raw reply
* Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
From: Benjamin Herrenschmidt @ 2010-07-08 10:49 UTC (permalink / raw)
To: lawrence rust; +Cc: linuxppc-dev
In-Reply-To: <1278579667.2850.5.camel@gagarin>
On Thu, 2010-07-08 at 11:01 +0200, lawrence rust wrote:
> On Thu, 2010-07-08 at 16:30 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2010-07-08 at 08:18 +0200, lawrence rust wrote:
> > >
> > > Sure. it would be preferable but unfortunately the PowerMac on-board IDE
> > > controller (CONFIG_BLK_DEV_IDE_PMAC), used for the DVD drive on B/W
> > > G3's, doesn't have a PATA equivalent. So it's pragmatic (until the IDE
> > > code is removed) to use the IDE cmd64x driver to minimise kernel code
> > > size.
> >
> > Sure it does nowadays: drivers/ata/pata_macio.c :-)
> >
> > I merged that upstream in december last year, so it didn't make 2.6.32
> > which your distro probably uses, but it is in .33 and later.
>
> OK I see that - good news. However, for the moment I believe that it's
> safer to stay with IDE. It's the smallest of changes but the wholesale
> move to libata could well break numerous system install scripts - e.g.
> for yaboot.
Well, distros have moved over mostly... I don't think keeping the
defaults to the old stuff upstream is going to help getting things like
yaboot fixed. I'll talk to Tony see what the situation there is
tomorrow, but I'd rather fix yaboot and switch the default over.
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox