xtensa patchset for 3.7

GIT PULL Chris Zankel 6 participants 10 messages Oct 3, 2012 – Oct 9, 2012

lore

Share & tools

lore

Chris Zankel

author

2012-10-03 22:24 UTC #0 lore raw

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:

[email protected]: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

Linus Torvalds

2012-10-03 22:41 UTC #1 lore raw

Quoted 2 lines · Chris Zankel

Please pull the changes for the Xtensa architecture for v3.7.

Closer, but no cigar.

Quoted 7 lines

The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linux 3.6 (2012-09-30 16:47:46 -0700)
are available in the git repository at:
[email protected]:czankel/xtensa-linux tags/xtensa-next-20121003

That should be

git://github.com/czankel/xtensa-linux tags/xtensa-next-20121003

which is the public git address of that server.

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?

Linus

Chris Zankel

author

2012-10-03 22:59 UTC #2 lore raw

Hi Linus,

Quoted 5 lines · Linus Torvalds

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.

Quoted 8 lines

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

Linus Torvalds

2012-10-03 23:08 UTC #3 lore raw

Quoted 3 lines · Chris Zankel

I'm actually located in the Bay Area (Max, who's helping out, is in St. Petersburg)

Oh, ok, just me being confused and careless searching my mail archive..

Quoted 2 lines

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.

Well, it should be pretty easy to find kernel developers to sign stuff in the bay area, so that will help.

There was a helper website for finding willing kernel keysigners by location, but I can't seem to recall it right now. Anybody?

Linus

Randy Dunlap

2012-10-03 23:12 UTC #4 lore raw

Quoted 7 lines · Linus Torvalds

Quoted 3 lines · Chris Zankel
I'm actually located in the Bay Area (Max, who's helping out, is in St. Petersburg)
Oh, ok, just me being confused and careless searching my mail archive..

Quoted 8 lines

Quoted 2 lines
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.
Well, it should be pretty easy to find kernel developers to sign stuff in the bay area, so that will help.
There was a helper website for finding willing kernel keysigners by location, but I can't seem to recall it right now. Anybody?

http://www.kernel.org/signature.html points us to

https://maps.google.com/maps/ms?ie=UTF&msa=0&msid=203700972965484840643.0004b223fd8be6d3e2d90

Signature · 1 line

~Randy

Chris Zankel

author

2012-10-09 04:31 UTC #5 lore raw

In reply to Linus Torvalds

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

 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

Al Viro

2012-10-03 23:48 UTC #6 lore raw

In reply to Chris Zankel

Quoted 6 lines · Chris Zankel

Hi Linus,
Please pull the changes for the Xtensa architecture for v3.7.
Thanks,
-Chris

BTW, could you do an xtensa counterpart of the stuff in
git.kernel.org/pub/scm/linux/kernel/git/viro/signal#experimental-kernel_thread? Basically,
* switch kernel_thread() away from "syscall in kernel" model;
select GENERIC_KERNEL_THREAD in Kconfig and have copy_thread() check p->flags & PF_KTHREAD instead of user_mode(regs). If it's true, set the child up so that it would wake up not in ret_from_fork() but in ret_from_kernel_thread(), the latter being

	schedule_tail(last);
	fn(arg);
	sys_exit(0);

where fn and arg would be picked from something set by copy_thread() - either pt_regs or callee-saved registers if your switch_to() deals with those (in the latter case you'll obviously have then already in place by the time your newborn kernel thread wakes up). Have the same value for kernel stack pointer regardless of user_mode. Use 'usp' for fn, 'unused' for arg and expect regs to be NULL. Kill kernel_thread() in entry.S.
* add ret_from_kernel_execve() that would simply set sp to value
normal for common_exception_return (i.e. what you used to set it when going into ret_from_kernel_thread()/ret_from_fork()) and branch to said common_exception_return(). Define __ARCH_WANT_KERNEL_EXECVE in unistd.h and kill kernel_execve() in entry.S. ret_from_kernel_execve() will get as its argument task_pt_regs(current), which often spares us some calculations.
* define __ARCH_WANT_SYS_EXECVE in unistd.h, kill xtensa_execve();
just use sys_execve instead.
* as an optimization, define current_pt_regs() as
(struct pt_regs *)((unsigned long)current_thread_info() +
KERNEL_STACK_SIZE - (XCHAL_NUM_AREGS-16)*4) - 1). I.e. an equivalent of
task_pt_regs(current) without useless work - task_stack_page(current) is expanded to task_stack_page(current_thread_info()->task), which is equal to current_thread_info()...

That would probably allow more glue removal - no more syscalls from the kernel, for one thing. For another, xtensa_clone() won't need to locate struct pt_regs * - current_pt_regs() would work just as well and be faster anyway. The same goes for xtensa_rt_sigreturn() and xtensa_sigaltstack()...

Max Filippov

2012-10-04 00:07 UTC #7 lore raw

Quoted 10 lines · Al Viro

Quoted 6 lines · Chris Zankel
Hi Linus,
Please pull the changes for the Xtensa architecture for v3.7.
Thanks,
-Chris
BTW, could you do an xtensa counterpart of the stuff in
git.kernel.org/pub/scm/linux/kernel/git/viro/signal#experimental-kernel_thread?

I will try to do it, thanks for the outline.

Quoted 34 lines

Basically,
* switch kernel_thread() away from "syscall in kernel" model;
select GENERIC_KERNEL_THREAD in Kconfig and have copy_thread() check p->flags & PF_KTHREAD instead of user_mode(regs). If it's true, set the child up so that it would wake up not in ret_from_fork() but in ret_from_kernel_thread(), the latter being
        schedule_tail(last);
        fn(arg);
        sys_exit(0);
where fn and arg would be picked from something set by copy_thread() - either pt_regs or callee-saved registers if your switch_to() deals with those (in the latter case you'll obviously have then already in place by the time your newborn kernel thread wakes up). Have the same value for kernel stack pointer regardless of user_mode. Use 'usp' for fn, 'unused' for arg and expect regs to be NULL. Kill kernel_thread() in entry.S.
* add ret_from_kernel_execve() that would simply set sp to value
normal for common_exception_return (i.e. what you used to set it when going into ret_from_kernel_thread()/ret_from_fork()) and branch to said common_exception_return(). Define __ARCH_WANT_KERNEL_EXECVE in unistd.h and kill kernel_execve() in entry.S. ret_from_kernel_execve() will get as its argument task_pt_regs(current), which often spares us some calculations.
* define __ARCH_WANT_SYS_EXECVE in unistd.h, kill xtensa_execve();
just use sys_execve instead.
* as an optimization, define current_pt_regs() as
(struct pt_regs *)((unsigned long)current_thread_info() +
KERNEL_STACK_SIZE - (XCHAL_NUM_AREGS-16)*4) - 1). I.e. an equivalent of
task_pt_regs(current) without useless work - task_stack_page(current) is expanded to task_stack_page(current_thread_info()->task), which is equal to current_thread_info()...
That would probably allow more glue removal - no more syscalls from the kernel, for one thing. For another, xtensa_clone() won't need to locate struct pt_regs * - current_pt_regs() would work just as well and be faster anyway. The same goes for xtensa_rt_sigreturn() and xtensa_sigaltstack()...

Signature · 2 lines

Thanks.
-- Max

Geert Uytterhoeven

2012-10-04 18:45 UTC #8 lore raw

In reply to Chris Zankel

Hi Chris,

Quoted 1 line · Chris Zankel

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 -- [email protected]

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

Chris Zankel

author

2012-10-04 19:21 UTC #9 lore raw

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

Quoted 16 lines · Geert Uytterhoeven

Hi Chris,
Quoted 1 line · Chris Zankel
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 -- [email protected]
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