Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: Stephen Boyd sb...@codeaurora.org Date: Fri, 6 May 2011 22:57:11 -0700 Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way. Move it to lib/Kconfig.debug so each arch doesn't have to define it. This obviously makes the option generic, but that's fine because the config is already used in generic code. It's not obvious to me that sysrq-P actually does anything different with this option enabled, but I erred on the side of caution by keeping the most inclusive wording. Cc: linux-a...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-dist-de...@blackfin.uclinux.org Cc: linux-m...@ml.linux-m32r.org Cc: linux-m...@linux-mips.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: Chris Metcalf cmetc...@tilera.com Cc: user-mode-linux-de...@lists.sourceforge.net Cc: x...@kernel.org Signed-off-by: Stephen Boyd sb...@codeaurora.org Acked-by: David S. Miller da...@davemloft.net ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
On Sat, May 7, 2011 at 7:57 AM, Stephen Boyd sb...@codeaurora.org wrote: Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way. Move it to lib/Kconfig.debug so each arch doesn't have to define it. This obviously makes the option generic, but that's fine because the config is already used in generic code. It's not obvious to me that sysrq-P actually does anything different with this option enabled, but I erred on the side of caution by keeping the most inclusive wording. Cc: linux-a...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-dist-de...@blackfin.uclinux.org Cc: linux-m...@ml.linux-m32r.org Cc: linux-m...@linux-mips.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: Chris Metcalf cmetc...@tilera.com Cc: user-mode-linux-de...@lists.sourceforge.net Cc: x...@kernel.org Signed-off-by: Stephen Boyd sb...@codeaurora.org --- Acked-by: Richard Weinberger rich...@nod.at -- Thanks, //richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Regarding P2020 in AMP mode
Hi,
I'm running P2020 in AMP mode, each core running its linux os.
Ethernet 1(@25000) and Ethernet 2(@26000) assigned to Core0 are working
fine.
I'm facing problems with Ethernet interface(@24000) assigned to Core1, its
not working.
I'm using dts file which were added by :
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-September/075594.html
Looks either there is some mistake in the dts file or my understanding is
wrong.
MDIO @24000 is defined in core0 dts file though the Ethernet is assigned to
Core 1.
DTS files :
http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
mdio@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 0x24520 0x20;
phy0: ethernet-phy@0 {
interrupt-parent = mpic;
interrupts = 3 1;
reg = 0x0;
};
phy1: ethernet-phy@1 {
interrupt-parent = mpic;
interrupts = 3 1;
reg = 0x1;
};
};
Also, MDIO for 25520 has wrong register value:
mdio@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 0x26520 0x20;
tbi0: tbi-phy@11 {
reg = 0x11;
device_type = tbi-phy;
};
};
Please correct me if I'm wrong. Has freescale released a working dts files
for P2020 in AMP mode ? as this seems to be not working.
Best Regards
Prasanna Khanapur.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
On Sat, May 7, 2011 at 01:57, Stephen Boyd wrote: Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way. Move it to lib/Kconfig.debug so each arch doesn't have to define it. This obviously makes the option generic, but that's fine because the config is already used in generic code. It's not obvious to me that sysrq-P actually does anything different with this option enabled, but I erred on the side of caution by keeping the most inclusive wording. Cc: uclinux-dist-de...@blackfin.uclinux.org arch/blackfin/Kconfig.debug | 9 - Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] ppc64: Fix compiler warning in pgtable-ppc64.h [-Wunused-but-set-variable]
The variable 'old' is set but not used in the wrprotect functions in
arch/powerpc/include/asm/pgtable-ppc64.h, which can trigger a compiler warning.
Remove the variable, since it's not used anyway.
Signed-off-by: Stratos Psomadakis pso...@ece.ntua.gr
---
arch/powerpc/include/asm/pgtable-ppc64.h | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index 2b09cd5..0b27dba 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -257,21 +257,20 @@ static inline int __ptep_test_and_clear_young(struct
mm_struct *mm,
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- unsigned long old;
- if ((pte_val(*ptep) _PAGE_RW) == 0)
- return;
- old = pte_update(mm, addr, ptep, _PAGE_RW, 0);
+ if ((pte_val(*ptep) _PAGE_RW) == 0)
+ return;
+
+ pte_update(mm, addr, ptep, _PAGE_RW, 0);
}
static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
{
- unsigned long old;
-
if ((pte_val(*ptep) _PAGE_RW) == 0)
return;
- old = pte_update(mm, addr, ptep, _PAGE_RW, 1);
+
+ pte_update(mm, addr, ptep, _PAGE_RW, 1);
}
/*
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] ppc/cleaup: Fix compiler warnings
Fix compiler warnings in ppc code, which can lead to build failure, if CONFIG_PPC_WERROR is set (default). arch/powerpc/include/asm/pgtable-ppc64.h | 13 ++--- arch/powerpc/kernel/Makefile |2 +- 2 files changed, 7 insertions(+), 8 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
The trick used to bypass the thread_struct fpr array in order to access the struct fpscr, in arch/powerpc/kernel/ptrace.c, can trigger an array subscript is above array bounds [-Werror=array-bounds] warning. Add -Wno-array-bounds to CFLAGS_ptrace.o, in arch/powerpc/kernel/Makefile to slience this warning. Signed-off-by: Stratos Psomadakis pso...@ece.ntua.gr --- arch/powerpc/kernel/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 3bb2a3e..92b1002 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -2,7 +2,7 @@ # Makefile for the linux kernel. # -CFLAGS_ptrace.o+= -DUTS_MACHINE='$(UTS_MACHINE)' +CFLAGS_ptrace.o+= -DUTS_MACHINE='$(UTS_MACHINE)' -Wno-array-bounds subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
Stratos Psomadakis pso...@cslab.ece.ntua.gr writes: +CFLAGS_ptrace.o += -DUTS_MACHINE='$(UTS_MACHINE)' -Wno-array-bounds You need to check first whether the option is valid. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RESEND PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
The trick used to bypass the thread_struct fpr array in order to access the struct fpscr, in arch/powerpc/kernel/ptrace.c, can trigger an array subscript is above array bounds [-Werror=array-bounds] warning. Add -Wno-array-bounds to CFLAGS_ptrace.o, in arch/powerpc/kernel/Makefile to slience this warning. Signed-off-by: Stratos Psomadakis pso...@ece.ntua.gr --- arch/powerpc/kernel/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 3bb2a3e..92b1002 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -2,7 +2,7 @@ # Makefile for the linux kernel. # -CFLAGS_ptrace.o+= -DUTS_MACHINE='$(UTS_MACHINE)' +CFLAGS_ptrace.o+= -DUTS_MACHINE='$(UTS_MACHINE)' $(call cc-option, -Wno-array-bounds) subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
On 05/07/2011 06:18 PM, Andreas Schwab wrote: Stratos Psomadakis pso...@cslab.ece.ntua.gr writes: +CFLAGS_ptrace.o += -DUTS_MACHINE='$(UTS_MACHINE)' -Wno-array-bounds You need to check first whether the option is valid. Andreas. I resent the patch, with $(call cc-option) to check if GCC supports the option. Is it ok? Thx. -- Stratos Psomadakis pso...@ece.ntua.gr ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PCI: portdrv: fix irq initialization on FSL pcie host controller
On Apr 28, 2011, at 3:01 AM, Xu Lei wrote: Any feedback on this patch? Thanks. On Friday, 2011-04-22 at 15:43 +0800, Lei Xu wrote: Root complex ports for Freescale PCIe host controller only receive interrupts, so if there is no irq setting for RC, it should not return error, otherwise it may result the PCIe host controller is disabled. Signed-off-by: Lei Xu b33...@freescale.com --- drivers/pci/pcie/portdrv_core.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index 595654a..95e64c8 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -209,7 +209,10 @@ static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask) irqs[i] = irq; irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1; -if (irq 0) +/* Root complex ports for Freescale PCIe host controller only + * receive interrupts, so if there is no irq setting for RC, + * it should not return error. */ +if ((irq 0) (dev-pcie_type != PCI_EXP_TYPE_ROOT_PORT)) return -ENODEV; return 0; } -- Regards Lei Reviewing this in more detail this is not the right solution. We should have an dev-irq set and need to fix that. The means to accomplish that is by fixing up the device tree to properly get the interrupt assigned to the root complex node. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
