All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yoshinori Sato <ysato@users.sourceforge.jp>
To: Rich Felker <dalias@libc.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Adam Borowski <kilobyte@angband.pl>,
	Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] remove arch/sh?
Date: Fri, 05 Jul 2019 22:51:55 +0900	[thread overview]
Message-ID: <87a7ds4mis.wl-ysato@users.sourceforge.jp> (raw)
In-Reply-To: <20190626153820.GP1506@brightrain.aerifal.cx>

On Thu, 27 Jun 2019 00:38:21 +0900,
Rich Felker wrote:
> 
> On Wed, Jun 26, 2019 at 08:25:20PM +0900, Yoshinori Sato wrote:
> > On Wed, 26 Jun 2019 00:48:09 +0900,
> > Arnd Bergmann wrote:
> > > 
> > > On Tue, Jun 25, 2019 at 4:28 PM Rich Felker <dalias@libc.org> wrote:
> > > > On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> > > > > don't build, or are incomplete and not worked on for a long
> > > > > time, compared to the bits that are known to work and that someone
> > > > > is still using or at least playing with.
> > > > > I guess a lot of the SoCs that have no board support other than
> > > > > the Hitachi/Renesas reference platform can go away too, as any products
> > > > > based on those boards have long stopped updating their kernels.
> > > >
> > > > My intent here was always, after getting device tree theoretically
> > > > working for some reasonable subset of socs/boards, drop the rest and
> > > > add them back as dts files (possibly plus some small drivers) only if
> > > > there's demand/complaint about regression.
> > > 
> > > Do you still think that this is a likely scenario for the future though?
> > > 
> > > If nobody's actively working on the DT support for the old chips and
> > > this is unlikely to change soon, removing the known-broken bits earlier
> > > should at least make it easier to keep maintaining the working bits
> > > afterwards.
> > > 
> > > FWIW, I went through the SH2, SH2A and SH3 based boards that
> > > are supported in the kernel and found almost all of them to
> > > be just reference platforms, with no actual product ever merged.
> > > IIRC the idea back then was that users would supply their
> > > own board files as an add-on patch, but I would consider all the
> > > ones that did to be obsolete now.
> > > 
> > > HP Jornada 6xx is the main machine that was once supported, but
> > > given that according to the defconfig file it only comes with 4MB
> > > of RAM, it is unlikely to still boot any 5.x kernel, let alone user
> > > space (wikipedia claims there were models with 16MB of RAM,
> > > but that is still not a lot these days).
> > > 
> > > "Magicpanel" was another product that is supported in theory, but
> > > the google search showed the 2007 patch for the required
> > > flash storage driver that was never merged.
> > > 
> > > Maybe everything but J2 and SH4(a) can just get retired?
> > > 
> > >      Arnd
> > 
> > I also have some boards, so it's possible to rewrite more.
> > I can not rewrite the target I do not have, so I think that
> > there is nothing but to retire.
> 
> To clarify, are you agreeing with Arnd's suggestion to retire/remove
> everything but jcore and sh4[a]?
> 
> Rich

I have SH2/2A/3 target board.
So can mantain CPU support.
But with board support it will be difficult.
I would like to make the transition to a common framework.
I also have to fix the parts that depend on each board for migration,
so I would like to limit the target for maintenance to only those
that can be used now.

-- 
Yosinori Sato

WARNING: multiple messages have this Message-ID (diff)
From: Yoshinori Sato <ysato@users.sourceforge.jp>
To: Rich Felker <dalias@libc.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Adam Borowski <kilobyte@angband.pl>,
	Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] remove arch/sh?
Date: Fri, 05 Jul 2019 13:51:55 +0000	[thread overview]
Message-ID: <87a7ds4mis.wl-ysato@users.sourceforge.jp> (raw)
In-Reply-To: <20190626153820.GP1506@brightrain.aerifal.cx>

On Thu, 27 Jun 2019 00:38:21 +0900,
Rich Felker wrote:
> 
> On Wed, Jun 26, 2019 at 08:25:20PM +0900, Yoshinori Sato wrote:
> > On Wed, 26 Jun 2019 00:48:09 +0900,
> > Arnd Bergmann wrote:
> > > 
> > > On Tue, Jun 25, 2019 at 4:28 PM Rich Felker <dalias@libc.org> wrote:
> > > > On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> > > > > don't build, or are incomplete and not worked on for a long
> > > > > time, compared to the bits that are known to work and that someone
> > > > > is still using or at least playing with.
> > > > > I guess a lot of the SoCs that have no board support other than
> > > > > the Hitachi/Renesas reference platform can go away too, as any products
> > > > > based on those boards have long stopped updating their kernels.
> > > >
> > > > My intent here was always, after getting device tree theoretically
> > > > working for some reasonable subset of socs/boards, drop the rest and
> > > > add them back as dts files (possibly plus some small drivers) only if
> > > > there's demand/complaint about regression.
> > > 
> > > Do you still think that this is a likely scenario for the future though?
> > > 
> > > If nobody's actively working on the DT support for the old chips and
> > > this is unlikely to change soon, removing the known-broken bits earlier
> > > should at least make it easier to keep maintaining the working bits
> > > afterwards.
> > > 
> > > FWIW, I went through the SH2, SH2A and SH3 based boards that
> > > are supported in the kernel and found almost all of them to
> > > be just reference platforms, with no actual product ever merged.
> > > IIRC the idea back then was that users would supply their
> > > own board files as an add-on patch, but I would consider all the
> > > ones that did to be obsolete now.
> > > 
> > > HP Jornada 6xx is the main machine that was once supported, but
> > > given that according to the defconfig file it only comes with 4MB
> > > of RAM, it is unlikely to still boot any 5.x kernel, let alone user
> > > space (wikipedia claims there were models with 16MB of RAM,
> > > but that is still not a lot these days).
> > > 
> > > "Magicpanel" was another product that is supported in theory, but
> > > the google search showed the 2007 patch for the required
> > > flash storage driver that was never merged.
> > > 
> > > Maybe everything but J2 and SH4(a) can just get retired?
> > > 
> > >      Arnd
> > 
> > I also have some boards, so it's possible to rewrite more.
> > I can not rewrite the target I do not have, so I think that
> > there is nothing but to retire.
> 
> To clarify, are you agreeing with Arnd's suggestion to retire/remove
> everything but jcore and sh4[a]?
> 
> Rich

I have SH2/2A/3 target board.
So can mantain CPU support.
But with board support it will be difficult.
I would like to make the transition to a common framework.
I also have to fix the parts that depend on each board for migration,
so I would like to limit the target for maintenance to only those
that can be used now.

-- 
Yosinori Sato

  parent reply	other threads:[~2019-07-05 13:51 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25  8:56 [RFC] remove arch/sh? Christoph Hellwig
2019-06-25  8:56 ` Christoph Hellwig
2019-06-25  9:02 ` John Paul Adrian Glaubitz
2019-06-25  9:02   ` John Paul Adrian Glaubitz
2019-06-25 11:21   ` Adam Borowski
2019-06-25 11:21     ` Adam Borowski
2019-06-25 12:02     ` John Paul Adrian Glaubitz
2019-06-25 12:02       ` John Paul Adrian Glaubitz
2019-06-25 12:50       ` Arnd Bergmann
2019-06-25 12:50         ` Arnd Bergmann
2019-06-25 14:28         ` Rich Felker
2019-06-25 14:28           ` Rich Felker
2019-06-25 15:48           ` Arnd Bergmann
2019-06-25 15:48             ` Arnd Bergmann
2019-06-26 11:25             ` Yoshinori Sato
2019-06-26 11:25               ` Yoshinori Sato
2019-06-26 15:38               ` Rich Felker
2019-06-26 15:38                 ` Rich Felker
2019-06-26 15:56                 ` John Paul Adrian Glaubitz
2019-06-26 15:56                   ` John Paul Adrian Glaubitz
2019-07-05 13:51                 ` Yoshinori Sato [this message]
2019-07-05 13:51                   ` Yoshinori Sato
2019-07-05 14:04                   ` John Paul Adrian Glaubitz
2019-07-05 14:04                     ` John Paul Adrian Glaubitz
2019-07-05 15:14                   ` Rich Felker
2019-07-05 15:14                     ` Rich Felker
2019-06-25 14:21   ` Rich Felker
2019-06-25 14:21     ` Rich Felker
2019-06-25 14:23     ` Christoph Hellwig
2019-06-25 14:23       ` Christoph Hellwig
2019-06-25 14:29       ` Rich Felker
2019-06-25 14:29         ` Rich Felker
2019-06-25 14:31         ` John Paul Adrian Glaubitz
2019-06-25 14:31           ` John Paul Adrian Glaubitz

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=87a7ds4mis.wl-ysato@users.sourceforge.jp \
    --to=ysato@users.sourceforge.jp \
    --cc=arnd@arndb.de \
    --cc=dalias@libc.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=hch@lst.de \
    --cc=kilobyte@angband.pl \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.