* RE: [PATCH 3/9] dmaengine: add private header file
From: H Hartley Sweeten @ 2012-03-07 0:47 UTC (permalink / raw)
To: Russell King - ARM Linux, Dan Williams, Vinod Koul
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <E1S52xe-0002Mn-Pn@rmk-PC.arm.linux.org.uk>
On Tuesday, March 06, 2012 3:34 PM, Russell King wrote:
>
> Add a local private header file to contain definitions and declarations
> which should only be used by DMA engine drivers.
>
> We also fix linux/dmaengine.h to use LINUX_DMAENGINE_H to guard against
> multiple inclusion.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
<snip>
> drivers/dma/dmaengine.h | 10 ++++++++++
<snip>
> drivers/dma/ep93xx_dma.c | 2 ++
<snip>
> include/linux/dmaengine.h | 4 ++--
<snip>
> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> new file mode 100644
> index 0000000..968570d
> --- /dev/null
> +++ b/drivers/dma/dmaengine.h
> @@ -0,0 +1,10 @@
> +/*
> + * The contents of this file are private to DMA engine drivers, and is n=
ot
> + * part of the API to be used by DMA engine users.
> + */
> +#ifndef DMAENGINE_H
> +#define DMAENGINE_H
> +
> +#include <linux/dmaengine.h>
> +
> +#endif
<snip>
> diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
> index bc45787..3260198 100644
> --- a/drivers/dma/ep93xx_dma.c
> +++ b/drivers/dma/ep93xx_dma.c
> @@ -28,6 +28,8 @@
> =20
> #include <mach/dma.h>
> =20
> +#include "dmaengine.h"
> +
> /* M2P registers */
> #define M2P_CONTROL 0x0000
> #define M2P_CONTROL_STALLINT BIT(0)
<snip>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 41d0f92..4b17ca8 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -18,8 +18,8 @@
> * The full GNU General Public License is included in this distribution =
in the
> * file called COPYING.
> */
> -#ifndef DMAENGINE_H
> -#define DMAENGINE_H
> +#ifndef LINUX_DMAENGINE_H
> +#define LINUX_DMAENGINE_H
> =20
> #include <linux/device.h>
> #include <linux/uio.h>
For ep93xx:
Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* RE: [PATCH 4/9] dmaengine: consolidate assignment of DMA cookies
From: H Hartley Sweeten @ 2012-03-07 0:53 UTC (permalink / raw)
To: Russell King - ARM Linux, Dan Williams, Vinod Koul
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <E1S52xy-0002Ms-Ud@rmk-PC.arm.linux.org.uk>
On Tuesday, March 06, 2012 3:35 PM, Russell King wrote:
>
> Everyone deals with assigning DMA cookies in the same way (it's part of
> the API so they should be), so lets consolidate the common code into a
> helper function to avoid this duplication.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
<snip>
> drivers/dma/dmaengine.h | 20 ++++++++++++++++++++
<snip>
> drivers/dma/ep93xx_dma.c | 9 +--------
<snip>
> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> index 968570d..7692c86 100644
> --- a/drivers/dma/dmaengine.h
> +++ b/drivers/dma/dmaengine.h
> @@ -7,4 +7,24 @@
> =20
> #include <linux/dmaengine.h>
> =20
> +/**
> + * dma_cookie_assign - assign a DMA engine cookie to the descriptor
> + * @tx: descriptor needing cookie
> + *
> + * Assign a unique non-zero per-channel cookie to the descriptor.
> + * Note: caller is expected to hold a lock to prevent concurrency.
> + */
> +static inline dma_cookie_t dma_cookie_assign(struct dma_async_tx_descrip=
tor *tx)
> +{
> + struct dma_chan *chan =3D tx->chan;
> + dma_cookie_t cookie;
> +
> + cookie =3D chan->cookie + 1;
> + if (cookie < DMA_MIN_COOKIE)
> + cookie =3D DMA_MIN_COOKIE;
> + tx->cookie =3D chan->cookie =3D cookie;
> +
> + return cookie;
> +}
> +
> #endif
<snip>
> diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
> index 3260198..e5aaae8 100644
> --- a/drivers/dma/ep93xx_dma.c
> +++ b/drivers/dma/ep93xx_dma.c
> @@ -783,17 +783,10 @@ static dma_cookie_t ep93xx_dma_tx_submit(struct dma=
_async_tx_descriptor *tx)
> unsigned long flags;
> =20
> spin_lock_irqsave(&edmac->lock, flags);
> -
> - cookie =3D edmac->chan.cookie;
> -
> - if (++cookie < 0)
> - cookie =3D 1;
> + cookie =3D dma_cookie_assign(tx);
> =20
> desc =3D container_of(tx, struct ep93xx_dma_desc, txd);
> =20
> - edmac->chan.cookie =3D cookie;
> - desc->txd.cookie =3D cookie;
> -
> /*
> * If nothing is currently prosessed, we push this descriptor
> * directly to the hardware. Otherwise we put the descriptor
For ep93xx:
Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* RE: [PATCH 5/9] dmaengine: provide a common function for completing a dma descriptor
From: H Hartley Sweeten @ 2012-03-07 0:56 UTC (permalink / raw)
To: Russell King - ARM Linux, Dan Williams, Vinod Koul
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <E1S52yJ-0002Mx-2e@rmk-PC.arm.linux.org.uk>
On Tuesday, March 06, 2012 3:35 PM, Russell King wrote:
>
> Provide a common function to do the cookie mechanics for completing
> a DMA descriptor.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
<snip>
> drivers/dma/dmaengine.h | 18 ++++++++++++++++++
<snip>
> drivers/dma/ep93xx_dma.c | 2 +-
<snip>
> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> index 7692c86..47e0997 100644
> --- a/drivers/dma/dmaengine.h
> +++ b/drivers/dma/dmaengine.h
> @@ -5,6 +5,7 @@
> #ifndef DMAENGINE_H
> #define DMAENGINE_H
> =20
> +#include <linux/bug.h>
> #include <linux/dmaengine.h>
> =20
> /**
> @@ -27,4 +28,21 @@ static inline dma_cookie_t dma_cookie_assign(struct dm=
a_async_tx_descriptor *tx)
> return cookie;
> }
> =20
> +/**
> + * dma_cookie_complete - complete a descriptor
> + * @tx: descriptor to complete
> + *
> + * Mark this descriptor complete by updating the channels completed
> + * cookie marker. Zero the descriptors cookie to prevent accidental
> + * repeated completions.
> + *
> + * Note: caller is expected to hold a lock to prevent concurrency.
> + */
> +static inline void dma_cookie_complete(struct dma_async_tx_descriptor *t=
x)
> +{
> + BUG_ON(tx->cookie < DMA_MIN_COOKIE);
> + tx->chan->completed_cookie =3D tx->cookie;
> + tx->cookie =3D 0;
> +}
> +
> #endif
<snip>
> diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
> index e5aaae8..1c56f75 100644
> --- a/drivers/dma/ep93xx_dma.c
> +++ b/drivers/dma/ep93xx_dma.c
> @@ -703,7 +703,7 @@ static void ep93xx_dma_tasklet(unsigned long data)
> desc =3D ep93xx_dma_get_active(edmac);
> if (desc) {
> if (desc->complete) {
> - edmac->chan.completed_cookie =3D desc->txd.cookie;
> + dma_cookie_complete(&desc->txd);
> list_splice_init(&edmac->active, &list);
> }
> callback =3D desc->txd.callback;
For ep93xx:
Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH v1 2/9] powerpc/PCI: compute I/O space bus-to-resource offset consistently
From: Bjorn Helgaas @ 2012-03-07 1:00 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-pci, linuxppc-dev
In-Reply-To: <20120307005905.27465.71131.stgit@bhelgaas.mtv.corp.google.com>
Make sure we compute CPU addresses (resource start/end) the same way both
when we set up the I/O aperture (hose->io_resource) and when we use
pcibios_bus_to_resource() to convert BAR values into resources.
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
arch/powerpc/include/asm/pci.h | 1 +
arch/powerpc/kernel/pci-common.c | 8 ++++++--
arch/powerpc/kernel/pci_32.c | 6 +++---
arch/powerpc/kernel/pci_64.c | 2 +-
4 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 201e352..6653f27 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -182,6 +182,7 @@ extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
const struct resource *rsrc,
resource_size_t *start, resource_size_t *end);
+extern resource_size_t pcibios_io_space_offset(struct pci_controller *hose);
extern void pcibios_setup_bus_devices(struct pci_bus *bus);
extern void pcibios_setup_bus_self(struct pci_bus *bus);
extern void pcibios_setup_phb_io_space(struct pci_controller *hose);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 910b9de..2efd52d 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1492,6 +1492,11 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
return pci_enable_resources(dev, mask);
}
+resource_size_t pcibios_io_space_offset(struct pci_controller *hose)
+{
+ return (unsigned long) hose->io_base_virt - _IO_BASE;
+}
+
static void __devinit pcibios_setup_phb_resources(struct pci_controller *hose, struct list_head *resources)
{
struct resource *res;
@@ -1516,8 +1521,7 @@ static void __devinit pcibios_setup_phb_resources(struct pci_controller *hose, s
(unsigned long long)res->start,
(unsigned long long)res->end,
(unsigned long)res->flags);
- pci_add_resource_offset(resources, res,
- (resource_size_t) hose->io_base_virt - _IO_BASE);
+ pci_add_resource_offset(resources, res, pcibios_io_space_offset(hose));
/* Hookup PHB Memory resources */
for (i = 0; i < 3; ++i) {
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index fdd1a3d..4b06ec5 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -219,9 +219,9 @@ void __devinit pcibios_setup_phb_io_space(struct pci_controller *hose)
struct resource *res = &hose->io_resource;
/* Fixup IO space offset */
- io_offset = (unsigned long)hose->io_base_virt - isa_io_base;
- res->start = (res->start + io_offset) & 0xffffffffu;
- res->end = (res->end + io_offset) & 0xffffffffu;
+ io_offset = pcibios_io_space_offset(hose);
+ res->start += io_offset;
+ res->end += io_offset;
}
static int __init pcibios_init(void)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 75417fd..94a54f6 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -168,7 +168,7 @@ static int __devinit pcibios_map_phb_io_space(struct pci_controller *hose)
return -ENOMEM;
/* Fixup hose IO resource */
- io_virt_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
+ io_virt_offset = pcibios_io_space_offset(hose);
hose->io_resource.start += io_virt_offset;
hose->io_resource.end += io_virt_offset;
^ permalink raw reply related
* [PATCH v1 3/9] powerpc/PCI: convert devtree bus addresses to resource
From: Bjorn Helgaas @ 2012-03-07 1:00 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-pci, linuxppc-dev
In-Reply-To: <20120307005905.27465.71131.stgit@bhelgaas.mtv.corp.google.com>
Normal PCI enumeration via PCI config space uses __pci_read_base(), where
the PCI core applies any bus-to-resource offset. But powerpc doesn't use
that path when enumerating via the device tree.
This adds the corresponding bus-to-resource conversion in the paths that
read BAR values from the OF device tree.
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
arch/powerpc/kernel/pci_of_scan.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index b37d0b5..89dde17 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -75,6 +75,7 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
{
u64 base, size;
unsigned int flags;
+ struct pci_bus_region region;
struct resource *res;
const u32 *addrs;
u32 i;
@@ -106,10 +107,11 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
}
- res->start = base;
- res->end = base + size - 1;
res->flags = flags;
res->name = pci_name(dev);
+ region.start = base;
+ region.end = base + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
}
@@ -209,6 +211,7 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
struct pci_bus *bus;
const u32 *busrange, *ranges;
int len, i, mode;
+ struct pci_bus_region region;
struct resource *res;
unsigned int flags;
u64 size;
@@ -270,9 +273,10 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
res = bus->resource[i];
++i;
}
- res->start = of_read_number(&ranges[1], 2);
- res->end = res->start + size - 1;
res->flags = flags;
+ region.start = of_read_number(&ranges[1], 2);
+ region.end = region.start + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
bus->number);
^ permalink raw reply related
* RE: [PATCH 6/9] dmaengine: consolidate tx_status functions
From: H Hartley Sweeten @ 2012-03-07 1:04 UTC (permalink / raw)
To: Russell King - ARM Linux, Dan Williams, Vinod Koul
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <E1S52yd-0002N1-76@rmk-PC.arm.linux.org.uk>
On Tuesday, March 06, 2012 3:35 PM, Russell King wrote:
>
> Now that we have the completed cookie in the dma_chan structure, we
> can consolidate the tx_status functions by providing a function to set
> the txstate structure and returning the DMA status. We also provide
> a separate helper to set the residue for cookies which are still in
> progress.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
<snip>
> drivers/dma/dmaengine.h | 31 +++++++++++++++++++++++++++++++
<snip>
> drivers/dma/ep93xx_dma.c | 7 +------
<snip>
> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
> index 47e0997..1ca5e0e 100644
> --- a/drivers/dma/dmaengine.h
> +++ b/drivers/dma/dmaengine.h
> @@ -45,4 +45,35 @@ static inline void dma_cookie_complete(struct dma_asyn=
c_tx_descriptor *tx)
> tx->cookie =3D 0;
> }
> =20
> +/**
> + * dma_cookie_status - report cookie status
> + * @chan: dma channel
> + * @cookie: cookie we are interested in
> + * @state: dma_tx_state structure to return last/used cookies
> + *
> + * Report the status of the cookie, filling in the state structure if
> + * non-NULL. No locking is required.
> + */
> +static inline enum dma_status dma_cookie_status(struct dma_chan *chan,
> + dma_cookie_t cookie, struct dma_tx_state *state)
> +{
> + dma_cookie_t used, complete;
> +
> + used =3D chan->cookie;
> + complete =3D chan->completed_cookie;
> + barrier();
> + if (state) {
> + state->last =3D complete;
> + state->used =3D used;
> + state->residue =3D 0;
> + }
> + return dma_async_is_complete(cookie, complete, used);
> +}
> +
> +static inline void dma_set_residue(struct dma_tx_state *state, u32 resid=
ue)
> +{
> + if (state)
> + state->residue =3D residue;
> +}
> +
> #endif
<snip>
> diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
> index 1c56f75..142ebf0 100644
> --- a/drivers/dma/ep93xx_dma.c
> +++ b/drivers/dma/ep93xx_dma.c
> @@ -1241,18 +1241,13 @@ static enum dma_status ep93xx_dma_tx_status(struc=
t dma_chan *chan,
> struct dma_tx_state *state)
> {
> struct ep93xx_dma_chan *edmac =3D to_ep93xx_dma_chan(chan);
> - dma_cookie_t last_used, last_completed;
> enum dma_status ret;
> unsigned long flags;
> =20
> spin_lock_irqsave(&edmac->lock, flags);
> - last_used =3D chan->cookie;
> - last_completed =3D chan->completed_cookie;
> + ret =3D dma_cookie_status(chan, cookie, state);
> spin_unlock_irqrestore(&edmac->lock, flags);
> =20
> - ret =3D dma_async_is_complete(cookie, last_completed, last_used);
> - dma_set_tx_state(state, last_completed, last_used, 0);
> -
> return ret;
> }
> =20
For ep93xx:
Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* Re: [PATCH] spufs raises two exceptions
From: Benjamin Herrenschmidt @ 2012-03-07 3:49 UTC (permalink / raw)
To: masterzorag; +Cc: linuxppc-dev, Al Viro, Arnd Bergmann
In-Reply-To: <4F55D84B.7030306@gmail.com>
On Tue, 2012-03-06 at 10:26 +0100, masterzorag wrote:
> I'm running my test program, it uses all available spus to compute via
> OpenCL
> kernel 3.2.5 on a ps3
> even on testing spu directly, it crashes
I think the patch is not 100% right yet. Looking at the code, we
have a real mess of who gets to clean what up here. This is an
attempt at sorting things by having the mutex and dentry dropped
in spufs_create() always. Can you give it a spin (untested):
Al, I'm not familiar with the vfs, can you take a quick look ?
Thanks !
Cheers,
Ben.
>
> =====================================
> [ BUG: bad unlock balance detected! ]
> -------------------------------------
> test/1067 is trying to release lock (&sb->s_type->i_mutex_key) at:
> [<d0000000005828a8>] .do_spu_create+0x90/0xd8 [spufs]
> but there are no more locks to release!
> other info that might help us debug this:
> no locks held by test/1067.
> stack backtrace:
> Call Trace:
> [c00000000e9bfa30] [c0000000000110d0] .show_stack+0x6c/0x16c (unreliable)
> [c00000000e9bfae0] [c000000000081f90] .print_unlock_inbalance_bug+0xe8/0x110
> [c00000000e9bfb70] [c0000000000868cc] .lock_release+0xd8/0x200
> [c00000000e9bfc10] [c0000000003efb60] .__mutex_unlock_slowpath+0x11c/0x1d8
> [c00000000e9bfcb0] [d0000000005828a8] .do_spu_create+0x90/0xd8 [spufs]
> [c00000000e9bfd70] [c0000000000346ac] .sys_spu_create+0x164/0x1c0
> [c00000000e9bfe30] [c0000000000097d8] syscall_exit+0x0/0x40
> ------------[ cut here ]------------
> kernel BUG at fs/dcache.c:474!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=2 NUMA PS3
> Modules linked in: spufs dm_mod btusb bluetooth usb_storage ohci_hcd
> snd_ps3 ehci_hcd snd_pcm snd_page_alloc snd_timer sg snd usbcore
> usb_common ps3flash rtc_ps3 soundcore ps3_lpm ps3vram [last unloaded:
> scsi_wait_scan]
> NIP: c000000000109f94 LR: c000000000109f84 CTR: c0000000000a029c
> REGS: c00000000e9bf930 TRAP: 0700 Not tainted (3.2.5)
> MSR: 8000000000028032 <EE,CE,IR,DR> CR: 22004822 XER: 00000000
> TASK = c0000000062f0ec0[1067] 'test' THREAD: c00000000e9bc000 CPU: 1
> GPR00: 0000000000000001 c00000000e9bfbb0 c0000000006812e8 c00000000543b798
> GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000002
> GPR08: 0000000000000000 0000000000000000 c000000000109f84 c0000000062f0ec0
> GPR12: 0000000082004824 c000000007ffe280 0000000000000004 00000000f7850688
> GPR16: 00000000f7830734 00000000f78517a4 00000000f7852008 00000000f78517a8
> GPR20: 00000000ff805dc0 000000000fd958a0 0000000000000000 000000000000000d
> GPR24: 000000000fd98240 c00000000e101e10 0000000040000010 c00000000616e080
> GPR28: c00000000543b738 c00000000543b798 c0000000006149e8 c00000000543b738
> NIP [c000000000109f94] .dput+0x48/0x214
> LR [c000000000109f84] .dput+0x38/0x214
> Call Trace:
> [c00000000e9bfbb0] [c000000000109f84] .dput+0x38/0x214 (unreliable)
> [c00000000e9bfc50] [c0000000000f1740] .fput+0x24c/0x288
> [c00000000e9bfd00] [c0000000000ed708] .filp_close+0xbc/0xe4
> [c00000000e9bfd90] [c0000000000ed800] .SyS_close+0xd0/0x128
> [c00000000e9bfe30] [c0000000000097d8] syscall_exit+0x0/0x40
> Instruction dump:
> fb61ffd8 fb81ffe0 fba1ffe8 f821ff61 418201c8 3bbf0060 7fa3eb78 482e7f31
> 60000000 813f0058 7d200074 7800d182 <0b000000> 2b890001 409d0010 3809ffff
> ---[ end trace c337aad05d94532f ]---
> ------------[ cut here ]------------
> kernel BUG at fs/dcache.c:474!
> Oops: Exception in kernel mode, sig: 5 [#2]
> SMP NR_CPUS=2 NUMA PS3
> Modules linked in: spufs dm_mod btusb bluetooth usb_storage ohci_hcd
> snd_ps3 ehci_hcd snd_pcm snd_page_alloc snd_timer sg snd usbcore
> usb_common ps3flash rtc_ps3 soundcore ps3_lpm ps3vram [last unloaded:
> scsi_wait_scan]
> NIP: c000000000109f94 LR: c000000000109f84 CTR: c0000000000a029c
> REGS: c00000000e9bec20 TRAP: 0700 Tainted: G D (3.2.5)
> MSR: 8000000000028032 <EE,CE,IR,DR> CR: 22004822 XER: 00000000
> TASK = c0000000062f0ec0[1067] 'test' THREAD: c00000000e9bc000 CPU: 1
> GPR00: 0000000000000001 c00000000e9beea0 c0000000006812e8 c0000000054361c8
> GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000002
> GPR08: 0000000000000000 0000000000000000 c000000000109f84 c0000000062f0ec0
> GPR12: 0000000042004824 c000000007ffe280 0000000000000004 00000000f7850688
> GPR16: 00000000f7830734 00000000f78517a4 00000000f7852008 00000000f78517a8
> GPR20: 00000000ff805dc0 000000000fd958a0 0000000000000000 0000000000000001
> GPR24: 000000000fd98240 c00000000e9b2390 0000000000000008 c0000000062bd010
> GPR28: c000000005436168 c0000000054361c8 c0000000006149e8 c000000005436168
> NIP [c000000000109f94] .dput+0x48/0x214
> LR [c000000000109f84] .dput+0x38/0x214
> Call Trace:
> [c00000000e9beea0] [c000000000109f84] .dput+0x38/0x214 (unreliable)
> [c00000000e9bef40] [c0000000000f1740] .fput+0x24c/0x288
> [c00000000e9beff0] [c0000000000c93a8] .remove_vma+0x68/0xcc
> [c00000000e9bf080] [c0000000000c951c] .exit_mmap+0x110/0x14c
> [c00000000e9bf1a0] [c00000000004b4c8] .mmput+0x5c/0x13c
> [c00000000e9bf230] [d00000000058237c] .spu_forget+0x54/0x7c [spufs]
> [c00000000e9bf2c0] [d00000000057c294] .spufs_dir_close+0x8c/0xc8 [spufs]
> [c00000000e9bf370] [c0000000000f166c] .fput+0x178/0x288
> [c00000000e9bf420] [c0000000000ed708] .filp_close+0xbc/0xe4
> [c00000000e9bf4b0] [c000000000050294] .put_files_struct+0xf4/0x1b8
> [c00000000e9bf560] [c0000000000520bc] .do_exit+0x23c/0x6f4
> [c00000000e9bf660] [c00000000001922c] .die+0x274/0x2a4
> [c00000000e9bf700] [c000000000019640] ._exception+0x88/0x17c
> [c00000000e9bf8c0] [c000000000005314] program_check_common+0x114/0x180
> --- Exception: 700 at .dput+0x48/0x214
> LR = .dput+0x38/0x214
> [c00000000e9bfc50] [c0000000000f1740] .fput+0x24c/0x288
> [c00000000e9bfd00] [c0000000000ed708] .filp_close+0xbc/0xe4
> [c00000000e9bfd90] [c0000000000ed800] .SyS_close+0xd0/0x128
> [c00000000e9bfe30] [c0000000000097d8] syscall_exit+0x0/0x40
> Instruction dump:
> fb61ffd8 fb81ffe0 fba1ffe8 f821ff61 418201c8 3bbf0060 7fa3eb78 482e7f31
> 60000000 813f0058 7d200074 7800d182 <0b000000> 2b890001 409d0010 3809ffff
> ---[ end trace c337aad05d945330 ]---
> Fixing recursive fault but reboot is needed!
>
> First time, the mutex gets unlocked in spufs_create_context, then the
> second time in do_spu_create.
> It seems that SPU main directory dentry has invalid d_count.
>
>
> This patch fixes all, OpenCL is running fine, testing spe runs without
> issues.
>
> --- arch/powerpc/platforms/cell/spufs/syscalls.c
> +++ arch/powerpc/platforms/cell/spufs/syscalls.c.new
> @@ -70,8 +70,8 @@
> ret = PTR_ERR(dentry);
> if (!IS_ERR(dentry)) {
> ret = spufs_create(&path, dentry, flags, mode, neighbor);
> - mutex_unlock(&path.dentry->d_inode->i_mutex);
> - dput(dentry);
> + if (ret < 0)
> + dput(dentry);
> path_put(&path);
> }
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] spufs raises two exceptions
From: Benjamin Herrenschmidt @ 2012-03-07 3:51 UTC (permalink / raw)
To: masterzorag; +Cc: linuxppc-dev, Al Viro, Arnd Bergmann
In-Reply-To: <1331092190.3105.3.camel@pasglop>
On Wed, 2012-03-07 at 14:49 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2012-03-06 at 10:26 +0100, masterzorag wrote:
> > I'm running my test program, it uses all available spus to compute via
> > OpenCL
> > kernel 3.2.5 on a ps3
> > even on testing spu directly, it crashes
>
> I think the patch is not 100% right yet. Looking at the code, we
> have a real mess of who gets to clean what up here. This is an
> attempt at sorting things by having the mutex and dentry dropped
> in spufs_create() always. Can you give it a spin (untested):
>
> Al, I'm not familiar with the vfs, can you take a quick look ?
Better with the actual patch :-)
powerpc/cell: Fix locking in spufs_create()
The error path in spufs_create() could cause double unlocks
among other horrors. Clean it up.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: masterzorag@gmail.com
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index d4a094c..63b4e43 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -454,19 +454,16 @@ spufs_create_context(struct inode *inode, struct dentry *dentry,
struct spu_gang *gang;
struct spu_context *neighbor;
- ret = -EPERM;
if ((flags & SPU_CREATE_NOSCHED) &&
- !capable(CAP_SYS_NICE))
- goto out_unlock;
+ !capable(CAP_SYa_NICE))
+ return -EPERM;
- ret = -EINVAL;
if ((flags & (SPU_CREATE_NOSCHED | SPU_CREATE_ISOLATE))
== SPU_CREATE_ISOLATE)
- goto out_unlock;
+ return -EINVAL;
- ret = -ENODEV;
if ((flags & SPU_CREATE_ISOLATE) && !isolated_loader)
- goto out_unlock;
+ return -ENODEV;
gang = NULL;
neighbor = NULL;
@@ -512,10 +509,6 @@ spufs_create_context(struct inode *inode, struct dentry *dentry,
out_aff_unlock:
if (affinity)
mutex_unlock(&gang->aff_mutex);
-out_unlock:
- mutex_unlock(&inode->i_mutex);
-out:
- dput(dentry);
return ret;
}
@@ -585,11 +578,9 @@ static int spufs_create_gang(struct inode *inode,
struct dentry *dentry,
struct vfsmount *mnt, umode_t mode)
{
- int ret;
-
- ret = spufs_mkgang(inode, dentry, mode & S_IRWXUGO);
+ int ret = spufs_mkgang(inode, dentry, mode & S_IRWXUGO);
if (ret)
- goto out;
+ return ret;
/*
* get references for dget and mntget, will be released
@@ -600,10 +591,6 @@ static int spufs_create_gang(struct inode *inode,
int err = simple_rmdir(inode, dentry);
WARN_ON(err);
}
-
-out:
- mutex_unlock(&inode->i_mutex);
- dput(dentry);
return ret;
}
@@ -613,22 +600,21 @@ static struct file_system_type spufs_type;
long spufs_create(struct path *path, struct dentry *dentry,
unsigned int flags, umode_t mode, struct file *filp)
{
- int ret;
+ int ret = -EINVAL;
- ret = -EINVAL;
/* check if we are on spufs */
if (path->dentry->d_sb->s_type != &spufs_type)
- goto out;
+ goto fail;
/* don't accept undefined flags */
if (flags & (~SPU_CREATE_FLAG_ALL))
- goto out;
+ goto fail;
/* only threads can be underneath a gang */
if (path->dentry != path->dentry->d_sb->s_root) {
if ((flags & SPU_CREATE_GANG) ||
!SPUFS_I(path->dentry->d_inode)->i_gang)
- goto out;
+ goto fail;
}
mode &= ~current_umask();
@@ -640,12 +626,17 @@ long spufs_create(struct path *path, struct dentry *dentry,
ret = spufs_create_context(path->dentry->d_inode,
dentry, path->mnt, flags, mode,
filp);
- if (ret >= 0)
+ if (ret >= 0) {
+ /* We drop these before fsnotify */
+ mutex_unlock(&inode->i_mutex);
+ dput(dentry);
fsnotify_mkdir(path->dentry->d_inode, dentry);
- return ret;
-out:
- mutex_unlock(&path->dentry->d_inode->i_mutex);
+ return ret;
+ }
+ fail:
+ mutex_unlock(&inode->i_mutex);
+ dput(dentry);
return ret;
}
diff --git a/arch/powerpc/platforms/cell/spufs/syscalls.c b/arch/powerpc/platforms/cell/spufs/syscalls.c
index 8591bb6..1a65ef2 100644
--- a/arch/powerpc/platforms/cell/spufs/syscalls.c
+++ b/arch/powerpc/platforms/cell/spufs/syscalls.c
@@ -70,11 +70,8 @@ static long do_spu_create(const char __user *pathname, unsigned int flags,
ret = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
ret = spufs_create(&path, dentry, flags, mode, neighbor);
- mutex_unlock(&path.dentry->d_inode->i_mutex);
- dput(dentry);
path_put(&path);
}
-
return ret;
}
^ permalink raw reply related
* Re: tlb flushing on Power
From: Michael Neuling @ 2012-03-07 5:28 UTC (permalink / raw)
To: Seth Jennings; +Cc: Robert Jennings, linuxppc-dev, Nitin Gupta, Dave Hansen
In-Reply-To: <4F54FE51.8070709@linux.vnet.ibm.com>
Seth,
> Thanks for the help! I was wondering if you could take a look at something
> for me.
>
> I've been working on this staging driver (zsmalloc memory allocator)
> that does virtual mapping of two pages.
>
> I have a github repo with the driver and the unsubmitted changes. I'm
> trying to make to get the pte/tlb stuff working in a portable way:
>
> git://github.com/spartacus06/linux.git (portable branch)
>
> The experimental commits are the top 5 and the branch is based on
> Greg's staging-next + frontswap-v11 patches.
>
> Could you take a look at the zs_map_object() and zs_unmap_object()
> in drivers/staging/zsmalloc/zsmalloc-main.c and see if they should
> work for PPC64?
I suggest you post the code directly to the list in reviewable chucks.
People are much more likely to review it if they don't have to download
some random git tree, checkout some branch, find the changes, etc etc.
If it's work in progress, mark it as an RFC patch and note what issues
you think still exist.
Mikey
^ permalink raw reply
* [PATCH v2] powerpc/dts: fix the compatible string of sec 4.0
From: Shengzhou Liu @ 2012-03-07 5:20 UTC (permalink / raw)
To: linuxppc-dev, stable; +Cc: Liu Shuo, Shengzhou Liu
From: Liu Shuo <shuo.liu@freescale.com>
Fix the compatible string of sec 4.0 to match with CAMM driver according
to Documentation/devicetree/bindings/crypto/fsl-sec4.txt
Signed-off-by: Liu Shuo <shuo.liu@freescale.com>
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
v2: refine description.
arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
index bf957a7..d4c9d5d 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
@@ -33,32 +33,32 @@
*/
crypto@30000 {
- compatible = "fsl,sec4.4", "fsl,sec4.0";
+ compatible = "fsl,sec-v4.4", "fsl,sec-v4.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x30000 0x10000>;
interrupts = <58 2 0 0>;
sec_jr0: jr@1000 {
- compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
+ compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = <45 2 0 0>;
};
sec_jr1: jr@2000 {
- compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
+ compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
reg = <0x2000 0x1000>;
interrupts = <45 2 0 0>;
};
sec_jr2: jr@3000 {
- compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
+ compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
reg = <0x3000 0x1000>;
interrupts = <45 2 0 0>;
};
sec_jr3: jr@4000 {
- compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
+ compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
reg = <0x4000 0x1000>;
interrupts = <45 2 0 0>;
};
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Linus Walleij @ 2012-03-07 8:33 UTC (permalink / raw)
To: Russell King - ARM Linux, Dan Williams, Vinod Koul
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120306223321.GD15201@n2100.arm.linux.org.uk>
On Tue, Mar 6, 2012 at 11:33 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> This patch series cleans up the handling of cookies in DMA engine drivers.
> This is done by providing a set of inline library functions for common
> tasks:
I just applied the latest patches right off and tested with some stressy
MMC operations on the U300 and Ux500. (I had some minor hell
since patch 8/9 and 9/9 were uuencoded but managed to fix it...)
It works like a charm!
The patches look good too.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH 1/9] pci_ids: Add device ID for IBM PCI-X bridge
From: Zhao Chenhui-B35336 @ 2012-03-07 8:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <08B5FFBF-FFF7-45FF-A98D-181CC0E6CEBC@kernel.crashing.org>
> On Mar 6, 2012, at 3:05 AM, Zhao Chenhui wrote:
>=20
> > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > ---
> > include/linux/pci_ids.h | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
>=20
> Just merge this with the 2nd patch that actually uses the ID.
>=20
> - k
Ok. I put it in the file mpc85xx_cds.c.
-Chenhui
^ permalink raw reply
* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Russell King - ARM Linux @ 2012-03-07 9:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Vinod Koul,
Barry Song, Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <CACRpkdYry6G4gi7LdVM4gYOQBKZCoQxdzLAGg1WcjB6rVD-PPQ@mail.gmail.com>
On Wed, Mar 07, 2012 at 09:33:49AM +0100, Linus Walleij wrote:
> On Tue, Mar 6, 2012 at 11:33 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
> > This patch series cleans up the handling of cookies in DMA engine drivers.
> > This is done by providing a set of inline library functions for common
> > tasks:
>
> I just applied the latest patches right off and tested with some stressy
> MMC operations on the U300 and Ux500. (I had some minor hell
> since patch 8/9 and 9/9 were uuencoded but managed to fix it...)
That'll be some MTA deciding to change the encoding, probably because some
MTA spotted UTF-8 characters in the description and decided to convert to
base64.
^ permalink raw reply
* RE: [PATCH 2/9] powerpc/mpc85xxcds: Fix PCI I/O space resource of PCI bridge
From: Zhao Chenhui-B35336 @ 2012-03-07 9:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <7FB9C27D-621B-4DF0-BFE0-CBF2D49B52D6@kernel.crashing.org>
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/p=
latforms/85xx/mpc85xx_cds.c
> > index 40f03da..c009c5b 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
> > @@ -3,7 +3,7 @@
> > *
> > * Maintained by Kumar Gala (see MAINTAINERS for contact information)
> > *
> > - * Copyright 2005 Freescale Semiconductor Inc.
> > + * Copyright 2005, 2011-2012 Freescale Semiconductor Inc.
> > *
> > * This program is free software; you can redistribute it and/or modif=
y it
> > * under the terms of the GNU General Public License as published by=
the
> > @@ -158,6 +158,31 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, 0x3fff, skip_fake_=
bridge);
> > DECLARE_PCI_FIXUP_EARLY(0x3fff, 0x1957, skip_fake_bridge);
> > DECLARE_PCI_FIXUP_EARLY(0xff3f, 0x5719, skip_fake_bridge);
> >
> > +/*
> > + * Fix Tsi310 PCI-X bridge resource.
> > + * Force the bridge to open a window from 0x0000-0x1fff in PCI I/O spa=
ce.
> > + * This allows legacy I/O(i8259, etc) on the VIA southbridge to be acc=
essed.
> > + */
>=20
> This comment and the code don't make sense. Why is the bridge described =
as Tsi310 in comments but the
> vendor ID is IBM ?
This chip is from IBM originally, and bought by IDT.
The vendor ID is IBM, but the part number is Tsi310(IDT).
-Chenhui
>=20
> > +void mpc85xx_cds_fixup_bus(struct pci_bus *bus)
> > +{
> > + struct pci_dev *dev =3D bus->self;
> > + struct resource *res =3D bus->resource[0];
> > +
> > + if (dev !=3D NULL &&
> > + dev->vendor =3D=3D PCI_VENDOR_ID_IBM &&
> > + dev->device =3D=3D PCI_DEVICE_ID_IBM_PCIX_BRIDGE) {
> > + if (res) {
> > + res->start =3D 0;
> > + res->end =3D 0x1fff;
> > + res->flags =3D IORESOURCE_IO;
> > + pr_info("mpc85xx_cds: PCI bridge resource fixup applied\n");
> > + pr_info("mpc85xx_cds: %pR\n", res);
> > + }
> > + }
> > +
> > + fsl_pcibios_fixup_bus(bus);
> > +}
^ permalink raw reply
* Re: [PATCH 2/9] powerpc/mpc85xxcds: Fix PCI I/O space resource of PCI bridge
From: Kumar Gala @ 2012-03-07 10:45 UTC (permalink / raw)
To: Zhao Chenhui-B35336; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <7AA2FF042C086D469F577FA6723434DA015EEA@039-SN1MPN1-002.039d.mgd.msft.net>
On Mar 7, 2012, at 3:31 AM, Zhao Chenhui-B35336 wrote:
>>> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c =
b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
>>> index 40f03da..c009c5b 100644
>>> --- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
>>> +++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
>>> @@ -3,7 +3,7 @@
>>> *
>>> * Maintained by Kumar Gala (see MAINTAINERS for contact information)
>>> *
>>> - * Copyright 2005 Freescale Semiconductor Inc.
>>> + * Copyright 2005, 2011-2012 Freescale Semiconductor Inc.
>>> *
>>> * This program is free software; you can redistribute it and/or =
modify it
>>> * under the terms of the GNU General Public License as published =
by the
>>> @@ -158,6 +158,31 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, 0x3fff, =
skip_fake_bridge);
>>> DECLARE_PCI_FIXUP_EARLY(0x3fff, 0x1957, skip_fake_bridge);
>>> DECLARE_PCI_FIXUP_EARLY(0xff3f, 0x5719, skip_fake_bridge);
>>>=20
>>> +/*
>>> + * Fix Tsi310 PCI-X bridge resource.
>>> + * Force the bridge to open a window from 0x0000-0x1fff in PCI I/O =
space.
>>> + * This allows legacy I/O(i8259, etc) on the VIA southbridge to be =
accessed.
>>> + */
>>=20
>> This comment and the code don't make sense. Why is the bridge =
described as Tsi310 in comments but the
>> vendor ID is IBM ?
>=20
> This chip is from IBM originally, and bought by IDT.
> The vendor ID is IBM, but the part number is Tsi310(IDT).
>=20
Ok, we should probably call it PCI_DEVICE_ID_..._TSI310
- k
^ permalink raw reply
* Re: [PATCH] spufs raises two exceptions
From: Arnd Bergmann @ 2012-03-07 12:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, masterzorag, Al Viro
In-Reply-To: <1331092280.3105.5.camel@pasglop>
On Wednesday 07 March 2012, Benjamin Herrenschmidt wrote:
> On Wed, 2012-03-07 at 14:49 +1100, Benjamin Herrenschmidt wrote:
> > On Tue, 2012-03-06 at 10:26 +0100, masterzorag wrote:
> > > I'm running my test program, it uses all available spus to compute via
> > > OpenCL
> > > kernel 3.2.5 on a ps3
> > > even on testing spu directly, it crashes
> >
> > I think the patch is not 100% right yet. Looking at the code, we
> > have a real mess of who gets to clean what up here. This is an
> > attempt at sorting things by having the mutex and dentry dropped
> > in spufs_create() always. Can you give it a spin (untested):
> >
> > Al, I'm not familiar with the vfs, can you take a quick look ?
>
> Better with the actual patch :-)
>
> powerpc/cell: Fix locking in spufs_create()
>
> The error path in spufs_create() could cause double unlocks
> among other horrors. Clean it up.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Reported-by: masterzorag@gmail.com
>
> diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
> index d4a094c..63b4e43 100644
> --- a/arch/powerpc/platforms/cell/spufs/inode.c
> +++ b/arch/powerpc/platforms/cell/spufs/inode.c
> @@ -454,19 +454,16 @@ spufs_create_context(struct inode *inode, struct dentry *dentry,
> struct spu_gang *gang;
> struct spu_context *neighbor;
>
> - ret = -EPERM;
> if ((flags & SPU_CREATE_NOSCHED) &&
> - !capable(CAP_SYS_NICE))
> - goto out_unlock;
> + !capable(CAP_SYa_NICE))
^typo
> + return -EPERM;
>
> - ret = -EINVAL;
> if ((flags & (SPU_CREATE_NOSCHED | SPU_CREATE_ISOLATE))
> == SPU_CREATE_ISOLATE)
> - goto out_unlock;
> + return -EINVAL;
>
> - ret = -ENODEV;
> if ((flags & SPU_CREATE_ISOLATE) && !isolated_loader)
> - goto out_unlock;
> + return -ENODEV;
>
> gang = NULL;
> neighbor = NULL;
This mostly changes coding style, pointlessly.
> @@ -512,10 +509,6 @@ spufs_create_context(struct inode *inode, struct dentry *dentry,
> out_aff_unlock:
> if (affinity)
> mutex_unlock(&gang->aff_mutex);
> -out_unlock:
> - mutex_unlock(&inode->i_mutex);
> -out:
> - dput(dentry);
> return ret;
> }
The original intention of this was to always unlock in the error case. It
seems that Al changed this in 1ba10681 "switch do_spufs_create() to
user_path_create(), fix double-unlock" to never unlock early but always
unlock in do_spu_create, fixing a different bug, but it looks like
he forgot this one in the process.
The reason why we originally had the unlock in the leaf functions is to
avoid a problem with spu_forget(), which had to be called without
the i_mutex held to avoid deadlocks.
> @@ -600,10 +591,6 @@ static int spufs_create_gang(struct inode *inode,
> int err = simple_rmdir(inode, dentry);
> WARN_ON(err);
> }
> -
> -out:
> - mutex_unlock(&inode->i_mutex);
> - dput(dentry);
> return ret;
> }
Right, this obviously goes together with the one above,
> @@ -613,22 +600,21 @@ static struct file_system_type spufs_type;
> long spufs_create(struct path *path, struct dentry *dentry,
> unsigned int flags, umode_t mode, struct file *filp)
> {
> - int ret;
> + int ret = -EINVAL;
>
> - ret = -EINVAL;
> /* check if we are on spufs */
> if (path->dentry->d_sb->s_type != &spufs_type)
> - goto out;
> + goto fail;
>
> /* don't accept undefined flags */
> if (flags & (~SPU_CREATE_FLAG_ALL))
> - goto out;
> + goto fail;
>
> /* only threads can be underneath a gang */
> if (path->dentry != path->dentry->d_sb->s_root) {
> if ((flags & SPU_CREATE_GANG) ||
> !SPUFS_I(path->dentry->d_inode)->i_gang)
> - goto out;
> + goto fail;
> }
>
> mode &= ~current_umask();
These just change coding style, and not in a helpful way.
> @@ -640,12 +626,17 @@ long spufs_create(struct path *path, struct dentry *dentry,
> ret = spufs_create_context(path->dentry->d_inode,
> dentry, path->mnt, flags, mode,
> filp);
> - if (ret >= 0)
> + if (ret >= 0) {
> + /* We drop these before fsnotify */
> + mutex_unlock(&inode->i_mutex);
> + dput(dentry);
> fsnotify_mkdir(path->dentry->d_inode, dentry);
> - return ret;
>
> -out:
> - mutex_unlock(&path->dentry->d_inode->i_mutex);
> + return ret;
> + }
> + fail:
> + mutex_unlock(&inode->i_mutex);
> + dput(dentry);
> return ret;
> }
>
> diff --git a/arch/powerpc/platforms/cell/spufs/syscalls.c b/arch/powerpc/platforms/cell/spufs/syscalls.c
> index 8591bb6..1a65ef2 100644
> --- a/arch/powerpc/platforms/cell/spufs/syscalls.c
> +++ b/arch/powerpc/platforms/cell/spufs/syscalls.c
> @@ -70,11 +70,8 @@ static long do_spu_create(const char __user *pathname, unsigned int flags,
> ret = PTR_ERR(dentry);
> if (!IS_ERR(dentry)) {
> ret = spufs_create(&path, dentry, flags, mode, neighbor);
> - mutex_unlock(&path.dentry->d_inode->i_mutex);
> - dput(dentry);
> path_put(&path);
> }
> -
> return ret;
> }
This moves the unlock in front of the fsnotify_mkdir, where it was before Al's
change. This seems independent of the other change.
Arnd
^ permalink raw reply
* Re: [PATCH] powerpc/srio: Fix the compile errors when building with 64bit
From: Liu Gang @ 2012-03-07 12:52 UTC (permalink / raw)
To: Kumar Gala
Cc: r58472, Paul Gortmaker, linux-kernel, r61911, Alexandre.Bounine,
akpm, linuxppc-dev, Shaohui Xie
In-Reply-To: <B946A444-73EC-4A70-AA7E-31FAF31FFF13@kernel.crashing.org>
Hi, Kumar,
On Tue, 2012-03-06 at 11:46 -0600, Kumar Gala wrote:
> How about a struct instead:
>
> struct rmu_dmsg {
> u16 dummy;
> u16 tid;
> u16 sid;
> u16 info;
> };
>
> struct rmu_dmsg *dmsg = fsl_dbell->dbell_ring.virt + (in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
>
> Than you can git rid of the DBELL_* macros.
Yes, this can really git rid of the DBELL_* macros and some other code.
I'll update the patch based on your comments.
Thanks a lot.
Liu Gang
^ permalink raw reply
* [PATCH v2] powerpc/srio: Fix the compile errors when building with 64bit
From: Liu Gang @ 2012-03-07 12:55 UTC (permalink / raw)
To: linuxppc-dev, Alexandre.Bounine
Cc: r58472, linux-kernel, r61911, paul.gortmaker, Liu Gang, akpm,
Shaohui Xie
For the file "arch/powerpc/sysdev/fsl_rmu.c", there will be some compile
errors while using the corenet64_smp_defconfig:
.../fsl_rmu.c:315: error: cast from pointer to integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:330: error: cast to pointer from integer of different size
.../fsl_rmu.c:332: error: cast to pointer from integer of different size
.../fsl_rmu.c:339: error: cast to pointer from integer of different size
.../fsl_rmu.c:340: error: cast to pointer from integer of different size
.../fsl_rmu.c:341: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:659: error: cast from pointer to integer of different size
.../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
but argument 5 has type 'size_t'
.../fsl_rmu.c:985: error: cast from pointer to integer of different size
.../fsl_rmu.c:997: error: cast to pointer from integer of different size
Rewrote the corresponding code with the support of 64bit building.
Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Changes in v2:
- Add the struct "rio_dbell_msg" to instead of some DBELL_* macros.
- Change the "virt_buf" to be "void *" type.
- Change "Signed-off-by" to "Reported-by" for Paul.
arch/powerpc/sysdev/fsl_rmu.c | 43 +++++++++++++++++++++-------------------
1 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..1bba6d1 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -100,14 +100,8 @@
#define DOORBELL_DSR_TE 0x00000080
#define DOORBELL_DSR_QFI 0x00000010
#define DOORBELL_DSR_DIQI 0x00000001
-#define DOORBELL_TID_OFFSET 0x02
-#define DOORBELL_SID_OFFSET 0x04
-#define DOORBELL_INFO_OFFSET 0x06
#define DOORBELL_MESSAGE_SIZE 0x08
-#define DBELL_SID(x) (*(u16 *)(x + DOORBELL_SID_OFFSET))
-#define DBELL_TID(x) (*(u16 *)(x + DOORBELL_TID_OFFSET))
-#define DBELL_INF(x) (*(u16 *)(x + DOORBELL_INFO_OFFSET))
struct rio_msg_regs {
u32 omr;
@@ -193,6 +187,13 @@ struct fsl_rmu {
int rxirq;
};
+struct rio_dbell_msg {
+ u16 pad1;
+ u16 tid;
+ u16 sid;
+ u16 info;
+};
+
/**
* fsl_rio_tx_handler - MPC85xx outbound message interrupt handler
* @irq: Linux interrupt number
@@ -311,8 +312,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
/* XXX Need to check/dispatch until queue empty */
if (dsr & DOORBELL_DSR_DIQI) {
- u32 dmsg =
- (u32) fsl_dbell->dbell_ring.virt +
+ struct rio_dbell_msg *dmsg =
+ fsl_dbell->dbell_ring.virt +
(in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
struct rio_dbell *dbell;
int found = 0;
@@ -320,25 +321,25 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: processing doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg), DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid, dmsg->info);
for (i = 0; i < MAX_PORT_NUM; i++) {
if (fsl_dbell->mport[i]) {
list_for_each_entry(dbell,
&fsl_dbell->mport[i]->dbells, node) {
if ((dbell->res->start
- <= DBELL_INF(dmsg))
+ <= dmsg->info)
&& (dbell->res->end
- >= DBELL_INF(dmsg))) {
+ >= dmsg->info)) {
found = 1;
break;
}
}
if (found && dbell->dinb) {
dbell->dinb(fsl_dbell->mport[i],
- dbell->dev_id, DBELL_SID(dmsg),
- DBELL_TID(dmsg),
- DBELL_INF(dmsg));
+ dbell->dev_id, dmsg->sid,
+ dmsg->tid,
+ dmsg->info);
break;
}
}
@@ -348,8 +349,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: spurious doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg),
- DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid,
+ dmsg->info);
}
setbits32(&fsl_dbell->dbell_regs->dmr, DOORBELL_DMR_DI);
out_be32(&fsl_dbell->dbell_regs->dsr, DOORBELL_DSR_DIQI);
@@ -657,7 +658,8 @@ fsl_add_outb_message(struct rio_mport *mport, struct rio_dev *rdev, int mbox,
int ret = 0;
pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d buffer " \
- "%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer, len);
+ "%8.8lx len %8.8zx\n", rdev->destid, mbox,
+ (unsigned long)buffer, len);
if ((len < 8) || (len > RIO_MAX_MSG_SIZE)) {
ret = -EINVAL;
goto out;
@@ -972,7 +974,8 @@ out:
void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
{
struct fsl_rmu *rmu = GET_RMM_HANDLE(mport);
- u32 phys_buf, virt_buf;
+ u32 phys_buf;
+ void *virt_buf;
void *buf = NULL;
int buf_idx;
@@ -982,7 +985,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
if (phys_buf == in_be32(&rmu->msg_regs->ifqepar))
goto out2;
- virt_buf = (u32) rmu->msg_rx_ring.virt + (phys_buf
+ virt_buf = rmu->msg_rx_ring.virt + (phys_buf
- rmu->msg_rx_ring.phys);
buf_idx = (phys_buf - rmu->msg_rx_ring.phys) / RIO_MAX_MSG_SIZE;
buf = rmu->msg_rx_ring.virt_buffer[buf_idx];
@@ -994,7 +997,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
}
/* Copy max message size, caller is expected to allocate that big */
- memcpy(buf, (void *)virt_buf, RIO_MAX_MSG_SIZE);
+ memcpy(buf, virt_buf, RIO_MAX_MSG_SIZE);
/* Clear the available buffer */
rmu->msg_rx_ring.virt_buffer[buf_idx] = NULL;
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH v2] powerpc/srio: Fix the compile errors when building with 64bit
From: David Laight @ 2012-03-07 13:18 UTC (permalink / raw)
To: Liu Gang, linuxppc-dev, Alexandre.Bounine
Cc: Shaohui Xie, r61911, linux-kernel, paul.gortmaker, akpm, r58472
In-Reply-To: <1331124924-18838-1-git-send-email-Gang.Liu@freescale.com>
> diff --git a/arch/powerpc/sysdev/fsl_rmu.c
b/arch/powerpc/sysdev/fsl_rmu.c
> index 1548578..1bba6d1 100644
> --- a/arch/powerpc/sysdev/fsl_rmu.c
> +++ b/arch/powerpc/sysdev/fsl_rmu.c
> @@ -657,7 +658,8 @@ fsl_add_outb_message(struct rio_mport=20
> *mport, struct rio_dev *rdev, int mbox,
> int ret =3D 0;
> =20
> pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d
buffer " \
> - "%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer,
len);
> + "%8.8lx len %8.8zx\n", rdev->destid, mbox,
> + (unsigned long)buffer, len);
Should 'buffer' be printed with %p ??
David
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/e500: make load_up_spe a normal fuction
From: Alexander Graf @ 2012-03-07 13:53 UTC (permalink / raw)
To: Yin Olivia-R63875
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <B5012D5F6E2BBC4DBF16B3E6037A5B7316CCE0@039-SN1MPN1-004.039d.mgd.msft.net>
On 02/28/2012 08:09 AM, Yin Olivia-R63875 wrote:
> Hi Scott,
>
> This had been reviewed before and accepted by internal tree.
> http://linux.freescale.net/patchwork/patch/11100/
> http://git.am.freescale.net/gitolite/gitweb.cgi/sdk/kvm.git/commit/?h=for-sdk1.2&id=c5088844dc665dbdae4fa51b8d58dc203bacc17e
>
> I didn't change anything except the line.
> I just commit to external kvm-ppc mailing list. Should I add my own Signed-off-by?
Yes, if you just take a patch from someone else and direct it to another
tree, you keep the From: line (git cherry-pick or git am should do that
automatically for you) and add your own SOB-line (git am -s can do that
for example).
Since you're also supposed to change the description, please note that
between Yu's SOB line and your SOB line with something like
Signed-off-by: Liu Yu<yu.liu@freescale.com>
[olivia: change description]
Signed-off-by: Olivia Yin<r63875@freescale.com>
Alex
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/e500: make load_up_spe a normal fuction
From: Alexander Graf @ 2012-03-07 13:56 UTC (permalink / raw)
To: Olivia Yin; +Cc: Liu Yu, kvm, B04825, kvm-ppc, Scott Wood, linuxppc-dev
In-Reply-To: <1330564819-11139-1-git-send-email-hong-hua.yin@freescale.com>
On 03/01/2012 02:20 AM, Olivia Yin wrote:
> From: Liu Yu<yu.liu@freescale.com>
>
> So that we can call it when improving SPE switch like book3e did for fp switch.
Timur / Scott, can you please (n)ack this one?
Alex
> Signed-off-by: Liu Yu<yu.liu@freescale.com>
> Signed-off-by: Olivia Yin<hong-hua.yin@freescale.com>
> ---
> v2: add Signed-off-by
>
> arch/powerpc/kernel/head_fsl_booke.S | 23 ++++++-----------------
> 1 files changed, 6 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> index d5d78c4..c96e025 100644
> --- a/arch/powerpc/kernel/head_fsl_booke.S
> +++ b/arch/powerpc/kernel/head_fsl_booke.S
> @@ -539,8 +539,10 @@ interrupt_base:
> /* SPE Unavailable */
> START_EXCEPTION(SPEUnavailable)
> NORMAL_EXCEPTION_PROLOG
> - bne load_up_spe
> - addi r3,r1,STACK_FRAME_OVERHEAD
> + beq 1f
> + bl load_up_spe
> + b fast_exception_return
> +1: addi r3,r1,STACK_FRAME_OVERHEAD
> EXC_XFER_EE_LITE(0x2010, KernelSPE)
> #else
> EXCEPTION(0x2020, SPEUnavailable, unknown_exception, EXC_XFER_EE)
> @@ -743,7 +745,7 @@ tlb_write_entry:
> /* Note that the SPE support is closely modeled after the AltiVec
> * support. Changes to one are likely to be applicable to the
> * other! */
> -load_up_spe:
> +_GLOBAL(load_up_spe)
> /*
> * Disable SPE for the task which had SPE previously,
> * and save its SPE registers in its thread_struct.
> @@ -791,20 +793,7 @@ load_up_spe:
> subi r4,r5,THREAD
> stw r4,last_task_used_spe@l(r3)
> #endif /* !CONFIG_SMP */
> - /* restore registers and return */
> -2: REST_4GPRS(3, r11)
> - lwz r10,_CCR(r11)
> - REST_GPR(1, r11)
> - mtcr r10
> - lwz r10,_LINK(r11)
> - mtlr r10
> - REST_GPR(10, r11)
> - mtspr SPRN_SRR1,r9
> - mtspr SPRN_SRR0,r12
> - REST_GPR(9, r11)
> - REST_GPR(12, r11)
> - lwz r11,GPR11(r11)
> - rfi
> + blr
>
> /*
> * SPE unavailable trap from kernel - print a message, but let
^ permalink raw reply
* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Vinod Koul @ 2012-03-07 13:54 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120306223321.GD15201@n2100.arm.linux.org.uk>
On Tue, 2012-03-06 at 22:33 +0000, Russell King - ARM Linux wrote:
> [v2 - more or less same description. Including lakml in cc for the full
> set]
>
> This patch series cleans up the handling of cookies in DMA engine drivers.
> This is done by providing a set of inline library functions for common
> tasks:
>
> - moving the 'last completed cookie' into struct dma_chan - everyone
> has this in their driver private channel data structure
>
> - consolidate allocation of cookies to DMA descriptors
>
> - common way to update 'last completed cookie' value
>
> - standard way to implement tx_status callback and update the residue
>
> - consolidate initialization of cookies
>
> - update implementations differing from the majority of DMA engine drivers
> to behave the same as the majority implementation in respect of cookies
>
> What this means is that we get to the point where all DMA engine drivers
> will hand out cookie value '2' as the first, and incrementing cookie
> values up to INT_MAX, returning to cookie '1' as the next cookie.
>
> Think of this patch series as round 1... I am hoping over time that more
> code can be consolidated between the DMA engine drivers and end up with a
> consistent way to handle various common themes in DMA engine hardware
> (like physical channel<->peripheral request signal selection.)
Thanks Russell,
I have tested this on atom today, and as expected works flawlessly :)
After all acks, I can merge or these can go thru your tree with my Ack.
Either way is okay.
I applied the v2 on a branch and also rebased on top of slave-dma.next.
There were few conflicts in imx-dma.c. Sacha, Javier, pls see that merge
is right.
This branch (rmk_cookie_fixes2_rebased) is not yet pushed, as I am not
able to connect to infradead.org, should be done when server is back.
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2] powerpc/dts: fix the compatible string of sec 4.0
From: Haiying Wang @ 2012-03-07 14:45 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linuxppc-dev, stable, Liu Shuo
In-Reply-To: <1331097606-22407-1-git-send-email-Shengzhou.Liu@freescale.com>
On Wed, 2012-03-07 at 13:20 +0800, Shengzhou Liu wrote:
> From: Liu Shuo <shuo.liu@freescale.com>
>
> Fix the compatible string of sec 4.0 to match with CAMM driver according
%s/CAMM/CAAM.
Haiying
> to Documentation/devicetree/bindings/crypto/fsl-sec4.txt
>
> Signed-off-by: Liu Shuo <shuo.liu@freescale.com>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> v2: refine description.
>
> arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
> index bf957a7..d4c9d5d 100644
> --- a/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
> @@ -33,32 +33,32 @@
> */
>
> crypto@30000 {
> - compatible = "fsl,sec4.4", "fsl,sec4.0";
> + compatible = "fsl,sec-v4.4", "fsl,sec-v4.0";
> #address-cells = <1>;
> #size-cells = <1>;
> reg = <0x30000 0x10000>;
> interrupts = <58 2 0 0>;
>
> sec_jr0: jr@1000 {
> - compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
> + compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
> reg = <0x1000 0x1000>;
> interrupts = <45 2 0 0>;
> };
>
> sec_jr1: jr@2000 {
> - compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
> + compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
> reg = <0x2000 0x1000>;
> interrupts = <45 2 0 0>;
> };
>
> sec_jr2: jr@3000 {
> - compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
> + compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
> reg = <0x3000 0x1000>;
> interrupts = <45 2 0 0>;
> };
>
> sec_jr3: jr@4000 {
> - compatible = "fsl,sec4.4-job-ring", "fsl,sec4.0-job-ring";
> + compatible = "fsl,sec-v4.4-job-ring", "fsl,sec-v4.0-job-ring";
> reg = <0x4000 0x1000>;
> interrupts = <45 2 0 0>;
> };
^ permalink raw reply
* Re: [PATCH 6/9] powerpc/mpc8548cds: Add FPGA node to dts
From: Tabi Timur-B04825 @ 2012-03-07 16:22 UTC (permalink / raw)
To: Zhao Chenhui-B35336; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1331024805-15926-5-git-send-email-chenhui.zhao@freescale.com>
On Tue, Mar 6, 2012 at 3:06 AM, Zhao Chenhui <chenhui.zhao@freescale.com> w=
rote:
> From: chenhui zhao <chenhui.zhao@freescale.com>
>
> Remove FPGA(CADMUS) macros in code. Move it to dts.
>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 6/9] powerpc/mpc8548cds: Add FPGA node to dts
From: Timur Tabi @ 2012-03-07 16:24 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev
In-Reply-To: <1331024805-15926-5-git-send-email-chenhui.zhao@freescale.com>
On Tue, Mar 6, 2012 at 3:06 AM, Zhao Chenhui <chenhui.zhao@freescale.com>
wrote:
> From: chenhui zhao <chenhui.zhao@freescale.com>
>
> Remove FPGA(CADMUS) macros in code. Move it to dts.
>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ 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