* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: James Bottomley @ 2014-03-22 22:37 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Fenghua Yu, linux-ia64, Tony Luck, Laura Abbott, linux-scsi,
linux-s390, x86, Heiko Carstens, linux-kernel, David S. Miller,
Martin Schwidefsky, Ingo Molnar, Paul Mackerras, H. Peter Anvin,
sparclinux, linux390, Andrew Morton, linuxppc-dev,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20140322222306.GM7528@n2100.arm.linux.org.uk>
On Sat, 2014-03-22 at 22:23 +0000, Russell King - ARM Linux wrote:
> On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
> > Perhaps now might be the time to ask which are the remaining
> > architectures that cannot do SG chaining and then we can fix them and
> > pull the whole thing out.
>
> Not quite. You're making the assumption that we can be sure that all
> the scatterlist users on an architecture have been converted - that's
> simply not true on ARM.
No I'm not, I said "now might be the time to ask which are the remaining
architectures that cannot do SG chaining" I think it's time to list them
so we know what work remains. I know we've got a bunch in parisc (all
of our iommu code in driver/parisc - about 5 different ones - are
unconverted). However, the conversion is pretty simple; it's mostly
replacing sglist++ with sglist=sg_next(sglist)
> We have some which have, and some which still
> have not been audited.
>
> The cases that get us here would be old platform DMA code which walks
> scatterlists handed to it from drivers - stuff like
> arch/arm/mach-rpc/dma.c (which probably can cope), and drivers/scsi/arm/*
> (which definitely can't because of their SCSI pointers save/restore
> handling message.) I know that's one case where SG_CHAIN definitely
> isn't supported on ARM.
>
> So, we had decided not to enable it, but this means that new stuff
> isn't benefitting from this. I've recently asked arm-soc to enable
> it for the modern multi-platform builds, because modern stuff really
> be written with correct SG chaining in mind.
OK, so lets see what the actual effort is.
James
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: Russell King - ARM Linux @ 2014-03-22 22:52 UTC (permalink / raw)
To: James Bottomley
Cc: Fenghua Yu, linux-ia64, Tony Luck, Laura Abbott, linux-scsi,
linux-s390, x86, Heiko Carstens, linux-kernel, David S. Miller,
Martin Schwidefsky, Ingo Molnar, Paul Mackerras, H. Peter Anvin,
sparclinux, linux390, Andrew Morton, linuxppc-dev,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1395527860.2143.61.camel@dabdike.int.hansenpartnership.com>
On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote:
> On Sat, 2014-03-22 at 22:23 +0000, Russell King - ARM Linux wrote:
> > On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
> > > Perhaps now might be the time to ask which are the remaining
> > > architectures that cannot do SG chaining and then we can fix them and
> > > pull the whole thing out.
> >
> > Not quite. You're making the assumption that we can be sure that all
> > the scatterlist users on an architecture have been converted - that's
> > simply not true on ARM.
>
> No I'm not, I said "now might be the time to ask which are the remaining
> architectures that cannot do SG chaining"
And I'm disagreeing with that statement which implies that it's something
that is an architecture wide property for any particular architecture.
Right now in mainline, if ARM has IOMMU support enabled, then SG_CHAIN
support will also be enabled. I've a patch out of tree which I've been
using for years which enables SG_CHAIN for a particular SoC (Dove).
Otherwise, it doesn't have support for SG_CHAIN.
PARISC on the other hand (as you list) has no support to enable SG_CHAIN
under any circumstances.
Where we're disagreeing is whether this is something that is always-on or
always-off for any particular architecture.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: James Bottomley @ 2014-03-22 22:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Fenghua Yu, linux-ia64, Tony Luck, Laura Abbott, linux-scsi,
linux-s390, x86, Heiko Carstens, linux-kernel, David S. Miller,
Martin Schwidefsky, Ingo Molnar, Paul Mackerras, H. Peter Anvin,
sparclinux, linux390, Andrew Morton, linuxppc-dev,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20140322225201.GN7528@n2100.arm.linux.org.uk>
On Sat, 2014-03-22 at 22:52 +0000, Russell King - ARM Linux wrote:
> On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote:
> > On Sat, 2014-03-22 at 22:23 +0000, Russell King - ARM Linux wrote:
> > > On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
> > > > Perhaps now might be the time to ask which are the remaining
> > > > architectures that cannot do SG chaining and then we can fix them and
> > > > pull the whole thing out.
> > >
> > > Not quite. You're making the assumption that we can be sure that all
> > > the scatterlist users on an architecture have been converted - that's
> > > simply not true on ARM.
> >
> > No I'm not, I said "now might be the time to ask which are the remaining
> > architectures that cannot do SG chaining"
>
> And I'm disagreeing with that statement which implies that it's something
> that is an architecture wide property for any particular architecture.
>
> Right now in mainline, if ARM has IOMMU support enabled, then SG_CHAIN
> support will also be enabled. I've a patch out of tree which I've been
> using for years which enables SG_CHAIN for a particular SoC (Dove).
> Otherwise, it doesn't have support for SG_CHAIN.
>
> PARISC on the other hand (as you list) has no support to enable SG_CHAIN
> under any circumstances.
>
> Where we're disagreeing is whether this is something that is always-on or
> always-off for any particular architecture.
Actually, I don't disagree with that. PA used to share sb_iommu with
ia64 (it's the same chipset for the HP versions), but we can't now
because ia64 is chained and we're not and there's no way to say chained
for this platform but not for these other more legacy ones. If you have
a proposal for this, I'd be interested, so I don't have to do an all or
nothing conversion, but the config option isn't it because our platform
configuration is runtime determined (we usually select every driver and
let the actual one be chosen at runtime from the config table).
James
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: Benjamin Herrenschmidt @ 2014-03-23 3:04 UTC (permalink / raw)
To: Laura Abbott
Cc: Fenghua Yu, Tony Luck, Russell King, Andrew Morton, linux-scsi,
linux-s390, x86, Heiko Carstens, linux-kernel,
James E.J. Bottomley, linux390, sparclinux, Ingo Molnar,
Paul Mackerras, H. Peter Anvin, Martin Schwidefsky, linux-ia64,
Thomas Gleixner, linuxppc-dev, David S. Miller, linux-arm-kernel
In-Reply-To: <1395512032-20575-2-git-send-email-lauraa@codeaurora.org>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 1594945..8122294 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -82,6 +82,7 @@ config ARM
> <http://www.arm.linux.org.uk/>.
>
> config ARM_HAS_SG_CHAIN
> + select ARCH_HAS_SG_CHAIN
> bool
>
Heh, a self-selecting config option... I didn't know that trick !
Ben.
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: Benjamin Herrenschmidt @ 2014-03-23 3:06 UTC (permalink / raw)
To: Laura Abbott
Cc: Fenghua Yu, Tony Luck, Russell King, Andrew Morton, linux-scsi,
linux-s390, x86, Heiko Carstens, linux-kernel,
James E.J. Bottomley, linux390, sparclinux, Ingo Molnar,
Paul Mackerras, H. Peter Anvin, Martin Schwidefsky, linux-ia64,
Thomas Gleixner, linuxppc-dev, David S. Miller, linux-arm-kernel
In-Reply-To: <1395512032-20575-2-git-send-email-lauraa@codeaurora.org>
On Sat, 2014-03-22 at 11:13 -0700, Laura Abbott wrote:
> Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture
> specific scatterlist.h, make it a proper Kconfig option and use that
> instead. At same time, remove the header files are are now mostly
> useless and just include asm-generic/scatterlist.h.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
For powerpc
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: Christoph Hellwig @ 2014-03-23 7:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ia64, Heiko Carstens, Paul Mackerras, H. Peter Anvin,
sparclinux, linux-s390, Russell King, linux-scsi, x86,
Ingo Molnar, Fenghua Yu, Laura Abbott, Thomas Gleixner,
linux-arm-kernel, Tony Luck, linux-kernel, James E.J. Bottomley,
Martin Schwidefsky, linux390, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <1395543886.3460.95.camel@pasglop>
On Sun, Mar 23, 2014 at 02:04:46PM +1100, Benjamin Herrenschmidt wrote:
>
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 1594945..8122294 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -82,6 +82,7 @@ config ARM
> > <http://www.arm.linux.org.uk/>.
> >
> > config ARM_HAS_SG_CHAIN
> > + select ARCH_HAS_SG_CHAIN
> > bool
> >
>
> Heh, a self-selecting config option... I didn't know that trick !
ARM vs ARCH. However the arm variant of the variable should probably be
consolidated into the ARCH one as a follow up.
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: Benjamin Herrenschmidt @ 2014-03-23 8:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-ia64, Heiko Carstens, Paul Mackerras, H. Peter Anvin,
sparclinux, linux-s390, Russell King, linux-scsi, x86,
Ingo Molnar, Fenghua Yu, Laura Abbott, Thomas Gleixner,
linux-arm-kernel, Tony Luck, linux-kernel, James E.J. Bottomley,
Martin Schwidefsky, linux390, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20140323070343.GA17945@infradead.org>
On Sun, 2014-03-23 at 00:03 -0700, Christoph Hellwig wrote:
> On Sun, Mar 23, 2014 at 02:04:46PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 1594945..8122294 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -82,6 +82,7 @@ config ARM
> > > <http://www.arm.linux.org.uk/>.
> > >
> > > config ARM_HAS_SG_CHAIN
> > > + select ARCH_HAS_SG_CHAIN
> > > bool
> > >
> >
> > Heh, a self-selecting config option... I didn't know that trick !
>
> ARM vs ARCH. However the arm variant of the variable should probably be
> consolidated into the ARCH one as a follow up.
Oh right... sorry for the noise.
Ben.
^ permalink raw reply
* Re: Pull request: scottwood/linux.git next
From: Benjamin Herrenschmidt @ 2014-03-23 23:16 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20140320042527.GA23206@home.buserror.net>
On Wed, 2014-03-19 at 23:25 -0500, Scott Wood wrote:
> The following changes since commit c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac:
>
> powerpc/powernv Platform dump interface (2014-03-07 16:19:10 +1100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
>
> for you to fetch changes up to 48b16180d0d91324e5d2423c6d53d97bbe3dcc14:
>
> fsl/pci: The new pci suspend/resume implementation (2014-03-19 22:37:44 -0500)
Stephen just informed me that your tree wasn't in -next ... Kumar's
still is.
Can you guys fix that up ? I somewhat rely on the FSL stuff to simmer
in -next on its own.
Cheers,
Ben.
> ----------------------------------------------------------------
> Luis Henriques (1):
> powerpc/kconfig: Remove TSI108_BRIDGE duplicates
>
> Minghuan Lian (1):
> powerpc/pci: Fix IMMRBAR address
>
> Prabhakar Kushwaha (1):
> powerpc/config: Remove unnecssary CONFIG_FSL_IFC
>
> Scott Wood (8):
> powerpc/booke64: Fix exception numbers
> powerpc/e6500: Make TLB lock recursive
> powerpc/booke64: Use SPRG7 for VDSO
> powerpc/booke64: Use SPRG_TLB_EXFRAME on bolted handlers
> powerpc/booke64: Remove ints from EXCEPTION_COMMON
> powerpc/booke64: Add crit/mc/debug support to EXCEPTION_COMMON
> powerpc/booke64: Critical and machine check exception support
> Revert "powerpc/watchdog: Don't enable interrupt on PPC64 BookE"
>
> Sebastian Siewior (1):
> powerpc: 85xx rdb: move np pointer to avoid builderror
>
> Tang Yuantian (2):
> powerpc/mpc85xx: Update clock nodes in device tree
> powerpc: T4240: Add ina220 node in dts
>
> Tiejun Chen (2):
> powerpc/book3e: initialize crit/mc/dbg kernel stack pointers
> powerpc/book3e: store crit/mc/dbg exception thread info
>
> Wang Dongsheng (2):
> powerpc/fsl: add PVR definition for E500MC and E5500
> fsl/pci: The new pci suspend/resume implementation
>
> Zhao Qiang (2):
> QE: split function mpc85xx_qe_init() into two functions.
> Corenet: Add QE platform support for Corenet
>
> harninder rai (1):
> powerpc/fsl: Add/update miscellaneous missing binding
>
> .../devicetree/bindings/powerpc/fsl/l2cache.txt | 23 ++
> .../devicetree/bindings/powerpc/fsl/mem-ctrlr.txt | 27 ++
> Documentation/devicetree/bindings/usb/fsl-usb.txt | 4 +-
> arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 36 ++
> arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 36 ++
> arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 60 +++
> arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 61 +++
> arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 113 ++++++
> arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 +
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 43 ++
> arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 61 +++
> arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 +
> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 86 ++++
> arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +
> arch/powerpc/boot/dts/t4240qds.dts | 42 ++
> arch/powerpc/configs/corenet64_smp_defconfig | 1 -
> arch/powerpc/configs/mpc85xx_defconfig | 1 -
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 -
> arch/powerpc/include/asm/exception-64e.h | 15 +-
> arch/powerpc/include/asm/kvm_booke_hv_asm.h | 17 +-
> arch/powerpc/include/asm/mmu-book3e.h | 9 +-
> arch/powerpc/include/asm/paca.h | 9 +-
> arch/powerpc/include/asm/reg.h | 15 +-
> arch/powerpc/kernel/asm-offsets.c | 2 +-
> arch/powerpc/kernel/exceptions-64e.S | 435 ++++++++++++++++-----
> arch/powerpc/kernel/setup_64.c | 20 +-
> arch/powerpc/kernel/vdso.c | 8 +-
> arch/powerpc/kernel/vdso32/getcpu.S | 2 +-
> arch/powerpc/kernel/vdso64/getcpu.S | 2 +-
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 +-
> arch/powerpc/kvm/book3s_interrupts.S | 4 +-
> arch/powerpc/kvm/bookehv_interrupts.S | 21 +-
> arch/powerpc/mm/tlb_low_64e.S | 63 +--
> arch/powerpc/mm/tlb_nohash.c | 11 +
> arch/powerpc/platforms/85xx/c293pcie.c | 1 +
> arch/powerpc/platforms/85xx/common.c | 6 +
> arch/powerpc/platforms/85xx/corenet_generic.c | 17 +
> arch/powerpc/platforms/85xx/ge_imp3a.c | 1 +
> arch/powerpc/platforms/85xx/mpc8536_ds.c | 1 +
> arch/powerpc/platforms/85xx/mpc85xx.h | 2 +
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 1 +
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 3 +
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 +-
> arch/powerpc/platforms/85xx/p1010rdb.c | 1 +
> arch/powerpc/platforms/85xx/p1022_ds.c | 1 +
> arch/powerpc/platforms/85xx/p1022_rdk.c | 1 +
> arch/powerpc/platforms/85xx/p1023_rds.c | 2 +
> arch/powerpc/platforms/85xx/qemu_e500.c | 1 +
> arch/powerpc/platforms/85xx/sbc8548.c | 1 +
> arch/powerpc/platforms/85xx/twr_p102x.c | 1 +
> arch/powerpc/platforms/85xx/xes_mpc85xx.c | 3 +
> arch/powerpc/platforms/embedded6xx/Kconfig | 2 -
> arch/powerpc/sysdev/fsl_pci.c | 178 +++++++--
> arch/powerpc/sysdev/fsl_pci.h | 8 +
> drivers/watchdog/booke_wdt.c | 8 -
> 61 files changed, 1312 insertions(+), 219 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt
^ permalink raw reply
* Re: Pull request: scottwood/linux.git next
From: Benjamin Herrenschmidt @ 2014-03-23 23:33 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <1395616617.3460.109.camel@pasglop>
On Mon, 2014-03-24 at 10:16 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2014-03-19 at 23:25 -0500, Scott Wood wrote:
> > The following changes since commit c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac:
> >
> > powerpc/powernv Platform dump interface (2014-03-07 16:19:10 +1100)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
> >
> > for you to fetch changes up to 48b16180d0d91324e5d2423c6d53d97bbe3dcc14:
> >
> > fsl/pci: The new pci suspend/resume implementation (2014-03-19 22:37:44 -0500)
>
> Stephen just informed me that your tree wasn't in -next ... Kumar's
> still is.
>
> Can you guys fix that up ? I somewhat rely on the FSL stuff to simmer
> in -next on its own.
Oh and where is my little summary to put in the merge commit ?
I made one up for this time around.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 18/18] powerpc/boot: add PPC64_BOOT_WRAPPER config option
From: Benjamin Herrenschmidt @ 2014-03-24 3:42 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <1395328213-19206-19-git-send-email-clg@fr.ibm.com>
On Thu, 2014-03-20 at 16:10 +0100, Cédric Le Goater wrote:
> The previous patch broke compatibility for 64bit big endian kernel.
>
> This patch adds a config option to compile the boot wrapper in 64bit
> only when CPU_LITTLE_ENDIAN is selected. It restores 32bit compilation
> and linking for the big endian kernel.
So I originally applied all 3 last patches of the series as one
(collapsed them in git) in order to not break bisection.
However, I had to take the series out in the end due to it
causing this error on some of my test configs:
powerpc64-linux-ld: cannot find arch/powerpc/boot/pseries-head.o: No such file or directory
I haven't had a chance to investigate yet, but sadly it looks like
this series might have to wait for the next round.
Ben.
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
> arch/powerpc/boot/Makefile | 2 +-
> arch/powerpc/boot/wrapper | 2 +-
> arch/powerpc/boot/zImage.lds.S | 8 ++++----
> arch/powerpc/platforms/Kconfig.cputype | 5 +++++
> 4 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index b7e640028711..35189540b699 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -23,7 +23,7 @@ BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> -fno-strict-aliasing -Os -msoft-float -pipe \
> -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
> -isystem $(shell $(CROSS32CC) -print-file-name=include)
> -ifdef CONFIG_PPC64
> +ifdef CONFIG_PPC64_BOOT_WRAPPER
> BOOTCFLAGS += -m64
> endif
> ifdef CONFIG_CPU_BIG_ENDIAN
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index 3270e2a5c901..1948cf8b8a40 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -140,7 +140,7 @@ fi
> elfformat="`${CROSS}objdump -p "$kernel" | grep 'file format' | awk '{print $4}'`"
> case "$elfformat" in
> elf64-powerpcle) format=elf64lppc ;;
> - elf64-powerpc) format=elf64ppc ;;
> + elf64-powerpc) format=elf32ppc ;;
> elf32-powerpc) format=elf32ppc ;;
> esac
>
> diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
> index afecab0aff5c..861e72109df2 100644
> --- a/arch/powerpc/boot/zImage.lds.S
> +++ b/arch/powerpc/boot/zImage.lds.S
> @@ -1,6 +1,6 @@
> #include <asm-generic/vmlinux.lds.h>
>
> -#ifdef CONFIG_PPC64
> +#ifdef CONFIG_PPC64_BOOT_WRAPPER
> OUTPUT_ARCH(powerpc:common64)
> #else
> OUTPUT_ARCH(powerpc:common)
> @@ -22,7 +22,7 @@ SECTIONS
> *(.rodata*)
> *(.data*)
> *(.sdata*)
> -#ifdef CONFIG_PPC32
> +#ifndef CONFIG_PPC64_BOOT_WRAPPER
> *(.got2)
> #endif
> }
> @@ -37,7 +37,7 @@ SECTIONS
> .interp : { *(.interp) }
> .rela.dyn :
> {
> -#ifdef CONFIG_PPC64
> +#ifdef CONFIG_PPC64_BOOT_WRAPPER
> __rela_dyn_start = .;
> #endif
> *(.rela*)
> @@ -67,7 +67,7 @@ SECTIONS
> _initrd_end = .;
> }
>
> -#ifdef CONFIG_PPC64
> +#ifdef CONFIG_PPC64_BOOT_WRAPPER
> .got :
> {
> __toc_start = .;
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 434fda39bf8b..a4aadb091a1e 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -421,6 +421,7 @@ config CPU_BIG_ENDIAN
>
> config CPU_LITTLE_ENDIAN
> bool "Build little endian kernel"
> + select PPC64_BOOT_WRAPPER
> help
> Build a little endian kernel.
>
> @@ -429,3 +430,7 @@ config CPU_LITTLE_ENDIAN
> little endian powerpc.
>
> endchoice
> +
> +config PPC64_BOOT_WRAPPER
> + def_bool n
> + depends on CPU_LITTLE_ENDIAN
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: Heiko Carstens @ 2014-03-24 5:47 UTC (permalink / raw)
To: Laura Abbott
Cc: Fenghua Yu, Tony Luck, Russell King, Andrew Morton, linux-scsi,
linux-s390, x86, linux-kernel, James E.J. Bottomley, linux390,
sparclinux, Ingo Molnar, Paul Mackerras, H. Peter Anvin,
Martin Schwidefsky, linux-ia64, Thomas Gleixner, linuxppc-dev,
David S. Miller, linux-arm-kernel
In-Reply-To: <1395512032-20575-2-git-send-email-lauraa@codeaurora.org>
On Sat, Mar 22, 2014 at 11:13:51AM -0700, Laura Abbott wrote:
> Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture
> specific scatterlist.h, make it a proper Kconfig option and use that
> instead. At same time, remove the header files are are now mostly
> useless and just include asm-generic/scatterlist.h.
>
[...]
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 65a0775..d6c2059 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -142,6 +142,7 @@ config S390
> select SYSCTL_EXCEPTION_TRACE
> select VIRT_CPU_ACCOUNTING
> select VIRT_TO_BUS
> + select ARCH_HAS_SG_CHAIN
>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
FWIW, it would have been nice to keep the list of selected configs sorted.
However no need to resend.
^ permalink raw reply
* Re: [PATCH 18/18] powerpc/boot: add PPC64_BOOT_WRAPPER config option
From: Cedric Le Goater @ 2014-03-24 8:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1395632548.3460.135.camel@pasglop>
Hi Benjamin,
> So I originally applied all 3 last patches of the series as one
> (collapsed them in git) in order to not break bisection.
>
> However, I had to take the series out in the end due to it
> causing this error on some of my test configs:
>
> powerpc64-linux-ld: cannot find arch/powerpc/boot/pseries-head.o: No such file or directory
>
> I haven't had a chance to investigate yet, but sadly it looks like
> this series might have to wait for the next round.
OK. I will take a look.
Thanks,
C.
^ permalink raw reply
* Re: [PATCH 18/18] powerpc/boot: add PPC64_BOOT_WRAPPER config option
From: Benjamin Herrenschmidt @ 2014-03-24 9:04 UTC (permalink / raw)
To: Cedric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <532FEEF0.40607@fr.ibm.com>
On Mon, 2014-03-24 at 09:38 +0100, Cedric Le Goater wrote:
> Hi Benjamin,
>
> > So I originally applied all 3 last patches of the series as one
> > (collapsed them in git) in order to not break bisection.
> >
> > However, I had to take the series out in the end due to it
> > causing this error on some of my test configs:
> >
> > powerpc64-linux-ld: cannot find arch/powerpc/boot/pseries-head.o: No such file or directory
> >
> > I haven't had a chance to investigate yet, but sadly it looks like
> > this series might have to wait for the next round.
>
> OK. I will take a look.
Specifically it was my cell and bimini configs, I'll get you the actual
config files (they are not defconfigs) separately.
Cheers,
Ben.
^ permalink raw reply
* Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig
From: Russell King - ARM Linux @ 2014-03-24 10:45 UTC (permalink / raw)
To: James Bottomley
Cc: Fenghua Yu, linux-ia64, Tony Luck, Laura Abbott, linux-scsi,
linux-s390, x86, Heiko Carstens, linux-kernel, David S. Miller,
Martin Schwidefsky, Ingo Molnar, Paul Mackerras, H. Peter Anvin,
sparclinux, linux390, Andrew Morton, linuxppc-dev,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <1395529151.2143.64.camel@dabdike.int.hansenpartnership.com>
On Sat, Mar 22, 2014 at 03:59:11PM -0700, James Bottomley wrote:
> On Sat, 2014-03-22 at 22:52 +0000, Russell King - ARM Linux wrote:
> > And I'm disagreeing with that statement which implies that it's something
> > that is an architecture wide property for any particular architecture.
> >
> > Right now in mainline, if ARM has IOMMU support enabled, then SG_CHAIN
> > support will also be enabled. I've a patch out of tree which I've been
> > using for years which enables SG_CHAIN for a particular SoC (Dove).
> > Otherwise, it doesn't have support for SG_CHAIN.
> >
> > PARISC on the other hand (as you list) has no support to enable SG_CHAIN
> > under any circumstances.
> >
> > Where we're disagreeing is whether this is something that is always-on or
> > always-off for any particular architecture.
>
> Actually, I don't disagree with that. PA used to share sb_iommu with
> ia64 (it's the same chipset for the HP versions), but we can't now
> because ia64 is chained and we're not and there's no way to say chained
> for this platform but not for these other more legacy ones. If you have
> a proposal for this, I'd be interested, so I don't have to do an all or
> nothing conversion, but the config option isn't it because our platform
> configuration is runtime determined (we usually select every driver and
> let the actual one be chosen at runtime from the config table).
At runtime, it's obviously a lot harder to resolve. However, that's not
what we're trying to do with this patch.
The main issue is that Laura is trying to add SG chain support to ARM64.
At the moment, ARM64 uses the asm-generic version of scatterlist.h
directly.
Her first spin of the patch involved creating
arch/arm64/include/asm/scatterlist.h, which was nothing more than an
include of the asm-generic header file of the same name, and the
definition of ARCH_HAS_SG_CHAIN. That seemed to be extremely wasteful
and sub-optimal way to handle this.
Moving this symbol into the Kconfig means that ARM64 no longer has to
have this additional file (and probably a bunch of other architectures
fall into that same camp) and the ARM specific CONFIG_ARM_HAS_SG_CHAIN
can be eliminated in favour of the now generic cross-arch config symbol.
We have plenty of other Kconfig symbols which control similar features
throughout the kernel source, there is no reason that this one should
not be the same.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* [PATCH] powerpc/boot: fix global entry point for pseries
From: Cédric Le Goater @ 2014-03-24 10:22 UTC (permalink / raw)
To: benh; +Cc: Cédric Le Goater, linuxppc-dev
In-Reply-To: <1395651884.30488.10.camel@pasglop>
Patch 15/18 "powerpc/boot: add a global entry point for pseries"
introduced a pseries-head.S file to fix the endian order when
entering the boot wrapper. This patch is a fix for some platforms
which also generate the zImage.pseries boot wrapper.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
Ben,
You can probably merge that one with patch 15. I can also
resend the whole patchset and merge the three last patches
as you did. As you wish.
Cheers,
arch/powerpc/boot/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 35189540b699..0d65b83e4af3 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -106,6 +106,10 @@ src-plat-$(CONFIG_AMIGAONE) += cuboot-amigaone.c
src-plat-$(CONFIG_PPC_PS3) += ps3-head.S ps3-hvcall.S ps3.c
src-plat-$(CONFIG_EPAPR_BOOT) += epapr.c epapr-wrapper.c
src-plat-$(CONFIG_PPC_PSERIES) += pseries-head.S
+src-plat-$(CONFIG_PPC_POWERNV) += pseries-head.S
+src-plat-$(CONFIG_PPC_IBM_CELL_BLADE) += pseries-head.S
+src-plat-$(CONFIG_PPC_CELLEB) += pseries-head.S
+src-plat-$(CONFIG_PPC_CELL_QPACE) += pseries-head.S
src-wlib := $(sort $(src-wlib-y))
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] i2c-cpm: Fix build by adding of_address.h and of_irq.h
From: Wolfram Sang @ 2014-03-24 13:49 UTC (permalink / raw)
To: Scott Wood
Cc: Richard Weinberger, Geert Uytterhoeven, linux-i2c, linuxppc-dev,
stable
In-Reply-To: <1395177024-5178-1-git-send-email-scottwood@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
On Tue, Mar 18, 2014 at 04:10:24PM -0500, Scott Wood wrote:
> Fixes a build break due to the undeclared use of irq_of_parse_and_map()
> and of_iomap(). This build break was apparently introduced while the
> driver was unbuildable due to the bug fixed by
> 62c19c9d29e65086e5ae76df371ed2e6b23f00cd ("i2c: Remove usage of
> orphaned symbol OF_I2C"). When 62c19c was added in v3.14-rc7,
> the driver was enabled again, breaking the powerpc mpc85xx_defconfig
> and mpc85xx_smp_defconfig.
>
> 62c19c is marked for stable, so this should go there as well.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: stable@kernel.org
Applied to for-current, thanks!
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* powerpc hugepage bug(s) when no valid hstates?
From: Nishanth Aravamudan @ 2014-03-24 23:02 UTC (permalink / raw)
To: linux-mm; +Cc: paulus, linuxppc-dev, anton, nyc
In KVM guests on Power, if the guest is not backed by hugepages, we see
the following in the guest:
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 64 kB
This seems like a configuration issue -- why is a hstate of 64k being
registered?
I did some debugging and found that the following does trigger,
mm/hugetlb.c::hugetlb_init():
/* Some platform decide whether they support huge pages at boot
* time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
* there is no such support
*/
if (HPAGE_SHIFT == 0)
return 0;
That check is only during init-time. So we don't support hugepages, but
none of the hugetlb APIs actually check this condition (HPAGE_SHIFT ==
0), so /proc/meminfo above falsely indicates there is a valid hstate (at
least one). But note that there is no /sys/kernel/mm/hugepages meaning
no hstate was actually registered.
Further, it turns out that huge_page_order(default_hstate) is 0, so
hugetlb_report_meminfo is doing:
1UL << (huge_page_order(h) + PAGE_SHIFT - 10)
which ends up just doing 1 << (PAGE_SHIFT - 10) and since the base page
size is 64k, we report a hugepage size of 64k... And allow the user to
allocate hugepages via the sysctl, etc.
What's the right thing to do here?
1) Should we add checks for HPAGE_SHIFT == 0 to all the hugetlb APIs? It
seems like HPAGE_SHIFT == 0 should be the equivalent, functionally, of
the config options being off. This seems like a lot of overhead, though,
to put everywhere, so maybe I can do it in an arch-specific macro, that
in asm-generic defaults to 0 (and so will hopefully be compiled out?).
2) What should hugetlbfs do when HPAGE_SHIFT == 0? Should it be
mountable? Obviously if it's mountable, we can't great files there
(since the fs will report insufficient space). [1]
Thanks,
Nish
[1]
Currently, I am seeing the following when I `mount -t hugetlbfs /none
/dev/hugetlbfs`, and then simply do a `ls /dev/hugetlbfs`. I think it's
related to the fact that hugetlbfs is properly not correctly setting
itself up in this state?:
Unable to handle kernel paging request for data at address 0x00000031
Faulting instruction address: 0xc000000000245710
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: pseries_rng rng_core virtio_net virtio_pci virtio_ring virtio
CPU: 0 PID: 1807 Comm: ls Not tainted 3.14.0-rc7-00066-g774868c-dirty #14
task: c00000007e804520 ti: c00000007aed4000 task.ti: c00000007aed4000
NIP: c000000000245710 LR: c00000000024586c CTR: 0000000000000000
REGS: c00000007aed74f0 TRAP: 0300 Not tainted (3.14.0-rc7-00066-g774868c-dirty)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24002484 XER: 00000000
CFAR: 00003fff91037760 DAR: 0000000000000031 DSISR: 40000000 SOFTE: 1
GPR00: c00000000024586c c00000007aed7770 c000000000d85420 c00000007d7a0010
GPR04: c000000000abcf20 c000000000ed7c78 0000000000000020 c000000000cbc880
GPR08: 0000000000000000 0000000000000000 0000000080000000 0000000000000002
GPR12: 0000000044002484 c00000000fe40000 0000000000000000 00000000100232f0
GPR16: 0000000000000001 0000000000000000 0000000000000000 c00000007d794a40
GPR20: 0000000000000000 0000000000000024 c00000007a49a200 c00000007a2bd000
GPR24: c00000007aed7bb8 c00000007d7a0090 0000000000014800 0000000000000000
GPR28: c00000007d7a0010 c00000007a49a210 c00000007d7a0150 0000000000000001
NIP [c000000000245710] .time_out_leases+0x30/0x100
LR [c00000000024586c] .__break_lease+0x8c/0x480
Call Trace:
[c00000007aed7770] [c0000000002434c0] .lease_alloc+0x20/0xe0 (unreliable)
[c00000007aed77f0] [c00000000024586c] .__break_lease+0x8c/0x480
[c00000007aed78e0] [c0000000001e0374] .do_dentry_open.isra.14+0xf4/0x370
[c00000007aed7980] [c0000000001e0624] .finish_open+0x34/0x60
[c00000007aed7a00] [c0000000001f519c] .do_last+0x56c/0xe40
[c00000007aed7b20] [c0000000001f5b68] .path_openat+0xf8/0x800
[c00000007aed7c40] [c0000000001f7810] .do_filp_open+0x40/0xb0
[c00000007aed7d70] [c0000000001e1f08] .do_sys_open+0x198/0x2e0
[c00000007aed7e30] [c00000000000a158] syscall_exit+0x0/0x98
Instruction dump:
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Nishanth Aravamudan @ 2014-03-24 23:05 UTC (permalink / raw)
To: linux-mm; +Cc: mgorman, cl, linuxppc-dev, anton, rientjes
In-Reply-To: <20140313170127.GE22247@linux.vnet.ibm.com>
Anyone have any ideas here?
On 13.03.2014 [10:01:27 -0700], Nishanth Aravamudan wrote:
> There might have been an error in my original mail, so resending...
>
> On 11.03.2014 [14:06:14 -0700], Nishanth Aravamudan wrote:
> > We have seen the following situation on a test system:
> >
> > 2-node system, each node has 32GB of memory.
> >
> > 2 gigantic (16GB) pages reserved at boot-time, both of which are
> > allocated from node 1.
> >
> > SLUB notices this:
> >
> > [ 0.000000] SLUB: Unable to allocate memory from node 1
> > [ 0.000000] SLUB: Allocating a useless per node structure in order to
> > be able to continue
> >
> > After boot, user then did:
> >
> > echo 24 > /proc/sys/vm/nr_hugepages
> >
> > And tasks are stuck:
> >
> > [<c0000000010980b8>] kexec_stack+0xb8/0x8000
> > [<c0000000000144d0>] .__switch_to+0x1c0/0x390
> > [<c0000000001ac708>] .throttle_direct_reclaim.isra.31+0x238/0x2c0
> > [<c0000000001b0b34>] .try_to_free_pages+0xb4/0x210
> > [<c0000000001a2f1c>] .__alloc_pages_nodemask+0x75c/0xb00
> > [<c0000000001eafb0>] .alloc_fresh_huge_page+0x70/0x150
> > [<c0000000001eb2d0>] .set_max_huge_pages.part.37+0x130/0x2f0
> > [<c0000000001eb7c8>] .hugetlb_sysctl_handler_common+0x168/0x180
> > [<c0000000002ae21c>] .proc_sys_call_handler+0xfc/0x120
> > [<c00000000021dcc0>] .vfs_write+0xe0/0x260
> > [<c00000000021e8c8>] .SyS_write+0x58/0xd0
> > [<c000000000009e7c>] syscall_exit+0x0/0x7c
> >
> > [<c00000004f9334b0>] 0xc00000004f9334b0
> > [<c0000000000144d0>] .__switch_to+0x1c0/0x390
> > [<c0000000001ac708>] .throttle_direct_reclaim.isra.31+0x238/0x2c0
> > [<c0000000001b0b34>] .try_to_free_pages+0xb4/0x210
> > [<c0000000001a2f1c>] .__alloc_pages_nodemask+0x75c/0xb00
> > [<c0000000001eafb0>] .alloc_fresh_huge_page+0x70/0x150
> > [<c0000000001eb2d0>] .set_max_huge_pages.part.37+0x130/0x2f0
> > [<c0000000001eb7c8>] .hugetlb_sysctl_handler_common+0x168/0x180
> > [<c0000000002ae21c>] .proc_sys_call_handler+0xfc/0x120
> > [<c00000000021dcc0>] .vfs_write+0xe0/0x260
> > [<c00000000021e8c8>] .SyS_write+0x58/0xd0
> > [<c000000000009e7c>] syscall_exit+0x0/0x7c
> >
> > [<c00000004f91f440>] 0xc00000004f91f440
> > [<c0000000000144d0>] .__switch_to+0x1c0/0x390
> > [<c0000000001ac708>] .throttle_direct_reclaim.isra.31+0x238/0x2c0
> > [<c0000000001b0b34>] .try_to_free_pages+0xb4/0x210
> > [<c0000000001a2f1c>] .__alloc_pages_nodemask+0x75c/0xb00
> > [<c0000000001eafb0>] .alloc_fresh_huge_page+0x70/0x150
> > [<c0000000001eb2d0>] .set_max_huge_pages.part.37+0x130/0x2f0
> > [<c0000000001eb54c>] .nr_hugepages_store_common.isra.39+0xbc/0x1b0
> > [<c0000000003662cc>] .kobj_attr_store+0x2c/0x50
> > [<c0000000002b2c2c>] .sysfs_write_file+0xec/0x1c0
> > [<c00000000021dcc0>] .vfs_write+0xe0/0x260
> > [<c00000000021e8c8>] .SyS_write+0x58/0xd0
> > [<c000000000009e7c>] syscall_exit+0x0/0x7c
> >
> > kswapd1 is also pegged at this point at 100% cpu.
> >
> > If we go in and manually:
> >
> > echo 24 >
> > /sys/devices/system/node/node0/hugepages/hugepages-16384kB/nr_hugepages
> >
> > rather than relying on the interleaving allocator from the sysctl, the
> > allocation succeeds (and the echo returns immediately).
> >
> > I think we are hitting the following:
> >
> > mm/hugetlb.c::alloc_fresh_huge_page_node():
> >
> > page = alloc_pages_exact_node(nid,
> > htlb_alloc_mask(h)|__GFP_COMP|__GFP_THISNODE|
> > __GFP_REPEAT|__GFP_NOWARN,
> > huge_page_order(h));
> >
> > include/linux/gfp.h:
> >
> > #define GFP_THISNODE (__GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY)
> >
> > and mm/page_alloc.c::__alloc_pages_slowpath():
> >
> > /*
> > * GFP_THISNODE (meaning __GFP_THISNODE, __GFP_NORETRY and
> > * __GFP_NOWARN set) should not cause reclaim since the subsystem
> > * (f.e. slab) using GFP_THISNODE may choose to trigger reclaim
> > * using a larger set of nodes after it has established that the
> > * allowed per node queues are empty and that nodes are
> > * over allocated.
> > */
> > if (IS_ENABLED(CONFIG_NUMA) &&
> > (gfp_mask & GFP_THISNODE) == GFP_THISNODE)
> > goto nopage;
> >
> > so we *do* reclaim in this callpath. Under my reading, since node1 is
> > exhausted, no matter how much work kswapd1 does, it will never reclaim
> > memory from node1 to satisfy a 16M page allocation request (or any
> > other, for that matter).
> >
> > I see the following possible changes/fixes, but am unsure if
> > a) my analysis is right
> > b) which is best.
> >
> > 1) Since we did notice early in boot that (in this case) node 1 was
> > exhausted, perhaps we should mark it as such there somehow, and if a
> > __GFP_THISNODE allocation request comes through on such a node, we
> > immediately fallthrough to nopage?
> >
> > 2) There is the following check
> > /*
> > * For order > PAGE_ALLOC_COSTLY_ORDER, if __GFP_REPEAT is
> > * specified, then we retry until we no longer reclaim any pages
> > * (above), or we've reclaimed an order of pages at least as
> > * large as the allocation's order. In both cases, if the
> > * allocation still fails, we stop retrying.
> > */
> > if (gfp_mask & __GFP_REPEAT && pages_reclaimed < (1 << order))
> > return 1;
> >
> > I wonder if we should add a check to also be sure that the pages we are
> > reclaiming, if __GFP_THISNODE is set, are from the right node?
> >
> > if (gfp_mask & __GFP_THISNODE && the progress we have made is on
> > the node requested?)
> >
> > 3) did_some_progress could be updated to track where the progress is
> > occuring, and if we are in __GFP_THISNODE allocation request and we
> > didn't make any progress on the correct node, we fail the allocation?
> >
> > I think this situation could be reproduced (and am working on it) by
> > exhausting a NUMA node with 16M hugepages and then using the generic
> > RR allocator to ask for more. Other node exhaustion cases probably
> > exist, but since we can't swap the hugepages, it seems like the most
> > straightforward way to try and reproduce it.
> >
> > Any thoughts on this? Am I way off base?
> >
> > Thanks,
> > Nish
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/opal: Add missing include
From: Michael Neuling @ 2014-03-25 0:43 UTC (permalink / raw)
To: benh; +Cc: sfr, linux-next, Linux PPC dev
next-20140324 currently fails compiling celleb_defconfig with:
arch/powerpc/include/asm/opal.h:894:42: error: 'struct notifier_block' declared inside parameter list [-Werror]
arch/powerpc/include/asm/opal.h:894:42: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
arch/powerpc/include/asm/opal.h:896:14: error: 'struct notifier_block' declared inside parameter list [-Werror]
This is due to a missing include which is added here.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index fe2aa0b..f57fb58 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -177,6 +177,8 @@ extern int opal_enter_rtas(struct rtas_args *args,
#ifndef __ASSEMBLY__
+#include <linux/notifier.h>
+
/* Other enums */
enum OpalVendorApiTokens {
OPAL_START_VENDOR_API_RANGE = 1000, OPAL_END_VENDOR_API_RANGE = 1999
^ permalink raw reply related
* Re: Pull request: scottwood/linux.git next
From: Scott Wood @ 2014-03-25 1:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <1395617608.3460.113.camel@pasglop>
On Mon, 2014-03-24 at 10:33 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-24 at 10:16 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-03-19 at 23:25 -0500, Scott Wood wrote:
> > > The following changes since commit c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac:
> > >
> > > powerpc/powernv Platform dump interface (2014-03-07 16:19:10 +1100)
> > >
> > > are available in the git repository at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
> > >
> > > for you to fetch changes up to 48b16180d0d91324e5d2423c6d53d97bbe3dcc14:
> > >
> > > fsl/pci: The new pci suspend/resume implementation (2014-03-19 22:37:44 -0500)
> >
> > Stephen just informed me that your tree wasn't in -next ... Kumar's
> > still is.
> >
> > Can you guys fix that up ? I somewhat rely on the FSL stuff to simmer
> > in -next on its own.
Stephen, what's the process for adding a tree?
I suppose we should update MAINTAINERS while we're at it.
> Oh and where is my little summary to put in the merge commit ?
>
> I made one up for this time around.
Oops, forgot again. Now I've added something to the script I use to
generate pull requests, to give me a reminder.
-Scott
^ permalink raw reply
* [PATCH] powerpc/85xx: Remove defconfigs
From: Michael Neuling @ 2014-03-25 1:15 UTC (permalink / raw)
To: Kumar Gala, Scott Wood, benh
Cc: Stewart Smith, Linux PPC dev, Mingkai Hu, Prabhakar Kushwaha,
Lijun Pan
These are always breaking and I feel like I'm the only one fixing them
and I don't even have one of these boards so let's just remove them.
They are also broken right now in linux-next when compiling modules.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
deleted file mode 100644
index 19f0fbe..0000000
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ /dev/null
@@ -1,272 +0,0 @@
-CONFIG_PPC_85xx=y
-CONFIG_PHYS_64BIT=y
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_AUDIT=y
-CONFIG_IRQ_DOMAIN_DEBUG=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_BSD_PROCESS_ACCT=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_EXPERT=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_MAC_PARTITION=y
-CONFIG_MPC8540_ADS=y
-CONFIG_MPC8560_ADS=y
-CONFIG_MPC85xx_CDS=y
-CONFIG_MPC85xx_MDS=y
-CONFIG_MPC8536_DS=y
-CONFIG_MPC85xx_DS=y
-CONFIG_MPC85xx_RDB=y
-CONFIG_C293_PCIE=y
-CONFIG_P1010_RDB=y
-CONFIG_P1022_DS=y
-CONFIG_P1022_RDK=y
-CONFIG_P1023_RDB=y
-CONFIG_P1023_RDS=y
-CONFIG_SOCRATES=y
-CONFIG_KSI8560=y
-CONFIG_XES_MPC85xx=y
-CONFIG_STX_GP3=y
-CONFIG_TQM8540=y
-CONFIG_TQM8541=y
-CONFIG_TQM8548=y
-CONFIG_TQM8555=y
-CONFIG_TQM8560=y
-CONFIG_SBC8548=y
-CONFIG_QUICC_ENGINE=y
-CONFIG_QE_GPIO=y
-CONFIG_HIGHMEM=y
-CONFIG_BINFMT_MISC=m
-CONFIG_MATH_EMULATION=y
-CONFIG_FORCE_MAX_ZONEORDER=12
-CONFIG_PCI=y
-CONFIG_PCI_MSI=y
-CONFIG_RAPIDIO=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_XFRM_USER=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_ADVANCED_ROUTER=y
-CONFIG_IP_MULTIPLE_TABLES=y
-CONFIG_IP_ROUTE_MULTIPATH=y
-CONFIG_IP_ROUTE_VERBOSE=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-CONFIG_IP_PNP_RARP=y
-CONFIG_NET_IPIP=y
-CONFIG_IP_MROUTE=y
-CONFIG_IP_PIMSM_V1=y
-CONFIG_IP_PIMSM_V2=y
-CONFIG_ARPD=y
-CONFIG_INET_ESP=y
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-CONFIG_IPV6=y
-CONFIG_IP_SCTP=m
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_MTD=y
-CONFIG_MTD_OF_PARTS=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLKDEVS=y
-CONFIG_MTD_BLOCK=y
-CONFIG_FTL=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_GEN_PROBE=y
-CONFIG_MTD_MAP_BANK_WIDTH_1=y
-CONFIG_MTD_MAP_BANK_WIDTH_2=y
-CONFIG_MTD_MAP_BANK_WIDTH_4=y
-CONFIG_MTD_CFI_I1=y
-CONFIG_MTD_CFI_I2=y
-CONFIG_MTD_CFI_INTELEXT=y
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP_OF=y
-CONFIG_MTD_M25P80=y
-CONFIG_MTD_CFI_UTIL=y
-CONFIG_MTD_NAND_ECC=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_IDS=y
-CONFIG_MTD_NAND_FSL_ELBC=y
-CONFIG_MTD_NAND_FSL_IFC=y
-CONFIG_MTD_UBI=y
-CONFIG_MTD_UBI_WL_THRESHOLD=4096
-CONFIG_MTD_UBI_BEB_RESERVE=1
-CONFIG_PROC_DEVICETREE=y
-CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_NBD=y
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=131072
-CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_LEGACY=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_CHR_DEV_ST=y
-CONFIG_BLK_DEV_SR=y
-CONFIG_CHR_DEV_SG=y
-CONFIG_SCSI_MULTI_LUN=y
-CONFIG_SCSI_LOGGING=y
-CONFIG_ATA=y
-CONFIG_SATA_AHCI=y
-CONFIG_SATA_FSL=y
-CONFIG_SATA_SIL24=y
-CONFIG_PATA_ALI=y
-CONFIG_PATA_VIA=y
-CONFIG_NETDEVICES=y
-CONFIG_DUMMY=y
-CONFIG_FS_ENET=y
-CONFIG_UCC_GETH=y
-CONFIG_GIANFAR=y
-CONFIG_E1000=y
-CONFIG_E1000E=y
-CONFIG_IGB=y
-CONFIG_MARVELL_PHY=y
-CONFIG_DAVICOM_PHY=y
-CONFIG_CICADA_PHY=y
-CONFIG_VITESSE_PHY=y
-CONFIG_AT803X_PHY=y
-CONFIG_FIXED_PHY=y
-CONFIG_INPUT_FF_MEMLESS=m
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIO_LIBPS2=y
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=2
-CONFIG_SERIAL_8250_RUNTIME_UARTS=2
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_DETECT_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
-CONFIG_SERIAL_QE=m
-CONFIG_NVRAM=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_CPM=m
-CONFIG_I2C_MPC=y
-CONFIG_SPI=y
-CONFIG_SPI_FSL_SPI=y
-CONFIG_SPI_FSL_ESPI=y
-CONFIG_GPIO_MPC8XXX=y
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=y
-CONFIG_FB=y
-CONFIG_FB_FSL_DIU=y
-# CONFIG_VGA_CONSOLE is not set
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FONTS=y
-CONFIG_FONT_8x8=y
-CONFIG_FONT_8x16=y
-CONFIG_SOUND=y
-CONFIG_SND=y
-# CONFIG_SND_SUPPORT_OLD_API is not set
-# CONFIG_SND_DRIVERS is not set
-CONFIG_SND_INTEL8X0=y
-# CONFIG_SND_PPC is not set
-# CONFIG_SND_USB is not set
-CONFIG_SND_SOC=y
-CONFIG_SND_POWERPC_SOC=y
-CONFIG_HID_A4TECH=y
-CONFIG_HID_APPLE=y
-CONFIG_HID_BELKIN=y
-CONFIG_HID_CHERRY=y
-CONFIG_HID_CHICONY=y
-CONFIG_HID_CYPRESS=y
-CONFIG_HID_EZKEY=y
-CONFIG_HID_GYRATION=y
-CONFIG_HID_LOGITECH=y
-CONFIG_HID_MICROSOFT=y
-CONFIG_HID_MONTEREY=y
-CONFIG_HID_PANTHERLORD=y
-CONFIG_HID_PETALYNX=y
-CONFIG_HID_SAMSUNG=y
-CONFIG_HID_SONY=y
-CONFIG_HID_SUNPLUS=y
-CONFIG_USB=y
-CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_FSL=y
-CONFIG_USB_OHCI_HCD=y
-CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
-CONFIG_USB_OHCI_HCD_PPC_OF_LE=y
-CONFIG_USB_STORAGE=y
-CONFIG_MMC=y
-CONFIG_MMC_SDHCI=y
-CONFIG_MMC_SDHCI_PLTFM=y
-CONFIG_MMC_SDHCI_OF_ESDHC=y
-CONFIG_EDAC=y
-CONFIG_EDAC_MM_EDAC=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_CMOS=y
-CONFIG_RTC_DRV_DS1307=y
-CONFIG_DMADEVICES=y
-CONFIG_FSL_DMA=y
-# CONFIG_NET_DMA is not set
-CONFIG_EXT2_FS=y
-CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_ISO9660_FS=m
-CONFIG_JOLIET=y
-CONFIG_ZISOFS=y
-CONFIG_UDF_FS=m
-CONFIG_MSDOS_FS=m
-CONFIG_VFAT_FS=y
-CONFIG_NTFS_FS=y
-CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_HUGETLBFS=y
-CONFIG_JFFS2_FS=y
-CONFIG_JFFS2_FS_DEBUG=1
-CONFIG_JFFS2_FS_WRITEBUFFER=y
-CONFIG_JFFS2_ZLIB=y
-CONFIG_JFFS2_RTIME=y
-CONFIG_UBIFS_FS=y
-CONFIG_UBIFS_FS_XATTR=y
-CONFIG_UBIFS_FS_LZO=y
-CONFIG_UBIFS_FS_ZLIB=y
-CONFIG_ADFS_FS=m
-CONFIG_AFFS_FS=m
-CONFIG_HFS_FS=m
-CONFIG_HFSPLUS_FS=m
-CONFIG_BEFS_FS=m
-CONFIG_BFS_FS=m
-CONFIG_EFS_FS=m
-CONFIG_CRAMFS=y
-CONFIG_VXFS_FS=m
-CONFIG_HPFS_FS=m
-CONFIG_QNX4FS_FS=m
-CONFIG_SYSV_FS=m
-CONFIG_UFS_FS=m
-CONFIG_NFS_FS=y
-CONFIG_NFS_V4=y
-CONFIG_ROOT_NFS=y
-CONFIG_NFSD=y
-CONFIG_CRC_T10DIF=y
-CONFIG_CRC16=y
-CONFIG_ZLIB_DEFLATE=y
-CONFIG_LZO_COMPRESS=y
-CONFIG_LZO_DECOMPRESS=y
-CONFIG_CRYPTO_DEFLATE=y
-CONFIG_CRYPTO_LZO=y
-CONFIG_DEBUG_FS=y
-CONFIG_DETECT_HUNG_TASK=y
-CONFIG_DEBUG_INFO=y
-CONFIG_CRYPTO_PCBC=m
-CONFIG_CRYPTO_SHA256=y
-CONFIG_CRYPTO_SHA512=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_FSL_CAAM=y
-CONFIG_CRYPTO_DEV_TALITOS=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
deleted file mode 100644
index 062312e..0000000
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ /dev/null
@@ -1,274 +0,0 @@
-CONFIG_PPC_85xx=y
-CONFIG_PHYS_64BIT=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=8
-CONFIG_EXPERIMENTAL=y
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_BSD_PROCESS_ACCT=y
-CONFIG_AUDIT=y
-CONFIG_IRQ_DOMAIN_DEBUG=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_EXPERT=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_MAC_PARTITION=y
-CONFIG_MPC8540_ADS=y
-CONFIG_MPC8560_ADS=y
-CONFIG_MPC85xx_CDS=y
-CONFIG_MPC85xx_MDS=y
-CONFIG_MPC8536_DS=y
-CONFIG_MPC85xx_DS=y
-CONFIG_MPC85xx_RDB=y
-CONFIG_C293_PCIE=y
-CONFIG_P1010_RDB=y
-CONFIG_P1022_DS=y
-CONFIG_P1022_RDK=y
-CONFIG_P1023_RDB=y
-CONFIG_P1023_RDS=y
-CONFIG_SOCRATES=y
-CONFIG_KSI8560=y
-CONFIG_XES_MPC85xx=y
-CONFIG_STX_GP3=y
-CONFIG_TQM8540=y
-CONFIG_TQM8541=y
-CONFIG_TQM8548=y
-CONFIG_TQM8555=y
-CONFIG_TQM8560=y
-CONFIG_SBC8548=y
-CONFIG_QUICC_ENGINE=y
-CONFIG_QE_GPIO=y
-CONFIG_HIGHMEM=y
-CONFIG_BINFMT_MISC=m
-CONFIG_MATH_EMULATION=y
-CONFIG_FORCE_MAX_ZONEORDER=12
-CONFIG_PCI=y
-CONFIG_PCI_MSI=y
-CONFIG_RAPIDIO=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_XFRM_USER=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_ADVANCED_ROUTER=y
-CONFIG_IP_MULTIPLE_TABLES=y
-CONFIG_IP_ROUTE_MULTIPATH=y
-CONFIG_IP_ROUTE_VERBOSE=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-CONFIG_IP_PNP_RARP=y
-CONFIG_NET_IPIP=y
-CONFIG_IP_MROUTE=y
-CONFIG_IP_PIMSM_V1=y
-CONFIG_IP_PIMSM_V2=y
-CONFIG_ARPD=y
-CONFIG_INET_ESP=y
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-CONFIG_IPV6=y
-CONFIG_IP_SCTP=m
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_MTD=y
-CONFIG_MTD_OF_PARTS=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLKDEVS=y
-CONFIG_MTD_BLOCK=y
-CONFIG_FTL=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_GEN_PROBE=y
-CONFIG_MTD_MAP_BANK_WIDTH_1=y
-CONFIG_MTD_MAP_BANK_WIDTH_2=y
-CONFIG_MTD_MAP_BANK_WIDTH_4=y
-CONFIG_MTD_CFI_I1=y
-CONFIG_MTD_CFI_I2=y
-CONFIG_MTD_CFI_INTELEXT=y
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP_OF=y
-CONFIG_MTD_M25P80=y
-CONFIG_MTD_CFI_UTIL=y
-CONFIG_MTD_NAND_ECC=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_IDS=y
-CONFIG_MTD_NAND_FSL_ELBC=y
-CONFIG_MTD_NAND_FSL_IFC=y
-CONFIG_MTD_UBI=y
-CONFIG_MTD_UBI_WL_THRESHOLD=4096
-CONFIG_MTD_UBI_BEB_RESERVE=1
-CONFIG_PROC_DEVICETREE=y
-CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_NBD=y
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=131072
-CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_LEGACY=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_CHR_DEV_ST=y
-CONFIG_BLK_DEV_SR=y
-CONFIG_CHR_DEV_SG=y
-CONFIG_SCSI_MULTI_LUN=y
-CONFIG_SCSI_LOGGING=y
-CONFIG_ATA=y
-CONFIG_SATA_AHCI=y
-CONFIG_SATA_FSL=y
-CONFIG_SATA_SIL24=y
-CONFIG_PATA_ALI=y
-CONFIG_NETDEVICES=y
-CONFIG_DUMMY=y
-CONFIG_FS_ENET=y
-CONFIG_UCC_GETH=y
-CONFIG_GIANFAR=y
-CONFIG_E1000E=y
-CONFIG_MARVELL_PHY=y
-CONFIG_DAVICOM_PHY=y
-CONFIG_CICADA_PHY=y
-CONFIG_VITESSE_PHY=y
-CONFIG_AT803X_PHY=y
-CONFIG_FIXED_PHY=y
-CONFIG_INPUT_FF_MEMLESS=m
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIO_LIBPS2=y
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=2
-CONFIG_SERIAL_8250_RUNTIME_UARTS=2
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_DETECT_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
-CONFIG_SERIAL_QE=m
-CONFIG_NVRAM=y
-CONFIG_I2C=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_CPM=m
-CONFIG_I2C_MPC=y
-CONFIG_SPI=y
-CONFIG_SPI_FSL_SPI=y
-CONFIG_SPI_FSL_ESPI=y
-CONFIG_GPIO_MPC8XXX=y
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=y
-CONFIG_FB=y
-CONFIG_FB_FSL_DIU=y
-# CONFIG_VGA_CONSOLE is not set
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FONTS=y
-CONFIG_FONT_8x8=y
-CONFIG_FONT_8x16=y
-CONFIG_SOUND=y
-CONFIG_SND=y
-# CONFIG_SND_SUPPORT_OLD_API is not set
-# CONFIG_SND_DRIVERS is not set
-CONFIG_SND_INTEL8X0=y
-# CONFIG_SND_PPC is not set
-# CONFIG_SND_USB is not set
-CONFIG_SND_SOC=y
-CONFIG_SND_POWERPC_SOC=y
-CONFIG_HID_A4TECH=y
-CONFIG_HID_APPLE=y
-CONFIG_HID_BELKIN=y
-CONFIG_HID_CHERRY=y
-CONFIG_HID_CHICONY=y
-CONFIG_HID_CYPRESS=y
-CONFIG_HID_EZKEY=y
-CONFIG_HID_GYRATION=y
-CONFIG_HID_LOGITECH=y
-CONFIG_HID_MICROSOFT=y
-CONFIG_HID_MONTEREY=y
-CONFIG_HID_PANTHERLORD=y
-CONFIG_HID_PETALYNX=y
-CONFIG_HID_SAMSUNG=y
-CONFIG_HID_SONY=y
-CONFIG_HID_SUNPLUS=y
-CONFIG_USB=y
-CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_FSL=y
-CONFIG_USB_OHCI_HCD=y
-CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
-CONFIG_USB_OHCI_HCD_PPC_OF_LE=y
-CONFIG_USB_STORAGE=y
-CONFIG_MMC=y
-CONFIG_MMC_SDHCI=y
-CONFIG_MMC_SDHCI_PLTFM=y
-CONFIG_MMC_SDHCI_OF_ESDHC=y
-CONFIG_EDAC=y
-CONFIG_EDAC_MM_EDAC=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_CMOS=y
-CONFIG_RTC_DRV_DS1307=y
-CONFIG_DMADEVICES=y
-CONFIG_FSL_DMA=y
-# CONFIG_NET_DMA is not set
-CONFIG_EXT2_FS=y
-CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_ISO9660_FS=m
-CONFIG_JOLIET=y
-CONFIG_ZISOFS=y
-CONFIG_UDF_FS=m
-CONFIG_MSDOS_FS=m
-CONFIG_VFAT_FS=y
-CONFIG_NTFS_FS=y
-CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_HUGETLBFS=y
-CONFIG_JFFS2_FS=y
-CONFIG_JFFS2_FS_DEBUG=1
-CONFIG_JFFS2_FS_WRITEBUFFER=y
-CONFIG_JFFS2_ZLIB=y
-CONFIG_JFFS2_RTIME=y
-CONFIG_UBIFS_FS=y
-CONFIG_UBIFS_FS_XATTR=y
-CONFIG_UBIFS_FS_LZO=y
-CONFIG_UBIFS_FS_ZLIB=y
-CONFIG_ADFS_FS=m
-CONFIG_AFFS_FS=m
-CONFIG_HFS_FS=m
-CONFIG_HFSPLUS_FS=m
-CONFIG_BEFS_FS=m
-CONFIG_BFS_FS=m
-CONFIG_EFS_FS=m
-CONFIG_CRAMFS=y
-CONFIG_VXFS_FS=m
-CONFIG_HPFS_FS=m
-CONFIG_QNX4FS_FS=m
-CONFIG_SYSV_FS=m
-CONFIG_UFS_FS=m
-CONFIG_NFS_FS=y
-CONFIG_NFS_V4=y
-CONFIG_ROOT_NFS=y
-CONFIG_NFSD=y
-CONFIG_CRC_T10DIF=y
-CONFIG_CRC16=y
-CONFIG_ZLIB_DEFLATE=y
-CONFIG_LZO_COMPRESS=y
-CONFIG_LZO_DECOMPRESS=y
-CONFIG_CRYPTO_DEFLATE=y
-CONFIG_CRYPTO_LZO=y
-CONFIG_DEBUG_FS=y
-CONFIG_DETECT_HUNG_TASK=y
-CONFIG_DEBUG_INFO=y
-CONFIG_CRYPTO_PCBC=m
-CONFIG_CRYPTO_SHA256=y
-CONFIG_CRYPTO_SHA512=y
-CONFIG_CRYPTO_AES=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_FSL_CAAM=y
-CONFIG_CRYPTO_DEV_TALITOS=y
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: Remove defconfigs
From: Scott Wood @ 2014-03-25 1:29 UTC (permalink / raw)
To: Michael Neuling
Cc: Stewart Smith, Linux PPC dev, Lijun Pan, Mingkai Hu,
Prabhakar Kushwaha
In-Reply-To: <12121.1395710142@ale.ozlabs.ibm.com>
On Tue, 2014-03-25 at 12:15 +1100, Michael Neuling wrote:
> These are always breaking and I feel like I'm the only one fixing them
> and
Always? Please elaborate.
> I don't even have one of these boards so let's just remove them.
What does you having one of these boards have to do with anything?
> They are also broken right now in linux-next when compiling modules.
A fix for that breakage is in i2c.git i2c/for-current (commit
5f12c5eca6e6b7aeb4b2028d579f614b4fe7a81f). I sent the patch to fix it
(I guess you're not "the only one fixing them") the day I found out
about the breakage. The breakage was introduced by commits from the i2c
tree, including one late in the rc cycle that enables a driver that
hadn't been enabled in a while (let's not do that again please).
> Signed-off-by: Michael Neuling <mikey@neuling.org>
>
> diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
> deleted file mode 100644
> index 19f0fbe..0000000
> --- a/arch/powerpc/configs/mpc85xx_defconfig
> +++ /dev/null
> @@ -1,272 +0,0 @@
NACK
I'm curious why you only removed this one defconfig when
mpc85xx_smp_defconfig had the same problem...
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Remove defconfigs
From: Michael Neuling @ 2014-03-25 1:59 UTC (permalink / raw)
To: Scott Wood
Cc: Stewart Smith, Linux PPC dev, Lijun Pan, Mingkai Hu,
Prabhakar Kushwaha
In-Reply-To: <1395710972.12479.418.camel@snotra.buserror.net>
Scott,
> On Tue, 2014-03-25 at 12:15 +1100, Michael Neuling wrote:
> > These are always breaking and I feel like I'm the only one fixing them
> > and
>
> Always? Please elaborate.
Maybe once every 2-3 months I have to send a fix up for them.
> > I don't even have one of these boards so let's just remove them.
>
> What does you having one of these boards have to do with anything?
Well it feels like I'm the only one fixing them (which I guess isn't
true), and I don't even really care about them.
> > They are also broken right now in linux-next when compiling modules.
>
> A fix for that breakage is in i2c.git i2c/for-current (commit
> 5f12c5eca6e6b7aeb4b2028d579f614b4fe7a81f). I sent the patch to fix it
> (I guess you're not "the only one fixing them") the day I found out
> about the breakage. The breakage was introduced by commits from the i2c
> tree, including one late in the rc cycle that enables a driver that
> hadn't been enabled in a while (let's not do that again please).
Great.
>
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> >
> > diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
> > deleted file mode 100644
> > index 19f0fbe..0000000
> > --- a/arch/powerpc/configs/mpc85xx_defconfig
> > +++ /dev/null
> > @@ -1,272 +0,0 @@
>
> NACK
Fair enough. It was more of a probe to see who really cared about
them. Clearly someone does.
> I'm curious why you only removed this one defconfig when
> mpc85xx_smp_defconfig had the same problem...
Should have been both.. I screwed that up.
Mikey
^ permalink raw reply
* RE: [PATCH] powerpc/85xx: Remove defconfigs
From: Mingkai.Hu @ 2014-03-25 1:53 UTC (permalink / raw)
To: Michael Neuling, Kumar Gala, Scott Wood, benh@kernel.crashing.org
Cc: Stewart Smith, Linux PPC dev, prabhakar@freescale.com, Lijun Pan
In-Reply-To: <12121.1395710142@ale.ozlabs.ibm.com>
This is a defconfig. You need to run "make mpc85xx_defconfig" to get the .c=
onfig file which is used to compile kernel.
Regards,
Mingkai
-----Original Message-----
From: Michael Neuling [mailto:mikey@neuling.org]=20
Sent: Tuesday, March 25, 2014 9:16 AM
To: Kumar Gala; Wood Scott-B07421; benh@kernel.crashing.org
Cc: Linux PPC dev; Kushwaha Prabhakar-B32579; Pan Lijun-B44306; Hu Mingkai-=
B21284; Stewart Smith
Subject: [PATCH] powerpc/85xx: Remove defconfigs
These are always breaking and I feel like I'm the only one fixing them and =
I don't even have one of these boards so let's just remove them.
They are also broken right now in linux-next when compiling modules.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/=
mpc85xx_defconfig
deleted file mode 100644
index 19f0fbe..0000000
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ /dev/null
@@ -1,272 +0,0 @@
-CONFIG_PPC_85xx=3Dy
-CONFIG_PHYS_64BIT=3Dy
-CONFIG_SYSVIPC=3Dy
-CONFIG_POSIX_MQUEUE=3Dy
-CONFIG_AUDIT=3Dy
-CONFIG_IRQ_DOMAIN_DEBUG=3Dy
-CONFIG_NO_HZ=3Dy
-CONFIG_HIGH_RES_TIMERS=3Dy
-CONFIG_BSD_PROCESS_ACCT=3Dy
-CONFIG_IKCONFIG=3Dy
-CONFIG_IKCONFIG_PROC=3Dy
-CONFIG_LOG_BUF_SHIFT=3D14
-CONFIG_BLK_DEV_INITRD=3Dy
-CONFIG_EXPERT=3Dy
-CONFIG_KALLSYMS_ALL=3Dy
-CONFIG_MODULES=3Dy
-CONFIG_MODULE_UNLOAD=3Dy
-CONFIG_MODULE_FORCE_UNLOAD=3Dy
-CONFIG_MODVERSIONS=3Dy
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=3Dy
-CONFIG_MAC_PARTITION=3Dy
-CONFIG_MPC8540_ADS=3Dy
-CONFIG_MPC8560_ADS=3Dy
-CONFIG_MPC85xx_CDS=3Dy
-CONFIG_MPC85xx_MDS=3Dy
-CONFIG_MPC8536_DS=3Dy
-CONFIG_MPC85xx_DS=3Dy
-CONFIG_MPC85xx_RDB=3Dy
-CONFIG_C293_PCIE=3Dy
-CONFIG_P1010_RDB=3Dy
-CONFIG_P1022_DS=3Dy
-CONFIG_P1022_RDK=3Dy
-CONFIG_P1023_RDB=3Dy
-CONFIG_P1023_RDS=3Dy
-CONFIG_SOCRATES=3Dy
-CONFIG_KSI8560=3Dy
-CONFIG_XES_MPC85xx=3Dy
-CONFIG_STX_GP3=3Dy
-CONFIG_TQM8540=3Dy
-CONFIG_TQM8541=3Dy
-CONFIG_TQM8548=3Dy
-CONFIG_TQM8555=3Dy
-CONFIG_TQM8560=3Dy
-CONFIG_SBC8548=3Dy
-CONFIG_QUICC_ENGINE=3Dy
-CONFIG_QE_GPIO=3Dy
-CONFIG_HIGHMEM=3Dy
-CONFIG_BINFMT_MISC=3Dm
-CONFIG_MATH_EMULATION=3Dy
-CONFIG_FORCE_MAX_ZONEORDER=3D12
-CONFIG_PCI=3Dy
-CONFIG_PCI_MSI=3Dy
-CONFIG_RAPIDIO=3Dy
-CONFIG_NET=3Dy
-CONFIG_PACKET=3Dy
-CONFIG_UNIX=3Dy
-CONFIG_XFRM_USER=3Dy
-CONFIG_NET_KEY=3Dy
-CONFIG_INET=3Dy
-CONFIG_IP_MULTICAST=3Dy
-CONFIG_IP_ADVANCED_ROUTER=3Dy
-CONFIG_IP_MULTIPLE_TABLES=3Dy
-CONFIG_IP_ROUTE_MULTIPATH=3Dy
-CONFIG_IP_ROUTE_VERBOSE=3Dy
-CONFIG_IP_PNP=3Dy
-CONFIG_IP_PNP_DHCP=3Dy
-CONFIG_IP_PNP_BOOTP=3Dy
-CONFIG_IP_PNP_RARP=3Dy
-CONFIG_NET_IPIP=3Dy
-CONFIG_IP_MROUTE=3Dy
-CONFIG_IP_PIMSM_V1=3Dy
-CONFIG_IP_PIMSM_V2=3Dy
-CONFIG_ARPD=3Dy
-CONFIG_INET_ESP=3Dy
-# CONFIG_INET_XFRM_MODE_BEET is not set -# CONFIG_INET_LRO is not set -CON=
FIG_IPV6=3Dy -CONFIG_IP_SCTP=3Dm -CONFIG_UEVENT_HELPER_PATH=3D"/sbin/hotplu=
g"
-CONFIG_DEVTMPFS=3Dy
-CONFIG_DEVTMPFS_MOUNT=3Dy
-CONFIG_MTD=3Dy
-CONFIG_MTD_OF_PARTS=3Dy
-CONFIG_MTD_CMDLINE_PARTS=3Dy
-CONFIG_MTD_CHAR=3Dy
-CONFIG_MTD_BLKDEVS=3Dy
-CONFIG_MTD_BLOCK=3Dy
-CONFIG_FTL=3Dy
-CONFIG_MTD_CFI=3Dy
-CONFIG_MTD_GEN_PROBE=3Dy
-CONFIG_MTD_MAP_BANK_WIDTH_1=3Dy
-CONFIG_MTD_MAP_BANK_WIDTH_2=3Dy
-CONFIG_MTD_MAP_BANK_WIDTH_4=3Dy
-CONFIG_MTD_CFI_I1=3Dy
-CONFIG_MTD_CFI_I2=3Dy
-CONFIG_MTD_CFI_INTELEXT=3Dy
-CONFIG_MTD_CFI_AMDSTD=3Dy
-CONFIG_MTD_PHYSMAP_OF=3Dy
-CONFIG_MTD_M25P80=3Dy
-CONFIG_MTD_CFI_UTIL=3Dy
-CONFIG_MTD_NAND_ECC=3Dy
-CONFIG_MTD_NAND=3Dy
-CONFIG_MTD_NAND_IDS=3Dy
-CONFIG_MTD_NAND_FSL_ELBC=3Dy
-CONFIG_MTD_NAND_FSL_IFC=3Dy
-CONFIG_MTD_UBI=3Dy
-CONFIG_MTD_UBI_WL_THRESHOLD=3D4096
-CONFIG_MTD_UBI_BEB_RESERVE=3D1
-CONFIG_PROC_DEVICETREE=3Dy
-CONFIG_BLK_DEV_LOOP=3Dy
-CONFIG_BLK_DEV_NBD=3Dy
-CONFIG_BLK_DEV_RAM=3Dy
-CONFIG_BLK_DEV_RAM_SIZE=3D131072
-CONFIG_EEPROM_AT24=3Dy
-CONFIG_EEPROM_LEGACY=3Dy
-CONFIG_BLK_DEV_SD=3Dy
-CONFIG_CHR_DEV_ST=3Dy
-CONFIG_BLK_DEV_SR=3Dy
-CONFIG_CHR_DEV_SG=3Dy
-CONFIG_SCSI_MULTI_LUN=3Dy
-CONFIG_SCSI_LOGGING=3Dy
-CONFIG_ATA=3Dy
-CONFIG_SATA_AHCI=3Dy
-CONFIG_SATA_FSL=3Dy
-CONFIG_SATA_SIL24=3Dy
-CONFIG_PATA_ALI=3Dy
-CONFIG_PATA_VIA=3Dy
-CONFIG_NETDEVICES=3Dy
-CONFIG_DUMMY=3Dy
-CONFIG_FS_ENET=3Dy
-CONFIG_UCC_GETH=3Dy
-CONFIG_GIANFAR=3Dy
-CONFIG_E1000=3Dy
-CONFIG_E1000E=3Dy
-CONFIG_IGB=3Dy
-CONFIG_MARVELL_PHY=3Dy
-CONFIG_DAVICOM_PHY=3Dy
-CONFIG_CICADA_PHY=3Dy
-CONFIG_VITESSE_PHY=3Dy
-CONFIG_AT803X_PHY=3Dy
-CONFIG_FIXED_PHY=3Dy
-CONFIG_INPUT_FF_MEMLESS=3Dm
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIO_LIBPS2=3Dy
-CONFIG_SERIAL_8250=3Dy
-CONFIG_SERIAL_8250_CONSOLE=3Dy
-CONFIG_SERIAL_8250_NR_UARTS=3D2
-CONFIG_SERIAL_8250_RUNTIME_UARTS=3D2
-CONFIG_SERIAL_8250_MANY_PORTS=3Dy
-CONFIG_SERIAL_8250_DETECT_IRQ=3Dy
-CONFIG_SERIAL_8250_RSA=3Dy
-CONFIG_SERIAL_QE=3Dm
-CONFIG_NVRAM=3Dy
-CONFIG_I2C_CHARDEV=3Dy
-CONFIG_I2C_CPM=3Dm
-CONFIG_I2C_MPC=3Dy
-CONFIG_SPI=3Dy
-CONFIG_SPI_FSL_SPI=3Dy
-CONFIG_SPI_FSL_ESPI=3Dy
-CONFIG_GPIO_MPC8XXX=3Dy
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=3Dy
-CONFIG_FB=3Dy
-CONFIG_FB_FSL_DIU=3Dy
-# CONFIG_VGA_CONSOLE is not set
-CONFIG_FRAMEBUFFER_CONSOLE=3Dy
-CONFIG_FONTS=3Dy
-CONFIG_FONT_8x8=3Dy
-CONFIG_FONT_8x16=3Dy
-CONFIG_SOUND=3Dy
-CONFIG_SND=3Dy
-# CONFIG_SND_SUPPORT_OLD_API is not set -# CONFIG_SND_DRIVERS is not set -=
CONFIG_SND_INTEL8X0=3Dy -# CONFIG_SND_PPC is not set -# CONFIG_SND_USB is n=
ot set -CONFIG_SND_SOC=3Dy -CONFIG_SND_POWERPC_SOC=3Dy -CONFIG_HID_A4TECH=
=3Dy -CONFIG_HID_APPLE=3Dy -CONFIG_HID_BELKIN=3Dy -CONFIG_HID_CHERRY=3Dy -C=
ONFIG_HID_CHICONY=3Dy -CONFIG_HID_CYPRESS=3Dy -CONFIG_HID_EZKEY=3Dy -CONFIG=
_HID_GYRATION=3Dy -CONFIG_HID_LOGITECH=3Dy -CONFIG_HID_MICROSOFT=3Dy -CONFI=
G_HID_MONTEREY=3Dy -CONFIG_HID_PANTHERLORD=3Dy -CONFIG_HID_PETALYNX=3Dy -CO=
NFIG_HID_SAMSUNG=3Dy -CONFIG_HID_SONY=3Dy -CONFIG_HID_SUNPLUS=3Dy -CONFIG_U=
SB=3Dy -CONFIG_USB_MON=3Dy -CONFIG_USB_EHCI_HCD=3Dy -CONFIG_USB_EHCI_FSL=3D=
y -CONFIG_USB_OHCI_HCD=3Dy -CONFIG_USB_OHCI_HCD_PPC_OF_BE=3Dy -CONFIG_USB_O=
HCI_HCD_PPC_OF_LE=3Dy -CONFIG_USB_STORAGE=3Dy -CONFIG_MMC=3Dy -CONFIG_MMC_S=
DHCI=3Dy -CONFIG_MMC_SDHCI_PLTFM=3Dy -CONFIG_MMC_SDHCI_OF_ESDHC=3Dy -CONFIG=
_EDAC=3Dy -CONFIG_EDAC_MM_EDAC=3Dy -CONFIG_RTC_CLASS=3Dy -CONFIG_RTC_DRV_CM=
OS=3Dy -CONFIG_RTC_DRV_DS1307=3Dy -CONFIG_DMADEVICES=3Dy -CONFIG_FSL_DMA=3D=
y -# CONFIG_NET_DMA is not set -CONFIG_EXT2_FS=3Dy -CONFIG_EXT3_FS=3Dy -# C=
ONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -CONFIG_ISO9660_FS=3Dm -CONFIG_JO=
LIET=3Dy -CONFIG_ZISOFS=3Dy -CONFIG_UDF_FS=3Dm -CONFIG_MSDOS_FS=3Dm -CONFIG=
_VFAT_FS=3Dy -CONFIG_NTFS_FS=3Dy -CONFIG_PROC_KCORE=3Dy -CONFIG_TMPFS=3Dy -=
CONFIG_HUGETLBFS=3Dy -CONFIG_JFFS2_FS=3Dy
-CONFIG_JFFS2_FS_DEBUG=3D1
-CONFIG_JFFS2_FS_WRITEBUFFER=3Dy
-CONFIG_JFFS2_ZLIB=3Dy
-CONFIG_JFFS2_RTIME=3Dy
-CONFIG_UBIFS_FS=3Dy
-CONFIG_UBIFS_FS_XATTR=3Dy
-CONFIG_UBIFS_FS_LZO=3Dy
-CONFIG_UBIFS_FS_ZLIB=3Dy
-CONFIG_ADFS_FS=3Dm
-CONFIG_AFFS_FS=3Dm
-CONFIG_HFS_FS=3Dm
-CONFIG_HFSPLUS_FS=3Dm
-CONFIG_BEFS_FS=3Dm
-CONFIG_BFS_FS=3Dm
-CONFIG_EFS_FS=3Dm
-CONFIG_CRAMFS=3Dy
-CONFIG_VXFS_FS=3Dm
-CONFIG_HPFS_FS=3Dm
-CONFIG_QNX4FS_FS=3Dm
-CONFIG_SYSV_FS=3Dm
-CONFIG_UFS_FS=3Dm
-CONFIG_NFS_FS=3Dy
-CONFIG_NFS_V4=3Dy
-CONFIG_ROOT_NFS=3Dy
-CONFIG_NFSD=3Dy
-CONFIG_CRC_T10DIF=3Dy
-CONFIG_CRC16=3Dy
-CONFIG_ZLIB_DEFLATE=3Dy
-CONFIG_LZO_COMPRESS=3Dy
-CONFIG_LZO_DECOMPRESS=3Dy
-CONFIG_CRYPTO_DEFLATE=3Dy
-CONFIG_CRYPTO_LZO=3Dy
-CONFIG_DEBUG_FS=3Dy
-CONFIG_DETECT_HUNG_TASK=3Dy
-CONFIG_DEBUG_INFO=3Dy
-CONFIG_CRYPTO_PCBC=3Dm
-CONFIG_CRYPTO_SHA256=3Dy
-CONFIG_CRYPTO_SHA512=3Dy
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_FSL_CAAM=3Dy
-CONFIG_CRYPTO_DEV_TALITOS=3Dy
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/conf=
igs/mpc85xx_smp_defconfig
deleted file mode 100644
index 062312e..0000000
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ /dev/null
@@ -1,274 +0,0 @@
-CONFIG_PPC_85xx=3Dy
-CONFIG_PHYS_64BIT=3Dy
-CONFIG_SMP=3Dy
-CONFIG_NR_CPUS=3D8
-CONFIG_EXPERIMENTAL=3Dy
-CONFIG_SYSVIPC=3Dy
-CONFIG_POSIX_MQUEUE=3Dy
-CONFIG_BSD_PROCESS_ACCT=3Dy
-CONFIG_AUDIT=3Dy
-CONFIG_IRQ_DOMAIN_DEBUG=3Dy
-CONFIG_NO_HZ=3Dy
-CONFIG_HIGH_RES_TIMERS=3Dy
-CONFIG_IKCONFIG=3Dy
-CONFIG_IKCONFIG_PROC=3Dy
-CONFIG_LOG_BUF_SHIFT=3D14
-CONFIG_BLK_DEV_INITRD=3Dy
-CONFIG_EXPERT=3Dy
-CONFIG_KALLSYMS_ALL=3Dy
-CONFIG_MODULES=3Dy
-CONFIG_MODULE_UNLOAD=3Dy
-CONFIG_MODULE_FORCE_UNLOAD=3Dy
-CONFIG_MODVERSIONS=3Dy
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=3Dy
-CONFIG_MAC_PARTITION=3Dy
-CONFIG_MPC8540_ADS=3Dy
-CONFIG_MPC8560_ADS=3Dy
-CONFIG_MPC85xx_CDS=3Dy
-CONFIG_MPC85xx_MDS=3Dy
-CONFIG_MPC8536_DS=3Dy
-CONFIG_MPC85xx_DS=3Dy
-CONFIG_MPC85xx_RDB=3Dy
-CONFIG_C293_PCIE=3Dy
-CONFIG_P1010_RDB=3Dy
-CONFIG_P1022_DS=3Dy
-CONFIG_P1022_RDK=3Dy
-CONFIG_P1023_RDB=3Dy
-CONFIG_P1023_RDS=3Dy
-CONFIG_SOCRATES=3Dy
-CONFIG_KSI8560=3Dy
-CONFIG_XES_MPC85xx=3Dy
-CONFIG_STX_GP3=3Dy
-CONFIG_TQM8540=3Dy
-CONFIG_TQM8541=3Dy
-CONFIG_TQM8548=3Dy
-CONFIG_TQM8555=3Dy
-CONFIG_TQM8560=3Dy
-CONFIG_SBC8548=3Dy
-CONFIG_QUICC_ENGINE=3Dy
-CONFIG_QE_GPIO=3Dy
-CONFIG_HIGHMEM=3Dy
-CONFIG_BINFMT_MISC=3Dm
-CONFIG_MATH_EMULATION=3Dy
-CONFIG_FORCE_MAX_ZONEORDER=3D12
-CONFIG_PCI=3Dy
-CONFIG_PCI_MSI=3Dy
-CONFIG_RAPIDIO=3Dy
-CONFIG_NET=3Dy
-CONFIG_PACKET=3Dy
-CONFIG_UNIX=3Dy
-CONFIG_XFRM_USER=3Dy
-CONFIG_NET_KEY=3Dy
-CONFIG_INET=3Dy
-CONFIG_IP_MULTICAST=3Dy
-CONFIG_IP_ADVANCED_ROUTER=3Dy
-CONFIG_IP_MULTIPLE_TABLES=3Dy
-CONFIG_IP_ROUTE_MULTIPATH=3Dy
-CONFIG_IP_ROUTE_VERBOSE=3Dy
-CONFIG_IP_PNP=3Dy
-CONFIG_IP_PNP_DHCP=3Dy
-CONFIG_IP_PNP_BOOTP=3Dy
-CONFIG_IP_PNP_RARP=3Dy
-CONFIG_NET_IPIP=3Dy
-CONFIG_IP_MROUTE=3Dy
-CONFIG_IP_PIMSM_V1=3Dy
-CONFIG_IP_PIMSM_V2=3Dy
-CONFIG_ARPD=3Dy
-CONFIG_INET_ESP=3Dy
-# CONFIG_INET_XFRM_MODE_BEET is not set -# CONFIG_INET_LRO is not set -CON=
FIG_IPV6=3Dy -CONFIG_IP_SCTP=3Dm -CONFIG_UEVENT_HELPER_PATH=3D"/sbin/hotplu=
g"
-CONFIG_DEVTMPFS=3Dy
-CONFIG_DEVTMPFS_MOUNT=3Dy
-CONFIG_MTD=3Dy
-CONFIG_MTD_OF_PARTS=3Dy
-CONFIG_MTD_CMDLINE_PARTS=3Dy
-CONFIG_MTD_CHAR=3Dy
-CONFIG_MTD_BLKDEVS=3Dy
-CONFIG_MTD_BLOCK=3Dy
-CONFIG_FTL=3Dy
-CONFIG_MTD_CFI=3Dy
-CONFIG_MTD_GEN_PROBE=3Dy
-CONFIG_MTD_MAP_BANK_WIDTH_1=3Dy
-CONFIG_MTD_MAP_BANK_WIDTH_2=3Dy
-CONFIG_MTD_MAP_BANK_WIDTH_4=3Dy
-CONFIG_MTD_CFI_I1=3Dy
-CONFIG_MTD_CFI_I2=3Dy
-CONFIG_MTD_CFI_INTELEXT=3Dy
-CONFIG_MTD_CFI_AMDSTD=3Dy
-CONFIG_MTD_PHYSMAP_OF=3Dy
-CONFIG_MTD_M25P80=3Dy
-CONFIG_MTD_CFI_UTIL=3Dy
-CONFIG_MTD_NAND_ECC=3Dy
-CONFIG_MTD_NAND=3Dy
-CONFIG_MTD_NAND_IDS=3Dy
-CONFIG_MTD_NAND_FSL_ELBC=3Dy
-CONFIG_MTD_NAND_FSL_IFC=3Dy
-CONFIG_MTD_UBI=3Dy
-CONFIG_MTD_UBI_WL_THRESHOLD=3D4096
-CONFIG_MTD_UBI_BEB_RESERVE=3D1
-CONFIG_PROC_DEVICETREE=3Dy
-CONFIG_BLK_DEV_LOOP=3Dy
-CONFIG_BLK_DEV_NBD=3Dy
-CONFIG_BLK_DEV_RAM=3Dy
-CONFIG_BLK_DEV_RAM_SIZE=3D131072
-CONFIG_EEPROM_AT24=3Dy
-CONFIG_EEPROM_LEGACY=3Dy
-CONFIG_BLK_DEV_SD=3Dy
-CONFIG_CHR_DEV_ST=3Dy
-CONFIG_BLK_DEV_SR=3Dy
-CONFIG_CHR_DEV_SG=3Dy
-CONFIG_SCSI_MULTI_LUN=3Dy
-CONFIG_SCSI_LOGGING=3Dy
-CONFIG_ATA=3Dy
-CONFIG_SATA_AHCI=3Dy
-CONFIG_SATA_FSL=3Dy
-CONFIG_SATA_SIL24=3Dy
-CONFIG_PATA_ALI=3Dy
-CONFIG_NETDEVICES=3Dy
-CONFIG_DUMMY=3Dy
-CONFIG_FS_ENET=3Dy
-CONFIG_UCC_GETH=3Dy
-CONFIG_GIANFAR=3Dy
-CONFIG_E1000E=3Dy
-CONFIG_MARVELL_PHY=3Dy
-CONFIG_DAVICOM_PHY=3Dy
-CONFIG_CICADA_PHY=3Dy
-CONFIG_VITESSE_PHY=3Dy
-CONFIG_AT803X_PHY=3Dy
-CONFIG_FIXED_PHY=3Dy
-CONFIG_INPUT_FF_MEMLESS=3Dm
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIO_LIBPS2=3Dy
-CONFIG_SERIAL_8250=3Dy
-CONFIG_SERIAL_8250_CONSOLE=3Dy
-CONFIG_SERIAL_8250_NR_UARTS=3D2
-CONFIG_SERIAL_8250_RUNTIME_UARTS=3D2
-CONFIG_SERIAL_8250_MANY_PORTS=3Dy
-CONFIG_SERIAL_8250_DETECT_IRQ=3Dy
-CONFIG_SERIAL_8250_RSA=3Dy
-CONFIG_SERIAL_QE=3Dm
-CONFIG_NVRAM=3Dy
-CONFIG_I2C=3Dy
-CONFIG_I2C_CHARDEV=3Dy
-CONFIG_I2C_CPM=3Dm
-CONFIG_I2C_MPC=3Dy
-CONFIG_SPI=3Dy
-CONFIG_SPI_FSL_SPI=3Dy
-CONFIG_SPI_FSL_ESPI=3Dy
-CONFIG_GPIO_MPC8XXX=3Dy
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=3Dy
-CONFIG_FB=3Dy
-CONFIG_FB_FSL_DIU=3Dy
-# CONFIG_VGA_CONSOLE is not set
-CONFIG_FRAMEBUFFER_CONSOLE=3Dy
-CONFIG_FONTS=3Dy
-CONFIG_FONT_8x8=3Dy
-CONFIG_FONT_8x16=3Dy
-CONFIG_SOUND=3Dy
-CONFIG_SND=3Dy
-# CONFIG_SND_SUPPORT_OLD_API is not set -# CONFIG_SND_DRIVERS is not set -=
CONFIG_SND_INTEL8X0=3Dy -# CONFIG_SND_PPC is not set -# CONFIG_SND_USB is n=
ot set -CONFIG_SND_SOC=3Dy -CONFIG_SND_POWERPC_SOC=3Dy -CONFIG_HID_A4TECH=
=3Dy -CONFIG_HID_APPLE=3Dy -CONFIG_HID_BELKIN=3Dy -CONFIG_HID_CHERRY=3Dy -C=
ONFIG_HID_CHICONY=3Dy -CONFIG_HID_CYPRESS=3Dy -CONFIG_HID_EZKEY=3Dy -CONFIG=
_HID_GYRATION=3Dy -CONFIG_HID_LOGITECH=3Dy -CONFIG_HID_MICROSOFT=3Dy -CONFI=
G_HID_MONTEREY=3Dy -CONFIG_HID_PANTHERLORD=3Dy -CONFIG_HID_PETALYNX=3Dy -CO=
NFIG_HID_SAMSUNG=3Dy -CONFIG_HID_SONY=3Dy -CONFIG_HID_SUNPLUS=3Dy -CONFIG_U=
SB=3Dy -CONFIG_USB_MON=3Dy -CONFIG_USB_EHCI_HCD=3Dy -CONFIG_USB_EHCI_FSL=3D=
y -CONFIG_USB_OHCI_HCD=3Dy -CONFIG_USB_OHCI_HCD_PPC_OF_BE=3Dy -CONFIG_USB_O=
HCI_HCD_PPC_OF_LE=3Dy -CONFIG_USB_STORAGE=3Dy -CONFIG_MMC=3Dy -CONFIG_MMC_S=
DHCI=3Dy -CONFIG_MMC_SDHCI_PLTFM=3Dy -CONFIG_MMC_SDHCI_OF_ESDHC=3Dy -CONFIG=
_EDAC=3Dy -CONFIG_EDAC_MM_EDAC=3Dy -CONFIG_RTC_CLASS=3Dy -CONFIG_RTC_DRV_CM=
OS=3Dy -CONFIG_RTC_DRV_DS1307=3Dy -CONFIG_DMADEVICES=3Dy -CONFIG_FSL_DMA=3D=
y -# CONFIG_NET_DMA is not set -CONFIG_EXT2_FS=3Dy -CONFIG_EXT3_FS=3Dy -# C=
ONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -CONFIG_ISO9660_FS=3Dm -CONFIG_JO=
LIET=3Dy -CONFIG_ZISOFS=3Dy -CONFIG_UDF_FS=3Dm -CONFIG_MSDOS_FS=3Dm -CONFIG=
_VFAT_FS=3Dy -CONFIG_NTFS_FS=3Dy -CONFIG_PROC_KCORE=3Dy -CONFIG_TMPFS=3Dy -=
CONFIG_HUGETLBFS=3Dy -CONFIG_JFFS2_FS=3Dy
-CONFIG_JFFS2_FS_DEBUG=3D1
-CONFIG_JFFS2_FS_WRITEBUFFER=3Dy
-CONFIG_JFFS2_ZLIB=3Dy
-CONFIG_JFFS2_RTIME=3Dy
-CONFIG_UBIFS_FS=3Dy
-CONFIG_UBIFS_FS_XATTR=3Dy
-CONFIG_UBIFS_FS_LZO=3Dy
-CONFIG_UBIFS_FS_ZLIB=3Dy
-CONFIG_ADFS_FS=3Dm
-CONFIG_AFFS_FS=3Dm
-CONFIG_HFS_FS=3Dm
-CONFIG_HFSPLUS_FS=3Dm
-CONFIG_BEFS_FS=3Dm
-CONFIG_BFS_FS=3Dm
-CONFIG_EFS_FS=3Dm
-CONFIG_CRAMFS=3Dy
-CONFIG_VXFS_FS=3Dm
-CONFIG_HPFS_FS=3Dm
-CONFIG_QNX4FS_FS=3Dm
-CONFIG_SYSV_FS=3Dm
-CONFIG_UFS_FS=3Dm
-CONFIG_NFS_FS=3Dy
-CONFIG_NFS_V4=3Dy
-CONFIG_ROOT_NFS=3Dy
-CONFIG_NFSD=3Dy
-CONFIG_CRC_T10DIF=3Dy
-CONFIG_CRC16=3Dy
-CONFIG_ZLIB_DEFLATE=3Dy
-CONFIG_LZO_COMPRESS=3Dy
-CONFIG_LZO_DECOMPRESS=3Dy
-CONFIG_CRYPTO_DEFLATE=3Dy
-CONFIG_CRYPTO_LZO=3Dy
-CONFIG_DEBUG_FS=3Dy
-CONFIG_DETECT_HUNG_TASK=3Dy
-CONFIG_DEBUG_INFO=3Dy
-CONFIG_CRYPTO_PCBC=3Dm
-CONFIG_CRYPTO_SHA256=3Dy
-CONFIG_CRYPTO_SHA512=3Dy
-CONFIG_CRYPTO_AES=3Dy
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_FSL_CAAM=3Dy
-CONFIG_CRYPTO_DEV_TALITOS=3Dy
^ permalink raw reply related
* Ask for help about fsl ppc toolchian issue "Illegal instruction"
From: 许久成 @ 2014-03-25 2:17 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]
Hi All,
We run into an issue when use e500mc toolchain g++ to compile c++ code for p2020 platform, the code as below:
main.c
#include <iostream>using namespace std;
int main(void) { cout << "asdfasdfasdfasdf";
return 0;}
compile it with command "powerpc-fls-linux-g++ main.c" and the output file's name is a.out, download the binary to p2020rdb board, but the console prints the error log "Illegal instruction".
It is all right on p2041 platform.
The version of toolchian:
Configured with: /local/workspace/yocto-iso-make/p4080ds/build_p4080ds_release/tmp/work-shared/gcc-4.6.2+svnr180516-r29+fsl.6/gcc-4_6-branch/configure --build=i686-linux --host=i686-fslsdk-linux --target=powerpc-fsl-linux --prefix=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr --exec_prefix=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr --bindir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/bin/ppce500mc-fsl-linux --sbindir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/bin/ppce500mc-fsl-linux --libexecdir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/libexec/ppce500mc-fsl-linux --datadir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/share --sysconfdir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/etc --sharedstatedir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/com --localstatedir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/var --libdir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/lib/ppce500mc-fsl-linux --includedir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/include --oldincludedir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/include --infodir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/share/info --mandir=/opt/fsl/1.2/sysroots/i686-fslsdk-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/local/workspace/yocto-iso-make/p4080ds/build_p4080ds_release/tmp/sysroots/i686-nativesdk-fslsdk-linux --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=powerpc-fsl-linux- --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-cheaders=c_global --with-local-prefix=/opt/fsl/1.2/sysroots/ppce500mc-fsl-linux/usr --with-gxx-include-dir=/opt/fsl/1.2/sysroots/ppce500mc-fsl-linux/usr/include/c++ --with-build-time-tools=/local/workspace/yocto-iso-make/p4080ds/build_p4080ds_release/tmp/sysroots/i686-linux/usr/powerpc-fsl-linux/bin --with-sysroot=/opt/fsl/1.2/sysroots/ppce500mc-fsl-linux --with-build-sysroot=/local/workspace/yocto-iso-make/p4080ds/build_p4080ds_release/tmp/sysroots/p4080ds --disable-libunwind-exceptions --disable-libssp --disable-libgomp --disable-libmudflap --with-mpfr=/local/workspace/yocto-iso-make/p4080ds/build_p4080ds_release/tmp/sysroots/i686-nativesdk-fslsdk-linux --with-mpc=/local/workspace/yocto-iso-make/p4080ds/build_p4080ds_release/tmp/sysroots/i686-nativesdk-fslsdk-linux --enable-nls --enable-__cxa_atexit --with-long-double-128Thread model: posixgcc version 4.6.2 (GCC)
Is e500mc family downward compitible with e500v2? C code can run correctly on p2020 with the e500mc toolchain.
Thanks & Best RegardsJiucheng
[-- Attachment #2: Type: text/html, Size: 3961 bytes --]
^ 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