Re: next-20081216 - powerpc link error 'dynreloc miscount'
On Wed, Dec 17, 2008 at 12:38:58PM +0530, Kamalesh Babulal wrote: > Hi, > next-20081216 build breaks on powerpc > > ld: dynreloc miscount for kernel/built-in.o, section .opd > ld: can not edit opd Bad value > make: *** [vmlinux.o] Error 1 Could it be this: http://sourceware.org/ml/binutils/2005-10/msg00334.html Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: next-20081216 - powerpc link error 'dynreloc miscount'
Hi Kamalesh, On Wed, 17 Dec 2008 12:38:58 +0530 Kamalesh Babulal wrote: > > next-20081216 build breaks on powerpc > > ld: dynreloc miscount for kernel/built-in.o, section .opd > ld: can not edit opd Bad value > make: *** [vmlinux.o] Error 1 > > # ld --version > GNU ld version 2.16.1 Debian GNU/Linux > > # gcc --version > gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) Yeah, I have seen this as well. A later toolchain (gcc 4.3.2, binutils 2.19) works ok. Also it is only a problem for some configs (see http://kisskb.ellerman.id.au/kisskb/branch/9/). It started with next-20081215. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgperT4Boubj6.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
next-20081216 - powerpc link error 'dynreloc miscount'
Hi, next-20081216 build breaks on powerpc ld: dynreloc miscount for kernel/built-in.o, section .opd ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 # ld --version GNU ld version 2.16.1 Debian GNU/Linux # gcc --version gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.28-rc8-next-20081216 # Tue Dec 16 15:27:34 2008 # CONFIG_PPC64=y # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_64=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=n CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_NS is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_RESOURCE_COUNTERS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_PROC_PID_CPUSET=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_CLASSIC_RCU=y # CONFIG_FREEZER is not set CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_SCANLOG=m CONFIG_LPARCFG=y CONFIG_PPC_SMLPAR=y CONFIG_CMM=y CONFIG_PPC_ISERIES=y # # iSeries device drivers # CONFIG_VIODASD=y CONFIG_VIOCD=m CONFIG_VIOTAPE=m CONFIG_VIOPATH=y CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y CONFIG_PPC_MAPLE=y CONFIG_PPC_PASEMI=y # # PA Semi PWRficient options # CONFIG_PPC_PASEMI_IOMMU=y #
[PATCH] powerpc/iseries: viodasd needs to depend on CONFIG_BLOCK
Otherwise you get lot of errors like these: drivers/block/viodasd.c:72: error: dereferencing pointer to incomplete type drivers/block/viodasd.c: In function 'viodasd_open': drivers/block/viodasd.c:135: error: dereferencing pointer to incomplete type drivers/block/viodasd.c: In function 'viodasd_release': drivers/block/viodasd.c:184: error: dereferencing pointer to incomplete type drivers/block/viodasd.c: In function 'viodasd_getgeo': drivers/block/viodasd.c:209: error: dereferencing pointer to incomplete type drivers/block/viodasd.c:214: error: implicit declaration of function 'get_capacity' drivers/block/viodasd.c: At top level: drivers/block/viodasd.c:222: error: variable 'viodasd_fops' has initializer but incomplete type drivers/block/viodasd.c:223: error: unknown field 'owner' specified in initializer Discovered by a randconfig build. Signed-off-by: Stephen Rothwell --- arch/powerpc/platforms/iseries/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/iseries/Kconfig b/arch/powerpc/platforms/iseries/Kconfig index 45ffd8e..ed3753d 100644 --- a/arch/powerpc/platforms/iseries/Kconfig +++ b/arch/powerpc/platforms/iseries/Kconfig @@ -9,6 +9,7 @@ menu "iSeries device drivers" config VIODASD tristate "iSeries Virtual I/O disk support" + depends on BLOCK help If you are running on an iSeries system and you want to use virtual disks created and managed by OS/400, say Y. -- 1.6.0.5 -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ndfc driver
On Wed, 10 Dec 2008 18:16:34 -0500 "Sean MacLennan" wrote: > Here is an updated patch. Doc has been moved to 4xx and amcc changed > to ibm. Anybody? Even if it is not perfect, it would be better to have a driver that at least compiles ;) Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More commits added to powerpc.git next and master branches
Josh Boyer writes: > I sent a pull request to you last week for my -next branch. It would be > nice to get those included as well. Sorry... Pulled and pushed out now. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix corruption error in rh_alloc_fixed()
Kumar Gala writes: > Paul are you planning on picking this up for .28 if not I'll pick it > up for .29 I was waiting for you to say if it needed to go in .28. Sounds like you don't think it's that urgent then? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Fix few build errors with CONFIG_QUICC_ENGINE=n
On Dec 16, 2008, at 1:14 PM, Anton Vorontsov wrote: On Tue, Dec 16, 2008 at 01:00:13PM -0600, Scott Wood wrote: Anton Vorontsov wrote: GCC can still issue the of_find_node_by_name() call. (I wonder if there is any way to tell gcc that particular function doesn't produce any side-effects so that gcc can optimize it away too). __attribute__((pure)) Ah, thanks! But I forgot that of_find_node_by_name() and friends aren't actually "pure", they're getting the node. :-( Looking at include/linux/compiler-gcc.h I'm guessing the proper way to use it is __pure & inclusion of compiler.h - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8572 - IPR Register
On Dec 16, 2008, at 4:08 PM, bterrell wrote: Kumar Gala-3 wrote: <1. Which PCIe port is the device on? 2. is this a INT-X style or MSI interrupt? 3. if INT-X is INT-A, B, C, D? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev He was posting a question for me. The external device (PLX8616 non-transparent bridge) which is sending the interrupt is connected to the first PCIE controller. The PCIE controller is configured in RC mode and is "x4". I'm using legacy (INTx) interrupts from the external switch NTB port. The NTB port always generates INTA, but is swizzled by the upstream port of the PLX8616 switch, so it comes to the PCIE controller as INTB I believe. It works fine when the the 8572 and 8616 both start after power-on reset. Can send multiple interrupts and each is acknowledged properly. However, after I generate a "hot reset" event from the PCIE controller to the upstream port on the 8616 (or link goes down/up), it no longer seems to propagate the INTx interrupt to the CPU. Either the 8616 is not sending the interrrupt or the 8572 is ignoring/masking it. I'm trying to determine which device is at fault. I don't have access to a PCIE analyzer at the moment. Looking for some more visibility into received interrupts within the 8572 PCIE or MPIC. FYI, I have not tried MSI yet but will soon. So I'll ask the same questions. I can point you at some registers to look at but wanted the details I asked about earlier. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8572 - IPR Register
Kumar Gala-3 wrote: > > > <1. Which PCIe port is the device on? > 2. is this a INT-X style or MSI interrupt? > 3. if INT-X is INT-A, B, C, D? > > - k > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > He was posting a question for me. The external device (PLX8616 non-transparent bridge) which is sending the interrupt is connected to the first PCIE controller. The PCIE controller is configured in RC mode and is "x4". I'm using legacy (INTx) interrupts from the external switch NTB port. The NTB port always generates INTA, but is swizzled by the upstream port of the PLX8616 switch, so it comes to the PCIE controller as INTB I believe. It works fine when the the 8572 and 8616 both start after power-on reset. Can send multiple interrupts and each is acknowledged properly. However, after I generate a "hot reset" event from the PCIE controller to the upstream port on the 8616 (or link goes down/up), it no longer seems to propagate the INTx interrupt to the CPU. Either the 8616 is not sending the interrrupt or the 8572 is ignoring/masking it. I'm trying to determine which device is at fault. I don't have access to a PCIE analyzer at the moment. Looking for some more visibility into received interrupts within the 8572 PCIE or MPIC. FYI, I have not tried MSI yet but will soon. thanks, Bill -- View this message in context: http://www.nabble.com/MPC8572---IPR-Register-tp21040440p21042870.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Protect against NULL pointer deref in phyp-dump code.
Acked-by: Manish Ahuja
Tony Breeds wrote:
> print_dump_header() will be called at least once with a NULL pointer in
> a normal boot sequence. if DEBUG is defined then we will get a deref,
> add a quick fix to exit early in the NULL pointer case.
>
> Signed-off-by: Tony Breeds
> ---
> arch/powerpc/platforms/pseries/phyp_dump.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/phyp_dump.c
> b/arch/powerpc/platforms/pseries/phyp_dump.c
> index edbc012..16e659a 100644
> --- a/arch/powerpc/platforms/pseries/phyp_dump.c
> +++ b/arch/powerpc/platforms/pseries/phyp_dump.c
> @@ -130,6 +130,9 @@ static unsigned long init_dump_header(struct
> phyp_dump_header *ph)
> static void print_dump_header(const struct phyp_dump_header *ph)
> {
> #ifdef DEBUG
> + if (ph == NULL)
> + return;
> +
> printk(KERN_INFO "dump header:\n");
> /* setup some ph->sections required */
> printk(KERN_INFO "version = %d\n", ph->version);
--
--
Manish Ahuja
Linux RAS Engineer.
IBM Linux Technology Center
mah...@us.ibm.com
512-838-1928, t/l 678-1928.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8572 - IPR Register
On Dec 16, 2008, at 1:54 PM, Morrison, Tom wrote: We are having a problem with an external interrupt not actually being received / detected on the MPC8572. This external device 'believes' that it has sent an interrupt (over PCIe) to the MPC8572 and we believe that the associated ExVPR register has correctly unmasked/configured this correctly. But, still NO interrupt... If you read the documentation about this configuration register, it indicates that there is some type of "IPR" register internal to the 8572 that indicates if an interrupt has been received by the PIC... We want to read that IPR register to verify that: a) the external device has sent the interrupt and we have configured something wrong in the chip b) there is no pending interrupt (thus none received) from this external device... Is there any way (hook (indirection) or crook (aka: secret register)) that would allow us to read this register? From all my investigations it looks like there isn't a 'straight forward' / documented way to do so...I am hoping you guys have gone beyond the 'straight forward' means and have found a way... Thanks in Advance... 1. Which PCIe port is the device on? 2. is this a INT-X style or MSI interrupt? 3. if INT-X is INT-A, B, C, D? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC8572 - IPR Register
We are having a problem with an external interrupt not actually being received / detected on the MPC8572. This external device 'believes' that it has sent an interrupt (over PCIe) to the MPC8572 and we believe that the associated ExVPR register has correctly unmasked/configured this correctly. But, still NO interrupt... If you read the documentation about this configuration register, it indicates that there is some type of "IPR" register internal to the 8572 that indicates if an interrupt has been received by the PIC... We want to read that IPR register to verify that: a) the external device has sent the interrupt and we have configured something wrong in the chip b) there is no pending interrupt (thus none received) from this external device... Is there any way (hook (indirection) or crook (aka: secret register)) that would allow us to read this register? From all my investigations it looks like there isn't a 'straight forward' / documented way to do so...I am hoping you guys have gone beyond the 'straight forward' means and have found a way... Thanks in Advance... Sincerely... Tom Morrison Principal S/W Engineer Tmorrison (at) empirix (dot) com www.empirix.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Fix few build errors with CONFIG_QUICC_ENGINE=n
On Tue, Dec 16, 2008 at 01:00:13PM -0600, Scott Wood wrote: > Anton Vorontsov wrote: >> GCC can still issue the of_find_node_by_name() call. (I wonder if >> there is any way to tell gcc that particular function doesn't >> produce any side-effects so that gcc can optimize it away too). > > __attribute__((pure)) Ah, thanks! But I forgot that of_find_node_by_name() and friends aren't actually "pure", they're getting the node. :-( -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Fix few build errors with CONFIG_QUICC_ENGINE=n
Anton Vorontsov wrote: GCC can still issue the of_find_node_by_name() call. (I wonder if there is any way to tell gcc that particular function doesn't produce any side-effects so that gcc can optimize it away too). __attribute__((pure)) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Fix few build errors with CONFIG_QUICC_ENGINE=n
On Tue, Dec 16, 2008 at 12:18:07PM -0600, Kumar Gala wrote: [..] >> This patch implements traditional way of !QE case handling. >> Alternative version is coming (w/o ifdefs in the board files). >> >> p.s. I don't know if it is 2.6.28 material... > > what's the state of this patch vs the alternate version? Pros of the alternative version: - No #ifdefs in .c files. Cons of the alternative version: - For this code (assuming QE=n): if ((np = of_find_node_by_name(NULL, "par_io")) != NULL) par_io_init(np); GCC can still issue the of_find_node_by_name() call. (I wonder if there is any way to tell gcc that particular function doesn't produce any side-effects so that gcc can optimize it away too). It's up to you to decide which version you want to merge. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Pass a valid token to rats_call() in phyp-dump code.
Yes,
That is required. It is in the patches that I sent to Ben, Paul & Brad.
I just waiting to post it with other patches.
Acked-by: Manish Ahuja
Tony Breeds wrote:
> ibm_configure_kernel_dump, is passed as the token to rtas_call() but I
> cannot see where it is initialised. Set it to something sane?
>
> Signed-off-by: Tony Breeds
> ---
> arch/powerpc/platforms/pseries/phyp_dump.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/phyp_dump.c
> b/arch/powerpc/platforms/pseries/phyp_dump.c
> index 16e659a..6cf35cd 100644
> --- a/arch/powerpc/platforms/pseries/phyp_dump.c
> +++ b/arch/powerpc/platforms/pseries/phyp_dump.c
> @@ -414,6 +414,8 @@ static int __init phyp_dump_setup(void)
> of_node_put(rtas);
> }
>
> + ibm_configure_kernel_dump = rtas_token("ibm,configure-kernel-dump");
> +
> print_dump_header(dump_header);
> dump_area_length = init_dump_header(&phdr);
> /* align down */
--
--
Manish Ahuja
Linux RAS Engineer.
IBM Linux Technology Center
mah...@us.ibm.com
512-838-1928, t/l 678-1928.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] powerpc/83xx: Fix sparse warnings in mpc836x_mds.c
On Dec 3, 2008, at 1:27 PM, Anton Vorontsov wrote: This patch fixes following sparse warnings: CHECK mpc836x_mds.c mpc836x_mds.c:75:12: warning: Using plain integer as NULL pointer mpc836x_mds.c:79:13: warning: incorrect type in assignment (different address spaces) mpc836x_mds.c:79:13:expected unsigned char [usertype] *static [toplevel] bcsr_regs mpc836x_mds.c:79:13:got void [noderef] * mpc836x_mds.c:105:3: warning: incorrect type in argument 1 (different address spaces) mpc836x_mds.c:105:3:expected unsigned char volatile [noderef] [usertype] *addr mpc836x_mds.c:105:3:got unsigned char [usertype] * mpc836x_mds.c:105:3: warning: incorrect type in argument 1 (different address spaces) mpc836x_mds.c:105:3:expected unsigned char const volatile [noderef] [usertype] *addr mpc836x_mds.c:105:3:got unsigned char [usertype] * mpc836x_mds.c:107:3: warning: incorrect type in argument 1 (different address spaces) mpc836x_mds.c:107:3:expected unsigned char volatile [noderef] [usertype] *addr mpc836x_mds.c:107:3:got unsigned char [usertype] * mpc836x_mds.c:107:3: warning: incorrect type in argument 1 (different address spaces) mpc836x_mds.c:107:3:expected unsigned char const volatile [noderef] [usertype] *addr mpc836x_mds.c:107:3:got unsigned char [usertype] * mpc836x_mds.c:131:11: warning: incorrect type in argument 1 (different address spaces) mpc836x_mds.c:131:11:expected void volatile [noderef] *addr mpc836x_mds.c:131:11:got unsigned char [usertype] *static [toplevel] bcsr_regs Signed-off-by: Anton Vorontsov --- arch/powerpc/platforms/83xx/mpc836x_mds.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix corruption error in rh_alloc_fixed()
The problem obviously only affect people that make use of rh_alloc_fixed(), which is the case when you program an MCC or a QMC controller of the CPM. Without the patch cpm_muram_alloc_fixed() succeed when it should not, for example when trying to allocate out of range areas or already allocated areas, so it is possible that buffer descriptors or other control structures used by other controllers get corrupted. Digging into old Linux (like 2.6.9, I haven't checked before), the problem seems to always have been present. Without this patch I experienced oops (sometimes panic, sometimes not) in various unrelated part (probably an indirect result of either corruption of rheap management structures or corruption caused by the CPM using crazy overwritten data) and also initialization of multi-channel control structures putting other communication controllers out-of-order. The only risk I can think off is that it could break some out of tree kernel space code which worked because of luck and a double error - for example when doing a single DPRam allocation from offset 0 while leaving an area reserved at the base of the DPRam. So I think it should be put in 2.6.28. Paul are you planning on picking this up for .28 if not I'll pick it up for .29 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Fix sparse warnings in board files
On Dec 5, 2008, at 9:48 AM, Anton Vorontsov wrote: This patch fixes following sparse warnings: CHECK 83xx/usb.c 83xx/usb.c:205:5: warning: symbol 'mpc837x_usb_cfg' was not declared. Should it be static? CHECK 83xx/mpc831x_rdb.c 83xx/mpc831x_rdb.c:45:13: warning: symbol 'mpc831x_rdb_init_IRQ' was not declared. Should it be static? CHECK 83xx/mpc832x_rdb.c 83xx/mpc832x_rdb.c:133:13: warning: symbol 'mpc832x_rdb_init_IRQ' was not declared. Should it be static? CHECK 83xx/mpc832x_mds.c 83xx/mpc832x_mds.c:68:12: warning: Using plain integer as NULL pointer 83xx/mpc832x_mds.c:72:13: warning: incorrect type in assignment (different address spaces) 83xx/mpc832x_mds.c:72:13:expected unsigned char [usertype] *static [toplevel] bcsr_regs 83xx/mpc832x_mds.c:72:13:got void [noderef] * 83xx/mpc832x_mds.c:99:11: warning: incorrect type in argument 1 (different address spaces) 83xx/mpc832x_mds.c:99:11:expected void volatile [noderef] 2>*addr 83xx/mpc832x_mds.c:99:11:got unsigned char [usertype] *static [toplevel] bcsr_regs Signed-off-by: Anton Vorontsov --- applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] powerpc: Implement get_brgfreq() and get_baudrate() stubs
On Dec 5, 2008, at 2:10 PM, Anton Vorontsov wrote: This is needed to not bother with ugly #ifdefs in the drivers. Signed-off-by: Anton Vorontsov --- arch/powerpc/sysdev/fsl_soc.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Fix few build errors with CONFIG_QUICC_ENGINE=n
On Dec 5, 2008, at 10:55 AM, Anton Vorontsov wrote: Some 83xx boards were not ready for the optional QUICC Engine support. This patch fixes following build errors: arch/powerpc/platforms/built-in.o: In function `flush_disable_caches': (.text+0xb308): undefined reference to `par_io_data_set' arch/powerpc/platforms/built-in.o: In function `flush_disable_caches': (.text+0xb334): undefined reference to `par_io_data_set' arch/powerpc/platforms/built-in.o: In function `flush_disable_caches': (.text+0xb408): undefined reference to `qe_ic_get_high_irq' arch/powerpc/platforms/built-in.o: In function `flush_disable_caches': (.text+0xb478): undefined reference to `qe_ic_get_low_irq' arch/powerpc/platforms/built-in.o: In function `mpc832x_spi_init': mpc832x_rdb.c:(.init.text+0x574c): undefined reference to `par_io_config_pin' mpc832x_rdb.c:(.init.text+0x5768): undefined reference to `par_io_config_pin' mpc832x_rdb.c:(.init.text+0x5784): undefined reference to `par_io_config_pin' mpc832x_rdb.c:(.init.text+0x57a0): undefined reference to `par_io_config_pin' mpc832x_rdb.c:(.init.text+0x57bc): undefined reference to `par_io_config_pin' arch/powerpc/platforms/built-in.o:mpc832x_rdb.c:(.init.text+0x57d8): more undefined references to `par_io_config_pin' follow arch/powerpc/platforms/built-in.o: In function `mpc836x_rdk_init_IRQ': mpc836x_rdk.c:(.init.text+0x5e84): undefined reference to `qe_ic_init' arch/powerpc/platforms/built-in.o: In function `mpc836x_rdk_setup_arch': mpc836x_rdk.c:(.init.text+0x5f10): undefined reference to `qe_reset' make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Anton Vorontsov --- This patch implements traditional way of !QE case handling. Alternative version is coming (w/o ifdefs in the board files). p.s. I don't know if it is 2.6.28 material... what's the state of this patch vs the alternate version? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: adding of_platform_drivers (was: Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq)
On Tue, Dec 16, 2008 at 01:27:32PM +0100, Wolfram Sang wrote: > > > +/* - > > > + * OF bus binding > > > + */ > > > + > > > +#if defined(CONFIG_OF) > > > > Same goes here, don't put #if in .c files please. > > So, generally speaking, this means that I should not put a > platform_driver and an of_platform_driver into one source file, but > rather create an of_$DRIVER.c then? Yes, this is the preferred way to do it. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'next' branch
Hi Kumar, On Mon, Dec 15, 2008 at 02:31:04PM -0600, Kumar Gala wrote: > Please pull from 'next' branch of > > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next > > to receive the following updates: > > arch/powerpc/boot/dts/mpc8572ds.dts | 16 > arch/powerpc/include/asm/cputable.h | 15 --- > 2 files changed, 16 insertions(+), 15 deletions(-) > > Benjamin Herrenschmidt (1): > powerpc: Fix bogus cache flushing on all 40x and BookE processors v2 > > Kumar Gala (1): > powerpc/85xx: Fix compile issues with mpc8572ds.dts Could you please take a look into these: powerpc/qe: Select QE_USB with USB_GADGET_FSL_QE http://patchwork.ozlabs.org/patch/7892/ [1/5] powerpc/qe: Implement QE Pin Multiplexing API http://patchwork.ozlabs.org/patch/11982/ [2/5] powerpc: Implement GPIO driver for simple memory-mapped banks http://patchwork.ozlabs.org/patch/11984/ [3/5] powerpc/83xx: Add USB Host/Gadget support for MPC8360E-MDS boards http://patchwork.ozlabs.org/patch/11985/ [4/5] powerpc/83xx: Add USB Host support for MPC8360E-RDK boards http://patchwork.ozlabs.org/patch/11986/ [5/5] powerpc/83xx: Fix sparse warnings in mpc836x_mds.c http://patchwork.ozlabs.org/patch/11987/ powerpc/83xx: Fix sparse warnings in board files http://patchwork.ozlabs.org/patch/12419/ powerpc/83xx: Fix few build errors with CONFIG_QUICC_ENGINE=n http://patchwork.ozlabs.org/patch/12425/ -- OR -- powerpc/qe: Fix few build errors with CONFIG_QUICC_ENGINE=n http://patchwork.ozlabs.org/patch/12426/ Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More commits added to powerpc.git next and master branches
Hi Paul, On Tue, Dec 16, 2008 at 04:10:34PM +1100, Paul Mackerras wrote: > I have added the following commits to the next and master branches of > my powerpc.git tree (including commits pulled from Kumar's tree). I > have also pulled in Linus' current tree and the 3 commits that I just > asked him to pull. Is there anything wrong with these down below? [1/3] of: Minor simplification for the of_parse_phandles_with_args() http://patchwork.ozlabs.org/patch/12449/ [2/3] of: of_parse_phandles_with_args() learns to differentiate 'hole' cells http://patchwork.ozlabs.org/patch/12450/ [3/3] of/gpio: Implement of_gpio_count() http://patchwork.ozlabs.org/patch/12451/ Can we apply them for 2.6.29? Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Dummy GPIO driver for use with SPI
On Fri, Dec 12, 2008 at 01:39:45PM -0800, Trent Piepho wrote:
> On Fri, 12 Dec 2008, Anton Vorontsov wrote:
> > On Fri, Dec 12, 2008 at 11:59:13AM -0500, Steven A. Falco wrote:
> >> What do you think about having a mechanism to specify that some
> >> SPI slaves have a chip select, while others don't have to have a
> >> chip select managed by the SPI subsystem?
> >
> > Um.. do you know that you can pass '0' as a GPIO?
> >
> > For example,
> >
> > spi-controller {
> > gpios = <&pio1 1 0 /* cs0 */
> > 0 /* cs1, no GPIO */
> > &pio2 2 0>;/* cs2 */
>
> It's ok the that middle specifier is only one word instead of three? Seems
> like "0 0 0" would be better, so all the specifiers are the same size.
>
> > normal case;
> > } else if (gpio == -EEXIST) {
>
> Isn't EEXIST (pathname already exists) backward?
In my thinking it's "the GPIO is specified (exists in the list), but
it's would be an error if you try to use it". So EEXIST.
> Seems like ENOENT would
> be the right error code. Except that's used for reading past the end...
> Maybe a reading past the end should be EINVAL or EBADF?
>
> Or return ENODEV for the 'hole' cell? Or ENOLINK?
I'd say it's a matter of taste, none of the errors are actually
appropriate. An appropriate errno value would be EHOLEINALIST,
but we don't have it.
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More commits added to powerpc.git next and master branches
On Tue, Dec 16, 2008 at 04:10:34PM +1100, Paul Mackerras wrote: >I have added the following commits to the next and master branches of >my powerpc.git tree (including commits pulled from Kumar's tree). I >have also pulled in Linus' current tree and the 3 commits that I just >asked him to pull. I sent a pull request to you last week for my -next branch. It would be nice to get those included as well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: Remove default kexec/crash_kernel ops assignments
Default ops are implicit now.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/platforms/cell/celleb_setup.c |9 -
arch/powerpc/platforms/cell/setup.c|6 --
arch/powerpc/platforms/embedded6xx/c2k.c |6 --
arch/powerpc/platforms/embedded6xx/prpmc2800.c |6 --
arch/powerpc/platforms/maple/setup.c |6 --
arch/powerpc/platforms/powermac/setup.c|6 --
arch/powerpc/platforms/ps3/setup.c |4
7 files changed, 0 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c
b/arch/powerpc/platforms/cell/celleb_setup.c
index b11cb30..07c234f 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -45,7 +45,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -226,9 +225,6 @@ define_machine(celleb_beat) {
.pci_setup_phb = celleb_setup_phb,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = beat_kexec_cpu_down,
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
#endif
};
@@ -248,9 +244,4 @@ define_machine(celleb_native) {
.pci_probe_mode = celleb_pci_probe_mode,
.pci_setup_phb = celleb_setup_phb,
.init_IRQ = celleb_init_IRQ_native,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/cell/setup.c
b/arch/powerpc/platforms/cell/setup.c
index ab721b5..5930536 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -35,7 +35,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -289,9 +288,4 @@ define_machine(cell) {
.progress = cell_progress,
.init_IRQ = cell_init_irq,
.pci_setup_phb = cell_setup_phb,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/embedded6xx/c2k.c
b/arch/powerpc/platforms/embedded6xx/c2k.c
index 32ba0fa..8cab573 100644
--- a/arch/powerpc/platforms/embedded6xx/c2k.c
+++ b/arch/powerpc/platforms/embedded6xx/c2k.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include
#include
@@ -147,9 +146,4 @@ define_machine(c2k) {
.get_irq= mv64x60_get_irq,
.restart= c2k_restart,
.calibrate_decr = generic_calibrate_decr,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index 4c485e9..670035f 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
@@ -155,9 +154,4 @@ define_machine(prpmc2800){
.get_irq= mv64x60_get_irq,
.restart= prpmc2800_restart,
.calibrate_decr = generic_calibrate_decr,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index d4c61c3..bfd60e4 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -50,7 +50,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -335,9 +334,4 @@ define_machine(maple) {
.calibrate_decr = generic_calibrate_decr,
.progress = maple_progress,
.power_save = power4_idle,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 1293772..9b78f53 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -60,7 +60,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -738,11 +737,6 @@ define_machine(powermac) {
.pci_probe_mode
[PATCH 2/3] powerpc: Make default kexec/crash_kernel ops implicit
This patch removes need for each platform to specify default kexec and
crash kernel ops, thus effectively adds a working kexec support for most
boards.
Platforms that can't cope with default ops will explode in some weird
way (a hang or reboot is most likely), which means that the board's
kexec support should be fixed or blacklisted via dummy _prepare callback
returning -ENOSYS.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/kernel/machine_kexec.c | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index 037ade7..4f797c0 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -22,6 +22,8 @@ void machine_crash_shutdown(struct pt_regs *regs)
{
if (ppc_md.machine_crash_shutdown)
ppc_md.machine_crash_shutdown(regs);
+ else
+ default_machine_crash_shutdown(regs);
}
/*
@@ -33,11 +35,8 @@ int machine_kexec_prepare(struct kimage *image)
{
if (ppc_md.machine_kexec_prepare)
return ppc_md.machine_kexec_prepare(image);
- /*
-* Fail if platform doesn't provide its own machine_kexec_prepare
-* implementation.
-*/
- return -ENOSYS;
+ else
+ return default_machine_kexec_prepare(image);
}
void machine_kexec_cleanup(struct kimage *image)
@@ -54,13 +53,11 @@ void machine_kexec(struct kimage *image)
{
if (ppc_md.machine_kexec)
ppc_md.machine_kexec(image);
- else {
- /*
-* Fall back to normal restart if platform doesn't provide
-* its own kexec function, and user insist to kexec...
-*/
- machine_restart(NULL);
- }
+ else
+ default_machine_kexec(image);
+
+ /* Fall back to normal restart if we're still alive. */
+ machine_restart(NULL);
for(;;);
}
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: Setup OF properties for ppc32 kexec
From: Dale Farnsworth
Refactor the setting of kexec OF properties, moving the common code
from machine_kexec_64.c to machine_kexec.c where it can be used on
both ppc64 and ppc32. This is needed for kexec to work on ppc32
platforms.
Signed-off-by: Dale Farnsworth
Signed-off-by: Anton Vorontsov
---
arch/powerpc/kernel/machine_kexec.c| 34
arch/powerpc/kernel/machine_kexec_64.c | 24 -
2 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index ac2a21f..037ade7 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -13,8 +13,10 @@
#include
#include
#include
+#include
#include
#include
+#include
void machine_crash_shutdown(struct pt_regs *regs)
{
@@ -118,3 +120,35 @@ int overlaps_crashkernel(unsigned long start, unsigned
long size)
{
return (start + size) > crashk_res.start && start <= crashk_res.end;
}
+
+/* Values we need to export to the second kernel via the device tree. */
+static unsigned long kernel_end;
+
+static struct property kernel_end_prop = {
+ .name = "linux,kernel-end",
+ .length = sizeof(unsigned long),
+ .value = &kernel_end,
+};
+
+static int __init kexec_setup(void)
+{
+ struct device_node *node;
+ struct property *prop;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ /* remove any stale properties so ours can be found */
+ prop = of_find_property(node, kernel_end_prop.name, NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ /* information needed by userspace when using default_machine_kexec */
+ kernel_end = __pa(_end);
+ prom_add_property(node, &kernel_end_prop);
+
+ of_node_put(node);
+ return 0;
+}
+late_initcall(kexec_setup);
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 3c4ca04..a89bce8 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -289,7 +289,7 @@ void default_machine_kexec(struct kimage *image)
}
/* Values we need to export to the second kernel via the device tree. */
-static unsigned long htab_base, kernel_end;
+static unsigned long htab_base;
static struct property htab_base_prop = {
.name = "linux,htab-base",
@@ -303,25 +303,20 @@ static struct property htab_size_prop = {
.value = &htab_size_bytes,
};
-static struct property kernel_end_prop = {
- .name = "linux,kernel-end",
- .length = sizeof(unsigned long),
- .value = &kernel_end,
-};
-
static void __init export_htab_values(void)
{
struct device_node *node;
struct property *prop;
+ /* On machines with no htab htab_address is NULL */
+ if (!htab_address)
+ return;
+
node = of_find_node_by_path("/chosen");
if (!node)
return;
/* remove any stale propertys so ours can be found */
- prop = of_find_property(node, kernel_end_prop.name, NULL);
- if (prop)
- prom_remove_property(node, prop);
prop = of_find_property(node, htab_base_prop.name, NULL);
if (prop)
prom_remove_property(node, prop);
@@ -329,19 +324,10 @@ static void __init export_htab_values(void)
if (prop)
prom_remove_property(node, prop);
- /* information needed by userspace when using default_machine_kexec */
- kernel_end = __pa(_end);
- prom_add_property(node, &kernel_end_prop);
-
- /* On machines with no htab htab_address is NULL */
- if (NULL == htab_address)
- goto out;
-
htab_base = __pa(htab_address);
prom_add_property(node, &htab_base_prop);
prom_add_property(node, &htab_size_prop);
- out:
of_node_put(node);
}
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] Kexec for PPC32 (6xx) machines
Hi all, This is Kexec part of the larger series[1] posted few months ago. I eliminated Kdump part in this resend (will post it as a separate entity later). Milton Miller hinted that current PPC32 Kexec implementation may not work on SMP hardware. I don't have any multi-core machines handy to actually try and/or fix it, but support for SMP should be straightforward: just need to bring the secondary CPUs down before Kexec'ing (the code is already in the machine_kexec_64.c, just needs to be factored out). The arch/powerpc/Kconfig already states that the Kexec support is experimental and may not work on certain hardware, so I don't see any reason to add !SMP dependency. Anyway, the majority of boards are UP and they don't need any fancy care to work. So let's support them. [1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061161.html -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
On Tue, Dec 16, 2008 at 01:41:56PM +0100, Wolfram Sang wrote: > > In addition to the stuff pointed out by Greg, I don't see what you > > actually gain by hacking the OF crap in to this driver. You would be > > better off layering the OF driver on top of this, rather than trying to > > make them live together in the same file. > > > > See pata_platform/pata_of_platform for an example of how to do this a bit > > more sanely. > > See my reply just posted. I found two ways to go, and from reading > discussions on the lists, finally decided for this way. May have been > the wrong path, but nothing that could not be changed. > I guess there are a couple of things to consider. If it fits in fairly nicely and can be optimized out for the users that don't care, then integration generally makes sense. In this case however you have a large and insular block that is ifdef'ed in and selected by Kconfig, suggesting that the only benefit is for your driver which wishes to tie in to parts of uio_pdrv_genirq, with there being no benefits the other way. This sort of situation suggests you are better off layering and simply exposing the functionality you need from uio_pdrv_genirq. This was certainly the case with pata_platform as well, and it worked out pretty well there compared to hacking it in-place. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
> It is pretty poor form to not even bother to Cc the only author of the > code you are modifying, and have no Signed-off-by or Acked-by to even > suggest that it was ever even looked at. This isn't something that ought > to have to be pointed out, either. Oops, yes, forgot this in the resend, I am sorry. I did CC Magnus in the first round, though, and he replied to me that he liked adding OF and just waited for Hans' reply first. > In addition to the stuff pointed out by Greg, I don't see what you > actually gain by hacking the OF crap in to this driver. You would be > better off layering the OF driver on top of this, rather than trying to > make them live together in the same file. > > See pata_platform/pata_of_platform for an example of how to do this a bit > more sanely. See my reply just posted. I found two ways to go, and from reading discussions on the lists, finally decided for this way. May have been the wrong path, but nothing that could not be changed. Kind regards, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
adding of_platform_drivers (was: Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq)
> > +/* - > > + * OF bus binding > > + */ > > + > > +#if defined(CONFIG_OF) > > Same goes here, don't put #if in .c files please. So, generally speaking, this means that I should not put a platform_driver and an of_platform_driver into one source file, but rather create an of_$DRIVER.c then? I found both ways used in the kernel and could not find hints about the preferred way to do it. I took this approach as I hoped it would save some code to directly convert the of_node to uioinfo without the detour of using a platform_device inbetween. Kind regards, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
On Thu, Dec 11, 2008 at 04:05:37PM +0100, Wolfram Sang wrote:
> Make the generic uio-driver also accessible for of devices. It utilizes the
> standard 'reg' and 'interrupt' properties. A typical usage would look like
> this:
>
> fpga...@3000 {
> compatible = "generic-uio";
> reg = <0x3000 0x20>;
> interrupts = <0xa>;
> interrupt-parent = <&fpga_irq_mux>;
> };
>
> To achieve this, the probe function has been refactored, so it can be used by
> platform and of code. Then, the of driver has been added.
>
> Signed-off-by: Wolfram Sang
It is pretty poor form to not even bother to Cc the only author of the
code you are modifying, and have no Signed-off-by or Acked-by to even
suggest that it was ever even looked at. This isn't something that ought
to have to be pointed out, either.
In addition to the stuff pointed out by Greg, I don't see what you
actually gain by hacking the OF crap in to this driver. You would be
better off layering the OF driver on top of this, rather than trying to
make them live together in the same file.
See pata_platform/pata_of_platform for an example of how to do this a bit
more sanely.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More commits added to powerpc.git next and master branches
> "Paul" == Paul Mackerras writes: Paul> I have added the following commits to the next and master Paul> branches of my powerpc.git tree (including commits pulled from Paul> Kumar's tree). I have also pulled in Linus' current tree and Paul> the 3 commits that I just asked him to pull. I would like to see http://patchwork.ozlabs.org/patch/13164/ in 2.6.29 - Any comments? -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] pasemi: ioremap/iounmap balance and failure handling
Olof Johansson wrote:
> On Sat, Dec 13, 2008 at 05:45:41PM +0100, Roel Kluin wrote:
>> map_onedev can return NULL, so catch that. Also iounmap if DMA controller
>> can't be
>> found.
>> +
>> iob_regs = map_onedev(iob_pdev, 0);
>> +if (iob_regs == NULL) {
>> +BUG();
>> +printk(KERN_WARNING "Can't ioremap I/O Bridge registers\n");
>> +err = -ENODEV;
>> +goto out;
>> +}
>
> I don't see the point of doing BUG() _and_ error recovery. BUG() is
> definitely heavy handed. Something like "pasemi_dma_init: Can't..." would
> be a good and detailed enough error message.
Thanks for reviewing. This patch should address your comments to patch V1.
As I asked in my V2, I think there may also be a problem with
pasemi_mac_init_module(): if pci_register_driver() fails, then iob_regs won't
get
iounmapped. right?
Is it ok to add the function pasemi_dma_exit() for these cleanup purposes?
and is it correct that we don't need to EXPORT_SYMBOL(pasemi_dma_exit)?
-8<>8---
map_onedev can return NULL, so catch that. Also iounmap if DMA controller can't
be
found.
Signed-off-by: Roel Kluin
---
arch/powerpc/include/asm/pasemi_dma.h |3 +++
arch/powerpc/platforms/pasemi/dma_lib.c | 15 ++-
drivers/net/pasemi_mac.c|6 +-
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pasemi_dma.h
b/arch/powerpc/include/asm/pasemi_dma.h
index 19fd793..7256a2c 100644
--- a/arch/powerpc/include/asm/pasemi_dma.h
+++ b/arch/powerpc/include/asm/pasemi_dma.h
@@ -535,4 +535,7 @@ extern void pasemi_dma_free_fun(int fun);
/* Initialize the library, must be called before any other functions */
extern int pasemi_dma_init(void);
+/* Clean up the library */
+extern void pasemi_dma_exit(void);
+
#endif /* ASM_PASEMI_DMA_H */
diff --git a/arch/powerpc/platforms/pasemi/dma_lib.c
b/arch/powerpc/platforms/pasemi/dma_lib.c
index 217af32..c97fba9 100644
--- a/arch/powerpc/platforms/pasemi/dma_lib.c
+++ b/arch/powerpc/platforms/pasemi/dma_lib.c
@@ -534,14 +534,17 @@ int pasemi_dma_init(void)
err = -ENODEV;
goto out;
}
+
iob_regs = map_onedev(iob_pdev, 0);
+ if (iob_regs == NULL)
+ printk(KERN_WARNING "pasemi_dma_init: Can't ioremap I/O Bridge
registers\n");
dma_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa007, NULL);
if (!dma_pdev) {
BUG();
printk(KERN_WARNING "Can't find DMA controller\n");
err = -ENODEV;
- goto out;
+ goto out_unmap;
}
dma_regs = map_onedev(dma_pdev, 0);
base_hw_irq = virq_to_hw(dma_pdev->irq);
@@ -624,9 +627,19 @@ int pasemi_dma_init(void)
printk(KERN_INFO "PA Semi PWRficient DMA library initialized "
"(%d tx, %d rx channels)\n", num_txch, num_rxch);
+ goto out;
+
+out_unmap:
+ iounmap(iob_regs);
out:
spin_unlock(&init_lock);
return err;
}
EXPORT_SYMBOL(pasemi_dma_init);
+
+void pasemi_dma_exit(void)
+{
+ iounmap(iob_regs);
+}
+
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index edc0fd5..0897fa0 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -1919,7 +1919,11 @@ int pasemi_mac_init_module(void)
if (err)
return err;
- return pci_register_driver(&pasemi_mac_driver);
+ err = pci_register_driver(&pasemi_mac_driver);
+ if (err)
+ pasemi_dma_exit();
+
+ return err;
}
module_init(pasemi_mac_init_module);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/1 v2] hvc_console: escape magic sysrq key
Hello Andreas,
thanks for your comments.
On Tue, Dec 16, 2008 at 10:36:55AM +0100, Andreas Schwab wrote:
> > + /* if ^0 is pressed again, reset
> > +* sysrq_pressed and flip ^0 char */
> The comment says ^0 twice when ^O is meant.
Correct. I have updated the comment.
> > + sysrq_pressed = (sysrq_pressed) ? 0 : 1;
> sysrq_pressed = !sysrc_pressed;
Ok, it might look better.
[PATCH v2] hvc_console: escape magic sysrq key
From: Hendrik Brueckner
The ctrl-o (^O) is a common control key used by several applications like vim.
To allow users to send ^O to the terminal, this patch introduces a check
if ^O is pressed again if the sysrq_pressed variable is already set.
In this case, clear sysrq_pressed state and flip the ^O character to the tty.
(The old behavior has always set "sysrq_pressed" if ^O has been entered, and it
has not flipped the ^O character to the tty.)
Signed-off-by: Hendrik Brueckner
---
drivers/char/hvc_console.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -642,8 +642,11 @@ int hvc_poll(struct hvc_struct *hp)
/* Handle the SysRq Hack */
/* XXX should support a sequence */
if (buf[i] == '\x0f') { /* ^O */
- sysrq_pressed = 1;
- continue;
+ /* if ^O is pressed again, reset
+* sysrq_pressed and flip ^O char */
+ sysrq_pressed = !sysrq_pressed;
+ if (sysrq_pressed)
+ continue;
} else if (sysrq_pressed) {
handle_sysrq(buf[i], tty);
sysrq_pressed = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/1] hvc_console: escape magic sysrq key
Hendrik Brueckner writes: > + /* if ^0 is pressed again, reset > + * sysrq_pressed and flip ^0 char */ The comment says ^0 twice when ^O is meant. > + sysrq_pressed = (sysrq_pressed) ? 0 : 1; sysrq_pressed = !sysrc_pressed; Andreas. -- Andreas Schwab, SuSE Labs, sch...@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/1] hvc_console: escape magic sysrq key
From: Hendrik Brueckner
The ctrl-o (^O) is a common control key used by several applications like vim.
To allow users to send ^O to the terminal, this patch introduces a check
if ^O is pressed again if the sysrq_pressed variable is already set.
In this case, clear sysrq_pressed state and flip the ^O character to the tty.
(The old behavior has always set "sysrq_pressed" if ^0 has been entered, and it
has not flipped the ^O character to the tty.)
Signed-off-by: Hendrik Brueckner
---
drivers/char/hvc_console.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -642,8 +642,11 @@ int hvc_poll(struct hvc_struct *hp)
/* Handle the SysRq Hack */
/* XXX should support a sequence */
if (buf[i] == '\x0f') { /* ^O */
- sysrq_pressed = 1;
- continue;
+ /* if ^0 is pressed again, reset
+* sysrq_pressed and flip ^0 char */
+ sysrq_pressed = (sysrq_pressed) ? 0 : 1;
+ if (sysrq_pressed)
+ continue;
} else if (sysrq_pressed) {
handle_sysrq(buf[i], tty);
sysrq_pressed = 0;
--
Hendrik Brueckner
D/3303 Linux on System z Development
eMail: brueck...@linux.vnet.ibm.com
IBM Deutschland Research & Development GmbH, Schoenaicher Str. 220, 71032
Boeblingen
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/1] hvc_console: send magic sysrq key to terminal
Hello, the patch allows to send the magic sysrq key to the terminal (if pressed twice), so that it can be consumed by applications (e.g. ^0 is used by some editors...) Ben, Paul, could you add the patch to your powerpc tree? Thanks and regards, Hendrik -- Hendrik Brueckner D/3303 Linux on System z Development eMail: brueck...@linux.vnet.ibm.com IBM Deutschland Research & Development GmbH, Schoenaicher Str. 220, 71032 Boeblingen IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Erich Baier Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More commits added to powerpc.git next and master branches
On Tue, 2008-12-16 at 20:01 +1100, Paul Mackerras wrote: > > Is there any reason you haven't been updating patchwork ? Or are you > > waiting for things in your -next branch to actually hit upstream ? > > Just an oversight. I have updated it now, at least for the patches I > committed. Cool, thanks. It's getting a little bit out of control, hence my asking :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More commits added to powerpc.git next and master branches
Benjamin Herrenschmidt writes: > Is there any reason you haven't been updating patchwork ? Or are you > waiting for things in your -next branch to actually hit upstream ? Just an oversight. I have updated it now, at least for the patches I committed. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: MTD: Add cached map support to physmap_of MTD driver
On Mon, 2008-12-15 at 17:11 -0800, Trent Piepho wrote: > Shame, as it provides a huge speed up. I suppose an alternative would be > to map the chip twice at different physical addresses, by just configuring > the chip select to be twice the size it should be, and giving them > different cacheability. Nice trick. That would probably work. > Or changing the mapping for writes and then changing it back. It wouldn't > be necessary to change the whole thing, just the page being written to. Right though changing mappings can be expensive. It might be worth looking at using fixmap for that tho, which is the fastest way to setup and tear down mappings, especially since we can (though we don't today) implement a bypass on those to directly load the TLB. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: MTD: Add cached map support to physmap_of MTD driver
On Mon, 2008-12-15 at 10:25 -0800, Trent Piepho wrote: > The MTD system supports operation where a direct mapped flash chip is > mapped twice. The normal mapping is a standard ioremap(), which is > non-cached and guarded on powerpc. The second mapping is used only for > reads and can be cached and non-guarded. Currently, only the pxa2xx > mapping driver makes use of this feature. This patch adds support to the > physmap_of driver on PPC32 platforms for this cached mapping mode. This can be dangerous tho. I think it's illegal as per the architecture to have the same physical address mapped twice with different caching attributes. More specifically, various processors can get very upset if you do an uncached access that happens to hit a line in the cache. The problem gets worsened by the fact that cores that support speculative loads and prefetch will potentially bring anything mapped into the cache even if it's not directly accessed. So you have to be very careful and first verify that on whatever core you intend to use that feature, what you are doing is indeed safe. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
