| Message ID | 20200424221948.1120587-1-arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] sh: remove sh5 support | expand |
Any progress on this? I plan to resend the sh dma-mapping I've been trying to get upstream for a year again, and they would conflict, so I could look into rebasing them first. On Sat, Apr 25, 2020 at 12:19:47AM +0200, Arnd Bergmann wrote: > The following changes since commit > ae83d0b416db002fe95601e7f97f64b59514d936: > > Linux 5.7-rc2 (2020-04-19 14:35:30 -0700) > > are available in the Git repository at: > > git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git > tags/sh5-remove > > for you to fetch changes up to 29e36fbee3be4c13ff6881a275c86d5f68acfa23: > > sh: remove sh5 support (2020-04-24 22:20:55 +0200) > > ---------------------------------------------------------------- > sh: remove sh5 support > > At long last, this is the removal of the 64-bit sh5 port > that never went into production. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > ---------------------------------------------------------------- > > v2: I should have fixed all the missing changes that Geert pointed out, > this time sending it as a pull request as the removal patch is > too big for the mailing lists, and a 'git format-patch -D' patch > is unreliable > > Arnd Bergmann (1): > sh: remove sh5 support > > arch/sh/Kconfig | 62 +- > arch/sh/Kconfig.cpu | 9 - > arch/sh/Kconfig.debug | 13 +- > arch/sh/Makefile | 29 +- > arch/sh/boot/compressed/Makefile | 12 +- > arch/sh/boot/compressed/misc.c | 8 - > arch/sh/drivers/pci/Makefile | 1 - > arch/sh/drivers/pci/ops-sh5.c | 65 - > arch/sh/drivers/pci/pci-sh5.c | 217 --- > arch/sh/drivers/pci/pci-sh5.h | 108 -- > arch/sh/include/asm/barrier.h | 4 +- > arch/sh/include/asm/bitops.h | 26 - > arch/sh/include/asm/bl_bit.h | 11 +- > arch/sh/include/asm/bl_bit_64.h | 37 - > arch/sh/include/asm/bugs.h | 4 - > arch/sh/include/asm/cache_insns.h | 12 +- > arch/sh/include/asm/cache_insns_64.h | 20 - > arch/sh/include/asm/checksum.h | 6 +- > arch/sh/include/asm/elf.h | 23 - > arch/sh/include/asm/extable.h | 4 - > arch/sh/include/asm/fixmap.h | 4 - > arch/sh/include/asm/io.h | 4 - > arch/sh/include/asm/irq.h | 3 - > arch/sh/include/asm/mmu_context.h | 12 - > arch/sh/include/asm/mmu_context_64.h | 75 - > arch/sh/include/asm/module.h | 4 - > arch/sh/include/asm/page.h | 21 +- > arch/sh/include/asm/pgtable.h | 17 - > arch/sh/include/asm/pgtable_64.h | 307 ---- > arch/sh/include/asm/posix_types.h | 6 +- > arch/sh/include/asm/processor.h | 14 +- > arch/sh/include/asm/processor_64.h | 212 --- > arch/sh/include/asm/ptrace_64.h | 14 - > arch/sh/include/asm/string.h | 6 +- > arch/sh/include/asm/string_64.h | 21 - > arch/sh/include/asm/switch_to.h | 11 +- > arch/sh/include/asm/switch_to_64.h | 32 - > arch/sh/include/asm/syscall.h | 6 +- > arch/sh/include/asm/syscall_64.h | 75 - > arch/sh/include/asm/syscalls.h | 9 +- > arch/sh/include/asm/syscalls_64.h | 18 - > arch/sh/include/asm/thread_info.h | 4 +- > arch/sh/include/asm/tlb.h | 6 +- > arch/sh/include/asm/tlb_64.h | 68 - > arch/sh/include/asm/traps.h | 4 - > arch/sh/include/asm/traps_64.h | 35 - > arch/sh/include/asm/types.h | 5 - > arch/sh/include/asm/uaccess.h | 4 - > arch/sh/include/asm/uaccess_64.h | 85 - > arch/sh/include/asm/unistd.h | 6 +- > arch/sh/include/asm/user.h | 7 - > arch/sh/include/asm/vmlinux.lds.h | 8 - > arch/sh/include/cpu-sh5/cpu/addrspace.h | 12 - > arch/sh/include/cpu-sh5/cpu/cache.h | 94 - > arch/sh/include/cpu-sh5/cpu/irq.h | 113 -- > arch/sh/include/cpu-sh5/cpu/mmu_context.h | 22 - > arch/sh/include/cpu-sh5/cpu/registers.h | 103 -- > arch/sh/include/cpu-sh5/cpu/rtc.h | 9 - > arch/sh/include/uapi/asm/posix_types.h | 8 +- > arch/sh/include/uapi/asm/posix_types_64.h | 29 - > arch/sh/include/uapi/asm/ptrace.h | 5 - > arch/sh/include/uapi/asm/ptrace_64.h | 15 - > arch/sh/include/uapi/asm/sigcontext.h | 13 - > arch/sh/include/uapi/asm/stat.h | 61 - > arch/sh/include/uapi/asm/swab.h | 10 - > arch/sh/include/uapi/asm/unistd.h | 8 +- > arch/sh/include/uapi/asm/unistd_64.h | 423 ----- > arch/sh/kernel/Makefile | 16 +- > arch/sh/kernel/cpu/Makefile | 1 - > arch/sh/kernel/cpu/init.c | 2 +- > arch/sh/kernel/cpu/irq/Makefile | 3 +- > arch/sh/kernel/cpu/irq/intc-sh5.c | 194 -- > arch/sh/kernel/cpu/proc.c | 1 - > arch/sh/kernel/cpu/sh5/Makefile | 16 - > arch/sh/kernel/cpu/sh5/clock-sh5.c | 76 - > arch/sh/kernel/cpu/sh5/entry.S | 2000 --------------------- > arch/sh/kernel/cpu/sh5/fpu.c | 106 -- > arch/sh/kernel/cpu/sh5/probe.c | 72 - > arch/sh/kernel/cpu/sh5/setup-sh5.c | 121 -- > arch/sh/kernel/cpu/sh5/switchto.S | 195 -- > arch/sh/kernel/cpu/sh5/unwind.c | 342 ---- > arch/sh/kernel/head_64.S | 346 ---- > arch/sh/kernel/irq_64.c | 48 - > arch/sh/kernel/module.c | 9 - > arch/sh/kernel/process.c | 2 - > arch/sh/kernel/process_64.c | 461 ----- > arch/sh/kernel/ptrace_64.c | 576 ------ > arch/sh/kernel/reboot.c | 6 - > arch/sh/kernel/sh_ksyms_64.c | 51 - > arch/sh/kernel/signal_64.c | 567 ------ > arch/sh/kernel/syscalls_64.S | 419 ----- > arch/sh/kernel/traps_64.c | 814 --------- > arch/sh/kernel/vmlinux.lds.S | 18 +- > arch/sh/lib64/Makefile | 17 - > arch/sh/lib64/copy_page.S | 89 - > arch/sh/lib64/copy_user_memcpy.S | 218 --- > arch/sh/lib64/memcpy.S | 202 --- > arch/sh/lib64/memset.S | 92 - > arch/sh/lib64/panic.c | 15 - > arch/sh/lib64/sdivsi3.S | 136 -- > arch/sh/lib64/strcpy.S | 98 - > arch/sh/lib64/strlen.S | 34 - > arch/sh/lib64/udelay.c | 49 - > arch/sh/lib64/udivdi3.S | 121 -- > arch/sh/lib64/udivsi3.S | 60 - > arch/sh/mm/Kconfig | 16 +- > arch/sh/mm/Makefile | 31 +- > arch/sh/mm/cache-sh5.c | 621 ------- > arch/sh/mm/cache.c | 6 - > arch/sh/mm/extable_64.c | 84 - > arch/sh/mm/tlb-sh5.c | 224 --- > arch/sh/mm/tlbex_64.c | 166 -- > arch/sh/mm/tlbflush_64.c | 172 -- > drivers/rtc/Kconfig | 2 +- > fs/Kconfig.binfmt | 2 +- > scripts/headers_install.sh | 3 - > tools/arch/sh/include/asm/barrier.h | 2 +- > 117 files changed, 67 insertions(+), 11554 deletions(-) > delete mode 100644 arch/sh/drivers/pci/ops-sh5.c > delete mode 100644 arch/sh/drivers/pci/pci-sh5.c > delete mode 100644 arch/sh/drivers/pci/pci-sh5.h > delete mode 100644 arch/sh/include/asm/bl_bit_64.h > delete mode 100644 arch/sh/include/asm/cache_insns_64.h > delete mode 100644 arch/sh/include/asm/mmu_context_64.h > delete mode 100644 arch/sh/include/asm/pgtable_64.h > delete mode 100644 arch/sh/include/asm/processor_64.h > delete mode 100644 arch/sh/include/asm/ptrace_64.h > delete mode 100644 arch/sh/include/asm/string_64.h > delete mode 100644 arch/sh/include/asm/switch_to_64.h > delete mode 100644 arch/sh/include/asm/syscall_64.h > delete mode 100644 arch/sh/include/asm/syscalls_64.h > delete mode 100644 arch/sh/include/asm/tlb_64.h > delete mode 100644 arch/sh/include/asm/traps_64.h > delete mode 100644 arch/sh/include/asm/uaccess_64.h > delete mode 100644 arch/sh/include/cpu-sh5/cpu/addrspace.h > delete mode 100644 arch/sh/include/cpu-sh5/cpu/cache.h > delete mode 100644 arch/sh/include/cpu-sh5/cpu/irq.h > delete mode 100644 arch/sh/include/cpu-sh5/cpu/mmu_context.h > delete mode 100644 arch/sh/include/cpu-sh5/cpu/registers.h > delete mode 100644 arch/sh/include/cpu-sh5/cpu/rtc.h > delete mode 100644 arch/sh/include/uapi/asm/posix_types_64.h > delete mode 100644 arch/sh/include/uapi/asm/ptrace_64.h > delete mode 100644 arch/sh/include/uapi/asm/unistd_64.h > delete mode 100644 arch/sh/kernel/cpu/irq/intc-sh5.c > delete mode 100644 arch/sh/kernel/cpu/sh5/Makefile > delete mode 100644 arch/sh/kernel/cpu/sh5/clock-sh5.c > delete mode 100644 arch/sh/kernel/cpu/sh5/entry.S > delete mode 100644 arch/sh/kernel/cpu/sh5/fpu.c > delete mode 100644 arch/sh/kernel/cpu/sh5/probe.c > delete mode 100644 arch/sh/kernel/cpu/sh5/setup-sh5.c > delete mode 100644 arch/sh/kernel/cpu/sh5/switchto.S > delete mode 100644 arch/sh/kernel/cpu/sh5/unwind.c > delete mode 100644 arch/sh/kernel/head_64.S > delete mode 100644 arch/sh/kernel/irq_64.c > delete mode 100644 arch/sh/kernel/process_64.c > delete mode 100644 arch/sh/kernel/ptrace_64.c > delete mode 100644 arch/sh/kernel/sh_ksyms_64.c > delete mode 100644 arch/sh/kernel/signal_64.c > delete mode 100644 arch/sh/kernel/syscalls_64.S > delete mode 100644 arch/sh/kernel/traps_64.c > delete mode 100644 arch/sh/lib64/Makefile > delete mode 100644 arch/sh/lib64/copy_page.S > delete mode 100644 arch/sh/lib64/copy_user_memcpy.S > delete mode 100644 arch/sh/lib64/memcpy.S > delete mode 100644 arch/sh/lib64/memset.S > delete mode 100644 arch/sh/lib64/panic.c > delete mode 100644 arch/sh/lib64/sdivsi3.S > delete mode 100644 arch/sh/lib64/strcpy.S > delete mode 100644 arch/sh/lib64/strlen.S > delete mode 100644 arch/sh/lib64/udelay.c > delete mode 100644 arch/sh/lib64/udivdi3.S > delete mode 100644 arch/sh/lib64/udivsi3.S > delete mode 100644 arch/sh/mm/cache-sh5.c > delete mode 100644 arch/sh/mm/extable_64.c > delete mode 100644 arch/sh/mm/tlb-sh5.c > delete mode 100644 arch/sh/mm/tlbex_64.c > delete mode 100644 arch/sh/mm/tlbflush_64.c > > -- > 2.26.0 > ---end quoted text---
[adding Linus] On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote: > Any progress on this? I plan to resend the sh dma-mapping I've been > trying to get upstream for a year again, and they would conflict, > so I could look into rebasing them first. So for years now it has been close to and in the end impossible to provoke sh maintainer action. At the same point hardware is pretty much long gone for the real commercial variants, and never took off for the open hardware nommu variant. Linus, would you ok with a 5.8 pull request to just kill off arch/sh/? > > On Sat, Apr 25, 2020 at 12:19:47AM +0200, Arnd Bergmann wrote: > > The following changes since commit > > ae83d0b416db002fe95601e7f97f64b59514d936: > > > > Linux 5.7-rc2 (2020-04-19 14:35:30 -0700) > > > > are available in the Git repository at: > > > > git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git > > tags/sh5-remove > > > > for you to fetch changes up to 29e36fbee3be4c13ff6881a275c86d5f68acfa23: > > > > sh: remove sh5 support (2020-04-24 22:20:55 +0200) > > > > ---------------------------------------------------------------- > > sh: remove sh5 support > > > > At long last, this is the removal of the 64-bit sh5 port > > that never went into production. > > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > > > ---------------------------------------------------------------- > > > > v2: I should have fixed all the missing changes that Geert pointed out, > > this time sending it as a pull request as the removal patch is > > too big for the mailing lists, and a 'git format-patch -D' patch > > is unreliable > > > > Arnd Bergmann (1): > > sh: remove sh5 support > > > > arch/sh/Kconfig | 62 +- > > arch/sh/Kconfig.cpu | 9 - > > arch/sh/Kconfig.debug | 13 +- > > arch/sh/Makefile | 29 +- > > arch/sh/boot/compressed/Makefile | 12 +- > > arch/sh/boot/compressed/misc.c | 8 - > > arch/sh/drivers/pci/Makefile | 1 - > > arch/sh/drivers/pci/ops-sh5.c | 65 - > > arch/sh/drivers/pci/pci-sh5.c | 217 --- > > arch/sh/drivers/pci/pci-sh5.h | 108 -- > > arch/sh/include/asm/barrier.h | 4 +- > > arch/sh/include/asm/bitops.h | 26 - > > arch/sh/include/asm/bl_bit.h | 11 +- > > arch/sh/include/asm/bl_bit_64.h | 37 - > > arch/sh/include/asm/bugs.h | 4 - > > arch/sh/include/asm/cache_insns.h | 12 +- > > arch/sh/include/asm/cache_insns_64.h | 20 - > > arch/sh/include/asm/checksum.h | 6 +- > > arch/sh/include/asm/elf.h | 23 - > > arch/sh/include/asm/extable.h | 4 - > > arch/sh/include/asm/fixmap.h | 4 - > > arch/sh/include/asm/io.h | 4 - > > arch/sh/include/asm/irq.h | 3 - > > arch/sh/include/asm/mmu_context.h | 12 - > > arch/sh/include/asm/mmu_context_64.h | 75 - > > arch/sh/include/asm/module.h | 4 - > > arch/sh/include/asm/page.h | 21 +- > > arch/sh/include/asm/pgtable.h | 17 - > > arch/sh/include/asm/pgtable_64.h | 307 ---- > > arch/sh/include/asm/posix_types.h | 6 +- > > arch/sh/include/asm/processor.h | 14 +- > > arch/sh/include/asm/processor_64.h | 212 --- > > arch/sh/include/asm/ptrace_64.h | 14 - > > arch/sh/include/asm/string.h | 6 +- > > arch/sh/include/asm/string_64.h | 21 - > > arch/sh/include/asm/switch_to.h | 11 +- > > arch/sh/include/asm/switch_to_64.h | 32 - > > arch/sh/include/asm/syscall.h | 6 +- > > arch/sh/include/asm/syscall_64.h | 75 - > > arch/sh/include/asm/syscalls.h | 9 +- > > arch/sh/include/asm/syscalls_64.h | 18 - > > arch/sh/include/asm/thread_info.h | 4 +- > > arch/sh/include/asm/tlb.h | 6 +- > > arch/sh/include/asm/tlb_64.h | 68 - > > arch/sh/include/asm/traps.h | 4 - > > arch/sh/include/asm/traps_64.h | 35 - > > arch/sh/include/asm/types.h | 5 - > > arch/sh/include/asm/uaccess.h | 4 - > > arch/sh/include/asm/uaccess_64.h | 85 - > > arch/sh/include/asm/unistd.h | 6 +- > > arch/sh/include/asm/user.h | 7 - > > arch/sh/include/asm/vmlinux.lds.h | 8 - > > arch/sh/include/cpu-sh5/cpu/addrspace.h | 12 - > > arch/sh/include/cpu-sh5/cpu/cache.h | 94 - > > arch/sh/include/cpu-sh5/cpu/irq.h | 113 -- > > arch/sh/include/cpu-sh5/cpu/mmu_context.h | 22 - > > arch/sh/include/cpu-sh5/cpu/registers.h | 103 -- > > arch/sh/include/cpu-sh5/cpu/rtc.h | 9 - > > arch/sh/include/uapi/asm/posix_types.h | 8 +- > > arch/sh/include/uapi/asm/posix_types_64.h | 29 - > > arch/sh/include/uapi/asm/ptrace.h | 5 - > > arch/sh/include/uapi/asm/ptrace_64.h | 15 - > > arch/sh/include/uapi/asm/sigcontext.h | 13 - > > arch/sh/include/uapi/asm/stat.h | 61 - > > arch/sh/include/uapi/asm/swab.h | 10 - > > arch/sh/include/uapi/asm/unistd.h | 8 +- > > arch/sh/include/uapi/asm/unistd_64.h | 423 ----- > > arch/sh/kernel/Makefile | 16 +- > > arch/sh/kernel/cpu/Makefile | 1 - > > arch/sh/kernel/cpu/init.c | 2 +- > > arch/sh/kernel/cpu/irq/Makefile | 3 +- > > arch/sh/kernel/cpu/irq/intc-sh5.c | 194 -- > > arch/sh/kernel/cpu/proc.c | 1 - > > arch/sh/kernel/cpu/sh5/Makefile | 16 - > > arch/sh/kernel/cpu/sh5/clock-sh5.c | 76 - > > arch/sh/kernel/cpu/sh5/entry.S | 2000 --------------------- > > arch/sh/kernel/cpu/sh5/fpu.c | 106 -- > > arch/sh/kernel/cpu/sh5/probe.c | 72 - > > arch/sh/kernel/cpu/sh5/setup-sh5.c | 121 -- > > arch/sh/kernel/cpu/sh5/switchto.S | 195 -- > > arch/sh/kernel/cpu/sh5/unwind.c | 342 ---- > > arch/sh/kernel/head_64.S | 346 ---- > > arch/sh/kernel/irq_64.c | 48 - > > arch/sh/kernel/module.c | 9 - > > arch/sh/kernel/process.c | 2 - > > arch/sh/kernel/process_64.c | 461 ----- > > arch/sh/kernel/ptrace_64.c | 576 ------ > > arch/sh/kernel/reboot.c | 6 - > > arch/sh/kernel/sh_ksyms_64.c | 51 - > > arch/sh/kernel/signal_64.c | 567 ------ > > arch/sh/kernel/syscalls_64.S | 419 ----- > > arch/sh/kernel/traps_64.c | 814 --------- > > arch/sh/kernel/vmlinux.lds.S | 18 +- > > arch/sh/lib64/Makefile | 17 - > > arch/sh/lib64/copy_page.S | 89 - > > arch/sh/lib64/copy_user_memcpy.S | 218 --- > > arch/sh/lib64/memcpy.S | 202 --- > > arch/sh/lib64/memset.S | 92 - > > arch/sh/lib64/panic.c | 15 - > > arch/sh/lib64/sdivsi3.S | 136 -- > > arch/sh/lib64/strcpy.S | 98 - > > arch/sh/lib64/strlen.S | 34 - > > arch/sh/lib64/udelay.c | 49 - > > arch/sh/lib64/udivdi3.S | 121 -- > > arch/sh/lib64/udivsi3.S | 60 - > > arch/sh/mm/Kconfig | 16 +- > > arch/sh/mm/Makefile | 31 +- > > arch/sh/mm/cache-sh5.c | 621 ------- > > arch/sh/mm/cache.c | 6 - > > arch/sh/mm/extable_64.c | 84 - > > arch/sh/mm/tlb-sh5.c | 224 --- > > arch/sh/mm/tlbex_64.c | 166 -- > > arch/sh/mm/tlbflush_64.c | 172 -- > > drivers/rtc/Kconfig | 2 +- > > fs/Kconfig.binfmt | 2 +- > > scripts/headers_install.sh | 3 - > > tools/arch/sh/include/asm/barrier.h | 2 +- > > 117 files changed, 67 insertions(+), 11554 deletions(-) > > delete mode 100644 arch/sh/drivers/pci/ops-sh5.c > > delete mode 100644 arch/sh/drivers/pci/pci-sh5.c > > delete mode 100644 arch/sh/drivers/pci/pci-sh5.h > > delete mode 100644 arch/sh/include/asm/bl_bit_64.h > > delete mode 100644 arch/sh/include/asm/cache_insns_64.h > > delete mode 100644 arch/sh/include/asm/mmu_context_64.h > > delete mode 100644 arch/sh/include/asm/pgtable_64.h > > delete mode 100644 arch/sh/include/asm/processor_64.h > > delete mode 100644 arch/sh/include/asm/ptrace_64.h > > delete mode 100644 arch/sh/include/asm/string_64.h > > delete mode 100644 arch/sh/include/asm/switch_to_64.h > > delete mode 100644 arch/sh/include/asm/syscall_64.h > > delete mode 100644 arch/sh/include/asm/syscalls_64.h > > delete mode 100644 arch/sh/include/asm/tlb_64.h > > delete mode 100644 arch/sh/include/asm/traps_64.h > > delete mode 100644 arch/sh/include/asm/uaccess_64.h > > delete mode 100644 arch/sh/include/cpu-sh5/cpu/addrspace.h > > delete mode 100644 arch/sh/include/cpu-sh5/cpu/cache.h > > delete mode 100644 arch/sh/include/cpu-sh5/cpu/irq.h > > delete mode 100644 arch/sh/include/cpu-sh5/cpu/mmu_context.h > > delete mode 100644 arch/sh/include/cpu-sh5/cpu/registers.h > > delete mode 100644 arch/sh/include/cpu-sh5/cpu/rtc.h > > delete mode 100644 arch/sh/include/uapi/asm/posix_types_64.h > > delete mode 100644 arch/sh/include/uapi/asm/ptrace_64.h > > delete mode 100644 arch/sh/include/uapi/asm/unistd_64.h > > delete mode 100644 arch/sh/kernel/cpu/irq/intc-sh5.c > > delete mode 100644 arch/sh/kernel/cpu/sh5/Makefile > > delete mode 100644 arch/sh/kernel/cpu/sh5/clock-sh5.c > > delete mode 100644 arch/sh/kernel/cpu/sh5/entry.S > > delete mode 100644 arch/sh/kernel/cpu/sh5/fpu.c > > delete mode 100644 arch/sh/kernel/cpu/sh5/probe.c > > delete mode 100644 arch/sh/kernel/cpu/sh5/setup-sh5.c > > delete mode 100644 arch/sh/kernel/cpu/sh5/switchto.S > > delete mode 100644 arch/sh/kernel/cpu/sh5/unwind.c > > delete mode 100644 arch/sh/kernel/head_64.S > > delete mode 100644 arch/sh/kernel/irq_64.c > > delete mode 100644 arch/sh/kernel/process_64.c > > delete mode 100644 arch/sh/kernel/ptrace_64.c > > delete mode 100644 arch/sh/kernel/sh_ksyms_64.c > > delete mode 100644 arch/sh/kernel/signal_64.c > > delete mode 100644 arch/sh/kernel/syscalls_64.S > > delete mode 100644 arch/sh/kernel/traps_64.c > > delete mode 100644 arch/sh/lib64/Makefile > > delete mode 100644 arch/sh/lib64/copy_page.S > > delete mode 100644 arch/sh/lib64/copy_user_memcpy.S > > delete mode 100644 arch/sh/lib64/memcpy.S > > delete mode 100644 arch/sh/lib64/memset.S > > delete mode 100644 arch/sh/lib64/panic.c > > delete mode 100644 arch/sh/lib64/sdivsi3.S > > delete mode 100644 arch/sh/lib64/strcpy.S > > delete mode 100644 arch/sh/lib64/strlen.S > > delete mode 100644 arch/sh/lib64/udelay.c > > delete mode 100644 arch/sh/lib64/udivdi3.S > > delete mode 100644 arch/sh/lib64/udivsi3.S > > delete mode 100644 arch/sh/mm/cache-sh5.c > > delete mode 100644 arch/sh/mm/extable_64.c > > delete mode 100644 arch/sh/mm/tlb-sh5.c > > delete mode 100644 arch/sh/mm/tlbex_64.c > > delete mode 100644 arch/sh/mm/tlbflush_64.c > > > > -- > > 2.26.0 > > > ---end quoted text--- ---end quoted text---
On 5/28/20 7:46 AM, Christoph Hellwig wrote: > [adding Linus] > > On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote: >> Any progress on this? I plan to resend the sh dma-mapping I've been >> trying to get upstream for a year again, and they would conflict, >> so I could look into rebasing them first. > > So for years now it has been close to and in the end impossible to > provoke sh maintainer action. At the same point hardware is pretty much > long gone for the real commercial variants, and never took off for the > open hardware nommu variant. > > Linus, would you ok with a 5.8 pull request to just kill off arch/sh/? We're maintaining SH in Debian so I'm interested in keeping arch/sh, but I'm also let down that SH maintainers aren't that active at the moment. I do know that Yoshinori Sato has a tree where he takes patches and sends PRs from time to time, but I have no idea what is going on. Adrian
On 5/28/20 12:55 AM, John Paul Adrian Glaubitz wrote: > On 5/28/20 7:46 AM, Christoph Hellwig wrote: >> [adding Linus] >> >> On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote: >>> Any progress on this? I plan to resend the sh dma-mapping I've been >>> trying to get upstream for a year again, and they would conflict, >>> so I could look into rebasing them first. >> >> So for years now it has been close to and in the end impossible to >> provoke sh maintainer action. At the same point hardware is pretty much >> long gone for the real commercial variants, and never took off for the >> open hardware nommu variant. >> >> Linus, would you ok with a 5.8 pull request to just kill off arch/sh/? > > We're maintaining SH in Debian so I'm interested in keeping arch/sh, but > I'm also let down that SH maintainers aren't that active at the moment. > > I do know that Yoshinori Sato has a tree where he takes patches and sends > PRs from time to time, but I have no idea what is going on. There are still people who care about the architecture and try to get fixes in: https://www.spinics.net/lists/linux-sh/msg56844.html Alas, I haven't had better luck getting Rich's attention, and I say that as someone who has his phone number. It met Sato-san for lunch once years ago, but he lives in Tokyo and english is not his first language. I was under the impression he became co-maintainer to show Rich the ropes of maintainership and to answer obscure architectural questions, not because he was volunteering for significantly more work. Rich was supposed to be load bearing. I don't really have the domain expertise to do it myself... :( Rob
On Wed, May 27, 2020 at 10:46:00PM -0700, Christoph Hellwig wrote: > [adding Linus] > > On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote: > > Any progress on this? I plan to resend the sh dma-mapping I've been > > trying to get upstream for a year again, and they would conflict, > > so I could look into rebasing them first. > > So for years now it has been close to and in the end impossible to > provoke sh maintainer action. At the same point hardware is pretty much > long gone for the real commercial variants, and never took off for the > open hardware nommu variant. > > Linus, would you ok with a 5.8 pull request to just kill off arch/sh/? It is in active use. Please do not act on such a request. I would be much quicker to ack things that actually need ack if I weren't CC'd on hundreds of random non-arch-specific changes that don't need it, but I understand that's how the kernel process works. If there are things that need ack please feel free to ping. Note that I specifically acked and requested the sh5 removal. Rich
On Thu, May 28, 2020 at 12:14:16PM -0400, Rich Felker wrote: > On Wed, May 27, 2020 at 10:46:00PM -0700, Christoph Hellwig wrote: > > [adding Linus] > > > > On Thu, May 07, 2020 at 07:35:52AM -0700, Christoph Hellwig wrote: > > > Any progress on this? I plan to resend the sh dma-mapping I've been > > > trying to get upstream for a year again, and they would conflict, > > > so I could look into rebasing them first. > > > > So for years now it has been close to and in the end impossible to > > provoke sh maintainer action. At the same point hardware is pretty much > > long gone for the real commercial variants, and never took off for the > > open hardware nommu variant. > > > > Linus, would you ok with a 5.8 pull request to just kill off arch/sh/? > > It is in active use. Please do not act on such a request. I would be > much quicker to ack things that actually need ack if I weren't CC'd on > hundreds of random non-arch-specific changes that don't need it, but I > understand that's how the kernel process works. If there are things > that need ack please feel free to ping. > > Note that I specifically acked and requested the sh5 removal. To follow up, I see that there was a patch series of yours (3/24) I missed ack'ing fairly recently. At first glance it looks good. It happened to arrive while I was getting over being horribly sick with what I thought was covid19. If there's further action needed on it I'll address it asap now that I'm aware of it. In general, most of the patches I see are things that the linux-sh list and myself end up cc'd on that are only tangentially related to arch/sh or even not related at all. In that case I normally trust other maintainers familiar with the cross-arch changes being made that the small arch/sh part of the change is ok if the broader change is abstractly ok. Part of why I really disliked the "just kill it all" response to this thread is that the sh5 removal is specifically for the sake of making the arch more maintainable. That, along with forward-porting Sato's SH4 device tree patches (I've tried this but ran into problems, and need some help with it), has long been on my agenda for the arch, to reduce (and ultimately eliminate) the amount of legacy "only on arch/sh" stuff left so that it's not a burden on other maintainers and contributors. Seeing sentiment along the lines of "why don't you just remove it all while you're at it?" as a response is disheartening and also dismissive of Arnd's work making the sh5 removal happen. Aside from that, the open source & open hardware J-core models are still active and in development, with the latest release having been made this month, and the J32 with MMU nearly complete and pending release, contingent mostly on integration and testing with Linux.
On 5/28/20 5:14 PM, Rich Felker wrote: > Aside from that, the open source & open hardware J-core models are > still active and in development, with the latest release having been > made this month, and the J32 with MMU nearly complete and pending > release, contingent mostly on integration and testing with Linux. J-core's doing stuff: https://github.com/j-core https://www.prnewswire.com/news-releases/spacechain-foundation-invests-in-core-semiconductor-to-produce-open-hardware-platform-for-direct-satellite-to-devices-communication-301061761.html https://www.reddit.com/r/IAmA/comments/gs7qpn/we_are_jeff_garzik_and_jeff_dionne_and_we_are/ And I note that I worked a year long contract in 2018 porting an existing sh4 Windows CE board to Linux (as a field upgrade to a widely deployed building control system with a big stock of parts to build replacement units), so conventional superh isn't exactly dead either. Rob
Hello Rich! On 5/29/20 12:14 AM, Rich Felker wrote: > To follow up, I see that there was a patch series of yours (3/24) I > missed ack'ing fairly recently. At first glance it looks good. It > happened to arrive while I was getting over being horribly sick with > what I thought was covid19. If there's further action needed on it > I'll address it asap now that I'm aware of it. Glad to hear from you again! I hope you have fully recovered! > In general, most of the patches I see are things that the linux-sh > list and myself end up cc'd on that are only tangentially related to > arch/sh or even not related at all. In that case I normally trust > other maintainers familiar with the cross-arch changes being made that > the small arch/sh part of the change is ok if the broader change is > abstractly ok. > > Part of why I really disliked the "just kill it all" response to this > thread is that the sh5 removal is specifically for the sake of making > the arch more maintainable. That, along with forward-porting Sato's > SH4 device tree patches (I've tried this but ran into problems, and > need some help with it), has long been on my agenda for the arch, to > reduce (and ultimately eliminate) the amount of legacy "only on > arch/sh" stuff left so that it's not a burden on other maintainers and > contributors. Seeing sentiment along the lines of "why don't you just > remove it all while you're at it?" as a response is disheartening and > also dismissive of Arnd's work making the sh5 removal happen. I agree. I have also poured endless hours into Debian's sh4 port fixing dozens of bugs myself and reporting them upstream whenever I couldn't fix them myself. I would also like to add that getting device tree support into SH would be a huge leap forward and I would be happy to help with the efforts. I still have some LANDISK and NextVoD devices available if anyone needs hardware for testing and development, FWIW. Would be great to also hear back from Sato-san, he is still active on his other Linux trees [1]. > Aside from that, the open source & open hardware J-core models are > still active and in development, with the latest release having been > made this month, and the J32 with MMU nearly complete and pending > release, contingent mostly on integration and testing with Linux. And I'm still very much looking forward to these. I will certainly buy a bunch of J32 to use them as buildds for Debian's sh4 port! Thanks, Adrian > [1] https://osdn.net/projects/uclinux-h8/scm/git/linux/branches
On Fri, May 29, 2020 at 12:32:07AM +0200, John Paul Adrian Glaubitz wrote: > Hello Rich! > > On 5/29/20 12:14 AM, Rich Felker wrote: > > To follow up, I see that there was a patch series of yours (3/24) I > > missed ack'ing fairly recently. At first glance it looks good. It > > happened to arrive while I was getting over being horribly sick with > > what I thought was covid19. If there's further action needed on it > > I'll address it asap now that I'm aware of it. > > Glad to hear from you again! I hope you have fully recovered! Yes, but it took a good while to get fully better, and according to tests it wasn't even covid19. Certainly shaped my view on taking the pandemic seriously at an appropriate time, though! > > In general, most of the patches I see are things that the linux-sh > > list and myself end up cc'd on that are only tangentially related to > > arch/sh or even not related at all. In that case I normally trust > > other maintainers familiar with the cross-arch changes being made that > > the small arch/sh part of the change is ok if the broader change is > > abstractly ok. > > > > Part of why I really disliked the "just kill it all" response to this > > thread is that the sh5 removal is specifically for the sake of making > > the arch more maintainable. That, along with forward-porting Sato's > > SH4 device tree patches (I've tried this but ran into problems, and > > need some help with it), has long been on my agenda for the arch, to > > reduce (and ultimately eliminate) the amount of legacy "only on > > arch/sh" stuff left so that it's not a burden on other maintainers and > > contributors. Seeing sentiment along the lines of "why don't you just > > remove it all while you're at it?" as a response is disheartening and > > also dismissive of Arnd's work making the sh5 removal happen. > > I agree. I have also poured endless hours into Debian's sh4 port fixing > dozens of bugs myself and reporting them upstream whenever I couldn't > fix them myself. > > I would also like to add that getting device tree support into SH would > be a huge leap forward and I would be happy to help with the efforts. I > still have some LANDISK and NextVoD devices available if anyone needs > hardware for testing and development, FWIW. And I still have the NextVoD and LANDISK. The NextVoD is ST-based, so not supported at all by upstream kernel, only the abandoned stlinux. I've long wanted to pull support for ST hardware back into mainline, and I think DT makes this viable rather than just a huge new mess on top of undermaintained code, but it'll need help to make it happen. > Would be great to also hear back from Sato-san, he is still active > on his other Linux trees [1]. Yes. > > Aside from that, the open source & open hardware J-core models are > > still active and in development, with the latest release having been > > made this month, and the J32 with MMU nearly complete and pending > > release, contingent mostly on integration and testing with Linux. > > And I'm still very much looking forward to these. I will certainly > buy a bunch of J32 to use them as buildds for Debian's sh4 port! Great! Rich
On Thu, May 28, 2020 at 12:14:16PM -0400, Rich Felker wrote: > It is in active use. Please do not act on such a request. I would be > much quicker to ack things that actually need ack if I weren't CC'd on > hundreds of random non-arch-specific changes that don't need it, but I > understand that's how the kernel process works. If there are things > that need ack please feel free to ping. > > Note that I specifically acked and requested the sh5 removal. But you did not actually pick it up - because of that it still isn't in linux-next and thus most likely will miss Linux 5.8.
On Thu, May 28, 2020 at 06:14:51PM -0400, Rich Felker wrote: > To follow up, I see that there was a patch series of yours (3/24) I > missed ack'ing fairly recently. At first glance it looks good. Well, I need a formal ACK, or even better have the arch maintainer pick it up, as that is how development is normally supposed to work. > In general, most of the patches I see are things that the linux-sh > list and myself end up cc'd on that are only tangentially related to > arch/sh or even not related at all. In that case I normally trust > other maintainers familiar with the cross-arch changes being made that > the small arch/sh part of the change is ok if the broader change is > abstractly ok. FYI, if you want to reduce the amount of crap you get Cced on, you can add yourself to .get_maintainer.ignore file in the kernel tree, as that at least removes a lot of the pass by cleanups found from git log. > Part of why I really disliked the "just kill it all" response to this > thread is that the sh5 removal is specifically for the sake of making > the arch more maintainable. That, along with forward-porting Sato's > SH4 device tree patches (I've tried this but ran into problems, and > need some help with it), has long been on my agenda for the arch, to > reduce (and ultimately eliminate) the amount of legacy "only on > arch/sh" stuff left so that it's not a burden on other maintainers and > contributors. Seeing sentiment along the lines of "why don't you just > remove it all while you're at it?" as a response is disheartening and > also dismissive of Arnd's work making the sh5 removal happen. We had the discussion before and things like the sh5 removal and device tree switch came out of it. But since then exactly nothing has happened - the arch code is still pretty much unmaintained and impossible to get a review for. No one expects super quick responses for a legacy architecture, but if there is no way to get feedback or patches queued up while the code keeps on bitrotting the architecture is effectively dead. I have no personal problem with the sh hardware, but if we want a Linux port to survive it will need at least a minimum amount of active maintainance.
On Fri, May 29, 2020 at 07:30:59AM -0700, Christoph Hellwig wrote: > On Thu, May 28, 2020 at 12:14:16PM -0400, Rich Felker wrote: > > It is in active use. Please do not act on such a request. I would be > > much quicker to ack things that actually need ack if I weren't CC'd on > > hundreds of random non-arch-specific changes that don't need it, but I > > understand that's how the kernel process works. If there are things > > that need ack please feel free to ping. > > > > Note that I specifically acked and requested the sh5 removal. > > But you did not actually pick it up - because of that it still isn't > in linux-next and thus most likely will miss Linux 5.8. Arnd sent the pull request for this and I expected it to be pulled from his tree, since he already had my approval for the change. Maybe Linus was expecting it to come through me. This seems to have been a miscommunication. Frustratingly, I _still_ don't have an official tree on kernel.org for the purpose of being the canonical place for linux-next to pull from, due to policies around pgp keys and nobody following up on signing mine. This is all really silly since there are ridiculously many independent channels I could cryptographically validate identity through with vanishing probability that they're all compromised. For the time being I'll reactivate my repo on git.musl-libc.org. Rich
On Fri, May 29, 2020 at 01:53:38PM -0400, Rich Felker wrote: > Frustratingly, I _still_ don't have an official tree on kernel.org for > the purpose of being the canonical place for linux-next to pull from, > due to policies around pgp keys and nobody following up on signing > mine. This is all really silly since there are ridiculously many > independent channels I could cryptographically validate identity > through with vanishing probability that they're all compromised. For > the time being I'll reactivate my repo on git.musl-libc.org. You don't need a kernel.org tree. None of the trees I maintain are hosted on kernel.org. Just make sure you sign your tags.
On 5/29/20 7:53 PM, Rich Felker wrote: > Frustratingly, I _still_ don't have an official tree on kernel.org for > the purpose of being the canonical place for linux-next to pull from, > due to policies around pgp keys and nobody following up on signing > mine. This is all really silly since there are ridiculously many > independent channels I could cryptographically validate identity > through with vanishing probability that they're all compromised. For > the time being I'll reactivate my repo on git.musl-libc.org. May I suggest to pick up these patches, for example? There might be more I missed, but getting these merged should already help a lot with the clean-up of arch/sh. > [RESEND PATCH v2] sh: sh4a: Bring back tmu3_device early device > https://marc.info/?l=linux-sh&m=159061283109675&w=2 > [PATCH] sh: Drop CONFIG_MTD_M25P80 in sh7757lcr_defconfig > https://marc.info/?l=linux-sh&m=158839364811658&w=2 > [PATCH v2] sh: Replace CONFIG_MTD_M25P80 with CONFIG_MTD_SPI_NOR in sh7757lcr_defconfig > https://marc.info/?l=linux-sh&m=158841749817761&w=2 > [PATCH 1/1] sh: remove sh5 support > https://marc.info/?l=linux-sh&m=158776683125080&w=2 > sh/mm: Fix a build failure via adding a missing bracket > https://marc.info/?l=linux-sh&m=158736532105299&w=2 > [PATCH 1/2] arch/sh: vmlinux.scr > https://marc.info/?l=linux-sh&m=158429470120959&w=2 > [PATCH] sh: configs: Cleanup old Kconfig IO scheduler options > https://marc.info/?l=linux-sh&m=158195850120215&w=2 > [PATCH resend 0/3] SH: compile fixup patches > https://marc.info/?l=linux-renesas-soc&m=157948330821790&w=2 > https://marc.info/?l=linux-sh&m=157852970316892&w=2 > https://marc.info/?l=linux-sh&m=157852984016938&w=2 > [PATCH][repost] sh: clkfwk: remove r8/r16/r32 > https://marc.info/?l=linux-renesas-soc&m=157852973916903&w=2 > [PATCH] sh: clk: Fix discarding const qualifier warning > https://marc.info/?l=linux-sh&m=157839999010776&w=2 > [PATCH next] sh: remove call to memset after dma_alloc_coherent > https://marc.info/?l=linux-sh&m=157793031102356&w=2 > [PATCH] sh: use generic strncpy() > https://marc.info/?l=linux-renesas-soc&m=157664657013309&w=2 > [PATCH v2] SH: Convert ins[bwl]/outs[bwl] macros to inline functions > https://marc.info/?l=linux-sh&m=157656907716201&w=2 > [PATCH v2] SH: Convert iounmap() macros to inline functions > https://marc.info/?l=linux-sh&m=157656903716172&w=2 > [PATCH v2] sh: add missing DECLARE_EXPORT() for __ashiftrt_r4_xx > https://marc.info/?l=linux-sh&m=157619891030685&w=2 > [PATCH] sh: add missing EXPORT_SYMBOL() for __delay > https://marc.info/?l=linux-kernel&m=157611811927852&w=2 > [PATCH] sh: kgdb: Mark expected switch fall-throughs > https://marc.info/?l=linux-sh&m=157241987926081&w=2 Adrian
On Sat, May 30, 2020 at 10:08 AM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > On 5/29/20 7:53 PM, Rich Felker wrote: > > Frustratingly, I _still_ don't have an official tree on kernel.org for > > the purpose of being the canonical place for linux-next to pull from, > > due to policies around pgp keys and nobody following up on signing > > mine. This is all really silly since there are ridiculously many > > independent channels I could cryptographically validate identity > > through with vanishing probability that they're all compromised. For > > the time being I'll reactivate my repo on git.musl-libc.org. > > May I suggest to pick up these patches, for example? There might be > more I missed, but getting these merged should already help a lot with > the clean-up of arch/sh. And https://marc.info/?l=linux-arch&m=153337991312146&w=2 Gr{oetje,eeting}s, Geert
On 5/30/20 3:08 AM, John Paul Adrian Glaubitz wrote: > On 5/29/20 7:53 PM, Rich Felker wrote: >> Frustratingly, I _still_ don't have an official tree on kernel.org for >> the purpose of being the canonical place for linux-next to pull from, >> due to policies around pgp keys and nobody following up on signing >> mine. This is all really silly since there are ridiculously many >> independent channels I could cryptographically validate identity >> through with vanishing probability that they're all compromised. For >> the time being I'll reactivate my repo on git.musl-libc.org. > > May I suggest to pick up these patches, for example? There might be > more I missed, but getting these merged should already help a lot with > the clean-up of arch/sh. Does that include the 2 fixes to build with current binutils I made puppy eyes about last -rc7 (in march)? https://marc.info/?l=linux-sh&m=158544749818664&w=2 Rob
On 5/31/20 5:20 AM, Rob Landley wrote: > On 5/30/20 3:08 AM, John Paul Adrian Glaubitz wrote: >> On 5/29/20 7:53 PM, Rich Felker wrote: >>> Frustratingly, I _still_ don't have an official tree on kernel.org for >>> the purpose of being the canonical place for linux-next to pull from, >>> due to policies around pgp keys and nobody following up on signing >>> mine. This is all really silly since there are ridiculously many >>> independent channels I could cryptographically validate identity >>> through with vanishing probability that they're all compromised. For >>> the time being I'll reactivate my repo on git.musl-libc.org. >> >> May I suggest to pick up these patches, for example? There might be >> more I missed, but getting these merged should already help a lot with >> the clean-up of arch/sh. > > Does that include the 2 fixes to build with current binutils I made puppy eyes > about last -rc7 (in march)? > > https://marc.info/?l=linux-sh&m=158544749818664&w=2 Yes, listed as "[PATCH 1/2] arch/sh: vmlinux.scr". @Rich: Do you think you can merge all those fixes in your local tree within the next days and send a PR to Linus? Otherwise, I can volunteer to become a third maintainer for arch/sh as I have the hardware for testing and can accept patches and send PRs. We shouldn't let contributors to arch/sh wait for too long. Adrian
On Sun, May 31, 2020 at 10:03:13AM +0200, John Paul Adrian Glaubitz wrote: > On 5/31/20 5:20 AM, Rob Landley wrote: > > On 5/30/20 3:08 AM, John Paul Adrian Glaubitz wrote: > >> On 5/29/20 7:53 PM, Rich Felker wrote: > >>> Frustratingly, I _still_ don't have an official tree on kernel.org for > >>> the purpose of being the canonical place for linux-next to pull from, > >>> due to policies around pgp keys and nobody following up on signing > >>> mine. This is all really silly since there are ridiculously many > >>> independent channels I could cryptographically validate identity > >>> through with vanishing probability that they're all compromised. For > >>> the time being I'll reactivate my repo on git.musl-libc.org. > >> > >> May I suggest to pick up these patches, for example? There might be > >> more I missed, but getting these merged should already help a lot with > >> the clean-up of arch/sh. > > > > Does that include the 2 fixes to build with current binutils I made puppy eyes > > about last -rc7 (in march)? > > > > https://marc.info/?l=linux-sh&m=158544749818664&w=2 > Yes, listed as "[PATCH 1/2] arch/sh: vmlinux.scr". > > @Rich: Do you think you can merge all those fixes in your local tree within > the next days and send a PR to Linus? > > Otherwise, I can volunteer to become a third maintainer for arch/sh as I have > the hardware for testing and can accept patches and send PRs. > > We shouldn't let contributors to arch/sh wait for too long. Yes, I'll try to get my tree ready for next/PR use tomorrow. Rich
Hi Rich!
On 6/1/20 4:55 AM, Rich Felker wrote:
> Yes, I'll try to get my tree ready for next/PR use tomorrow.
Great, really looking forward.
Adrian
On Sat, May 30, 2020 at 10:08:09AM +0200, John Paul Adrian Glaubitz wrote: > On 5/29/20 7:53 PM, Rich Felker wrote: > > Frustratingly, I _still_ don't have an official tree on kernel.org for > > the purpose of being the canonical place for linux-next to pull from, > > due to policies around pgp keys and nobody following up on signing > > mine. This is all really silly since there are ridiculously many > > independent channels I could cryptographically validate identity > > through with vanishing probability that they're all compromised. For > > the time being I'll reactivate my repo on git.musl-libc.org. > > May I suggest to pick up these patches, for example? There might be > more I missed, but getting these merged should already help a lot with > the clean-up of arch/sh. This was really helpful, but one thing that would make it easier if you have any more to list is including message-ids rather than (or in addition to) marc.info links. I had to go through and reverse them all to message-ids (or at least subjects) to find the patches from my mailbox to git-am. > > [RESEND PATCH v2] sh: sh4a: Bring back tmu3_device early device > > https://marc.info/?l=linux-sh&m=159061283109675&w=2 OK. > > [PATCH] sh: Drop CONFIG_MTD_M25P80 in sh7757lcr_defconfig > > https://marc.info/?l=linux-sh&m=158839364811658&w=2 > > > [PATCH v2] sh: Replace CONFIG_MTD_M25P80 with CONFIG_MTD_SPI_NOR in sh7757lcr_defconfig > > https://marc.info/?l=linux-sh&m=158841749817761&w=2 Doesn't the second one here replace the first? > > [PATCH 1/1] sh: remove sh5 support > > https://marc.info/?l=linux-sh&m=158776683125080&w=2 I'm trying to figure out how to apply this since it was generated with -D and git-am maliciously rejects it for that reason with an arcane error message. > > sh/mm: Fix a build failure via adding a missing bracket > > https://marc.info/?l=linux-sh&m=158736532105299&w=2 Already upstream. > > [PATCH 1/2] arch/sh: vmlinux.scr > > https://marc.info/?l=linux-sh&m=158429470120959&w=2 OK. > > [PATCH] sh: configs: Cleanup old Kconfig IO scheduler options > > https://marc.info/?l=linux-sh&m=158195850120215&w=2 OK. > > [PATCH resend 0/3] SH: compile fixup patches > > https://marc.info/?l=linux-renesas-soc&m=157948330821790&w=2 > > https://marc.info/?l=linux-sh&m=157852970316892&w=2 > > https://marc.info/?l=linux-sh&m=157852984016938&w=2 OK. > > [PATCH][repost] sh: clkfwk: remove r8/r16/r32 > > https://marc.info/?l=linux-renesas-soc&m=157852973916903&w=2 This one had objections by Geert that called for a v2, and was teplaced by: > > [PATCH] sh: clk: Fix discarding const qualifier warning > > https://marc.info/?l=linux-sh&m=157839999010776&w=2 But this still had objections that the definitions on all archs should be fixed for const correctness. It looks like that patch series is still bouncing around; should I apply the SH part of it now? > > [PATCH next] sh: remove call to memset after dma_alloc_coherent > > https://marc.info/?l=linux-sh&m=157793031102356&w=2 Can anyone confirm that this is correct/safe? > > [PATCH] sh: use generic strncpy() > > https://marc.info/?l=linux-renesas-soc&m=157664657013309&w=2 Can you fill me in on the status of this? It looks like you were following it. The subject says "use generic strncpy" but it's updating the asm, and I think there are problems with the proposed asm. > > [PATCH v2] SH: Convert ins[bwl]/outs[bwl] macros to inline functions > > https://marc.info/?l=linux-sh&m=157656907716201&w=2 OK. > > [PATCH v2] SH: Convert iounmap() macros to inline functions > > https://marc.info/?l=linux-sh&m=157656903716172&w=2 OK. > > [PATCH v2] sh: add missing DECLARE_EXPORT() for __ashiftrt_r4_xx > > https://marc.info/?l=linux-sh&m=157619891030685&w=2 OK. > > [PATCH] sh: add missing EXPORT_SYMBOL() for __delay > > https://marc.info/?l=linux-kernel&m=157611811927852&w=2 OK. > > [PATCH] sh: kgdb: Mark expected switch fall-throughs > > https://marc.info/?l=linux-sh&m=157241987926081&w=2 This is already upstream. Rich
On Mon, Jun 1, 2020 at 8:13 PM Rich Felker <dalias@libc.org> wrote: > On Sat, May 30, 2020 at 10:08:09AM +0200, John Paul Adrian Glaubitz wrote: > > On 5/29/20 7:53 PM, Rich Felker wrote: > > > [PATCH next] sh: remove call to memset after dma_alloc_coherent > > > https://marc.info/?l=linux-sh&m=157793031102356&w=2 > > Can anyone confirm that this is correct/safe? Yes, this is safe, I checked both the API definition and the sh implementation in arch_dma_alloc(), which passes __GFP_ZERO. Arnd
On Mon, Jun 01, 2020 at 02:13:00PM -0400, Rich Felker wrote: > On Sat, May 30, 2020 at 10:08:09AM +0200, John Paul Adrian Glaubitz wrote: > > On 5/29/20 7:53 PM, Rich Felker wrote: > > > Frustratingly, I _still_ don't have an official tree on kernel.org for > > > the purpose of being the canonical place for linux-next to pull from, > > > due to policies around pgp keys and nobody following up on signing > > > mine. This is all really silly since there are ridiculously many > > > independent channels I could cryptographically validate identity > > > through with vanishing probability that they're all compromised. For > > > the time being I'll reactivate my repo on git.musl-libc.org. > > > > May I suggest to pick up these patches, for example? There might be > > more I missed, but getting these merged should already help a lot with > > the clean-up of arch/sh. > > This was really helpful, but one thing that would make it easier if > you have any more to list is including message-ids rather than (or in > addition to) marc.info links. I had to go through and reverse them all > to message-ids (or at least subjects) to find the patches from my > mailbox to git-am. Hmm, it looks like Andrew Morton just pulled most of these into -mm, apparently independently of me getting them in my for-next a few hours ago, since his versions lack my signed-off-by. That's ok though, as long as they go up. Some details since further action is needed on a few: > > > [RESEND PATCH v2] sh: sh4a: Bring back tmu3_device early device > > > https://marc.info/?l=linux-sh&m=159061283109675&w=2 > > OK. In -mm. > > > [PATCH] sh: Drop CONFIG_MTD_M25P80 in sh7757lcr_defconfig > > > https://marc.info/?l=linux-sh&m=158839364811658&w=2 > > > > > [PATCH v2] sh: Replace CONFIG_MTD_M25P80 with CONFIG_MTD_SPI_NOR in sh7757lcr_defconfig > > > https://marc.info/?l=linux-sh&m=158841749817761&w=2 > > Doesn't the second one here replace the first? The first one was pulled and the second wasn't so I think the second needs to be rewritten on top of the first now. > > > [PATCH 1/1] sh: remove sh5 support > > > https://marc.info/?l=linux-sh&m=158776683125080&w=2 > > I'm trying to figure out how to apply this since it was generated with > -D and git-am maliciously rejects it for that reason with an arcane > error message. Not included in -mm. I'll keep it in my for-next. > > > sh/mm: Fix a build failure via adding a missing bracket > > > https://marc.info/?l=linux-sh&m=158736532105299&w=2 > > Already upstream. No action needed. > > > [PATCH 1/2] arch/sh: vmlinux.scr > > > https://marc.info/?l=linux-sh&m=158429470120959&w=2 > > OK. Included in -mm. > > > [PATCH] sh: configs: Cleanup old Kconfig IO scheduler options > > > https://marc.info/?l=linux-sh&m=158195850120215&w=2 > > OK. Not included in -mm. I'll keep. > > > [PATCH resend 0/3] SH: compile fixup patches > > > https://marc.info/?l=linux-renesas-soc&m=157948330821790&w=2 > > > https://marc.info/?l=linux-sh&m=157852970316892&w=2 > > > https://marc.info/?l=linux-sh&m=157852984016938&w=2 > > OK. > > > > [PATCH][repost] sh: clkfwk: remove r8/r16/r32 > > > https://marc.info/?l=linux-renesas-soc&m=157852973916903&w=2 > > This one had objections by Geert that called for a v2, and was > teplaced by: > > > > [PATCH] sh: clk: Fix discarding const qualifier warning > > > https://marc.info/?l=linux-sh&m=157839999010776&w=2 > > But this still had objections that the definitions on all archs should > be fixed for const correctness. It looks like that patch series is > still bouncing around; should I apply the SH part of it now? The first one here is now in -mm, so further cleanup action is needed but I think that will happen with the cross-arch patch series. > > > [PATCH next] sh: remove call to memset after dma_alloc_coherent > > > https://marc.info/?l=linux-sh&m=157793031102356&w=2 > > Can anyone confirm that this is correct/safe? Arnd confirmed it and it's in -mm now anyway. > > > [PATCH] sh: use generic strncpy() > > > https://marc.info/?l=linux-renesas-soc&m=157664657013309&w=2 > > Can you fill me in on the status of this? It looks like you were > following it. The subject says "use generic strncpy" but it's updating > the asm, and I think there are problems with the proposed asm. Actual generic-strncpy is in -mm now so I think this should be ok. If there's a desire to use the asm, it needs fixes. Latest proposed version is using named labels (not numbered ones) in an inline asm block so the compiler can in theory duplicate it and break assembly. > > > [PATCH v2] SH: Convert ins[bwl]/outs[bwl] macros to inline functions > > > https://marc.info/?l=linux-sh&m=157656907716201&w=2 > > OK. In -mm, with followup style fix. > > > [PATCH v2] SH: Convert iounmap() macros to inline functions > > > https://marc.info/?l=linux-sh&m=157656903716172&w=2 > > OK. In -mm. > > > [PATCH v2] sh: add missing DECLARE_EXPORT() for __ashiftrt_r4_xx > > > https://marc.info/?l=linux-sh&m=157619891030685&w=2 > > OK. Missing from -mm so I'll keep it. > > > [PATCH] sh: add missing EXPORT_SYMBOL() for __delay > > > https://marc.info/?l=linux-kernel&m=157611811927852&w=2 > > OK. In -mm. > > > [PATCH] sh: kgdb: Mark expected switch fall-throughs > > > https://marc.info/?l=linux-sh&m=157241987926081&w=2 > > This is already upstream. No action needed. Rich
On Mon, 1 Jun 2020 21:33:32 -0400 Rich Felker <dalias@libc.org> wrote: > Hmm, it looks like Andrew Morton just pulled most of these into -mm, > apparently independently of me getting them in my for-next a few hours > ago, since his versions lack my signed-off-by. That's ok though, as > long as they go up. Some details since further action is needed on a > few: It would be better if these were to go via the sh tree. So please go ahead and merge them up - I'll drop my copies when they turn up in -next via the sh tree.
On Mon, Jun 01, 2020 at 07:49:36PM -0700, Andrew Morton wrote: > On Mon, 1 Jun 2020 21:33:32 -0400 Rich Felker <dalias@libc.org> wrote: > > > Hmm, it looks like Andrew Morton just pulled most of these into -mm, > > apparently independently of me getting them in my for-next a few hours > > ago, since his versions lack my signed-off-by. That's ok though, as > > long as they go up. Some details since further action is needed on a > > few: > > It would be better if these were to go via the sh tree. So please go > ahead and merge them up - I'll drop my copies when they turn up in > -next via the sh tree. OK. That simplifies things a bit. Thanks. Rich
Hi Rich! On 6/2/20 3:33 AM, Rich Felker wrote: > Hmm, it looks like Andrew Morton just pulled most of these into -mm, > apparently independently of me getting them in my for-next a few hours > ago, since his versions lack my signed-off-by. That's ok though, as > long as they go up. Some details since further action is needed on a > few: I thought Andrew dropped them again since he saw you become active. I can't find them in his tree. Adrian
On 6/3/20 9:27 AM, John Paul Adrian Glaubitz wrote: > On 6/2/20 3:33 AM, Rich Felker wrote: >> Hmm, it looks like Andrew Morton just pulled most of these into -mm, >> apparently independently of me getting them in my for-next a few hours >> ago, since his versions lack my signed-off-by. That's ok though, as >> long as they go up. Some details since further action is needed on a >> few: > > I thought Andrew dropped them again since he saw you become active. > > I can't find them in his tree. Ah, sorry. I missed Andrew's message here, sorry. In any case, I suggest merging all the patches now which have been reviewed and acked and send a PR to Linus. We can then go through the list of patches needing review and merge them later. Adrian
Hi Rich! On 6/2/20 3:33 AM, Rich Felker wrote: >>>> [PATCH 1/2] arch/sh: vmlinux.scr >>>> https://marc.info/?l=linux-sh&m=158429470120959&w=2 >> >> OK. > > Included in -mm. I just had a look at your tree and it looks you forgot to merge the second patch of the series, see: > https://marc.info/?l=linux-sh&m=158429470221261&w=2 Can you include the patch as well? And would it be okay to send a PR to Linus after that? Thanks, Adrian
On Fri, Jun 05, 2020 at 05:38:18PM +0200, John Paul Adrian Glaubitz wrote: > Hi Rich! > > On 6/2/20 3:33 AM, Rich Felker wrote: > >>>> [PATCH 1/2] arch/sh: vmlinux.scr > >>>> https://marc.info/?l=linux-sh&m=158429470120959&w=2 > >> > >> OK. > > > > Included in -mm. > > I just had a look at your tree and it looks you forgot to merge the second > patch of the series, see: > > > https://marc.info/?l=linux-sh&m=158429470221261&w=2 > > Can you include the patch as well? This one is outside arch/sh and I'm not sure it's permissible to go up through my tree. I was also under the impression that only part 1 was needed to fix the immediate problem on sh and tha part 2 was for completeness and to make sure the same doesn't happen on other archs in the future, but maybe my understanding here is incorrect. > And would it be okay to send a PR to Linus > after that? Sure, will do right away once we resolve what to do with the above, and provided you don't have anything else you want me to evaluate for inclusion. Rich
On 6/5/20 5:43 PM, Rich Felker wrote: >> Can you include the patch as well? > > This one is outside arch/sh and I'm not sure it's permissible to go up > through my tree. I was also under the impression that only part 1 was > needed to fix the immediate problem on sh and tha part 2 was for > completeness and to make sure the same doesn't happen on other archs > in the future, but maybe my understanding here is incorrect. Ah, sorry, I missed that. You're right, it should probably go through someone else's tree then. >> And would it be okay to send a PR to Linus >> after that? > > Sure, will do right away once we resolve what to do with the above, > and provided you don't have anything else you want me to evaluate for > inclusion. Since we haven't agreed on the __get_user_64() patch yet, I would be in favor of getting the changes pulled in that have already been reviewed and acknowledged. I rather don't want the other contributors to wait any longer. Arnd in particular has done a tremendous job to untangle all the SH-5 code and I think we should finally get this in :). Thanks, Adrian
On Fri, Jun 05, 2020 at 05:47:34PM +0200, John Paul Adrian Glaubitz wrote: > On 6/5/20 5:43 PM, Rich Felker wrote: > >> Can you include the patch as well? > > > > This one is outside arch/sh and I'm not sure it's permissible to go up > > through my tree. I was also under the impression that only part 1 was > > needed to fix the immediate problem on sh and tha part 2 was for > > completeness and to make sure the same doesn't happen on other archs > > in the future, but maybe my understanding here is incorrect. > > Ah, sorry, I missed that. You're right, it should probably go through > someone else's tree then. Do you know if it's needed to un-break sh4? If so we should push to get whoever has jurisdiction over it to include it; otherwise I'm indifferent. > >> And would it be okay to send a PR to Linus > >> after that? > > > > Sure, will do right away once we resolve what to do with the above, > > and provided you don't have anything else you want me to evaluate for > > inclusion. > > Since we haven't agreed on the __get_user_64() patch yet, I would be > in favor of getting the changes pulled in that have already been > reviewed and acknowledged. I rather don't want the other contributors > to wait any longer. Arnd in particular has done a tremendous job to > untangle all the SH-5 code and I think we should finally get this > in :). Absolutely agreed. Rich
Hi Rich! On 6/5/20 5:59 PM, Rich Felker wrote: >> Ah, sorry, I missed that. You're right, it should probably go through >> someone else's tree then. > > Do you know if it's needed to un-break sh4? If so we should push to > get whoever has jurisdiction over it to include it; otherwise I'm > indifferent. No, the patch is only necessary when enabling Infiniband support with CONFIG_INFINIBAND_USER_ACCESS enabled. However, according to Geert, every architecture is supposed to have 64-bit get_user() these days, therefore my patch is required anyways, but it's not an acute problem. Adrian
Hi Adrian, On Fri, Jun 5, 2020 at 7:58 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > On 6/5/20 5:59 PM, Rich Felker wrote: > >> Ah, sorry, I missed that. You're right, it should probably go through > >> someone else's tree then. > > > > Do you know if it's needed to un-break sh4? If so we should push to > > get whoever has jurisdiction over it to include it; otherwise I'm > > indifferent. I think the above is about the asm-generic/vmlinux.lds.h patch? https://marc.info/?l=linux-sh&m=158429470221261&w=2 That one falls under Arnd's jurisdiction. And AFAIUC, it matters for recent binutils only? So Arnd should know. > No, the patch is only necessary when enabling Infiniband support with > CONFIG_INFINIBAND_USER_ACCESS enabled. > > However, according to Geert, every architecture is supposed to have > 64-bit get_user() these days, therefore my patch is required anyways, > but it's not an acute problem. This is about a different patch. Still a build failure, but who cares about Infiniband? (I still care more about SH ;-) Gr{oetje,eeting}s, Geert
On Fri, 5 Jun 2020 20:23:07 +0200 Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Adrian, > > On Fri, Jun 5, 2020 at 7:58 PM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote: > > On 6/5/20 5:59 PM, Rich Felker wrote: > > >> Ah, sorry, I missed that. You're right, it should probably go through > > >> someone else's tree then. > > > > > > Do you know if it's needed to un-break sh4? If so we should push to > > > get whoever has jurisdiction over it to include it; otherwise I'm > > > indifferent. > > I think the above is about the asm-generic/vmlinux.lds.h patch? > https://marc.info/?l=linux-sh&m=158429470221261&w=2 > > That one falls under Arnd's jurisdiction. > And AFAIUC, it matters for recent binutils only? So Arnd should know. > Aligning RO_AFTER_INIT_DATA is simply a no-brainer: --- a/include/asm-generic/vmlinux.lds.h~include-asm-generic-vmlinuxldsh-align-ro_after_init +++ a/include/asm-generic/vmlinux.lds.h @@ -374,6 +374,7 @@ */ #ifndef RO_AFTER_INIT_DATA #define RO_AFTER_INIT_DATA \ + . = ALIGN(8); \ __start_ro_after_init = .; \ *(.data..ro_after_init) \ JUMP_TABLE_DATA \ So I'll send this in to Linus for 5.8-rc1. And I think I'll add a cc:stable to it, so people can use older kernels with newer toolchains. I still have a few other sh patches sitting here: https://ozlabs.org/~akpm/mmotm/broken-out/sh-clkfwk-remove-r8-r16-r32.patch https://ozlabs.org/~akpm/mmotm/broken-out/sh-remove-call-to-memset-after-dma_alloc_coherent.patch https://ozlabs.org/~akpm/mmotm/broken-out/sh-use-generic-strncpy.patch https://ozlabs.org/~akpm/mmotm/broken-out/sh-add-missing-export_symbol-for-__delay.patch What should I do with those?
The following changes since commit ae83d0b416db002fe95601e7f97f64b59514d936: Linux 5.7-rc2 (2020-04-19 14:35:30 -0700) are available in the Git repository at: git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git tags/sh5-remove for you to fetch changes up to 29e36fbee3be4c13ff6881a275c86d5f68acfa23: sh: remove sh5 support (2020-04-24 22:20:55 +0200) ---------------------------------------------------------------- sh: remove sh5 support At long last, this is the removal of the 64-bit sh5 port that never went into production. Signed-off-by: Arnd Bergmann <arnd@arndb.de> ---------------------------------------------------------------- v2: I should have fixed all the missing changes that Geert pointed out, this time sending it as a pull request as the removal patch is too big for the mailing lists, and a 'git format-patch -D' patch is unreliable Arnd Bergmann (1): sh: remove sh5 support arch/sh/Kconfig | 62 +- arch/sh/Kconfig.cpu | 9 - arch/sh/Kconfig.debug | 13 +- arch/sh/Makefile | 29 +- arch/sh/boot/compressed/Makefile | 12 +- arch/sh/boot/compressed/misc.c | 8 - arch/sh/drivers/pci/Makefile | 1 - arch/sh/drivers/pci/ops-sh5.c | 65 - arch/sh/drivers/pci/pci-sh5.c | 217 --- arch/sh/drivers/pci/pci-sh5.h | 108 -- arch/sh/include/asm/barrier.h | 4 +- arch/sh/include/asm/bitops.h | 26 - arch/sh/include/asm/bl_bit.h | 11 +- arch/sh/include/asm/bl_bit_64.h | 37 - arch/sh/include/asm/bugs.h | 4 - arch/sh/include/asm/cache_insns.h | 12 +- arch/sh/include/asm/cache_insns_64.h | 20 - arch/sh/include/asm/checksum.h | 6 +- arch/sh/include/asm/elf.h | 23 - arch/sh/include/asm/extable.h | 4 - arch/sh/include/asm/fixmap.h | 4 - arch/sh/include/asm/io.h | 4 - arch/sh/include/asm/irq.h | 3 - arch/sh/include/asm/mmu_context.h | 12 - arch/sh/include/asm/mmu_context_64.h | 75 - arch/sh/include/asm/module.h | 4 - arch/sh/include/asm/page.h | 21 +- arch/sh/include/asm/pgtable.h | 17 - arch/sh/include/asm/pgtable_64.h | 307 ---- arch/sh/include/asm/posix_types.h | 6 +- arch/sh/include/asm/processor.h | 14 +- arch/sh/include/asm/processor_64.h | 212 --- arch/sh/include/asm/ptrace_64.h | 14 - arch/sh/include/asm/string.h | 6 +- arch/sh/include/asm/string_64.h | 21 - arch/sh/include/asm/switch_to.h | 11 +- arch/sh/include/asm/switch_to_64.h | 32 - arch/sh/include/asm/syscall.h | 6 +- arch/sh/include/asm/syscall_64.h | 75 - arch/sh/include/asm/syscalls.h | 9 +- arch/sh/include/asm/syscalls_64.h | 18 - arch/sh/include/asm/thread_info.h | 4 +- arch/sh/include/asm/tlb.h | 6 +- arch/sh/include/asm/tlb_64.h | 68 - arch/sh/include/asm/traps.h | 4 - arch/sh/include/asm/traps_64.h | 35 - arch/sh/include/asm/types.h | 5 - arch/sh/include/asm/uaccess.h | 4 - arch/sh/include/asm/uaccess_64.h | 85 - arch/sh/include/asm/unistd.h | 6 +- arch/sh/include/asm/user.h | 7 - arch/sh/include/asm/vmlinux.lds.h | 8 - arch/sh/include/cpu-sh5/cpu/addrspace.h | 12 - arch/sh/include/cpu-sh5/cpu/cache.h | 94 - arch/sh/include/cpu-sh5/cpu/irq.h | 113 -- arch/sh/include/cpu-sh5/cpu/mmu_context.h | 22 - arch/sh/include/cpu-sh5/cpu/registers.h | 103 -- arch/sh/include/cpu-sh5/cpu/rtc.h | 9 - arch/sh/include/uapi/asm/posix_types.h | 8 +- arch/sh/include/uapi/asm/posix_types_64.h | 29 - arch/sh/include/uapi/asm/ptrace.h | 5 - arch/sh/include/uapi/asm/ptrace_64.h | 15 - arch/sh/include/uapi/asm/sigcontext.h | 13 - arch/sh/include/uapi/asm/stat.h | 61 - arch/sh/include/uapi/asm/swab.h | 10 - arch/sh/include/uapi/asm/unistd.h | 8 +- arch/sh/include/uapi/asm/unistd_64.h | 423 ----- arch/sh/kernel/Makefile | 16 +- arch/sh/kernel/cpu/Makefile | 1 - arch/sh/kernel/cpu/init.c | 2 +- arch/sh/kernel/cpu/irq/Makefile | 3 +- arch/sh/kernel/cpu/irq/intc-sh5.c | 194 -- arch/sh/kernel/cpu/proc.c | 1 - arch/sh/kernel/cpu/sh5/Makefile | 16 - arch/sh/kernel/cpu/sh5/clock-sh5.c | 76 - arch/sh/kernel/cpu/sh5/entry.S | 2000 --------------------- arch/sh/kernel/cpu/sh5/fpu.c | 106 -- arch/sh/kernel/cpu/sh5/probe.c | 72 - arch/sh/kernel/cpu/sh5/setup-sh5.c | 121 -- arch/sh/kernel/cpu/sh5/switchto.S | 195 -- arch/sh/kernel/cpu/sh5/unwind.c | 342 ---- arch/sh/kernel/head_64.S | 346 ---- arch/sh/kernel/irq_64.c | 48 - arch/sh/kernel/module.c | 9 - arch/sh/kernel/process.c | 2 - arch/sh/kernel/process_64.c | 461 ----- arch/sh/kernel/ptrace_64.c | 576 ------ arch/sh/kernel/reboot.c | 6 - arch/sh/kernel/sh_ksyms_64.c | 51 - arch/sh/kernel/signal_64.c | 567 ------ arch/sh/kernel/syscalls_64.S | 419 ----- arch/sh/kernel/traps_64.c | 814 --------- arch/sh/kernel/vmlinux.lds.S | 18 +- arch/sh/lib64/Makefile | 17 - arch/sh/lib64/copy_page.S | 89 - arch/sh/lib64/copy_user_memcpy.S | 218 --- arch/sh/lib64/memcpy.S | 202 --- arch/sh/lib64/memset.S | 92 - arch/sh/lib64/panic.c | 15 - arch/sh/lib64/sdivsi3.S | 136 -- arch/sh/lib64/strcpy.S | 98 - arch/sh/lib64/strlen.S | 34 - arch/sh/lib64/udelay.c | 49 - arch/sh/lib64/udivdi3.S | 121 -- arch/sh/lib64/udivsi3.S | 60 - arch/sh/mm/Kconfig | 16 +- arch/sh/mm/Makefile | 31 +- arch/sh/mm/cache-sh5.c | 621 ------- arch/sh/mm/cache.c | 6 - arch/sh/mm/extable_64.c | 84 - arch/sh/mm/tlb-sh5.c | 224 --- arch/sh/mm/tlbex_64.c | 166 -- arch/sh/mm/tlbflush_64.c | 172 -- drivers/rtc/Kconfig | 2 +- fs/Kconfig.binfmt | 2 +- scripts/headers_install.sh | 3 - tools/arch/sh/include/asm/barrier.h | 2 +- 117 files changed, 67 insertions(+), 11554 deletions(-) delete mode 100644 arch/sh/drivers/pci/ops-sh5.c delete mode 100644 arch/sh/drivers/pci/pci-sh5.c delete mode 100644 arch/sh/drivers/pci/pci-sh5.h delete mode 100644 arch/sh/include/asm/bl_bit_64.h delete mode 100644 arch/sh/include/asm/cache_insns_64.h delete mode 100644 arch/sh/include/asm/mmu_context_64.h delete mode 100644 arch/sh/include/asm/pgtable_64.h delete mode 100644 arch/sh/include/asm/processor_64.h delete mode 100644 arch/sh/include/asm/ptrace_64.h delete mode 100644 arch/sh/include/asm/string_64.h delete mode 100644 arch/sh/include/asm/switch_to_64.h delete mode 100644 arch/sh/include/asm/syscall_64.h delete mode 100644 arch/sh/include/asm/syscalls_64.h delete mode 100644 arch/sh/include/asm/tlb_64.h delete mode 100644 arch/sh/include/asm/traps_64.h delete mode 100644 arch/sh/include/asm/uaccess_64.h delete mode 100644 arch/sh/include/cpu-sh5/cpu/addrspace.h delete mode 100644 arch/sh/include/cpu-sh5/cpu/cache.h delete mode 100644 arch/sh/include/cpu-sh5/cpu/irq.h delete mode 100644 arch/sh/include/cpu-sh5/cpu/mmu_context.h delete mode 100644 arch/sh/include/cpu-sh5/cpu/registers.h delete mode 100644 arch/sh/include/cpu-sh5/cpu/rtc.h delete mode 100644 arch/sh/include/uapi/asm/posix_types_64.h delete mode 100644 arch/sh/include/uapi/asm/ptrace_64.h delete mode 100644 arch/sh/include/uapi/asm/unistd_64.h delete mode 100644 arch/sh/kernel/cpu/irq/intc-sh5.c delete mode 100644 arch/sh/kernel/cpu/sh5/Makefile delete mode 100644 arch/sh/kernel/cpu/sh5/clock-sh5.c delete mode 100644 arch/sh/kernel/cpu/sh5/entry.S delete mode 100644 arch/sh/kernel/cpu/sh5/fpu.c delete mode 100644 arch/sh/kernel/cpu/sh5/probe.c delete mode 100644 arch/sh/kernel/cpu/sh5/setup-sh5.c delete mode 100644 arch/sh/kernel/cpu/sh5/switchto.S delete mode 100644 arch/sh/kernel/cpu/sh5/unwind.c delete mode 100644 arch/sh/kernel/head_64.S delete mode 100644 arch/sh/kernel/irq_64.c delete mode 100644 arch/sh/kernel/process_64.c delete mode 100644 arch/sh/kernel/ptrace_64.c delete mode 100644 arch/sh/kernel/sh_ksyms_64.c delete mode 100644 arch/sh/kernel/signal_64.c delete mode 100644 arch/sh/kernel/syscalls_64.S delete mode 100644 arch/sh/kernel/traps_64.c delete mode 100644 arch/sh/lib64/Makefile delete mode 100644 arch/sh/lib64/copy_page.S delete mode 100644 arch/sh/lib64/copy_user_memcpy.S delete mode 100644 arch/sh/lib64/memcpy.S delete mode 100644 arch/sh/lib64/memset.S delete mode 100644 arch/sh/lib64/panic.c delete mode 100644 arch/sh/lib64/sdivsi3.S delete mode 100644 arch/sh/lib64/strcpy.S delete mode 100644 arch/sh/lib64/strlen.S delete mode 100644 arch/sh/lib64/udelay.c delete mode 100644 arch/sh/lib64/udivdi3.S delete mode 100644 arch/sh/lib64/udivsi3.S delete mode 100644 arch/sh/mm/cache-sh5.c delete mode 100644 arch/sh/mm/extable_64.c delete mode 100644 arch/sh/mm/tlb-sh5.c delete mode 100644 arch/sh/mm/tlbex_64.c delete mode 100644 arch/sh/mm/tlbflush_64.c