Re: xtensa build failures in -next due to DMA API changes
Hi Andrew, Linus has merged the Xtensa patches, so you should be ready to go. Thanks, -Chris On Wed, Aug 26, 2015 at 10:41 AM, Christoph Hellwig wrote: > On Wed, Aug 26, 2015 at 10:53:25AM +0300, Max Filippov wrote: >> Looks like I just need to remove now redundant function definitions from >> xtensa/include/asm/dma-mapping.h. A patch that removes these >> functions is attached, but I'm not sure where it should go. To the Andrew's >> tree? Or should the xtensa tree merge Christoph's series and apply it on >> top? > > This looks fine to me. Thanks for converting xtensa to the generic > DMA code! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xtensa build failures in -next due to DMA API changes
I'll send the pull request as soon as possible. On Wed, Aug 26, 2015 at 12:59 AM, Andrew Morton wrote: > On Wed, 26 Aug 2015 10:53:25 +0300 Max Filippov wrote: > >> On Tue, Aug 25, 2015 at 11:24 PM, Christoph Hellwig wrote: >> > On Tue, Aug 25, 2015 at 01:21:40PM -0700, Guenter Roeck wrote: >> >> I also see >> >> >> >> arch/xtensa/include/asm/dma-mapping.h:#include >> >> >> >> >> >> It looks like there is a conflict with "xtensa: reimplement DMA API using >> >> common >> >> helpers" by Max Filippov, which added the include. This patch is in -next. >> > >> > Oh. That one clashes badly with my whole series, basically each >> > of my patches will need the same work done for the other architectures >> > applied to xtensa as well. >> > >> > In terms of effort it might be a better idea to rebase the patch from >> > Max on top of the series, as it will become a lot simpler that way. >> >> Looks like I just need to remove now redundant function definitions from >> xtensa/include/asm/dma-mapping.h. A patch that removes these >> functions is attached, but I'm not sure where it should go. To the Andrew's >> tree? Or should the xtensa tree merge Christoph's series and apply it on >> top? > > I can add it to Christoph's patch series. This means that I won't be > merging Christoph's patches until you've sent your queue in to Linus, so > please don't leave it too late in the merge window. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] xtensa: improve vmlinux.lds.S sed post-processing
Thanks Max. Running a test build and will add to xtensa-next.
On Fri, Aug 21, 2015 at 10:43 AM, Max Filippov wrote:
> Current sed script makes assumptions about the structure of rules that
> group .text sections in the vmlinux linker script. These assumptions
> get broken occasionally, e.g.: 779c88c94c34 "ARM: 8321/1: asm-generic:
> introduce.text.fixup input section", or 9bebe9e5b0f3 "kbuild: Fix
> .text.unlikely placement".
>
> Rewrite sed rules so that they don't depend on number/arrangement of text
> sections in *(...) blocks.
>
> Signed-off-by: Max Filippov
> ---
> This fixes breakage in the linux-next. Chris, could you please apply it to
> your for_next branch?
>
> Changes v2 -> v3:
> - rebase to the current master
>
> Changes v1 -> v2:
> - don't change arbitrary sections containing .text, only .text, .ref.text
> and .[a-z]*it.text
>
> arch/xtensa/kernel/Makefile | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/xtensa/kernel/Makefile b/arch/xtensa/kernel/Makefile
> index d3a0f0f..ad93217 100644
> --- a/arch/xtensa/kernel/Makefile
> +++ b/arch/xtensa/kernel/Makefile
> @@ -27,10 +27,11 @@ AFLAGS_head.o += -mtext-section-literals
> #
> # Replicate rules in scripts/Makefile.build
>
> -sed-y = -e 's/\*(\(\.[a-z]*it\|\.ref\|\)\.text)/*(\1.literal \1.text)/g' \
> - -e 's/\.text\.unlikely/.literal.unlikely .text.unlikely/g' \
> - -e 's/\*(\(\.text .*\))/*(.literal \1)/g'\
> - -e 's/\*(\(\.text\.[a-z]*\))/*(\1.literal \1)/g'
> +sed-y = -e ':a; s/\*(\([^)]*\)\.text\.unlikely/*(\1.literal.unlikely
> .{text}.unlikely/; ta; ' \
> + -e ':b; s/\*(\([^)]*\)\.text\(\.[a-z]*\)/*(\1.{text}\2.literal
> .{text}\2/; tb; ' \
> + -e ':c; s/\*(\([^)]*\)\(\.[a-z]*it\|\.ref\)\.text/*(\1\2.literal
> \2.{text}/; tc; ' \
> + -e ':d; s/\*(\([^)]\+ \|\)\.text/*(\1.literal .{text}/; td; ' \
> + -e 's/\.{text}/.text/g'
>
> quiet_cmd__cpp_lds_S = LDS $@
> cmd__cpp_lds_S = $(CPP) $(cpp_flags) -P -C -Uxtensa -D__ASSEMBLY__ $<\
> --
> 1.8.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] xtensa: keep exception/interrupt stack continuous
Hi Max, Not such a big fan about these changes as they introduce additional load and stores and a branch. Copy spill area: - is this only for debugging? Could the debugger identify the 'kernel exception' frame and handle it appropriately? - if we need it for debugging/perf, maybe move these line under a kernel option (could be enabled by default) - since we know the kernel stack frame size, why can't we just load from that offset (instead of the l32i and add). Also, can't we use s32e (need to look up the spec again). Branch: - is there any logical change in the code or are these only to avoid using a0? - if for a0, couldn't we load a0 just before the 'xsr a3, ps' and keep the code as before? Thanks, -Chris On Mon, Jul 6, 2015 at 6:32 AM, Max Filippov wrote: > Restore original a0 in the kernel exception stack frame. This way it > looks like the frame that got interrupt/exception did alloca (copy a0 and > a1 potentially spilled under old stack to the new location as well) to > save registers and then did a call to handler. The point where > interrupt/exception was taken is not in the stack chain, only in pt_regs > (call4 from that address can be simulated to keep it in the stack trace). > > Signed-off-by: Max Filippov > --- > arch/xtensa/kernel/entry.S | 60 > +++--- > 1 file changed, 35 insertions(+), 25 deletions(-) > > diff --git a/arch/xtensa/kernel/entry.S b/arch/xtensa/kernel/entry.S > index 82bbfa5..ab6a857 100644 > --- a/arch/xtensa/kernel/entry.S > +++ b/arch/xtensa/kernel/entry.S > @@ -218,7 +218,7 @@ _user_exception: > /* We are back to the original stack pointer (a1) */ > > 2: /* Now, jump to the common exception handler. */ > - > + movia0, 0 # terminate user stack trace with 0 > j common_exception > > ENDPROC(user_exception) > @@ -264,6 +264,19 @@ ENTRY(kernel_exception) > .globl _kernel_exception > _kernel_exception: > > + /* Copy spill slots of a0 and a1 to imitate movsp > +* in order to keep exception stack continuous > +*/ > + l32ia0, a1, PT_AREG1 > + addia2, a1, -16 > + addia0, a0, -16 > + l32ia3, a0, 0 > + l32ia0, a0, 4 > + s32ia3, a2, 0 > + s32ia0, a2, 4 > + > + l32ia0, a1, PT_AREG0# restore saved a0 > + > /* Save SAR and turn off single stepping */ > > movia2, 0 > @@ -338,52 +351,50 @@ common_exception: > xsr a2, lcount > s32ia2, a1, PT_LCOUNT > > - /* It is now save to restore the EXC_TABLE_FIXUP variable. */ > + /* It is now safe to restore the EXC_TABLE_FIXUP variable. */ > > - rsr a0, exccause > movia3, 0 > rsr a2, excsave1 > - s32ia0, a1, PT_EXCCAUSE > s32ia3, a2, EXC_TABLE_FIXUP > > - /* All unrecoverable states are saved on stack, now, and a1 is valid, > -* so we can allow exceptions and interrupts (*) again. > -* Set PS(EXCM = 0, UM = 0, RING = 0, OWB = 0, WOE = 1, INTLEVEL = X) > + /* Save remaining unrecoverable states (exccause, ps) on stack. > +* Now we can allow exceptions again. In case we've got an interrupt > +* PS.INTLEVEL is set to LOCKLEVEL disabling furhter interrupts, > +* otherwise it's left unchanged. > * > -* (*) We only allow interrupts if they were previously enabled and > -* we're not handling an IRQ > +* Set PS(EXCM = 0, UM = 0, RING = 0, OWB = 0, WOE = 1, INTLEVEL = X) > */ > > rsr a3, ps > - addia0, a0, -EXCCAUSE_LEVEL1_INTERRUPT > - movia2, LOCKLEVEL > + movia2, (1 << PS_WOE_BIT) > extui a3, a3, PS_INTLEVEL_SHIFT, PS_INTLEVEL_WIDTH > - # a3 = PS.INTLEVEL > - moveqz a3, a2, a0 # a3 = LOCKLEVEL iff interrupt > - movia2, 1 << PS_WOE_BIT > or a3, a3, a2 > - rsr a0, exccause > - xsr a3, ps > > + rsr a2, exccause > + bneia2, EXCCAUSE_LEVEL1_INTERRUPT, 1f > + movia3, (1 << PS_WOE_BIT) | LOCKLEVEL > +1: > + xsr a3, ps > + s32ia2, a1, PT_EXCCAUSE > s32ia3, a1, PT_PS # save ps > > /* Save lbeg, lend */ > > - rsr a2, lbeg > + rsr a4, lbeg > rsr a3, lend > - s32ia2, a1, PT_LBEG > + s32ia4, a1, PT_LBEG > s32ia3, a1, PT_LEND > > /* Save SCOMPARE1 */ > > #if XCHAL_HAVE_S32C1I > - rsr a2, scompare1 > - s32ia2, a1, PT_SCOMPARE1 > + rsr a3, scompare1 > + s32ia3, a1, PT_SCOMPARE1 > #endif > > /* Save optional registers. */ > > - save_xtregs_opt a1 a2 a4 a5 a6 a7 PT_XTREGS_OPT > + save_xtregs_opt a1 a3 a4 a5 a6 a7 PT_XTREGS_OPT > > #ifdef CONFIG_TRACE_IRQFLAGS > l32ia4, a1, PT_D
Re: [PATCH 7/8] xtensa: implement counting and sampling perf events
Hi Max,
We could probably still use NMI with a separate stack. However, for
exception handling while in NMI, we might have to implement something
similar to x86_64 (https://lwn.net/Articles/484932/).
Cheers!
-Chris
On Mon, Jul 6, 2015 at 7:22 AM, Max Filippov wrote:
> On Mon, Jul 6, 2015 at 5:05 PM, Peter Zijlstra wrote:
>> On Mon, Jul 06, 2015 at 04:56:09PM +0300, Max Filippov wrote:
>>> On Mon, Jul 6, 2015 at 4:47 PM, Peter Zijlstra wrote:
>>> > On Mon, Jul 06, 2015 at 04:32:48PM +0300, Max Filippov wrote:
>>> >> +static int __init xtensa_pmu_init(void)
>>> >> +{
>>> >> + int ret;
>>> >> + int irq = irq_create_mapping(NULL, XCHAL_PROFILING_INTERRUPT);
>>> >
>>> > Does this platform have interrupt priorities which you can partially
>>> > mask in order to create NMI like behaviour?
>>>
>>> Not sure what you mean by "NMI like".
>>
>> There's a number of archs where we implement NMIs by having
>> local_irq_disable() only disable part of the interrupt priority range
>> and making sure all 'normal' IRQs are mapped in that priority range.
>>
>> We then map our NMI handlers to a priority above the 'normal' range,
>> such that these interrupts can indeed happen when interrupts are
>> 'disabled.
>>
>> See for example:
>>
>> b4f4372f96e0 ("sparc64: Make %pil level 15 a pseudo-NMI.")
>> 0c25e9e6cbe7 ("sparc64: Adjust __raw_local_irq_save() to cooperate in NMIs.")
>> c011f80ba091 ("sparc64: Add some more commentary to __raw_local_irq_save()")
>
> Ok, I see. I guess I can change IRQ disabling logic to not mask perf IRQ
> in case it's configured as the only interrupt on its level and it's the
> highest
> medium-level IRQ.
>
>>> Interrupt priorities are fixed in the current xtensa architecture, and
>>> we can in theory mask certain level and below, but practically we
>>> always mask all low- and medium- level interrupts.
>>>
>>> Also we currently can't have handlers for high priority interrupts written
>>> in C.
>>
>> Why not? Surely this can be cured with an assembly stub?
>
> IIUC that was a deliberate architecture design choice and working around
> it penalizes all interrupt handlers. But let me take another close look.
>
>> The advantage of having NMIs is that profiling information for the
>> kernel becomes much more useful. Without this local_irq_enable() will be
>> a very 'hot' function.
>
> I haven't noticed that in my testing.
>
> --
> Thanks.
> -- Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resend 3/5] xtensa: Provide dummy dma_alloc_attrs() and dma_free_attrs()
Hi Guenter,
Sorry for the delay. Will work on it later today or tomorrow.
Thanks,
-Chris
On Mon, May 4, 2015 at 3:30 PM, Guenter Roeck wrote:
> xtensa:allmodconfig fails to build with the following errors.
>
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:
> In function ‘gk20a_instobj_dtor_dma’:
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:154:2: error:
> implicit declaration of function ‘dma_free_attrs’
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:
> In function ‘gk20a_instobj_ctor_dma’:
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:218:2: error:
> implicit declaration of function ‘dma_alloc_attrs’
>
> Xtensa does not provide those functions at this time.
> Provide dummy implementations to avoid build errors.
>
> Acked-by: Max Filippov
> Signed-off-by: Guenter Roeck
> ---
> Please consider pushing this patch into mainline, or provide feedback
> on how to improve it to be acceptable.
>
> arch/xtensa/include/asm/dma-mapping.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/xtensa/include/asm/dma-mapping.h
> b/arch/xtensa/include/asm/dma-mapping.h
> index 172a02a6ad14..ba78ccf651e7 100644
> --- a/arch/xtensa/include/asm/dma-mapping.h
> +++ b/arch/xtensa/include/asm/dma-mapping.h
> @@ -185,4 +185,17 @@ static inline int dma_get_sgtable(struct device *dev,
> struct sg_table *sgt,
> return -EINVAL;
> }
>
> +static inline void *dma_alloc_attrs(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t flag,
> + struct dma_attrs *attrs)
> +{
> + return NULL;
> +}
> +
> +static inline void dma_free_attrs(struct device *dev, size_t size,
> + void *vaddr, dma_addr_t dma_handle,
> + struct dma_attrs *attrs)
> +{
> +}
> +
> #endif /* _XTENSA_DMA_MAPPING_H */
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] xtensa: Fix fix linker script transformation for .text / .text.fixup
On Wed, Apr 8, 2015 at 6:08 AM, Guenter Roeck wrote: > On 04/07/2015 11:14 PM, Max Filippov wrote: >>> Linker script transformation needs to be updated to detect and handle >>> the new section. >> I've posted a patch for it to the linux-xtensa ML a while ago: >> http://lists.linux-xtensa.org/pipermail/linux-xtensa/Week-of-Mon-20150330/001913.html >> This doesn't handle literals for .text.fixup AFAICT. >> > It doesn't, but then it wasn't supposed to. .text.fixup is arm specific. > > Guenter Hi Max, It would seem Guenter's fix addresses the issue. Are there any additional benefits in your patch (better localized code, etc.?) Cheers! -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] xtensa/uapi: Add definition of TIOC[SG]RS485
Hi Ricardo, I'll add it to the xtensa-next tree today.. Thanks, -Chris On 9/9/14, 10:32 AM, Ricardo Ribalda Delgado wrote: Hello Max I really don't know who should do it, the maintainer of tty-next or you :). I guess Greg will want that his is fixed on his tree asap, since that build is broken. Lets give him some time to reply, if nothing happens, then please apply it through your tree. Best regards On Tue, Sep 9, 2014 at 5:24 PM, Max Filippov wrote: On Mon, Sep 8, 2014 at 10:20 PM, Ricardo Ribalda Delgado wrote: Commit: e676253b19b2d269cccf67fdb1592120a0cd0676 [3/21] serial/8250: Add support for RS485 IOCTLs, adds support for RS485 ioctls for 825_core on all the archs. Unfortunaltely the definition of TIOCSRS485 and TIOCGRS485 was missing on the ioctls.h file Reported-by: kbuild test robot Signed-off-by: Ricardo Ribalda Delgado --- arch/xtensa/include/uapi/asm/ioctls.h | 2 ++ 1 file changed, 2 insertions(+) Acked-by: Max Filippov If you want this patch to go through the xtensa tree please let me know, I'll include it to my fixes branch then. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SLUB/USE_SPLIT_PTLOCKS compatibility
On 10/14/2013 04:49 AM, Max Filippov wrote: > Buddy allocator was used here prior to commit 6656920 [XTENSA] Add > support for cache-aliasing I can only guess that the change was made > to make allocated page tables have the same colour, but am not sure > why this is needed. Chris? Max, I think you are right that in an earlier attempt to support cache aliasing, we tried to allocate pages with the correct 'color', and cached pages locally (if I remember correctly). The approach we use now doesn't require that so the suggested patches are fine. (Note that cache aliasing support hasn't been committed to mainline yet) Thanks, -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xtensa: Fix broken allmodconfig build
Hi Guenter, On 9/2/13 7:55 PM, Guenter Roeck wrote: On 08/27/2013 09:06 PM, Guenter Roeck wrote: xtansa allmodbuild fails with: arch/xtensa/kernel/xtensa_ksyms.c:129:1: error: '_mcount' undeclared here (not in a function) make[2]: *** [arch/xtensa/kernel/xtensa_ksyms.o] Error 1 make[1]: *** [arch/xtensa/kernel] Error 2 The breakage is due to commit 478ba61af (xtensa: add static function tracer support) which exports _mcount without declaring it. Cc: Max Filippov Signed-off-by: Guenter Roeck --- Ping ... 3.11 now ships with xtensa allmodconfig broken, which is completely unnecessary. Sorry for the delay. I just added it to the xtensa for_next tree, and will push it upstream shortly. Thanks, -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: xtensa: include: asm: define '_PAGE_CHG_MASK' when 'NOMMU'
Hi Chen, On 06/22/2013 12:46 AM, Chen Gang wrote: > After define it, with the same .config file, also report another errors > below, Did I use the incorrect cross-compiler tools ? It almost seems that you are not using the cross compiler. There are two ways to specify the cross compiler. 1. As part of the config: make ARCH=xtensa menuconfig and set General setup ---> (xtensa-linux-gnu-) Cross-compiler tool prefix 2. Provide with make: make ARCH=xtensa CROSS_COMPILE=xtensa-linux-gnu- Since you are not specifying CROSS_COMPILE, did you configure it in .config? -Chris > > (the attachment is the related .config file) > > Thanks. > > > The related environments: > > [root@dhcp122 ~]# rpm -qf /usr/bin/xtensa-linux-gnu-gcc > gcc-xtensa-linux-gnu-4.7.1-0.1.20120606.fc17.x86_64 > [root@dhcp122 ~]# /usr/bin/xtensa-linux-gnu-gcc -v > Using built-in specs. > COLLECT_GCC=/usr/bin/xtensa-linux-gnu-gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/xtensa-linux-gnu/4.7.1/lto-wrapper > Target: xtensa-linux-gnu > Configured with: ../gcc-4.7.1-RC-20120606/configure > --disable-dependency-tracking --disable-silent-rules --prefix=/usr > --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc > --datadir=/usr/share --includedir=/usr/include --libexecdir=/usr/libexec > --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man > --infodir=/usr/share/info --build=x86_64-redhat-linux-gnu > --host=x86_64-redhat-linux-gnu --target=xtensa-linux-gnu --enable-targets=all > --program-prefix=xtensa-linux-gnu- --enable-languages=c --without-headers > --enable-sjlj-exceptions --with-system-libunwind --disable-nls > --disable-threads --disable-shared --disable-libmudflap --disable-libssp > --disable-libgomp --disable-libquadmath --disable-gold > --disable-decimal-float --enable-checking= --enable-gnu-unique-object > --enable-linker-build-id --disable-plugin --enable-nls --with-system-zlib > --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --enable-obsolete > Thread model: single > gcc version 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606) (GCC) > > When type the command "make ARCH=xtensa allmodconfig", it always reports: > "gcc: error: unrecognized command line option ‘-mlongcalls’" > > The related error: > > AS arch/xtensa/kernel/coprocessor.o > arch/xtensa/kernel/coprocessor.S: Assembler messages: > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (0) for > 'rur0' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (1) for > 'rur1' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (2) for > 'rur2' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (3) for > 'rur3' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (8) for > 'rur8' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (9) for > 'rur9' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (10) for > 'rur10' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (11) for > 'rur11' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (12) for > 'rur12' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (13) for > 'rur13' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (24) for > 'rur24' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (25) for > 'rur25' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (26) for > 'rur26' > arch/xtensa/kernel/coprocessor.S:98: Error: invalid register number (27) for > 'rur27' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error: unknown opcode or format name > 'wras128i' > arch/xtensa/kernel/coprocessor.S:98: Error:
[merged] Re: [PATCH 3/3] xtensa: Switch to asm-generic/linkage.h
Should make it to Linus' tree shortly. Thanks, -Chris On 05/07/2013 02:57 AM, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > --- > arch/xtensa/include/asm/Kbuild|1 + > arch/xtensa/include/asm/linkage.h | 16 > 2 files changed, 1 insertions(+), 16 deletions(-) > delete mode 100644 arch/xtensa/include/asm/linkage.h > > diff --git a/arch/xtensa/include/asm/Kbuild b/arch/xtensa/include/asm/Kbuild > index 095f0a2..1b98264 100644 > --- a/arch/xtensa/include/asm/Kbuild > +++ b/arch/xtensa/include/asm/Kbuild > @@ -15,6 +15,7 @@ generic-y += irq_regs.h > generic-y += kdebug.h > generic-y += kmap_types.h > generic-y += kvm_para.h > +generic-y += linkage.h > generic-y += local.h > generic-y += local64.h > generic-y += percpu.h > diff --git a/arch/xtensa/include/asm/linkage.h > b/arch/xtensa/include/asm/linkage.h > deleted file mode 100644 > index bf2128a..000 > --- a/arch/xtensa/include/asm/linkage.h > +++ /dev/null > @@ -1,16 +0,0 @@ > -/* > - * include/asm-xtensa/linkage.h > - * > - * This file is subject to the terms and conditions of the GNU General Public > - * License. See the file "COPYING" in the main directory of this archive > - * for more details. > - * > - * Copyright (C) 2001 - 2005 Tensilica Inc. > - */ > - > -#ifndef _XTENSA_LINKAGE_H > -#define _XTENSA_LINKAGE_H > - > -/* Nothing to do here ... */ > - > -#endif /* _XTENSA_LINKAGE_H */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/34] idle: Consolidate idle implementations
Hi Thomas, On 3/28/13 2:24 AM, Thomas Gleixner wrote: On Thu, 28 Mar 2013, Chris Zankel wrote: For Xtensa: Acked-by: Chris Zankel Thanks for going the extra mile and test-compiling it. Though, the build fails later with: arch/xtensa/kernel/built-in.o:(.init.literal+0x90): undefined reference to `platform_pcibios_init' arch/xtensa/kernel/built-in.o: In function `setup_arch': (.init.text+0x1de): undefined reference to `platform_pcibios_init' drivers/built-in.o: In function `pci_assign_unassigned_resources': [...] Thanks for the info. With KALLSYMS enabled, the .rodata section between the .text and the .init.text section is extended to a point where it exceeds the call range between those sections. I'm working on a fix (basically, move the .init.text section close to the .init section). Thanks, -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] xtensa changes for 3.9
The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200: Linux 3.8 (2013-02-18 15:58:34 -0800) are available in the git repository at: git://github.com/czankel/xtensa-linux.git tags/xtensa-next-20130225 for you to fetch changes up to 9cf81c759b7db1db593b2ca60b74ec350d5f9205: xtensa: add accept4 syscall (2013-02-25 22:48:51 -0800) Changes for arch/xtensa for the 3.9 merge window. Added features: - add support for thread local storage (TLS) - add accept4 and finit_module syscalls - support medium-priority interrupts - add support for dc232c processor variant - support file-base simulated disk for ISS simulator Bug fixes: - fix return values returned by the str[n]cmp functions - avoid mmap cache aliasing - fix handling of 'windowed registers' in ptrace -------- Chris Zankel (2): xtensa: add support for TLS xtensa: add accept4 syscall Marc Gauthier (1): xtensa: dispatch medium-priority interrupts Max Filippov (10): xtensa: rename prom_update_property to of_update_property xtensa: fix ipc_parse_version selection xtensa: pull signal definitions from signal-defs.h xtensa: add finit_module syscall xtensa: avoid mmap cache aliasing xtensa: fix str[n]cmp return value xtensa: move spill_registers to traps.h xtensa: complete ptrace handling of register windows xtensa: do not enable GENERIC_GPIO by default xtensa: add missing include asm/uaccess.h to checksum.h Pete Delaney (1): xtensa: Add config files for Diamond 233L - Rev C processor variant Stephen Warren (1): xtensa: use new common dtc rule Victor Prupis (1): xtensa: ISS: add host file-based simulated disk dann (1): xtensa: add support for oprofile arch/xtensa/Kconfig| 46 +- arch/xtensa/Makefile |6 +- arch/xtensa/boot/Makefile | 12 - arch/xtensa/boot/dts/Makefile | 15 + arch/xtensa/include/asm/atomic.h |6 +- arch/xtensa/include/asm/checksum.h |1 + arch/xtensa/include/asm/elf.h |3 +- arch/xtensa/include/asm/pgtable.h |4 + arch/xtensa/include/asm/processor.h|4 +- arch/xtensa/include/asm/ptrace.h |3 +- arch/xtensa/include/asm/regs.h |1 + arch/xtensa/include/asm/string.h |4 +- arch/xtensa/include/asm/timex.h|8 +- arch/xtensa/include/asm/traps.h| 24 + arch/xtensa/include/uapi/asm/signal.h | 11 +- arch/xtensa/include/uapi/asm/unistd.h |7 +- arch/xtensa/kernel/asm-offsets.c |1 + arch/xtensa/kernel/entry.S | 69 ++- arch/xtensa/kernel/head.S |9 +- arch/xtensa/kernel/process.c |5 +- arch/xtensa/kernel/ptrace.c| 35 +- arch/xtensa/kernel/setup.c | 42 ++ arch/xtensa/kernel/signal.c|6 +- arch/xtensa/kernel/syscall.c | 41 ++ arch/xtensa/kernel/traps.c | 74 +-- arch/xtensa/kernel/vectors.S | 57 ++- arch/xtensa/kernel/vmlinux.lds.S | 68 ++- arch/xtensa/oprofile/Makefile |9 + arch/xtensa/oprofile/backtrace.c | 171 +++ arch/xtensa/oprofile/init.c| 26 ++ arch/xtensa/platforms/iss/Makefile |1 + arch/xtensa/platforms/iss/simdisk.c| 375 arch/xtensa/platforms/xtfpga/setup.c |4 +- arch/xtensa/variants/dc233c/include/variant/core.h | 475 .../variants/dc233c/include/variant/tie-asm.h | 193 arch/xtensa/variants/dc233c/include/variant/tie.h | 150 +++ 36 files changed, 1851 insertions(+), 115 deletions(-) create mode 100644 arch/xtensa/boot/dts/Makefile create mode 100644 arch/xtensa/oprofile/Makefile create mode 100644 arch/xtensa/oprofile/backtrace.c create mode 100644 arch/xtensa/oprofile/init.c create mode 100644 arch/xtensa/platforms/iss/simdisk.c create mode 100644 arch/xtensa/variants/dc233c/include/variant/core.h create mode 100644 arch/xtensa/variants/dc233c/include/variant/tie-asm.h create mode 100644 arch/xtensa/variants/dc233c/include/variant/tie.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH REPOST] xtensa: use new common dtc rule
Hi Stephen, Thanks for the patch. I have added it to the 'for_next' tree. Max, since you added that feature for Xtensa, any comments before I ask to pull? -Chris On 1/2/13 7:27 PM, Stephen Warren wrote: From: Stephen Warren The current rules have the .dtb files build in a different directory from the .dts files. This patch changes xtensa to use the generic dtb rule which builds .dtb files in the same directory as the source .dts. This requires moving parts of arch/xtensa/boot/Makefile into newly created arch/xtensa/boot/dts/Makefile, and updating arch/xtensa/Makefile to call the new Makefile. Cc: Chris Zankel Cc: Max Filippov Cc: linux-xte...@linux-xtensa.org Signed-off-by: Stephen Warren --- This patch applies recent dtc-rule-related changes to the xtensa arch. They couldn't be applied along with the similar changes for other archs due to dependencies on other xtensa changes. This should apply OK now to Linus's tree, or for 3.9. Note: I have not tested this recently. arch/xtensa/Makefile |4 ++-- arch/xtensa/boot/Makefile | 12 arch/xtensa/boot/dts/Makefile | 15 +++ 3 files changed, 17 insertions(+), 14 deletions(-) create mode 100644 arch/xtensa/boot/dts/Makefile diff --git a/arch/xtensa/Makefile b/arch/xtensa/Makefile index 0aa7270..48c1a5b 100644 --- a/arch/xtensa/Makefile +++ b/arch/xtensa/Makefile @@ -88,7 +88,7 @@ core-y+= $(buildvar) $(buildplf) libs-y+= arch/xtensa/lib/ $(LIBGCC) ifneq ($(CONFIG_BUILTIN_DTB),"") -core-$(CONFIG_OF) += arch/xtensa/boot/ +core-$(CONFIG_OF) += arch/xtensa/boot/dts/ endif boot := arch/xtensa/boot @@ -101,7 +101,7 @@ zImage: vmlinux $(Q)$(MAKE) $(build)=$(boot) $@ %.dtb: - $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ + $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@ define archhelp @echo '* zImage - Compressed kernel image (arch/xtensa/boot/images/zImage.*)' diff --git a/arch/xtensa/boot/Makefile b/arch/xtensa/boot/Makefile index 818647e..64ffc4b 100644 --- a/arch/xtensa/boot/Makefile +++ b/arch/xtensa/boot/Makefile @@ -25,18 +25,6 @@ bootdir-$(CONFIG_XTENSA_PLATFORM_ISS) += boot-elf bootdir-$(CONFIG_XTENSA_PLATFORM_XT2000) += boot-redboot boot-elf boot-uboot bootdir-$(CONFIG_XTENSA_PLATFORM_XTFPGA) += boot-redboot boot-elf boot-uboot - -BUILTIN_DTB := $(patsubst "%",%,$(CONFIG_BUILTIN_DTB)).dtb.o -ifneq ($(CONFIG_BUILTIN_DTB),"") -obj-$(CONFIG_OF) += $(BUILTIN_DTB) -endif - -# Rule to build device tree blobs -$(obj)/%.dtb: $(src)/dts/%.dts FORCE - $(call if_changed_dep,dtc) - -clean-files := *.dtb.S - zImage Image: $(bootdir-y) $(bootdir-y): $(addprefix $(obj)/,$(subdir-y)) \ diff --git a/arch/xtensa/boot/dts/Makefile b/arch/xtensa/boot/dts/Makefile new file mode 100644 index 000..5f711bb --- /dev/null +++ b/arch/xtensa/boot/dts/Makefile @@ -0,0 +1,15 @@ +# +# arch/xtensa/boot/dts/Makefile +# +# This file is subject to the terms and conditions of the GNU General Public +# License. See the file "COPYING" in the main directory of this archive +# for more details. +# +# + +BUILTIN_DTB := $(patsubst "%",%,$(CONFIG_BUILTIN_DTB)).dtb.o +ifneq ($(CONFIG_BUILTIN_DTB),"") +obj-$(CONFIG_OF) += $(BUILTIN_DTB) +endif + +clean-files := *.dtb.S -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [digsig:dmi 20/35] WARNING: security/integrity/built-in.o(.text+0x1d8): Section mismatch in reference from the function integrity_inode_free() to the variable .init.data:ima_use_tcb
Pressed the 'send' button a bit too fast. On 11/07/2012 03:31 PM, Chris Zankel wrote: > Hi, > > Looking a bit into it, I think modpost is broken. I'm working on a fix. This is specific to Xtensa. Symbols are stored in a separate '.lit' section, but modpost doesn't seem to currently resolve it correctly. Cheers! -Chris > > Cheers! > -Chris > > On 11/06/2012 03:57 AM, Fengguang Wu wrote: >> Perhaps we should CC more people.. >> >> On Tue, Nov 06, 2012 at 01:47:18PM +0200, Kasatkin, Dmitry wrote: >>> On Tue, Nov 6, 2012 at 1:41 PM, Fengguang Wu wrote: >>>> On Tue, Nov 06, 2012 at 01:16:16PM +0200, Kasatkin, Dmitry wrote: >>>>> Hi, >>>>> >>>>> I do not see that integrity_inode_free() uses ima_use_tcb. >>>>> >>>>> I think it is false positive. >>>> Interestingly, when trying to reproduce the problem, I got this >>>> slightly different message: >> Now after make clean, I get both the warnings on ima_use_tcb and >> chosen_lsm. >> >>>> WARNING: security/built-in.o(.text+0x2b68c): Section mismatch in reference >>>> from the function integrity_inode_free() to the variable .init.d >>>> ata:chosen_lsm >>>> The function integrity_inode_free() references >>>> the variable __initdata chosen_lsm. >>>> This is often because integrity_inode_free lacks a __initdata >>>> annotation or the annotation of chosen_lsm is wrong. >>>> >>> Hello, >>> >>> chosen_lsm has nothing to do with integrity subsystem, though >>> integrity_inode_free() is called from security_inode_free(), >>> which is part of security subsystem files which uses chosen_lsm... >>> >>> That is very strange. >>> >>> - Dmitry >>> >>> >>>> Thanks, >>>> Fengguang >>>> >>>>> On Wed, Oct 31, 2012 at 5:11 PM, kbuild test robot >>>>> wrote: >>>>>> tree: >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kasatkin/linux-digsig.git >>>>>> dmi >>>>>> head: 2309bb884f94d84ecb1a6a176d3e8199de7d6dad >>>>>> commit: 13ba29dcf6f0021a14a04f6f3a4560a399c02b34 [20/35] integrity: >>>>>> create and inititialize a keyring with builtin public key >>>>>> config: make ARCH=xtensa allyesconfig >>>>>> >>>>>> All warnings: >>>>>> >>>>>> WARNING: security/integrity/built-in.o(.text+0x1d8): Section mismatch in >>>>>> reference from the function integrity_inode_free() to the variable >>>>>> .init.data:ima_use_tcb >>>>>> The function integrity_inode_free() references >>>>>> the variable __initdata ima_use_tcb. >>>>>> This is often because integrity_inode_free lacks a __initdata >>>>>> annotation or the annotation of ima_use_tcb is wrong. >>>>>> >>>>>> --- >>>>>> 0-DAY kernel build testing backend Open Source Technology Center >>>>>> Fengguang Wu, Yuanhan Liu Intel Corporation >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [digsig:dmi 20/35] WARNING: security/integrity/built-in.o(.text+0x1d8): Section mismatch in reference from the function integrity_inode_free() to the variable .init.data:ima_use_tcb
Hi, Looking a bit into it, I think modpost is broken. I'm working on a fix. Cheers! -Chris On 11/06/2012 03:57 AM, Fengguang Wu wrote: > Perhaps we should CC more people.. > > On Tue, Nov 06, 2012 at 01:47:18PM +0200, Kasatkin, Dmitry wrote: >> On Tue, Nov 6, 2012 at 1:41 PM, Fengguang Wu wrote: >>> On Tue, Nov 06, 2012 at 01:16:16PM +0200, Kasatkin, Dmitry wrote: Hi, I do not see that integrity_inode_free() uses ima_use_tcb. I think it is false positive. >>> Interestingly, when trying to reproduce the problem, I got this >>> slightly different message: > Now after make clean, I get both the warnings on ima_use_tcb and > chosen_lsm. > >>> WARNING: security/built-in.o(.text+0x2b68c): Section mismatch in reference >>> from the function integrity_inode_free() to the variable .init.d >>> ata:chosen_lsm >>> The function integrity_inode_free() references >>> the variable __initdata chosen_lsm. >>> This is often because integrity_inode_free lacks a __initdata >>> annotation or the annotation of chosen_lsm is wrong. >>> >> Hello, >> >> chosen_lsm has nothing to do with integrity subsystem, though >> integrity_inode_free() is called from security_inode_free(), >> which is part of security subsystem files which uses chosen_lsm... >> >> That is very strange. >> >> - Dmitry >> >> >>> Thanks, >>> Fengguang >>> On Wed, Oct 31, 2012 at 5:11 PM, kbuild test robot wrote: > tree: > git://git.kernel.org/pub/scm/linux/kernel/git/kasatkin/linux-digsig.git > dmi > head: 2309bb884f94d84ecb1a6a176d3e8199de7d6dad > commit: 13ba29dcf6f0021a14a04f6f3a4560a399c02b34 [20/35] integrity: > create and inititialize a keyring with builtin public key > config: make ARCH=xtensa allyesconfig > > All warnings: > > WARNING: security/integrity/built-in.o(.text+0x1d8): Section mismatch in > reference from the function integrity_inode_free() to the variable > .init.data:ima_use_tcb > The function integrity_inode_free() references > the variable __initdata ima_use_tcb. > This is often because integrity_inode_free lacks a __initdata > annotation or the annotation of ima_use_tcb is wrong. > > --- > 0-DAY kernel build testing backend Open Source Technology Center > Fengguang Wu, Yuanhan Liu Intel Corporation > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PULL REQUEST for 3.7-rc4 - second attempt] xtensa: fix syscall table and vfork, and switch to generic thread/execve
Hi Linus, Sorry for the mishap with my previous attempt. I noted the change to use the git protocol, so it won't happen again (I think I actually used the wrong one also the past two times). Regarding the invalid tag, I hadn't pushed the tag up before creating the message, so git-request-pull seems to have defaulted to the previous tag (or branch name?), and no warning. I'll verify the tag next time. Original message: Would be great if you could pull the Xtensa tree for some important bug fixes. With the change to uapi, there was a bug introduced that results in an empty syscall table (mult-inclusion bug). Switching to the generic thread/execve allowed us to fix a bug we had in vfork(). Thanks, -Chris The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://github.com/czankel/xtensa-linux.git tags/xtensa-next-20121101 for you to fetch changes up to dc241f2c1761bfdec85915f4bbf7e750663f3442: xtensa: switch to generic sys_execve() (2012-10-25 15:00:44 -0700) Xtensa patchset for 3.7-rc4 -------- Chris Zankel (3): xtensa: allow multi-inclusion for uapi/unistd.h xtensa: use physical addresses for bus addresses xtensa: reset windowbase/windowstart when cloning the VM Max Filippov (3): xtensa: switch to generic kernel_thread() xtensa: switch to generic kernel_execve() xtensa: switch to generic sys_execve() arch/xtensa/Kconfig |2 + arch/xtensa/include/asm/io.h |4 ++ arch/xtensa/include/asm/processor.h |4 +- arch/xtensa/include/asm/syscall.h |2 +- arch/xtensa/include/asm/unistd.h | 15 ++-- arch/xtensa/include/uapi/asm/unistd.h | 16 ++--- arch/xtensa/kernel/entry.S| 57 --- arch/xtensa/kernel/process.c | 128 ++--- arch/xtensa/kernel/syscall.c |7 +- arch/xtensa/kernel/xtensa_ksyms.c |1 - 10 files changed, 104 insertions(+), 132 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PULL REQUEST for 3.7-rc4] xtensa: fix syscall table and vfork, and switch to generic thread/execve
Hi Linus, Would be great if you could pull the Xtensa tree for some important bug fixes. With the change to uapi, there was a bug introduced that results in an empty syscall table (mult-inclusion bug). Switching to the generic thread/execve allowed us to fix a bug we had in vfork(). Thanks, -Chris -- The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: https://github.com/czankel/xtensa-linux.git for_next for you to fetch changes up to dc241f2c1761bfdec85915f4bbf7e750663f3442: xtensa: switch to generic sys_execve() (2012-10-25 15:00:44 -0700) Xtensa patchset for 3.7-rc4 Chris Zankel (3): xtensa: allow multi-inclusion for uapi/unistd.h xtensa: use physical addresses for bus addresses xtensa: reset windowbase/windowstart when cloning the VM Max Filippov (3): xtensa: switch to generic kernel_thread() xtensa: switch to generic kernel_execve() xtensa: switch to generic sys_execve() arch/xtensa/Kconfig |2 + arch/xtensa/include/asm/io.h |4 ++ arch/xtensa/include/asm/processor.h |4 +- arch/xtensa/include/asm/syscall.h |2 +- arch/xtensa/include/asm/unistd.h | 15 ++-- arch/xtensa/include/uapi/asm/unistd.h | 16 ++--- arch/xtensa/kernel/entry.S| 57 --- arch/xtensa/kernel/process.c | 128 ++--- arch/xtensa/kernel/syscall.c |7 +- arch/xtensa/kernel/xtensa_ksyms.c |1 - 10 files changed, 104 insertions(+), 132 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 60/85] xtensa: add missing system calls to the syscall table
Hi Ben, On 10/27/2012 11:26 AM, Ben Hutchings wrote: > On Thu, 2012-10-25 at 17:06 -0700, Greg Kroah-Hartman wrote: > [...] >> #define __NR_available287 287 >> -__SYSCALL(287, sys_faccessat, 0) >> +__SYSCALL(287, sys_ni_syscall, 0) > [...] > > Why was this one un-plumbed rather than properly numbered (#define > __NR_faccessat)? I can only speculate, that this was probably a copy/paste error that has been there for a long time. __NR_faccessat is (and was) defined as number 301. Given that 287 was never defined, it's save to fix the table entry and set it to sys_ni_syscall. unistd.h: [...] #define __NR_faccessat 301 __SYSCALL(301, sys_faccessat, 4) [...] Thanks, -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH stable] xtensa: add missing system calls to the syscall table
Hi Greg, Could you please include this patch in the next stable tree? It adds system calls required for libc builds, so would be great to have it there. Thanks, -Chris From 72b843f6fa14a818a833625d78d8023828366bb1 Mon Sep 17 00:00:00 2001 From: Chris Zankel Date: Wed, 24 Oct 2012 12:59:28 -0700 Subject: [PATCH 1/1] xtensa: add missing system calls to the syscall table Add the following system calls to the syscall table: fallocate sendmmsg umount2 syncfs epoll_create1 inotify_init1 signalfd4 dup3 pipe2 timerfd_create timerfd_settime timerfd_gettime eventfd2 preadv pwritev fanotify_init fanotify_mark process_vm_readv process_vm_writev name_to_handle_at open_by_handle_at sync_file_range perf_event_open rt_tgsigqueueinfo clock_adjtime prlimit64 kcmp Note that we have to use the 'sys_sync_file_range2' version, so that the 64-bit arguments are aligned correctly to the argument registers Signed-off-by: Chris Zankel --- arch/xtensa/include/asm/unistd.h | 91 ++ 1 file changed, 72 insertions(+), 19 deletions(-) diff --git a/arch/xtensa/include/asm/unistd.h b/arch/xtensa/include/asm/unistd.h index bc7e005..6b3ff98 100644 --- a/arch/xtensa/include/asm/unistd.h +++ b/arch/xtensa/include/asm/unistd.h @@ -148,8 +148,8 @@ __SYSCALL( 59, sys_getdents, 3) __SYSCALL( 60, sys_getdents64, 3) #define __NR_fcntl64 61 __SYSCALL( 61, sys_fcntl64, 3) -#define __NR_available62 62 -__SYSCALL( 62, sys_ni_syscall, 0) +#define __NR_fallocate 62 +__SYSCALL(62, sys_fallocate, 6) #define __NR_fadvise64_64 63 __SYSCALL( 63, xtensa_fadvise64_64, 6) #define __NR_utime 64/* glibc 2.3.3 ?? */ @@ -264,8 +264,8 @@ __SYSCALL(112, sys_socketpair, 4) __SYSCALL(113, sys_sendfile, 4) #define __NR_sendfile64 114 __SYSCALL(114, sys_sendfile64, 4) -#define __NR_available115115 -__SYSCALL(115, sys_ni_syscall, 0) +#define __NR_sendmmsg115 +__SYSCALL(115, sys_sendmmsg, 4) /* Process Operations */ @@ -380,11 +380,11 @@ __SYSCALL(168, sys_msgrcv, 4) __SYSCALL(169, sys_msgctl, 4) #define __NR_available170170 __SYSCALL(170, sys_ni_syscall, 0) -#define __NR_available171171 -__SYSCALL(171, sys_ni_syscall, 0) /* File System */ +#define __NR_umount2171 +__SYSCALL(171, sys_umount, 2) #define __NR_mount 172 __SYSCALL(172, sys_mount, 5) #define __NR_swapon 173 @@ -399,8 +399,8 @@ __SYSCALL(176, sys_umount, 2) __SYSCALL(177, sys_swapoff, 1) #define __NR_sync 178 __SYSCALL(178, sys_sync, 0) -#define __NR_available179179 -__SYSCALL(179, sys_ni_syscall, 0) +#define __NR_syncfs179 +__SYSCALL(179, sys_syncfs, 1) #define __NR_setfsuid 180 __SYSCALL(180, sys_setfsuid, 1) #define __NR_setfsgid 181 @@ -455,7 +455,7 @@ __SYSCALL(203, sys_reboot, 3) #define __NR_quotactl 204 __SYSCALL(204, sys_quotactl, 4) #define __NR_nfsservctl 205 -__SYSCALL(205, sys_ni_syscall, 0) +__SYSCALL(205, sys_ni_syscall, 0)/* old nfsservctl */ #define __NR__sysctl 206 __SYSCALL(206, sys_sysctl, 1) #define __NR_bdflush 207 @@ -562,7 +562,7 @@ __SYSCALL(252, sys_timer_getoverrun, 1) /* System */ -#define __NR_reserved244 253 +#define __NR_reserved253253 __SYSCALL(253, sys_ni_syscall, 0) #define __NR_lookup_dcookie 254 __SYSCALL(254, sys_lookup_dcookie, 4) @@ -609,8 +609,8 @@ __SYSCALL(272, sys_pselect6, 0) __SYSCALL(273, sys_ppoll, 0) #define __NR_epoll_pwait274 __SYSCALL(274, sys_epoll_pwait, 0) -#define __NR_available275275 -__SYSCALL(275, sys_ni_syscall, 0) +#define __NR_epoll_create1275 +__SYSCALL(275, sys_epoll_create1, 1) #define __NR_inotify_init276 __SYSCALL(276, sys_inotify_init, 0) @@ -618,8 +618,8 @@ __SYSCALL(276, sys_inotify_init, 0) __SYSCALL(277, sys_inotify_add_watch, 3) #define __NR_inotify_rm_watch278 __SYSCALL(278, sys_inotify_rm_watch, 2) -#define __NR_available279279 -__SYSCALL(279, sys_ni_syscall, 0) +#define __NR_inotify_init1279 +__SYSCALL(279, sys_inotify_init1, 1) #define __NR_getcpu280 __SYSCALL(280, sys_getcpu, 0) @@ -635,10 +635,10 @@ __SYSCALL(283, sys_ioprio_get, 3) __SYSCALL(284, sys_set_robust_list, 3) #define __NR_get_robust_list285 __SYSCALL(285, sys_get_robust_list, 3) -#define __NR_reserved286286/* sync_file_rangeX */ -__SYSCALL(286, sys_ni_syscall, 3) +#define __NR_available286286 +__SYSCALL(286, sys_ni_syscall, 0) #define __NR_available287287 -__SYSCALL(287, sys_faccessat, 0) +__SYSCALL(287, sys_ni_syscall, 0) /* Relative File Operations */ @@ -683,10 +683,63 @@ __SYSCALL(305, sys_ni_syscall, 0) __SYSCALL(306, sys_eventfd, 1
Re: linux-next: manual merge of the xtensa tree with Linus' tree
Hi Stephen,
Sorry, I accidentally pushed this patch up; should be fixed the next
next time you pull.
Thanks,
-Chris
On 10/21/2012 04:40 PM, Stephen Rothwell wrote:
Hi Chris,
Today's linux-next merge of the xtensa tree got a conflict in
arch/xtensa/include/uapi/asm/unistd.h between commit 7216cabfff51
("xtensa: add missing system calls to the syscall table") from Linus'
tree and commit daff2ab722aa ("xtensa: add missing system calls to the
syscall table") from the xtensa tree.
These clearly were meant to be the same patch but the on in Linus' tree
has a later date, so I used it and can carry the fix as necessary (no
action is required).
Also, the top most commit in the xtensa tree has no signed-off-by line or
any real commit message. Please fix that up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] xtensa patches
Hi Linus,
Could you please pull the changes from the Xtensa repository. They are
all limited to the xtensa subtree and include some important changes
(adding long missing system calls for newer libc versions and other
fixes) and the UAPI changes.
Thanks,
-Chris
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
https://github.com/czankel/xtensa-linux.git tags/xtensa-next-20121018
for you to fetch changes up to 7216cabfff5149670445cd65d415ed5db21314b4:
xtensa: add missing system calls to the syscall table (2012-10-19
10:46:44 -0700)
Xtensa patchset for 3.7-rc2
Chris Zankel (3):
xtensa: fix memmove(), bcopy(), and memcpy().
xtensa: minor compiler warning fix
xtensa: add missing system calls to the syscall table
David Howells (1):
UAPI: (Scripted) Disintegrate arch/xtensa/include/asm
Marc Gauthier (2):
xtensa: copy_thread with CLONE_VM must not copy live parent AR
windows
xtensa: fix missing return in do_page_fault for SIGBUS case
Max Filippov (6):
xtensa: ISS: fix specific simcalls
xtensa: ISS: fix rs_put_char
xtensa: fix boot parameters parsing
xtensa: reorganize SR referencing
xtensa: fix unaligned usermode access
xtensa: Use Kbuild infrastructure to handle asm-generic headers
arch/xtensa/boot/boot-redboot/bootstrap.S |8 +-
arch/xtensa/include/asm/Kbuild | 28 +-
arch/xtensa/include/asm/atomic.h | 12 +-
arch/xtensa/include/asm/bitsperlong.h |1 -
arch/xtensa/include/asm/bug.h | 18 -
arch/xtensa/include/asm/cacheflush.h |2 +-
arch/xtensa/include/asm/cmpxchg.h |4 +-
arch/xtensa/include/asm/coprocessor.h |5 +-
arch/xtensa/include/asm/cputime.h |6 -
arch/xtensa/include/asm/delay.h|2 +-
arch/xtensa/include/asm/device.h |7 -
arch/xtensa/include/asm/div64.h| 16 -
arch/xtensa/include/asm/emergency-restart.h|6 -
arch/xtensa/include/asm/errno.h| 16 -
arch/xtensa/include/asm/fcntl.h|1 -
arch/xtensa/include/asm/futex.h|1 -
arch/xtensa/include/asm/hardirq.h | 16 -
arch/xtensa/include/asm/ioctl.h|1 -
arch/xtensa/include/asm/irq_regs.h |1 -
arch/xtensa/include/asm/irqflags.h |4 +-
arch/xtensa/include/asm/kdebug.h |1 -
arch/xtensa/include/asm/kmap_types.h |6 -
arch/xtensa/include/asm/kvm_para.h |1 -
arch/xtensa/include/asm/local.h| 16 -
arch/xtensa/include/asm/local64.h |1 -
arch/xtensa/include/asm/mmu_context.h |4 +-
arch/xtensa/include/asm/param.h| 20 +-
arch/xtensa/include/asm/percpu.h | 16 -
arch/xtensa/include/asm/ptrace.h | 66 +-
arch/xtensa/include/asm/regs.h | 55 +-
arch/xtensa/include/asm/resource.h | 16 -
arch/xtensa/include/asm/scatterlist.h | 16 -
arch/xtensa/include/asm/sections.h | 16 -
arch/xtensa/include/asm/siginfo.h | 16 -
arch/xtensa/include/asm/signal.h | 134 +---
arch/xtensa/include/asm/statfs.h | 17 -
arch/xtensa/include/asm/termios.h | 105 ---
arch/xtensa/include/asm/timex.h|8 +-
arch/xtensa/include/asm/tlbflush.h |8 +-
arch/xtensa/include/asm/topology.h | 16 -
arch/xtensa/include/asm/types.h| 15 +-
arch/xtensa/include/asm/unistd.h | 702
+-
arch/xtensa/include/asm/xor.h | 16 -
arch/xtensa/include/uapi/asm/Kbuild| 22 +
arch/xtensa/include/{ => uapi}/asm/auxvec.h|0
arch/xtensa/include/{ => uapi}/asm/byteorder.h |0
arch/xtensa/include/{ => uapi}/asm/ioctls.h|0
arch/xtensa/include/{ => uapi}/asm/ipcbuf.h|0
arch/xtensa/include/{ => uapi}/asm/mman.h |0
arch/xtensa/include/{ => uapi}/asm/msgbuf.h|0
arch/xtensa/include/uapi/asm/param.h | 30 +
arch/xtensa/include/{ => uapi}/asm/poll.h |0
arch/xtensa/include/{ => uapi}/asm/posix_types.h |0
arch/xtensa/include/uapi/asm/ptrace.h | 77 ++
arch/xtensa/include/{ => uapi}/asm/sembuf.h|0
arch/xtensa/include/{ => uapi}/asm/setup.h
Re: [ 103/133] xtensa: Add missing RCU idle APIs on idle loop
Hi Greg,
Thanks for adding it.
Signed-off-by: Chris Zankel
On 10/10/2012 03:52 PM, Greg Kroah-Hartman wrote:
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Frederic Weisbecker
commit 11ad47a0edbd62bfc0547cfcdf227a911433f207 upstream.
In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the xtensa's idle loop.
Reported-by: Paul E. McKenney
Signed-off-by: Frederic Weisbecker
Cc: Chris Zankel
Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
Signed-off-by: Greg Kroah-Hartman
---
arch/xtensa/kernel/process.c |3 +++
1 file changed, 3 insertions(+)
--- a/arch/xtensa/kernel/process.c
+++ b/arch/xtensa/kernel/process.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -110,8 +111,10 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
while (!need_resched())
platform_idle();
+ rcu_idle_exit();
schedule_preempt_disabled();
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] xtensa patchset for 3.7
Hi Linus,
Trying again with the correct url and a signed key; hoping we can light
the cigars now...
Please pull the changes for the Xtensa architecture for v3.7. The Xtensa
tree has been broken for some time now, and this patchset brings it back
to life. It has been part of the linux-next tree for some time.
Most changes are inside the xtensa subdirectory; the other changes
mostly add another rule to already existing #ifdefs to exclude Xtensa,
where required. The only 'common' change is to add two more sections
('.xt.prop' and '.xt.lit') to the white list in modpost.
Thanks,
-Chris
-->
The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linux 3.6 (2012-09-30 16:47:46 -0700)
are available in the git repository at:
https://github.com/czankel/xtensa-linux.git tags/xtensa-next-20121008
for you to fetch changes up to 70cefe765433529fc894fd1995a1d5883cb33e05:
xtensa: Setup CROSS_COMPILE at the top (2012-10-04 12:16:20 -0700)
Xtensa patchset for 3.7
----
Chris Zankel (1):
MAINTAINERS: add Max Filippov as an xtensa port maintainer
Geert Uytterhoeven (1):
xtensa: Setup CROSS_COMPILE at the top
Max Filippov (25):
xtensa: fix linker script transformation for .text.unlikely
xtensa: ISS: only build networking if configured
xtensa/PCI: fix WT caching attribute
xtensa: fix xtensa_irq_unmask calls
xtensa: ISS: fix __simc implementation
modpost: fix modpost warnings for xtensa
xtensa: fix ioremap
xtensa: adopt generic io routines
xtensa: set NO_IOPORT to 'n' by default
xtensa: add ARCH_WANT_OPTIONAL_GPIOLIB to xtensa config
xtensa: change default platform clock frequency to 10MHz
xtensa: ISS: add dummy serial.h for ISS platform
xtensa: ISS: add platform_pcibios_init
xtensa: ISS: change keyboard polling rate
xtensa: ISS: exit simulator in case of halt or poweroff
xtensa: ISS: drop unused io.c
xtensa: fix parallel make
xtensa: fix CODA build
hisax: disable build for big-endian xtensa
xtensa: rename MISC SR definition to avoid name clashes
parport: disable for xtensa arch
xtensa: add missing symbol exports
xtensa: provide dummy gcc intrinsics
xtensa: fix TIOCGSERIAL and TIOCSSERIAL definitions
xtensa: drop CONFIG_EMBEDDED_RAMDISK
MAINTAINERS|2 +
arch/xtensa/Kconfig| 23 +--
arch/xtensa/Makefile | 34 ++--
arch/xtensa/boot/Makefile |2 +-
arch/xtensa/boot/boot-elf/Makefile | 24 +--
arch/xtensa/boot/boot-elf/boot.lds.S |7 -
arch/xtensa/boot/boot-redboot/Makefile | 12 +-
arch/xtensa/boot/boot-redboot/boot.ld |7 -
arch/xtensa/boot/boot-redboot/bootstrap.S | 10 --
arch/xtensa/boot/ramdisk/Makefile | 23 ---
arch/xtensa/configs/s6105_defconfig|5 -
arch/xtensa/include/asm/io.h | 172
+++-
arch/xtensa/include/asm/ioctls.h |4 +-
arch/xtensa/include/asm/regs.h |2 +-
arch/xtensa/kernel/Makefile|3 +-
arch/xtensa/kernel/io.c| 75 -
arch/xtensa/kernel/irq.c |4 +-
arch/xtensa/kernel/pci-dma.c |4 +
arch/xtensa/kernel/pci.c |2 +-
arch/xtensa/kernel/platform.c |4 +-
arch/xtensa/kernel/setup.c | 12 --
arch/xtensa/kernel/vmlinux.lds.S |5 -
arch/xtensa/kernel/xtensa_ksyms.c | 25 +++
arch/xtensa/platforms/iss/Makefile |4 +-
arch/xtensa/platforms/iss/console.c| 15 +-
.../platforms/iss/include/platform/simcall.h | 53 ++
arch/xtensa/platforms/iss/io.c | 32
arch/xtensa/platforms/iss/network.c| 49 --
arch/xtensa/platforms/iss/setup.c | 14 +-
drivers/isdn/hisax/Kconfig | 10 +-
drivers/parport/Kconfig|2 +-
drivers/usb/musb/musb_io.h |3 +-
scripts/mod/modpost.c |2 +
33 files changed, 169 insertions(+), 476 deletions(-)
delete mode 100644 arch/xtensa/boot/ramdisk/Makefile
delete mode 100644 arch/xtensa/kernel/io.c
create mode 100644 arch/xtensa/platforms/iss/include/platform/serial.h
delete mode 100644 arch/xtensa/platforms/iss/io.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
Re: [GIT PULL] xtensa patchset for 3.7
Hi Geert,
Sorry, misunderstood it. Won't happen again.
I have added it to https://github.com/czankel/xtensa-linux.git
xtensa-next, so it should be pulled to mainline soon (once I'm done with
my homework of getting my key signed ;-)
Thanks,
-Chris
On 10/04/2012 11:45 AM, Geert Uytterhoeven wrote:
Hi Chris,
On Thu, Oct 4, 2012 at 12:23 AM, Chris Zankel wrote:
Patchset for the Xtensa architecture for 3.7
I think you forgot https://lkml.org/lkml/2012/9/10/560
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] xtensa patchset for 3.7
Hi Linus, On 10/03/2012 03:41 PM, Linus Torvalds wrote: That should be git://github.com/czankel/xtensa-linux tags/xtensa-next-20121003 which is the public git address of that server. Sorry about that. I mistakenly used 'origin' instead of the actual address. However, you now do have a signed tag, but the key you have used for it is not available on any of the regular keyservers. Neither pgp.mit.edu nor keys.gnupg.net know about that key A1F191F0, which I assume also means that it's not actually signed by anybody else either. I see that you're based in St Petersburg, is there anybody around you can get your key signed with? I'm actually located in the Bay Area (Max, who's helping out, is in St. Petersburg), and could stop by anywhere around here. I'll also try ask some old friends if they are still in the position to certify the signature. Thanks, -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] xtensa patchset for 3.7
Hi Linus, Please pull the changes for the Xtensa architecture for v3.7. Thanks, -Chris The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: g...@github.com:czankel/xtensa-linux tags/xtensa-next-20121003 for you to fetch changes up to 9ad79b58510b2845e5ffa77654596d7184a827ab: xtensa: drop CONFIG_EMBEDDED_RAMDISK (2012-10-03 15:13:09 -0700) Patchset for the Xtensa architecture for 3.7 Chris Zankel (1): MAINTAINERS: add Max Filippov as an xtensa port maintainer Max Filippov (25): xtensa: fix linker script transformation for .text.unlikely xtensa: ISS: only build networking if configured xtensa/PCI: fix WT caching attribute xtensa: fix xtensa_irq_unmask calls xtensa: ISS: fix __simc implementation modpost: fix modpost warnings for xtensa xtensa: fix ioremap xtensa: adopt generic io routines xtensa: set NO_IOPORT to 'n' by default xtensa: add ARCH_WANT_OPTIONAL_GPIOLIB to xtensa config xtensa: change default platform clock frequency to 10MHz xtensa: ISS: add dummy serial.h for ISS platform xtensa: ISS: add platform_pcibios_init xtensa: ISS: change keyboard polling rate xtensa: ISS: exit simulator in case of halt or poweroff xtensa: ISS: drop unused io.c xtensa: fix parallel make xtensa: fix CODA build hisax: disable build for big-endian xtensa xtensa: rename MISC SR definition to avoid name clashes parport: disable for xtensa arch xtensa: add missing symbol exports xtensa: provide dummy gcc intrinsics xtensa: fix TIOCGSERIAL and TIOCSSERIAL definitions xtensa: drop CONFIG_EMBEDDED_RAMDISK MAINTAINERS|2 + arch/xtensa/Kconfig| 23 +-- arch/xtensa/Makefile | 10 +- arch/xtensa/boot/Makefile |2 +- arch/xtensa/boot/boot-elf/Makefile | 24 +-- arch/xtensa/boot/boot-elf/boot.lds.S |7 - arch/xtensa/boot/boot-redboot/Makefile | 12 +- arch/xtensa/boot/boot-redboot/boot.ld |7 - arch/xtensa/boot/boot-redboot/bootstrap.S | 10 -- arch/xtensa/boot/ramdisk/Makefile | 23 --- arch/xtensa/configs/s6105_defconfig|5 - arch/xtensa/include/asm/io.h | 172 +++- arch/xtensa/include/asm/ioctls.h |4 +- arch/xtensa/include/asm/regs.h |2 +- arch/xtensa/kernel/Makefile|3 +- arch/xtensa/kernel/io.c| 75 - arch/xtensa/kernel/irq.c |4 +- arch/xtensa/kernel/pci-dma.c |4 + arch/xtensa/kernel/pci.c |2 +- arch/xtensa/kernel/platform.c |4 +- arch/xtensa/kernel/setup.c | 12 -- arch/xtensa/kernel/vmlinux.lds.S |5 - arch/xtensa/kernel/xtensa_ksyms.c | 25 +++ arch/xtensa/platforms/iss/Makefile |4 +- arch/xtensa/platforms/iss/console.c| 15 +- .../platforms/iss/include/platform/simcall.h | 53 ++ arch/xtensa/platforms/iss/io.c | 32 arch/xtensa/platforms/iss/network.c| 49 -- arch/xtensa/platforms/iss/setup.c | 14 +- drivers/isdn/hisax/Kconfig | 10 +- drivers/parport/Kconfig|2 +- drivers/usb/musb/musb_io.h |3 +- scripts/mod/modpost.c |2 + 33 files changed, 157 insertions(+), 464 deletions(-) delete mode 100644 arch/xtensa/boot/ramdisk/Makefile delete mode 100644 arch/xtensa/kernel/io.c create mode 100644 arch/xtensa/platforms/iss/include/platform/serial.h delete mode 100644 arch/xtensa/platforms/iss/io.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xtensa port maintenance
Hi Arnd, Given the recent renewed push for Xtensa, I'll step in to feed the changes upstream. We might change that in future, though. Max has volunteered to help bring the Xtensa port up-to-date. Most of the recent development was done on outdated trees and never got submitted in true kernel-manner (i.e. small changes at a time). It's also important to bring the ecosystem (compilers, libraries, etc.) to the latest trees, and my understanding is that there's also work going on in that area. I have set up a tree on github for now, and will work close with Max to get his changes to Stephen's linux-next tree and eventually Linus' tree. I think it's fine to add Max as a second maintainer, so he can help filtering patches. Cheers! -Chris On 8/10/12 2:15 PM, Arnd Bergmann wrote: On Monday 06 August 2012, Max Filippov wrote: I have a couple of questions regarding the path of xtensa-specific patches upstream: - which git tree should they be targeted for? Should I set up a tree for pull requests, or will patches be picked up into some existing tree? (Looks like Linus' tree is the right target. AFAIK previously xtensa patches went mostly through akpm tree). Setting up a git tree is a good first step if you want to be the official maintainer, and if you want to get it included into linux-next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xtensa port maintenance
Hi Max, On 08/07/2012 09:43 AM, Max Filippov wrote: On Tue, Aug 7, 2012 at 9:40 AM, Chris Zankel wrote: Hi Max, On 08/06/2012 04:38 PM, Max Filippov wrote: AFAIK xtensa linux port is currently in bad shape: it doesn't work in the mainline, it fails to build in the linux-next. The latest working kernels for xtensa are 2.6.29...31 trees hosted at the git.linux-xtensa.org. I wouldn't say it's in bad shape, I just built an vmlinux image from the latest tree (3.6.0-rc1), but it might not be very stable. One of the major issues is not really the kernel but there's actually no way to build a fairly recent version of the toolchain. I have been using a somewhat more recent buildroot version than what is on xtensa-linux.org, but even that version of buildroot is rather old now and needed a few patches. I've been using userspace built from the buildroot image hosted on linux-xtensa.org with gcc-4.4.5 + binutils-2.20.1. I use gcc-4.6.3 (without libc) + binutils-2.22 to build the kernel. I had an impression that mentioned buildroot was able to produce userspace where LTP could run successfully for days. So, my initial plan is to use that userspace with mainline kernel. Good plan! I have a subset thereof that builds toolchain (without libc) and the kernel. Buildroot gave me an impression of not very reproducible environment, perhaps I spent too little time on it. So I made an image and I hope that pre-built image may be used, at least in the beginning. I had to lightly patch U-boot hosted on linux-xtensa.org to make it work on LX60/110/200 QEMU models. I guess we can start with pre-built image of the bootloader too. I'm not settled on Buildroot, but I had the best experience with it so far. OpenEmbedded was a real pain when I used it (it might have improved a lot since, though). I once even started my own build system, but it became fairly complicated once I wanted to build a bootable system with a C library and various packages. Ok. I'd like to have even generic patches (my current queue is mostly generic) reviewed. Do you prefer to read them on github or on the linux-xtensa mailing list? I looked over them briefly, and only had one or two questions. I'll send them tomorrow (our time). Thanks, -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-Xtensa] Re: xtensa port maintenance
Hi Vadim, On 08/06/2012 11:00 PM, Vadim Malenboim wrote: Hi All, I've beed dealing with the xtensa port for couple of months and I'd like to contribute / help as much as possible. I have an ML605 Xilinx Evaluation Board and already succeeded running the clean-stable version from xtensa-linux on it. I propose doing the testing on this board and any other tasks / issues you think I can help, I'd be glad to. Excellent!! I'm looking forward to your help. -Chris Vadim. On Tue, Aug 7, 2012 at 8:40 AM, Chris Zankel <mailto:ch...@zankel.net>> wrote: Hi Max, On 08/06/2012 04:38 PM, Max Filippov wrote: AFAIK xtensa linux port is currently in bad shape: it doesn't work in the mainline, it fails to build in the linux-next. The latest working kernels for xtensa are 2.6.29...31 trees hosted at the git.linux-xtensa.org <http://git.linux-xtensa.org>. I wouldn't say it's in bad shape, I just built an vmlinux image from the latest tree (3.6.0-rc1), but it might not be very stable. One of the major issues is not really the kernel but there's actually no way to build a fairly recent version of the toolchain. I have been using a somewhat more recent buildroot version than what is on xtensa-linux.org <http://xtensa-linux.org>, but even that version of buildroot is rather old now and needed a few patches. The tree on linux-xtensa.org <http://linux-xtensa.org> has quite diverted from mainline now. Pete has done a great job maintaining those kernel versions, fixing a lot of bugs, and adding a ton of new additional features, but it will take quite some effort to merge them with the latest kernel. I have a goal to make xtensa arch in the linux mainline usable. Awesome!! Every help is very much appreciated. Currently I have a number of patches on top of Linus' tree that allow to build working allnoconfig, defconfig and allmodconfig kernels for ISS machine with dc232b and fsf core variants [1]. For the next several weeks I'm planning to You might expect that I'm more than curious to see those changes :-) forward-port patches accumulated in linux-xtensa.org <http://linux-xtensa.org> git trees and make the resulting kernels rock-solid. I'd like to restore xtensa participation in the linux-next. Further (currently undetailed) plans are to bring modern Linux features to the xtensa port, e.g. device trees. That would be great. Might I also add that we'd need to have a working toolchain and bootable image. For me, buildroot seems to be the quickest route here. That would also require possibly adding patches to the toolchain and uClibc that are currently missing. There's also the bootloader, etc. I have a couple of questions regarding the path of xtensa-specific patches upstream: - which git tree should they be targeted for? Should I set up a tree for pull requests, or will patches be picked up into some existing tree? (Looks like Linus' tree is the right target. AFAIK previously xtensa patches went mostly through akpm tree). Yes, Andrew has been very helpful stepping in and adding those patches. Most if not all of those patches were fixes because of generic kernel changes and not major fixes or changes to the core of the Xtensa port. Ideally, it would be great if you could create a git tree (I saw you already have a version on github already?) that would allow us to look over those patches. The goal should be to have a system to build toolchain, bootable image, and kernel, so we can run some regression tests on either the simulator (qemu) or an actual board. Once we have a regression test system in place, we can then add more features and funnel those patches either through me or more directly.. What do you think? If you already have such a system in place, it would be great if you could send me some instructions to recreate it locally. We can give you also access to the wiki to add any information there. - which mailing lists should they go to? (I guess that besides linux-xte...@linux-xtensa.org <mailto:linux-xte...@linux-xtensa.org> list they should go to linux-kernel@vger.kernel.org <mailto:linux-kernel@vger.kernel.org> for general review. Anything else?) For now, I would really appreciate if you could hold off sending any major patch to the linux-kernel mailing list until we had a chance to look over them unless it's some generic patch (fixing an issue because of an API cha
Re: xtensa port maintenance
Hi Max, On 08/06/2012 04:38 PM, Max Filippov wrote: AFAIK xtensa linux port is currently in bad shape: it doesn't work in the mainline, it fails to build in the linux-next. The latest working kernels for xtensa are 2.6.29...31 trees hosted at the git.linux-xtensa.org. I wouldn't say it's in bad shape, I just built an vmlinux image from the latest tree (3.6.0-rc1), but it might not be very stable. One of the major issues is not really the kernel but there's actually no way to build a fairly recent version of the toolchain. I have been using a somewhat more recent buildroot version than what is on xtensa-linux.org, but even that version of buildroot is rather old now and needed a few patches. The tree on linux-xtensa.org has quite diverted from mainline now. Pete has done a great job maintaining those kernel versions, fixing a lot of bugs, and adding a ton of new additional features, but it will take quite some effort to merge them with the latest kernel. I have a goal to make xtensa arch in the linux mainline usable. Awesome!! Every help is very much appreciated. Currently I have a number of patches on top of Linus' tree that allow to build working allnoconfig, defconfig and allmodconfig kernels for ISS machine with dc232b and fsf core variants [1]. For the next several weeks I'm planning to You might expect that I'm more than curious to see those changes :-) forward-port patches accumulated in linux-xtensa.org git trees and make the resulting kernels rock-solid. I'd like to restore xtensa participation in the linux-next. Further (currently undetailed) plans are to bring modern Linux features to the xtensa port, e.g. device trees. That would be great. Might I also add that we'd need to have a working toolchain and bootable image. For me, buildroot seems to be the quickest route here. That would also require possibly adding patches to the toolchain and uClibc that are currently missing. There's also the bootloader, etc. I have a couple of questions regarding the path of xtensa-specific patches upstream: - which git tree should they be targeted for? Should I set up a tree for pull requests, or will patches be picked up into some existing tree? (Looks like Linus' tree is the right target. AFAIK previously xtensa patches went mostly through akpm tree). Yes, Andrew has been very helpful stepping in and adding those patches. Most if not all of those patches were fixes because of generic kernel changes and not major fixes or changes to the core of the Xtensa port. Ideally, it would be great if you could create a git tree (I saw you already have a version on github already?) that would allow us to look over those patches. The goal should be to have a system to build toolchain, bootable image, and kernel, so we can run some regression tests on either the simulator (qemu) or an actual board. Once we have a regression test system in place, we can then add more features and funnel those patches either through me or more directly.. What do you think? If you already have such a system in place, it would be great if you could send me some instructions to recreate it locally. We can give you also access to the wiki to add any information there. - which mailing lists should they go to? (I guess that besides linux-xte...@linux-xtensa.org list they should go to linux-kernel@vger.kernel.org for general review. Anything else?) For now, I would really appreciate if you could hold off sending any major patch to the linux-kernel mailing list until we had a chance to look over them unless it's some generic patch (fixing an issue because of an API change to the kernel, etc.) Andrew is currently adding all Xtensa patches sent to that list, and I would hate having to irritate him having to ask to remove or change patches, etc. Should you wonder what I am: I am a member of St.Petersburg Open Source and Linux Lab [2]. My previous contributions to Linux are related to p54spi wireless driver. I'm also a developer and maintainer of the target-xtensa QEMU port [3]. That's so great!! I didn't know there was a QEMU port for Xtensa. Bottom line, I hope you agree with me that the kernel, although the most fun part, is only one piece of the puzzle, and we also need a running system. If you already have that in place, we can jump to the kernel fairly quickly. Thanks, -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git-xtensa doesn't like my cross compiler
Hi Adrian, Thanks for pointing this out. I'm working on a fix. BTW, which branch do you use? release or testing? Thanks, -CHris Adrian Bunk wrote: With git-xtensa I'm getting: <-- snip --> ... /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/xtensa/Makefile:30: *** No Xtensa toolchain found on PATH.. Stop. make: *** [sub-make] Error 2 <-- snip --> My xtensa cross toolchain is prefixed xtensa-linux- and arch/xtensa/Makefile shouldn't make any assumptions regarding how the cross compiler is named. cu Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix modpost warnings for xtensa
Andrew, Andrew Morton wrote: This generates unfixable-by-me rejects against Sam's git-kbuild tree. Sam already had a pull request into Linus for that tree. Could I ask that you wait for that piece of dust to settle and then regenerate the diff? Thanks Andrew. I will wait for his updates. -Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix modpost warnings for xtensa
[PATCH] fix modpost warnings for xtensa
The Xtensa architecture places literal pools in sections separate
from the instructions. The corresponsing text sections, therefore,
reference the .literal section, and we have to suppress those
warnings. The naming convention defines the name for a literal
section as .SECTION.literal, unless .SECTION is .text. In that case
the name is only .literal. Using strncmp() instead of strcmp()
to compare the from-section with .SECTION.init.refok in pattern 0
should not cause any regressions for other architectures.
We also need to suppress warnings for two informational
sections (.xt.lit and .xt.prop) used by the Xtensa architecture.
Signed-off-by: Chris Zankel <[EMAIL PROTECTED]>
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 3645e98..9061443 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -645,12 +645,20 @@ static int strrcmp(const char *s, const char *sub)
* powerpc has a machine desc table for each platform.
* It is mixture of function pointers of .init.text and .text.
* fromsec = .machvec | .machine.desc
+ *
+ * Pattern 11:
+ * Xtensa uses literal sections for constants that are accessed PC-relative.
+ * Literal sections may savely reference their text sections.
+ * (Note that the name for the literal section omits any trailing '.text')
+ * tosec = [.text]
+ * fromsec = .literal
**/
static int secref_whitelist(const char *modname, const char *tosec,
const char *fromsec, const char *atsym,
const char *refsymname)
{
int f1 = 1, f2 = 1;
+ int len;
const char **s;
const char *pat2sym[] = {
"driver",
@@ -672,8 +680,10 @@ static int secref_whitelist(const char *modname, const
char *tosec,
};
/* Check for pattern 0 */
- if ((strcmp(fromsec, ".text.init.refok") == 0) ||
- (strcmp(fromsec, ".data.init.refok") == 0))
+ if ((strncmp(fromsec, ".text.init.refok",
+strlen(".text.init.refok")) == 0) ||
+ (strncmp(fromsec, ".data.init.refok",
+strlen(".data.init.refok")) == 0))
return 1;
/* Check for pattern 1 */
@@ -733,6 +743,16 @@ static int secref_whitelist(const char *modname, const
char *tosec,
(strcmp(fromsec, ".machine.desc") == 0))
return 1;
+
+ /* Check for pattern 11 */
+ len = strlen(tosec) - strlen(".text");
+ if (len <= 0 || strcmp(tosec + len, ".text") != 0)
+ len = strlen(tosec);
+ if (strncmp(tosec, fromsec, len) == 0
+ && (strlen(fromsec) > len)
+ && (strcmp(fromsec + len, ".literal") == 0))
+ return 1;
+
return 0;
}
@@ -858,10 +878,9 @@ static void warn_sec_mismatch(const char *modname, const
char *fromsec,
if (refsym && strlen(elf->strtab + refsym->st_name))
refsymname = elf->strtab + refsym->st_name;
- /* check whitelist - we may ignore it */
- if (before &&
- secref_whitelist(modname, secname, fromsec,
-elf->strtab + before->st_name, refsymname))
+ if (secref_whitelist(modname, secname, fromsec,
+before ? elf->strtab + before->st_name : "",
+refsymname))
return;
/* fromsec whitelist - without a valid 'before'
@@ -1053,6 +1072,8 @@ static int init_section_ref_ok(const char *name)
"__ftr_fixup", /* powerpc cpu feature fixup */
"__fw_ftr_fixup", /* powerpc firmware feature fixup */
".cranges", /* used by sh64 */
+ ".xt.prop", /* xtensa informational section */
+ ".xt.lit", /* xtensa informational section */
NULL
};
/* Start of section names */
@@ -1134,6 +1155,8 @@ static int exit_section_ref_ok(const char *name)
".smp_locks",
".plt", /* seen on ARCH=um build on x86_64. Harmless */
".cranges", /* used by sh64 */
+ ".xt.prop", /* xtensa informational section */
+ ".xt.lit", /* xtensa informational section */
NULL
};
/* Start of section names */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Jeremy, Could you please add the ELF architecture-magic number for Xtensa (94) when you finally submit this patch? Jeremy Fitzhardinge wrote: This patch cleans up the ELF headers and their users. It does several related things: --- /dev/null +++ b/include/linux/elf-const.h @@ -0,0 +1,222 @@ +#ifndef _LINUX_ELF_CONST_H +#define _LINUX_ELF_CONST_H + +/* These constants define the various ELF target machines */ +#define EM_NONE0 ... +#define EM_V85087 /* NEC v850 */ +#define EM_M32R88 /* Renesas M32R */ #define EM_XTENSA 94 Thanks, -Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: We also need to get rid of verify_area in entry.S
Jesper, Thanks for the patches. I'll take a look at the entry.S one and will pass it along to Andres, and will incorporate the signal.c patch. I am currently working on the system call interface and am removing the non-rt signal calls, so the signal.c patch probably doesn't apply cleanly anymore. Thanks, ~Chris Jesper Juhl wrote: In addition to the patch I sent a few minutes ago, there's one last reference to verify_area left in xtensa. It's in arch/xtensa/kernel/entry.S, and I'm going to need your help to get rid of that one since that code is over my head and I assume that the naive approach below would just break it : - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
