On 2013年03月23日 03:17, Yoder Stuart-B08248 wrote:
> allmodconfig is creating config combinations that don't
> happen in a normal build (at least currently)-- 64-bit build
> that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64.
if it should not happen.
can we add dependency to let it will never h
Added the following domain attributes for the FSL PAMU driver:
1. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
2. Added an attribute for enabling/disabling DMA to a particular
memory window.
3. Added domain attribute to chec
Add an iommu domain pointer to device (powerpc) archdata. Devices
are attached to iommu domains and this pointer provides a mechanism
to correlate between a device and the associated iommu domain. This
field is set when a device is attached to a domain.
Signed-off-by: Varun Sethi
---
- no chang
Each iommu window can have access permissions associated with it. Extended the
window_enable API to incorporate window access permissions.
In case of PAMU each window can have its specific set of permissions.
Signed-off-by: Varun Sethi
---
- no change in v10.
drivers/iommu/iommu.c |5 +++--
This is required in case of PAMU, as it can support a window size of up
to 64G (even on 32bit).
Signed-off-by: Varun Sethi
---
- no change in v10.
drivers/iommu/amd_iommu.c |2 +-
drivers/iommu/exynos-iommu.c |2 +-
drivers/iommu/intel-iommu.c|2 +-
drivers/iommu/iommu.c
This patchset provides the Freescale PAMU (Peripheral Access Management Unit)
driver
and the corresponding IOMMU API implementation. PAMU is the IOMMU present on
Freescale
QorIQ platforms. PAMU can authorize memory access, remap the memory address,
and remap
the I/O transaction type.
This set
On 03/22/2013 01:14:51 AM, Wang Dongsheng-B40534 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, March 21, 2013 7:00 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
> Li Yang-R58472
> Subject: Re: [PATC
On 03/22/2013 05:58:37 AM, Johannes Berg wrote:
On Tue, 2013-03-19 at 17:16 -0500, Scott Wood wrote:
> > > I wonder about kernel modules, though flushing 32 MiB wouldn't
be
> > > adequate there.
> >
> > Good question, but would they be running? You have to have
everything
> > built in that
On 03/22/2013 12:46:24 AM, Wang Dongsheng-B40534 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, March 21, 2013 5:49 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
> Zhao Chenhui-B35336; Li Yang-R58472
> -Original Message-
> From: Michael Neuling [mailto:mi...@neuling.org]
> Sent: Thursday, March 21, 2013 6:21 PM
> To: Chen Gang F T; Yoder Stuart-B08248; Kumar Gala
> Cc: Chen Gang; Benjamin Herrenschmidt; s...@canb.auug.org.au;
> pau...@samba.org; m...@ozlabs.org;
> imun...@au1.ibm.com
From: Stuart Yoder
For 32-bit, CONFIG_EPAPR_PARAVIRT pulls in both epapr_paravirt.c
and epapr_hcalls.c which contains the 32-bit paravirt idle loop.
For 64-bit, the paravirt idle loop is in idle_book3e.S and that
source file is included only if CONFIG_PPC_BOOK3E_64 defined.
This patch makes tha
---
I took a stab at impl. IFF_UNICAST_FLT as an exercise but I
didn't get around to test it. So I figured perhaps someone else
wants/need it so here is a start. With any luck it will work
as is. This is on 3.0 so it might not apply without tweaks.
drivers/net/ethernet/freescale/ucc_geth.c | 22
* Vaidyanathan Srinivasan [2013-03-22 21:19:35]:
[snip]
> Prior to the above commit:
> #define node_distance(from,to)
> ((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE)
>
> Restoring compatible behavior with this patch for old powerpc systems
> with device tree wher
powerpc: fix numa distance for form0 device tree
The following commit breaks numa distance setup for old powerpc
systems that use form0 encoding in device tree.
commit 41eab6f88f24124df89e38067b3766b7bef06ddb
powerpc/numa: Use form 1 affinity to setup node dist
From: Ananth N Mavinakayanahalli
prepare_uprobe() already checks if the underlying unstruction
(on file) is a trap variant. We don't need to check this again.
Signed-off-by: Ananth N Mavinakayanahalli
---
arch/powerpc/kernel/uprobes.c |6 --
1 file changed, 6 deletions(-)
Index: linux
From: Ananth N Mavinakayanahalli
Powerpc has many trap variants that could be used by entities like gdb.
Currently, running gdb on a program being traced by uprobes causes an
endless loop since uprobes doesn't understand that the trap was inserted
by some other entity and a SIGTRAP needs to be de
From: Ananth N Mavinakayanahalli
Refuse to place a uprobe if a trap variant already exists in the
file copy at the address.
Signed-off-by: Ananth N Mavinakayanahalli
---
kernel/events/uprobes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-3.9-rc3/kernel/events/uprobes
From: Ananth N Mavinakayanahalli
Some architectures like powerpc have multiple variants of the trap
instruction. Introduce an additional helper is_trap_insn() for run-time
handling of non-uprobe traps on such architectures.
While there, change is_swbp_at_addr() to is_trap_at_addr() for reading
c
On Fri, Mar 22, 2013 at 03:54:06PM +0100, Oleg Nesterov wrote:
> On 03/22, Ananth N Mavinakayanahalli wrote:
> >
> > +/**
> > + * is_trap_insn - check if instruction is breakpoint instruction.
> > + * @insn: instruction to be checked.
> > + * Default implementation of is_trap_insn
> > + * Returns t
On 03/22, Ananth N Mavinakayanahalli wrote:
>
> +/**
> + * is_trap_insn - check if instruction is breakpoint instruction.
> + * @insn: instruction to be checked.
> + * Default implementation of is_trap_insn
> + * Returns true if @insn is a breakpoint instruction.
> + *
> + * This function is needed
On 03/22, Ananth N Mavinakayanahalli wrote:
>
> On Thu, Mar 21, 2013 at 04:58:09PM +0100, Oleg Nesterov wrote:
> >
> > - verify_opcode()->is_swbp_insn() means:
> >
> > is this insn fine for uprobe? (we do not care about
> > gdb, we simply ignore this problem)
>
> I will
Le 03/22/13 15:29, Jason Cooper a écrit :
Ok, thanks! Does that mean that you want these changes to go via
your tree? David initially applied my v2 of this patchset, and since
it thouches mostly ethernet driver stuff, I would rather make it go
via his tree if both of you agree.
Yeah, I thought
On Fri, Mar 22, 2013 at 03:24:55PM +0100, Florian Fainelli wrote:
> Le 03/22/13 15:14, Jason Cooper a écrit :
> >On Fri, Mar 22, 2013 at 02:39:24PM +0100, Florian Fainelli wrote:
> >>Hi all,
> >>
> >>This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
> >>instead of rolling
From: Florian Fainelli
Date: Fri, 22 Mar 2013 14:39:24 +0100
> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
> instead of rolling its own implementation. As a result, all users of this
> mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
>
Le 03/22/13 15:14, Jason Cooper a écrit :
On Fri, Mar 22, 2013 at 02:39:24PM +0100, Florian Fainelli wrote:
Hi all,
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a result, all users of this
mv643xx_eth driver are conve
On Fri, Mar 22, 2013 at 1:43 AM, Zhicheng Fan wrote:
> + qe: qe@fffe8 {
> + ranges = <0x0 0xf 0xffe8 0x4>;
> + reg = <0xf 0xffe8 0 0x480>;
> + brg-frequency = <0>;
> + bus-frequency = <0>;
These four lines should be un
On Fri, Mar 22, 2013 at 02:39:24PM +0100, Florian Fainelli wrote:
> Hi all,
>
> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
> instead of rolling its own implementation. As a result, all users of this
> mv643xx_eth driver are converted to register an "orion-mdio" pl
Hello,
On Fri, 22 Mar 2013 14:39:24 +0100, Florian Fainelli wrote:
> Hi all,
>
> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
> instead of rolling its own implementation. As a result, all users of this
> mv643xx_eth driver are converted to register an "orion-mdio"
This isn't specifically needed in order to build the kernel. It's
stored in flash with firmware. However, keep it in the kernel for
reference (and to have an example for fsl_dpa device tree usage).
Signed-off-by: Ben Collins
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/boot/dts/sgy-cts-100
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver voluntarily overlaps
with the Marvell Ethernet s
This patch renames the base register cookie in the mvmdio drive from
"smireg" to "regs" since a subsequent patch is going to use an ioremap()
cookie whose size is larger than a single register of 4 bytes. No
functionnal code change introduced.
Acked-by: Thomas Petazzoni
Signed-off-by: Florian Fai
This patch enhances the "mvmdio" to support a SMI error/done interrupt
line which can be used along with a wait queue instead of doing
busy-waiting on the registers. This is a feature which is available in
the mv643xx_eth SMI code and thus reduces again the gap between the two.
Signed-off-by: Flor
This patch changes the mvmdio driver not to use device tree
helper functions such as of_mdiobus_register() and of_iomap() so we can
instantiate this driver using a classic platform_device approach. Use
the device manager helper to ioremap() the base register cookie so we
get automatic freeing upon
Hi all,
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a result, all users of this
mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
The mvmdio driver is also updated to support an interrupt lin
On Fri, Mar 22, 2013 at 02:35:50PM +1100, Stephen Rothwell wrote:
> Fixes these build error when CONFIG_KVM is not defined:
>
> In file included from arch/powerpc/include/asm/kvm_ppc.h:33:0,
> from arch/powerpc/kernel/setup_64.c:67:
> arch/powerpc/include/asm/kvm_book3s.h:65:20: e
Zhicheng Fan wrote:
Hi Timur,
you are right ,the QE can not support the 36-bit , I test it on
the p1025 ,the qe can not work
but we need the qe node , becase the dts include the
fsl/p1021si-post.dtsi
that needed, I will send other patch
My suggestion: with a 36-bit
From: Ananth N Mavinakayanahalli
The current implementation of uprobes assumes that uprobes always wins
even when a register request is at a location with a conditional
breakpoint by some other entity. Refer to [1] for more details.
Remove the breakpoint instruction check during registration on
From: Ananth N Mavinakayanahalli
Powerpc has many trap variants that could be used by entities like gdb.
Currently, running gdb on a program being traced by uprobes causes an
endless loop since uprobes doesn't understand that the trap was inserted
by some other entity and a SIGTRAP needs to be de
From: Ananth N Mavinakayanahalli
Some architectures like powerpc have multiple variants of the trap
instruction. Introduce an additional helper is_trap_insn() for run-time
handling of non-uprobe traps on such architectures.
While there, change is_swbp_at_addr() to is_trap_at_addr() for reading
c
On Tue, 2013-03-19 at 17:16 -0500, Scott Wood wrote:
> > > I wonder about kernel modules, though flushing 32 MiB wouldn't be
> > > adequate there.
> >
> > Good question, but would they be running? You have to have everything
> > built in that you need to load the image? Or maybe not, with the
> >
fix the following errors:
Error: arch/powerpc/boot/dts/p1025rdb.dtsi:326.2-3 label or path, 'qe',
not found
Error: arch/powerpc/boot/dts/fsl/p1021si-post.dtsi:242.2-3 label or
path, 'qe', not found
FATAL ERROR: Syntax error parsing input tree
Signed-off-by: Zhicheng Fan
On 03/22/2013 02:42 AM, Timur Tabi wrote:
On Thu, Mar 21, 2013 at 4:26 AM, Zhicheng Fan wrote:
+ qe: qe@fffe8 {
+ ranges = <0x0 0xf 0xffe8 0x4>;
Are you sure this works? The QE can't handle 36-bit addresses, and I
think the MURAM is located inside the QE addres
42 matches
Mail list logo
