RE: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, March 06, 2013 2:48 AM > To: Jia Hongtao-B38951 > Cc: Wood Scott-B07421; Stuart Yoder; linuxppc-dev@lists.ozlabs.org; Kumar > Gala > Subject: Re: [PATCH V4] powerpc/85xx: Add machine check handler to fix > PCIe erratum on mpc85xx > > On 03/05/2013 04:12:30 AM, Jia Hongtao-B38951 wrote: > > > > > > > -Original Message- > > > From: Wood Scott-B07421 > > > Sent: Tuesday, March 05, 2013 7:46 AM > > > To: Stuart Yoder > > > Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Kumar Gala > > > Subject: Re: [PATCH V4] powerpc/85xx: Add machine check handler to > > fix > > > PCIe erratum on mpc85xx > > > > > > On 03/04/2013 10:16:10 AM, Stuart Yoder wrote: > > > > On Mon, Mar 4, 2013 at 2:40 AM, Jia Hongtao > > > > wrote: > > > > > A PCIe erratum of mpc85xx may causes a core hang when a link of > > PCIe > > > > > goes down. when the link goes down, Non-posted transactions > > issued > > > > > via the ATMU requiring completion result in an instruction > > stall. > > > > > At the same time a machine-check exception is generated to the > > core > > > > > to allow further processing by the handler. We implements the > > > > handler > > > > > which skips the instruction caused the stall. > > > > > > > > Can you explain at a high level how just skipping an instruction > > > > solves > > > > anything? If you just skip a load/store and continue like > > nothing is > > > > wrong, isn't your system possibly in a really bad state. > > > > > > If the instruction was a load, we probably at least want to fill the > > > destination register with 0x or similar. > > > > You discuss this with Liu Shuo about a year ago. > > here is the log: > > > > " > > On 02/01/2012 02:18 AM, shuo@freescale.com wrote: > > > v3 : Skip the instruction only. Don't access the user space memory > > in > > > mechine check. > > > > It may be the least bad option for now, but be aware that there's a > > small chance that this will cause a leak of sensitive information > > (such as a piece of a crypto key that happened to be sitting in the > > register to be loaded into). > > Yes, that's (one reason) why you'd want to fill in a known value. Note > the "for now". :-) > > -Scott I think there is no overwhelming reason to fill the destination register with 0x. There's a small chance that 0x is treated as regular data rather than an error sign. Also setting this register may influence the user space under certain circumstance. So I think just ignore the skipped instruction is an acceptable option for this fix. -Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
Hi Benjamin,
Could you please apply this patch?
Regards,
dongsheng
> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Wednesday, February 20, 2013 1:58 PM
> To: 'Kumar Gala'
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
>
>
>
> > -Original Message-
> > From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> > Sent: Tuesday, February 19, 2013 3:43 AM
> > To: Wang Dongsheng-B40534
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
> >
> >
> > On Jan 30, 2013, at 9:10 PM, Wang Dongsheng wrote:
> >
> > > Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc->action-
> > >flag.
> > > So the wake up interrupt will not be disable in suspend_device_irqs.
> > >
> > > Signed-off-by: Wang Dongsheng
> > > ---
> > > arch/powerpc/sysdev/mpic.c | 15 +++
> > > 1 files changed, 15 insertions(+), 0 deletions(-)
> >
> > Why are we doing this globally for all interrupts? Don't we only have
> > some specific interrupts that wake us up?
> > Also, I'm guessing the wake behavior for interrupts is FSL specific so
> > should not apply to ALL users of MPIC.
>
> That is IRQ wakeup (PM) control. Actually not all interrupts will be set.
> We just let mpic have this ability. It's control by driver.
> If a device has the ability to wake up system, this device driver can set
> irq wake up(through enable/disable_irq_wake()), and the driver do not
> need add a flag(IRQF_NO_SUSPEND) to request_irq().
>
> for example,
>
> suspend()
> {
> ...;
> enable_irq_wake(irq);
> ...;
> }
>
> resume()
> {
> ...;
> disable_irq_wake(irq);
> ...;
> }
>
> >
> > - k
> >
>
> > >
> > > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > > index 9c6e535..2ed0220 100644
> > > --- a/arch/powerpc/sysdev/mpic.c
> > > +++ b/arch/powerpc/sysdev/mpic.c
> > > @@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d,
> > > unsigned
> > int flow_type)
> > > return IRQ_SET_MASK_OK_NOCOPY;
> > > }
> > >
> > > +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
> > > + struct irq_desc *desc = container_of(d, struct irq_desc,
> > > +irq_data);
> > > +
> > > + if (on)
> > > + desc->action->flags |= IRQF_NO_SUSPEND;
> > > + else
> > > + desc->action->flags &= ~IRQF_NO_SUSPEND;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > void mpic_set_vector(unsigned int virq, unsigned int vector) {
> > > struct mpic *mpic = mpic_from_irq(virq); @@ -957,6 +969,7 @@ static
> > > struct irq_chip mpic_irq_chip = {
> > > .irq_unmask = mpic_unmask_irq,
> > > .irq_eoi= mpic_end_irq,
> > > .irq_set_type = mpic_set_irq_type,
> > > + .irq_set_wake = mpic_irq_set_wake,
> > > };
> > >
> > > #ifdef CONFIG_SMP
> > > @@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip = {
> > > .irq_mask = mpic_mask_tm,
> > > .irq_unmask = mpic_unmask_tm,
> > > .irq_eoi= mpic_end_irq,
> > > + .irq_set_wake = mpic_irq_set_wake,
> > > };
> > >
> > > #ifdef CONFIG_MPIC_U3_HT_IRQS
> > > @@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip = {
> > > .irq_unmask = mpic_unmask_ht_irq,
> > > .irq_eoi= mpic_end_ht_irq,
> > > .irq_set_type = mpic_set_irq_type,
> > > + .irq_set_wake = mpic_irq_set_wake,
> > > };
> > > #endif /* CONFIG_MPIC_U3_HT_IRQS */
> > >
> > > --
> > > 1.7.5.1
> > >
> > >
> > > ___
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][RFC, upstream] powerpc: remove the PPC_CLOCK dependency
From: Tang Yuantian config FSL_SOC and CPM do not really depend on PPC_CLOCK. So remove it. PPC_CLOCK also keeps powerpc archtecture from supporting COMMON_CLK. Signed-off-by: Tang Yuantian --- arch/powerpc/Kconfig |1 - arch/powerpc/platforms/Kconfig |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 352f416..383485b 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -655,7 +655,6 @@ config SBUS config FSL_SOC bool select HAVE_CAN_FLEXCAN if NET && CAN - select PPC_CLOCK config FSL_PCI bool diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index e7a896a..aba81cd 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -343,7 +343,6 @@ config FSL_ULI1575 config CPM bool - select PPC_CLOCK config OF_RTC bool -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][V2] powerpc: remove the PPC_CLOCK dependency
From: Tang Yuantian config FSL_SOC and CPM do not really depend on PPC_CLOCK. So remove it. PPC_CLOCK also keeps powerpc archtecture from supporting COMMON_CLK. Signed-off-by: Tang Yuantian --- v2: correct the title arch/powerpc/Kconfig |1 - arch/powerpc/platforms/Kconfig |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 352f416..383485b 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -655,7 +655,6 @@ config SBUS config FSL_SOC bool select HAVE_CAN_FLEXCAN if NET && CAN - select PPC_CLOCK config FSL_PCI bool diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index e7a896a..aba81cd 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -343,7 +343,6 @@ config FSL_ULI1575 config CPM bool - select PPC_CLOCK config OF_RTC bool -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
> > Yes, that's (one reason) why you'd want to fill in a known value. Note > > the "for now". :-) > > > > -Scott > > I think there is no overwhelming reason to fill the destination register > with 0x. > > There's a small chance that 0x is treated as regular data rather > than an error sign. > > Also setting this register may influence the user space under certain > circumstance. > > So I think just ignore the skipped instruction is an acceptable option for > this fix. The 'random' value is just as likely to affect the reader, but only for some values - so you'll get almost impossible to repeat bugs. If a fixed value (0 or ~0) has an adverse effect, at least it will have the same every time. Read errors are also likely to affect device drivers reading status bits, since these are very likely 'write to clear' any driver would have to be willing to process the 'dummy' value in a manner that won't loop forever (especially in an ISR). You don't need every access to be via a function that explicitly (somehow) detects that the fault happened, but knowing that a specific value might be caused by a dead PCIe bus, and being able to find out whether that is true (to avoid looping forever) is probably useful. This is probably similar to what a driver needs to recover from an external PCIe list being unplugged. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Bisected 3.9-rc1 boot failure on G5
Hi, Booting 3.9-rc1 fails with the following dump: Invalid memory access at %SSR0: .0380 %SSR1: 9000.00081000 According to bisect, it's caused by 1fbe9cf2598dae3bd464d860bd89c67b1ff8682b (powerpc: Build kernel with -mcmodel=medium). I'm loading & booting the kernel with GRUB 2.00 on iMac G5 (PowerMac8,1), toolchain is GCC 4.7.2 / binutils 2.23.1. A. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
> bisect tells me that since your commit > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint > registers", > compiling linux fails with : > > cc1: warnings being treated as errors > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used uninitialized > in this function > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > could you look at that ? Sure. How are you compiling this? Is there a ppc defconfig that hits it? Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote: > > bisect tells me that since your commit > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint > > registers", > > compiling linux fails with : > > > > cc1: warnings being treated as errors > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > uninitialized in this function > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > could you look at that ? > > Sure. I use gcc-4.2.2, and my .config follows. Philippe # # Automatically generated file; DO NOT EDIT. # Linux/powerpc 3.9.0-rc1 Kernel Configuration # # CONFIG_PPC64 is not set # # Processor support # CONFIG_PPC_BOOK3S_32=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_PPC_HAVE_PMU_SUPPORT=y # CONFIG_SMP is not set # CONFIG_PPC_DOORBELL is not set CONFIG_PPC32=y CONFIG_32BIT=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set # CONFIG_ARCH_DMA_ADDR_T_64BIT is not set CONFIG_MMU=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set # CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set CONFIG_NR_IRQS=512 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_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_EPAPR_BOOT is not set # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_FHANDLE is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set CONFIG_GENERIC_TIME_VSYSCALL_OLD=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_EXCEPTION_TRACE=y # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_JUMP_LABEL is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=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_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_VIRT_TO_BUS=y CONFIG_HAVE
Re: 3.9-rc1 powerpc ptrace.c: 'brk.len' is used uninitialized
Philippe De Muyter wrote: > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote: > > > bisect tells me that since your commit > > > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7 > > > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint > > > registers", > > > compiling linux fails with : > > > > > > cc1: warnings being treated as errors > > > arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace': > > > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used > > > uninitialized in this function > > > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here > > > > > > could you look at that ? > > > > Sure. > > I use gcc-4.2.2, and my .config follows. I'm a bit lost. I don't have 4.2.2 (which is ancient BTW) and I can't hit this on 4.3,4.5 or 4.6 with your config. It compiles fine. Also: > arch/powerpc/kernel/ptrace.c:1450: warning: 'brk.len' is used uninitialized > in this function > arch/powerpc/kernel/ptrace.c:1352: note: 'brk.len' was declared here These line numbers make no sense at all WRT v3.9-rc1. brk.len is neither declared or used in those lines: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/ptrace.c?id=v3.9-rc1#n1450 or http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/ptrace.c?id=v3.9-rc1#n1352 I happy to fix but I just can't follow this bug report. Mikey > > Philippe > > # > # Automatically generated file; DO NOT EDIT. > # Linux/powerpc 3.9.0-rc1 Kernel Configuration > # > # CONFIG_PPC64 is not set > > # > # Processor support > # > CONFIG_PPC_BOOK3S_32=y > # CONFIG_PPC_85xx is not set > # CONFIG_PPC_8xx is not set > # CONFIG_40x is not set > # CONFIG_44x is not set > # CONFIG_E200 is not set > CONFIG_PPC_BOOK3S=y > CONFIG_6xx=y > CONFIG_PPC_FPU=y > # CONFIG_ALTIVEC is not set > CONFIG_PPC_STD_MMU=y > CONFIG_PPC_STD_MMU_32=y > # CONFIG_PPC_MM_SLICES is not set > CONFIG_PPC_HAVE_PMU_SUPPORT=y > # CONFIG_SMP is not set > # CONFIG_PPC_DOORBELL is not set > CONFIG_PPC32=y > CONFIG_32BIT=y > CONFIG_WORD_SIZE=32 > # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set > # CONFIG_ARCH_DMA_ADDR_T_64BIT is not set > CONFIG_MMU=y > # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set > # CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set > CONFIG_NR_IRQS=512 > 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_GENERIC_HWEIGHT=y > CONFIG_GENERIC_GPIO=y > CONFIG_PPC=y > CONFIG_EARLY_PRINTK=y > CONFIG_GENERIC_NVRAM=y > CONFIG_SCHED_OMIT_FRAME_POINTER=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_PPC_OF=y > CONFIG_PPC_UDBG_16550=y > # CONFIG_GENERIC_TBSYNC is not set > CONFIG_AUDIT_ARCH=y > CONFIG_GENERIC_BUG=y > # CONFIG_EPAPR_BOOT is not set > # CONFIG_DEFAULT_UIMAGE is not set > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > # CONFIG_PPC_DCR_NATIVE is not set > # CONFIG_PPC_DCR_MMIO is not set > CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > CONFIG_ARCH_SUPPORTS_UPROBES=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > CONFIG_IRQ_WORK=y > > # > # General setup > # > CONFIG_EXPERIMENTAL=y > CONFIG_BROKEN_ON_SMP=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_CROSS_COMPILE="" > CONFIG_LOCALVERSION="" > CONFIG_LOCALVERSION_AUTO=y > CONFIG_DEFAULT_HOSTNAME="(none)" > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > CONFIG_SYSVIPC_SYSCTL=y > # CONFIG_POSIX_MQUEUE is not set > # CONFIG_FHANDLE is not set > # CONFIG_AUDIT is not set > CONFIG_HAVE_GENERIC_HARDIRQS=y > > # > # IRQ subsystem > # > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_SHOW=y > CONFIG_GENERIC_IRQ_SHOW_LEVEL=y > CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_SPARSE_IRQ=y > # CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set > CONFIG_GENERIC_TIME_VSYSCALL_OLD=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_GENERIC_CMOS_UPDATE=y > > # > # Timers subsystem > # > # CONFIG_NO_HZ is not set > # CONFIG_HIGH_RES_TIMERS is not set > > # > # CPU/Task time and stats accounting > # > CONFIG_TICK_CPU_ACCOUNTING=y > # CONFIG_BSD_PROCESS_ACCT is not set > # CONFIG_TASKSTATS is not set > > # > # RCU Subsystem > # > CONFIG_TINY_RCU=y > # CONFIG_PREEMPT_RCU is not set > # CONFIG_RCU_STALL_COMMON is not set > # CONFIG_TREE_RCU_TRACE is not set > # CONFIG_IKCONFIG is not set > CONFIG_LOG_BUF_SHIFT=17 > # CONFIG_CGROUPS is not set > # CONFIG_CHECKPOINT_RESTORE is not set > # CONFIG_NAMESPACES is not set > CONFIG_UIDGID_CONVERTED=y > # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set > # CONFIG_SCHED_AUTOGROUP is not set > # CONFIG_SYSFS_DEPRECATED is not set > # CONFIG_RELAY is not set > # CONFIG_BLK_DEV_INITRD is not set > # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > CONFIG_SYSCTL=y > CONFIG_ANON_INODES=y > CONFIG_EXPERT=y > CONFIG_SYSCTL_SYSCALL=y > CONFIG_SYSCTL_EXCEPTION_TRACE=y > # CONFIG_KALLSYMS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG
Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
于 2013年03月05日 17:36, Jiri Slaby 写道: > On 03/05/2013 02:58 AM, Chen Gang wrote: >> > 于 2013年02月28日 21:47, Jiri Slaby 写道: > when strlen(&pi->location_code[0]) == HVCS_CLC_LENGTH + 2 >>> >> It cannot, pi->location_code is defined as char[HVCS_CLC_LENGTH + 1]. >>> >> >> > >> > really, it is, I did not notice it. >> > >> > but I still prefer to modify it, but the patch should be changed >> > such as: >> > subject: beautify code: deleting useless judging code. >> > comments: src buf len and dest buf len are the same, strcpy is better. >> > contents: using strcpy instead of strncpy, and delete judging code. >> > >> > is it ok ? > Yeah. > I will send patch v2. >> > BTW: >> > sorry for my reply is too late, and did not notify it, originally before. >> > I have to do some urgent things, during these days. >> > my father had a serious heart disease, and is in hospital. > No problem, these drivers are not so critical. Neither these code paths > in them. Take care of your relatives first. thanks. -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: make sure that we alays include CONFIG_BINFMT_ELF
Our kernel is not much good without BINFMT_ELF and this fixes a build warning on 64 bit allnoconfig builds: warning: (COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF) Signed-off-by: Stephen Rothwell --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index b89d7eb..a091c01 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -90,6 +90,7 @@ config GENERIC_GPIO config PPC bool default y + select BINFMT_ELF select OF select OF_EARLY_FLATTREE select HAVE_FTRACE_MCOUNT_RECORD -- 1.8.1 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpvgCHNoScW7.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
oh, this patch has integrated into next-20130307 tree. (commit 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b) it seems we need a regression for this commit, then I send patch v2 is it correct ? :-) 于 2013年03月07日 12:10, Chen Gang 写道: > 于 2013年03月05日 17:36, Jiri Slaby 写道: >> On 03/05/2013 02:58 AM, Chen Gang wrote: 于 2013年02月28日 21:47, Jiri Slaby 写道: >> when strlen(&pi->location_code[0]) == HVCS_CLC_LENGTH + 2 >> It cannot, pi->location_code is defined as char[HVCS_CLC_LENGTH + 1]. >> really, it is, I did not notice it. but I still prefer to modify it, but the patch should be changed such as: subject: beautify code: deleting useless judging code. comments: src buf len and dest buf len are the same, strcpy is better. contents: using strcpy instead of strncpy, and delete judging code. is it ok ? >> Yeah. >> > > I will send patch v2. > > BTW: sorry for my reply is too late, and did not notify it, originally before. I have to do some urgent things, during these days. my father had a serious heart disease, and is in hospital. >> No problem, these drivers are not so critical. Neither these code paths >> in them. Take care of your relatives first. > > thanks. > -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] Enable multiple MSI feature in pSeries
Hi all Any comments? or any questions about my patchset? Thanks Mike 在 2013-01-15二的 15:38 +0800，Mike Qiu写道： > Currently, multiple MSI feature hasn't been enabled in pSeries, > These patches try to enbale this feature. > > These patches have been tested by using ipr driver, and the driver patch > has been made by Wen Xiong : > > [PATCH 0/7] Add support for new IBM SAS controllers > > Test platform: One partition of pSeries with one cpu core(4 SMTs) and >RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) in POWER7 > OS version: SUSE Linux Enterprise Server 11 SP2 (ppc64) with 3.8-rc3 kernel > > IRQ 21 and 22 are assigned to the ipr device which support 2 mutiple MSI. > > The test results is shown by 'cat /proc/interrups': > CPU0 CPU1 CPU2 CPU3 > 16: 240458 261601 226310 200425 XICS Level IPI > 17: 0 0 0 0 XICS Level RAS_EPOW > 18: 10 0 3 2 XICS Level > hvc_console > 19: 122182 28481 28527 28864 XICS Level ibmvscsi > 20:5067388226108118 XICS Level eth0 > 21: 6 5 5 5 XICS Level host1-0 > 22:817814816813 XICS Level host1-1 > LOC: 398077 316725 231882 203049 Local timer interrupts > SPU: 1659919961903 Spurious interrupts > CNT: 0 0 0 0 Performance > monitoring interrupts > MCE: 0 0 0 0 Machine check exceptions > > Mike Qiu (3): > irq: Set multiple MSI descriptor data for multiple IRQs > irq: Add hw continuous IRQs map to virtual continuous IRQs support > powerpc/pci: Enable pSeries multiple MSI feature > > arch/powerpc/kernel/msi.c|4 -- > arch/powerpc/platforms/pseries/msi.c | 62 - > include/linux/irq.h |4 ++ > include/linux/irqdomain.h|3 ++ > kernel/irq/chip.c| 40 - > kernel/irq/irqdomain.c | 61 + > 6 files changed, 158 insertions(+), 16 deletions(-) > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
On Thu, 2013-03-07 at 12:34 +0800, Chen Gang wrote: > oh, this patch has integrated into next-20130307 tree. > (commit 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b) > it seems we need a regression for this commit, then I send patch v2 > > is it correct ? Just send a fixup patch on top of the existing upstream. Ben. > :-) > > > 于 2013年03月07日 12:10, Chen Gang 写道: > > 于 2013年03月05日 17:36, Jiri Slaby 写道: > >> On 03/05/2013 02:58 AM, Chen Gang wrote: > 于 2013年02月28日 21:47, Jiri Slaby 写道: > >> when strlen(&pi->location_code[0]) == HVCS_CLC_LENGTH + 2 > >> It cannot, pi->location_code is defined as char[HVCS_CLC_LENGTH + 1]. > >> > > really, it is, I did not notice it. > > but I still prefer to modify it, but the patch should be changed > such as: > subject: beautify code: deleting useless judging code. > comments: src buf len and dest buf len are the same, strcpy is > better. > contents: using strcpy instead of strncpy, and delete judging code. > > is it ok ? > >> Yeah. > >> > > > > I will send patch v2. > > > > > BTW: > sorry for my reply is too late, and did not notify it, originally > before. > I have to do some urgent things, during these days. > my father had a serious heart disease, and is in hospital. > >> No problem, these drivers are not so critical. Neither these code paths > >> in them. Take care of your relatives first. > > > > thanks. > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/tty/hvc: using strlcpy instead of strncpy
于 2013年03月07日 14:05, Benjamin Herrenschmidt 写道: > On Thu, 2013-03-07 at 12:34 +0800, Chen Gang wrote: >> > oh, this patch has integrated into next-20130307 tree. >> > (commit 9276dfd27897a0b29d8b5814f39a1f82f56b6b6b) >> > it seems we need a regression for this commit, then I send patch v2 >> > >> > is it correct ? > Just send a fixup patch on top of the existing upstream. ok, thanks. :-) -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
