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
