Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: Stephen Boyd 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 > Cc: user-mode-linux-de...@lists.sourceforge.net > Cc: x...@kernel.org > Signed-off-by: Stephen Boyd Acked-by: David S. Miller ___ 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 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 > Cc: user-mode-linux-de...@lists.sourceforge.net > Cc: x...@kernel.org > Signed-off-by: Stephen Boyd > --- Acked-by: Richard Weinberger -- 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 -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 --- 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 --- 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 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 --- 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 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 ___ 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 >> --- >> 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