From: Rich Felker <dalias@libc.org> To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Christoph Hellwig <hch@infradead.org>, Arnd Bergmann <arnd@arndb.de>, linux-sh@vger.kernel.org, ysato@users.sourceforge.jp, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, Rob Landley <rob@landley.net>, Geert Uytterhoeven <geert@linux-m68k.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [GIT PULL] sh: remove sh5 support Date: Thu, 28 May 2020 22:37:23 +0000 [thread overview] Message-ID: <20200528223723.GJ1079@brightrain.aerifal.cx> (raw) In-Reply-To: <a2fd7d94-2610-476a-a06a-5a058956db56@physik.fu-berlin.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: Rich Felker <dalias@libc.org> To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Christoph Hellwig <hch@infradead.org>, Arnd Bergmann <arnd@arndb.de>, linux-sh@vger.kernel.org, ysato@users.sourceforge.jp, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, Rob Landley <rob@landley.net>, Geert Uytterhoeven <geert@linux-m68k.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [GIT PULL] sh: remove sh5 support Date: Thu, 28 May 2020 18:37:23 -0400 [thread overview] Message-ID: <20200528223723.GJ1079@brightrain.aerifal.cx> (raw) In-Reply-To: <a2fd7d94-2610-476a-a06a-5a058956db56@physik.fu-berlin.de> 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
next prev parent reply other threads:[~2020-05-28 22:37 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-24 22:19 [GIT PULL] sh: remove sh5 support Arnd Bergmann 2020-04-24 22:19 ` Arnd Bergmann 2020-04-24 22:19 ` [PATCH 1/1] " Arnd Bergmann 2020-04-24 22:19 ` Arnd Bergmann 2020-05-07 14:35 ` [GIT PULL] " Christoph Hellwig 2020-05-07 14:35 ` Christoph Hellwig 2020-05-28 5:46 ` Christoph Hellwig 2020-05-28 5:46 ` Christoph Hellwig 2020-05-28 5:55 ` John Paul Adrian Glaubitz 2020-05-28 5:55 ` John Paul Adrian Glaubitz 2020-05-28 9:40 ` Rob Landley 2020-05-28 9:40 ` Rob Landley 2020-05-28 16:14 ` Rich Felker 2020-05-28 16:14 ` Rich Felker 2020-05-28 22:14 ` Rich Felker 2020-05-28 22:14 ` Rich Felker 2020-05-28 22:28 ` Rob Landley 2020-05-28 22:28 ` Rob Landley 2020-05-28 22:32 ` John Paul Adrian Glaubitz 2020-05-28 22:32 ` John Paul Adrian Glaubitz 2020-05-28 22:37 ` Rich Felker [this message] 2020-05-28 22:37 ` Rich Felker 2020-05-29 14:35 ` Christoph Hellwig 2020-05-29 14:35 ` Christoph Hellwig 2020-05-29 14:30 ` Christoph Hellwig 2020-05-29 14:30 ` Christoph Hellwig 2020-05-29 17:53 ` Rich Felker 2020-05-29 17:53 ` Rich Felker 2020-05-29 18:22 ` Christoph Hellwig 2020-05-29 18:22 ` Christoph Hellwig 2020-05-30 8:08 ` John Paul Adrian Glaubitz 2020-05-30 8:08 ` John Paul Adrian Glaubitz 2020-05-30 8:47 ` Geert Uytterhoeven 2020-05-30 8:47 ` Geert Uytterhoeven 2020-05-31 3:20 ` Rob Landley 2020-05-31 3:20 ` Rob Landley 2020-05-31 8:03 ` John Paul Adrian Glaubitz 2020-05-31 8:03 ` John Paul Adrian Glaubitz 2020-06-01 2:55 ` Rich Felker 2020-06-01 2:55 ` Rich Felker 2020-06-01 8:16 ` John Paul Adrian Glaubitz 2020-06-01 8:16 ` John Paul Adrian Glaubitz 2020-06-01 18:13 ` Rich Felker 2020-06-01 18:13 ` Rich Felker 2020-06-01 21:12 ` Arnd Bergmann 2020-06-01 21:12 ` Arnd Bergmann 2020-06-02 1:33 ` Rich Felker 2020-06-02 1:33 ` Rich Felker 2020-06-02 2:49 ` Andrew Morton 2020-06-02 2:49 ` Andrew Morton 2020-06-02 2:53 ` Rich Felker 2020-06-02 2:53 ` Rich Felker 2020-06-03 7:27 ` John Paul Adrian Glaubitz 2020-06-03 7:27 ` John Paul Adrian Glaubitz 2020-06-03 7:31 ` John Paul Adrian Glaubitz 2020-06-03 7:31 ` John Paul Adrian Glaubitz 2020-06-05 15:38 ` John Paul Adrian Glaubitz 2020-06-05 15:38 ` John Paul Adrian Glaubitz 2020-06-05 15:43 ` Rich Felker 2020-06-05 15:43 ` Rich Felker 2020-06-05 15:47 ` John Paul Adrian Glaubitz 2020-06-05 15:47 ` John Paul Adrian Glaubitz 2020-06-05 15:59 ` Rich Felker 2020-06-05 15:59 ` Rich Felker 2020-06-05 17:58 ` John Paul Adrian Glaubitz 2020-06-05 17:58 ` John Paul Adrian Glaubitz 2020-06-05 18:23 ` Geert Uytterhoeven 2020-06-05 18:23 ` Geert Uytterhoeven 2020-06-06 0:50 ` Andrew Morton 2020-06-06 0:50 ` Andrew Morton
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200528223723.GJ1079@brightrain.aerifal.cx \ --to=dalias@libc.org \ --cc=arnd@arndb.de \ --cc=geert@linux-m68k.org \ --cc=glaubitz@physik.fu-berlin.de \ --cc=hch@infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=rob@landley.net \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --cc=ysato@users.sourceforge.jp \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.