* [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
* Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
From: Milton Miller @ 2010-07-08 9:07 UTC (permalink / raw)
To: Matthew McClintock; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <1278535881-6463-1-git-send-email-msm@freescale.com>
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
>
> - 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: lawrence rust @ 2010-07-08 9:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1278570620.28659.79.camel@pasglop>
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.
-- Lawrence
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-07-08 8:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a few powerpc nits and bits still for 2.6.35. Mostly simple/trivial
stuff and some gcc-4.5 related fixes.
Thanks !
Cheers,
Ben.
The following changes since commit 2aa72f612144a0a7d4b0b22ae7c122692ac6a013:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Blanchard (1):
powerpc: Linux cannot run with 0 cores
Denis Kirjanov (1):
powerpc/iseries: Fix possible null pointer dereference in iSeries_pcibios_fixup_resources
Johannes Berg (1):
powerpc: Fix logic error in fixup_irqs
Matt Evans (1):
powerpc/perf_event: Fix for power_pmu_disable()
Paul E. McKenney (1):
powerpc: Fix default_machine_crash_shutdown #ifdef botch
Sam Ravnborg (1):
powerpc: Fix userspace build of ptrace.h
Stephen Rothwell (3):
powerpc: Fix module building for gcc 4.5 and 64 bit
powerpc: Fix compile errors in prom_init_check for gcc 4.5
powerpc: Fix feature-fixup tests for gcc 4.5
Yang Li (1):
powerpc: Disable SPARSE_IRQ by default
arch/powerpc/Kconfig | 4 +-
arch/powerpc/Makefile | 4 +-
arch/powerpc/include/asm/ptrace.h | 32 ++++-----
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/irq.c | 5 +-
arch/powerpc/kernel/perf_event.c | 5 +-
arch/powerpc/kernel/prom_init.c | 2 +-
arch/powerpc/kernel/prom_init_check.sh | 6 ++
arch/powerpc/lib/Makefile | 4 +-
arch/powerpc/lib/crtsavres.S | 129 ++++++++++++++++++++++++++++++++
arch/powerpc/lib/feature-fixups.c | 17 ++--
arch/powerpc/platforms/iseries/pci.c | 6 +-
scripts/mod/modpost.c | 5 +
13 files changed, 184 insertions(+), 37 deletions(-)
^ permalink raw reply
* [PATCH v2] powerpc/kexec: Switch to a static PACA on the way out
From: Matt Evans @ 2010-07-08 7:55 UTC (permalink / raw)
To: Milton Miller, linuxppc-dev
With dynamic PACAs, the kexecing CPU's PACA won't lie within the kernel
static data and there is a chance that something may stomp it when preparing
to kexec. This patch switches this final CPU to a static PACA just before
we pull the switch.
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
v2: Changes from Milton's review:
- Use setup_paca() and move from setup_64.c,
- SLB cache inval. not required,
- Adjust 'paca' (oops..), and
- Poison data_offset/per_cpu_offset
arch/powerpc/include/asm/paca.h | 2 +-
arch/powerpc/kernel/machine_kexec_64.c | 20 ++++++++++++++++++++
arch/powerpc/kernel/paca.c | 10 ++++++++++
arch/powerpc/kernel/setup_64.c | 10 ----------
4 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 8ce7963..1ff6662 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -146,7 +146,7 @@ struct paca_struct {
extern struct paca_struct *paca;
extern __initdata struct paca_struct boot_paca;
extern void initialise_paca(struct paca_struct *new_paca, int cpu);
-
+extern void setup_paca(struct paca_struct *new_paca);
extern void allocate_pacas(void);
extern void free_unused_pacas(void);
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 26f9900..c4d0123 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -273,6 +273,12 @@ static void kexec_prepare_cpus(void)
static union thread_union kexec_stack __init_task_data =
{ };
+/*
+ * For similar reasons to the stack above, the kexecing CPU needs to be on a
+ * static PACA; we switch to kexec_paca.
+ */
+struct paca_struct kexec_paca;
+
/* Our assembly helper, in kexec_stub.S */
extern NORET_TYPE void kexec_sequence(void *newstack, unsigned long start,
void *image, void *control,
@@ -300,6 +306,20 @@ void default_machine_kexec(struct kimage *image)
kexec_stack.thread_info.task = current_thread_info()->task;
kexec_stack.thread_info.flags = 0;
+ /* We need a static PACA, too; copy this CPU's PACA over and switch to
+ * it. Also poison per_cpu_offset to catch anyone using non-static
+ * data.
+ */
+ memcpy(&kexec_paca, get_paca(), sizeof(struct paca_struct));
+ kexec_paca.data_offset = 0xedeaddeadeeeeeeeUL;
+ paca = (struct paca_struct *)RELOC_HIDE(&kexec_paca, 0) -
+ kexec_paca.paca_index;
+ setup_paca(&kexec_paca);
+
+ /* XXX: If anyone does 'dynamic lppacas' this will also need to be
+ * switched to a static version!
+ */
+
/* Some things are best done in assembly. Finding globals with
* a toc is easier in C, so pass in what we can.
*/
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index f88acf0..3db8d64 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -105,6 +105,16 @@ void __init initialise_paca(struct paca_struct *new_paca, int cpu)
#endif /* CONFIG_PPC_STD_MMU_64 */
}
+/* Put the paca pointer into r13 and SPRG_PACA */
+void setup_paca(struct paca_struct *new_paca)
+{
+ local_paca = new_paca;
+ mtspr(SPRN_SPRG_PACA, local_paca);
+#ifdef CONFIG_PPC_BOOK3E
+ mtspr(SPRN_SPRG_TLB_EXFRAME, local_paca->extlb);
+#endif
+}
+
static int __initdata paca_size;
void __init allocate_pacas(void)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index f3fb5a7..6efbed4 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -142,16 +142,6 @@ early_param("smt-enabled", early_smt_enabled);
#define check_smt_enabled()
#endif /* CONFIG_SMP */
-/* Put the paca pointer into r13 and SPRG_PACA */
-static void __init setup_paca(struct paca_struct *new_paca)
-{
- local_paca = new_paca;
- mtspr(SPRN_SPRG_PACA, local_paca);
-#ifdef CONFIG_PPC_BOOK3E
- mtspr(SPRN_SPRG_TLB_EXFRAME, local_paca->extlb);
-#endif
-}
-
/*
* Early initialization entry point. This is called by head.S
* with MMU translation disabled. We rely on the "feature" of
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
From: Benjamin Herrenschmidt @ 2010-07-08 6:30 UTC (permalink / raw)
To: lawrence rust; +Cc: linuxppc-dev
In-Reply-To: <1278569907.1411.19.camel@gagarin>
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.
> A minor correction to my previous post, the first version of Ubuntu to
> suffer from this problem was 9.10.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
From: lawrence rust @ 2010-07-08 6:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1278565221.28659.74.camel@pasglop>
On Thu, 2010-07-08 at 15:00 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2010-07-03 at 20:21 +0200, lawrence rust wrote:
> > The Blue/White Apple PowerMac G3 and early G4's use a cmd64x compatible
> > IDE disk controller. E.g. lspci shows...
> >
> > 01:01.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 07)
> >
> > Unfortunately the default pmac32 configuration does not include this
> > driver and so PowerMac G3's can't load a root filesystem. This is an
> > issue on a least Ubuntu since version 9.04, which uses the default
> > config as a starting point.
> >
> > Signed-off-by: Lawrence Rust <lawrence at softsystem.co.uk>
>
> Shouldn't we just switch the whole thing to libata now anyways ?
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.
A minor correction to my previous post, the first version of Ubuntu to
suffer from this problem was 9.10.
-- Lawrence
>
> Cheers,
> Ben.
>
> > diff -uprN a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
> > --- a/arch/powerpc/configs/pmac32_defconfig 2010-05-16 23:17:36.000000000 +0200
> > +++ b/arch/powerpc/configs/pmac32_defconfig 2010-07-03 20:11:10.000000000 +0200
> > @@ -738,7 +738,7 @@ CONFIG_BLK_DEV_IDEDMA_PCI=y
> > # CONFIG_BLK_DEV_AEC62XX is not set
> > # CONFIG_BLK_DEV_ALI15X3 is not set
> > # CONFIG_BLK_DEV_AMD74XX is not set
> > -# CONFIG_BLK_DEV_CMD64X is not set
> > +CONFIG_BLK_DEV_CMD64X=y
> > # CONFIG_BLK_DEV_TRIFLEX is not set
> > # CONFIG_BLK_DEV_CS5520 is not set
> > # CONFIG_BLK_DEV_CS5530 is not set
> >
> >
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
--
-- Lawrence Rust
^ permalink raw reply
* Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
From: Artem Bityutskiy @ 2010-07-08 5:57 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Mike Frysinger, Barry Song, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton,
David Woodhouse
In-Reply-To: <20100622165734.GA20699@oksana.dev.rtsoft.ru>
On Tue, 2010-06-22 at 20:57 +0400, Anton Vorontsov wrote:
> Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
> probing/JEDEC code"), m25p80 driver successfully registers chips
> even if JEDEC probing fails.
>
> This was needed to support non-JEDEC flashes. Though, it appears
> that some platforms (e.g. blackfin bf533 stamp[1]) used the old
> behavior to detect if there's any flash connected, so the driver
> have to fail on JEDEC probing errors.
>
> This patch restores the old behavior for JEDEC flashes, and adds
> "-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
> still supports non-JEDEC flashes.
>
> [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
>
> Reported-by: Mingquan Pan
> Reported-by: Barry Song <21cnbao@gmail.com>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
Pushed both patches to my l2-mtd-2.6.git / dunno, added Mike's ack.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
From: Benjamin Herrenschmidt @ 2010-07-08 6:08 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20100625095606.GG12443@tyan-ft48-01.lab.bos.redhat.com>
On Fri, 2010-06-25 at 11:56 +0200, Jakub Jelinek wrote:
> static inline void sync(void)
> diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
> index b8f152e..288d8b2 100644
> --- a/arch/powerpc/include/asm/atomic.h
> +++ b/arch/powerpc/include/asm/atomic.h
> @@ -19,14 +19,14 @@ static __inline__ int atomic_read(const atomic_t *v)
> {
> int t;
>
> - __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
> + __asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m<>"(v->counter));
>
> return t;
> }
>
This gives me:
/home/benh/linux-powerpc-test/arch/powerpc/kernel/time.c: In function ‘timer_interrupt’:
/home/benh/linux-powerpc-test/arch/powerpc/include/asm/atomic.h:22: error: ‘asm’ operand has impossible constraints
make[2]: *** [arch/powerpc/kernel/time.o] Error 1
$ gcc --version
gcc (Debian 4.4.4-1) 4.4.4
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Grant Likely @ 2010-07-08 5:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Steve Deiters, linuxppc-dev
In-Reply-To: <1278565845.28659.75.camel@pasglop>
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. plain memcpy() access to anything localbus-attached on the
mpc5xxx is the wrong thing to do. memcpy_to/fromio might do the right
thing; but the caller must understand the limitations of the localplus
bus. The byte-wise alignment that memcpy_to/fromio() does may not
work (depending on configuration).
Steve, what code is doing a memcpy from flash?
g.
^ permalink raw reply
* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Benjamin Herrenschmidt @ 2010-07-08 5:10 UTC (permalink / raw)
To: Steve Deiters; +Cc: linuxppc-dev
In-Reply-To: <181804936ABC2349BE503168465576460F272CA4@exchserver.basler.com>
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 ?
Cheers,
Ben.
> Signed-off-by: Steve Deiters <SteveDeiters@basler.com>
> ---
> arch/powerpc/lib/copy_32.S | 56
> ++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
> index 74a7f41..42e7df5 100644
> --- a/arch/powerpc/lib/copy_32.S
> +++ b/arch/powerpc/lib/copy_32.S
> @@ -226,6 +226,60 @@ _GLOBAL(memmove)
> bgt backwards_memcpy
> /* fall through */
>
> +#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx)
> +
> +/*
> + * Alternate memcpy for MPC512x and MPC52xx to guarantee source
> + * address is always aligned to prevent corruption issues when
> + * copying unaligned from the local bus. This only fixes the usage
> + * when copying from the local bus (e.g. Flash) and will not fix
> + * issues copying to the local bus
> + */
> +_GLOBAL(memcpy)
> + srwi. r7,r5,3
> + addi r6,r3,-4
> + addi r4,r4,-4
> + beq 2f /* if less than 8 bytes to do */
> + andi. r0,r4,3 /* get src word aligned */
> + mtctr r7
> + bne 5f
> +1: lwz r7,4(r4)
> + lwzu r8,8(r4)
> + stw r7,4(r6)
> + stwu r8,8(r6)
> + bdnz 1b
> + andi. r5,r5,7
> +2: cmplwi 0,r5,4
> + blt 3f
> + andi. r0,r4,3
> + bne 3f
> + lwzu r0,4(r4)
> + addi r5,r5,-4
> + stwu r0,4(r6)
> +3: cmpwi 0,r5,0
> + beqlr
> + mtctr r5
> + addi r4,r4,3
> + addi r6,r6,3
> +4: lbzu r0,1(r4)
> + stbu r0,1(r6)
> + bdnz 4b
> + blr
> +5: subfic r0,r0,4
> + mtctr r0
> +6: lbz r7,4(r4)
> + addi r4,r4,1
> + stb r7,4(r6)
> + addi r6,r6,1
> + bdnz 6b
> + subf r5,r0,r5
> + rlwinm. r7,r5,32-3,3,31
> + beq 2b
> + mtctr r7
> + b 1b
> +
> +#else
> +
> _GLOBAL(memcpy)
> srwi. r7,r5,3
> addi r6,r3,-4
> @@ -267,6 +321,8 @@ _GLOBAL(memcpy)
> mtctr r7
> b 1b
>
> +#endif
> +
> _GLOBAL(backwards_memcpy)
> rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */
> add r6,r3,r5
^ permalink raw reply
* Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
From: Benjamin Herrenschmidt @ 2010-07-08 5:00 UTC (permalink / raw)
To: lawrence rust; +Cc: linuxppc-dev
In-Reply-To: <1278181316.3232.45.camel@gagarin>
On Sat, 2010-07-03 at 20:21 +0200, lawrence rust wrote:
> The Blue/White Apple PowerMac G3 and early G4's use a cmd64x compatible
> IDE disk controller. E.g. lspci shows...
>
> 01:01.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 07)
>
> Unfortunately the default pmac32 configuration does not include this
> driver and so PowerMac G3's can't load a root filesystem. This is an
> issue on a least Ubuntu since version 9.04, which uses the default
> config as a starting point.
>
> Signed-off-by: Lawrence Rust <lawrence at softsystem.co.uk>
Shouldn't we just switch the whole thing to libata now anyways ?
Cheers,
Ben.
> diff -uprN a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
> --- a/arch/powerpc/configs/pmac32_defconfig 2010-05-16 23:17:36.000000000 +0200
> +++ b/arch/powerpc/configs/pmac32_defconfig 2010-07-03 20:11:10.000000000 +0200
> @@ -738,7 +738,7 @@ CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_AEC62XX is not set
> # CONFIG_BLK_DEV_ALI15X3 is not set
> # CONFIG_BLK_DEV_AMD74XX is not set
> -# CONFIG_BLK_DEV_CMD64X is not set
> +CONFIG_BLK_DEV_CMD64X=y
> # CONFIG_BLK_DEV_TRIFLEX is not set
> # CONFIG_BLK_DEV_CS5520 is not set
> # CONFIG_BLK_DEV_CS5530 is not set
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] edac: mpc85xx: Fix MPC85xx dependency
From: Anton Vorontsov @ 2010-07-08 4:56 UTC (permalink / raw)
To: Andrew Morton
Cc: Peter Tyser, linux-kernel, Dave Jiang, linuxppc-dev,
Doug Thompson
In-Reply-To: <20100707144502.22b91374.akpm@linux-foundation.org>
On Wed, Jul 07, 2010 at 02:45:02PM -0700, Andrew Morton wrote:
> On Fri, 2 Jul 2010 16:41:11 +0400
> Anton Vorontsov <avorontsov@mvista.com> wrote:
>
> > Since commit 5753c082f66eca5be81f6bda85c1718c5eea6ada ("powerpc/85xx:
> > Kconfig cleanup"), there is no MPC85xx Kconfig symbol anymore, so the
> > driver became non-selectable.
>
> hm. 5753c082f66eca5be81f6bda85c1718c5eea6ada got merged into mainline
> six months ago. How come nobody noticed?
Dunno. Well, it's hard to notice these sorts of things until
somebody actually needs this driver on MPC85xx platform. :-)
> > This patch fixes the issue by switching to PPC_85xx symbol.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> > ---
[...]
> > - depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)
> > + depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || PPC_85xx)
> > help
> > Support for error detection and correction on the Freescale
> > MPC8349, MPC8560, MPC8540, MPC8548
>
> I suppose we shold scoot this into 2.6.35 and mark it for -stable
> backporting. All very odd.
Yeah, -stable 2.6.{33,34} sounds good.
Thanks.
^ 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