All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.