LinuxLists.cc - [GIT PULL] sh: remove sh5 support

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-28 05:48:06

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-28 05:58:15

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-05-28 09:42:50

by Rob Landley

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-28 16:16:36

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-28 22:19:18

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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.

2020-05-28 22:30:58

by Rob Landley

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-28 22:36:44

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-05-28 22:41:58

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-29 14:33:16

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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.

2020-05-29 14:37:36

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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.

2020-05-29 17:58:10

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-29 18:26:54

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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.

2020-05-30 08:10:33

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-05-30 08:49:33

by Geert Uytterhoeven

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

On Sat, May 30, 2020 at 10:08 AM John Paul Adrian Glaubitz
<[email protected]> 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

--
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

2020-05-31 03:23:37

by Rob Landley

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-05-31 08:06:36

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-06-01 02:57:41

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-06-01 08:18:47

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-06-01 18:43:46

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-06-01 21:15:07

by Arnd Bergmann

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

On Mon, Jun 1, 2020 at 8:13 PM Rich Felker <[email protected]> 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

2020-06-02 01:36:34

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-06-02 02:53:44

by Andrew Morton

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

On Mon, 1 Jun 2020 21:33:32 -0400 Rich Felker <[email protected]> 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.

2020-06-02 02:55:29

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

On Mon, Jun 01, 2020 at 07:49:36PM -0700, Andrew Morton wrote:
> On Mon, 1 Jun 2020 21:33:32 -0400 Rich Felker <[email protected]> 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

2020-06-03 07:30:12

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-06-03 07:34:12

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-06-05 15:42:48

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-06-05 15:46:27

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-06-05 15:50:43

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2020-06-05 16:04:29

[permalink] [raw]

Subject: Re: [GIT PULL] sh: remove sh5 support

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

2020-06-05 18:01:12