LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Gerhard Pircher <gerhard_pircher@gmx.net>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Sparc kernel list <sparclinux@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: Old platforms: bring out your dead
Date: Thu, 14 Jan 2021 22:21:10 +0100
Message-ID: <CAK8P3a1+SdAW8VKnvMdXNVcpR-ykNdPoqLqb59uxzB+jNFJRtg@mail.gmail.com> (raw)
In-Reply-To: <1be37673-db0e-f09d-68c8-f929be4019ab@physik.fu-berlin.de>

On Thu, Jan 14, 2021 at 10:43 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On 1/12/21 11:46 PM, Linus Walleij wrote:
> > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote:
> > This is actually one of the most interesting things written in this discussion.
> >
> > I have both revamped and deleted subarchitectures in the ARM tree. We
> > never deleted anyone's pet project *unless* they were clearly unwilling to
> > work on it (such as simply testning new patches) and agreed that it will
> > not go on.
>
> I'm not arguing this. This was more about killing (sub-)architectures because they
> haven't seen git activity for a long time which I think is poor metric to determine
> whether a port is dead or not. And reading through the other answers in this thread,
> it seems I'm not alone with this stance.

I think it's mainly a misunderstanding of what I am trying to do
in finding the platforms that have been completely abandoned.
There are now eight platforms on the list that are unmaintained
and have no known users. All of them were actively getting patched
and tested in the past as can be easily seen from the changelog,
but then the maintainers stopped sending patches five years or
longer ago, which indicates that something changed: either the platform
port was now perfect and has been working fine ever since
(e.g. highbank, digicolor, nspire, ...), or the maintainers (or rather
their employers) gave up and never continued the job (picoxcell,
prima2, efm32, ...).

I can usually guess which one is the case, but the only way to be
sure is to ask, which is what I did in that email.

> > 3. Migrate old systems to use the
> >    contemporary hardware descriptions (such as device tree or ACPI)
> >    because it makes things so much easier to maintain. Some
> >    upfront work, but a great win for everyone. Especially for
> >    subsystem maintainers.
>
> There is such a patch set for arch/sh to add device tree support, but so far it has not
> been merged yet, unfortunately. Apparently, it causes some regression on LANDISK devices
> according to Rich Felker.
>
> Maybe we can finally get it merged this year:
>
> > https://lore.kernel.org/patchwork/cover/693910/
>
> Since Geert also has a LANDISK SH device now for testing, he might be able to help.

Doing a proper device tree conversion for arch/sh/ is a huge task,
so unless someone is going to work on that full-time for a while,
I don't see this going anywhere. If nobody has even rebased that
patch series in the past five years, it's fairly unlikely that they will
do it soon.

One of the bigger problems is converting to CONFIG_COMMON_CLK,
as was done for one of the simpler chips in the patch series you
reference above.

> > And if your arch uses highmem then please get rid of highmem. I'm
> > trying to do this a bit right now for ARM let's see how it goes.
>
> Is there a list of architectures which still need highmem?

These are the architectures that currently allow highmem:

| arch/arm/Kconfig:config HIGHMEM

We're working on CONFIG_VMSPLIT_4G_4G as a replacement
to keep ARMv7VE based platforms working after highmem gets
removed, and possibly use ZSWAP to help platforms for
which this is not enough. There are a few users on ARMV7VE
with more than 4GB (keystone2, highbank, armadaxp, some
broadcom STB SoCs) or ARMv7-A with more than 2GB (imx6q,
tegra3), but those memory configurations were shipped in
minute quantities compared to smaller memory versions of the
same boards, so the plan is to wait until the known users have
all stopped needing kernel updates, possibly around 2025.

| arch/arc/Kconfig:config HIGHMEM
| arch/microblaze/Kconfig:config HIGHMEM

I don't think we have upstream support for platforms with a need for
highmem, but these are both used in deeply embedded systems
that tend to not follow mainline kernels. Also, both have hardware
support for 64-bit cores, which I guess will be used in the future
on systems that have more than a gigabyte of RAM.

| arch/csky/Kconfig:config HIGHMEM
| arch/nds32/Kconfig.cpu:config HIGHMEM

These were only merged fairly recently, and as far as I can
tell, highmem support was mainly added for the purpose of
completeness, not because of actual user requirements.
Both architectures are getting replaced with RV64 cores from
the respective companies (Andes and C-Sky/T-Head).

| arch/powerpc/Kconfig:config HIGHMEM
| arch/sparc/Kconfig:config HIGHMEM
| arch/x86/Kconfig:config HIGHMEM

Highmem was used extensively on these in the past, but mainly
on older machines. Most o the x86 users here would already
be on 64-bit hardware and can just change their kernels to
x86-64, but 32-bit machines from around 2004 to 2006
on both powerpc and x86, as well as some older servers, are
likely to lose some of their memory or may have to use ZSWAP
instead.

| arch/mips/Kconfig:config HIGHMEM
| arch/xtensa/Kconfig:config HIGHMEM

AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
tricks won't work. OTOH, most mips platforms that support
highmem are on older 64-bit cores and can probably move to
64-bit kernels as well, but some can not (ingenic xburst,
loongson1, bmips, ...)

P5600 (Baikal-T1) is often used with 4GB or at most 8GB on
desktops, this will be interesting to migrate. Since it's MIPS32r5,
this may use more than 512MB of lowmem with some tricks that
need to be implemented.

Most of the embedded MIPS32 ones support less than those 512MB
of RAM and are not affected.

I have no idea who uses xtensa systems with lots of memory on
modern kernels.




      Arnd

  parent reply index

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 22:55 Arnd Bergmann
2021-01-08 23:32 ` Steven Rostedt
2021-01-09 22:04   ` Arnd Bergmann
2021-01-08 23:44 ` Thomas Bogendoerfer
2021-01-09  0:16 ` Linus Walleij
2021-01-09 17:32   ` Florian Fainelli
2021-01-09 21:59   ` Arnd Bergmann
2021-01-09  5:56 ` Willy Tarreau
2021-01-09 21:52   ` Arnd Bergmann
2021-01-10  6:21     ` Willy Tarreau
2021-01-10 10:44       ` Russell King - ARM Linux admin
2021-01-11  9:50     ` David Laight
2021-01-13 10:27       ` Andy Shevchenko
2021-01-13 12:02         ` Linus Walleij
2021-01-13 12:17           ` Andy Shevchenko
2021-01-13 12:21             ` Andy Shevchenko
2021-01-15  0:03               ` Bernd Petrovitsch
2021-01-15  0:24                 ` William Breathitt Gray
2021-01-15  8:59                   ` David Laight
2021-01-13 12:30           ` William Breathitt Gray
2021-01-13 12:56             ` William Breathitt Gray
2021-01-13 13:44           ` Arnd Bergmann
2021-02-04 21:01         ` Pavel Machek
2021-02-05  9:13           ` David Laight
2021-02-05  9:29             ` Pavel Machek
2021-01-09 17:34 ` Florian Fainelli
2021-01-09 21:18   ` Arnd Bergmann
2021-01-09 17:43 ` Russell King - ARM Linux admin
2021-01-09 21:34   ` Arnd Bergmann
2021-01-11 20:09     ` Russell King - ARM Linux admin
2021-01-09 20:19 ` Baruch Siach
2021-01-09 21:19   ` Arnd Bergmann
     [not found] ` <67171E13-6786-4B44-A8C2-3302963B055F@gmail.com>
2021-01-09 22:20   ` Arnd Bergmann
2021-01-10 18:12     ` Fabian Vogt
2021-01-10 19:20       ` Arnd Bergmann
2021-01-10 21:33       ` Linus Walleij
2021-01-11  0:33         ` Russell King - ARM Linux admin
2021-01-11 12:32           ` Arnd Bergmann
2021-01-11 12:36             ` Russell King - ARM Linux admin
2021-01-09 23:12 ` Andrew Lunn
2021-01-10  8:45   ` Arnd Bergmann
2021-01-10 16:46     ` Andrew Lunn
2021-01-10 17:27       ` Arnd Bergmann
2021-01-10 19:51         ` Andrew Lunn
2021-01-10 15:51 ` Neil Armstrong
2021-01-10 15:56   ` Arnd Bergmann
2021-01-10 17:35 ` John Paul Adrian Glaubitz
2021-01-10 21:46   ` Sam Ravnborg
2021-01-11  8:05     ` John Paul Adrian Glaubitz
2021-01-11 14:55       ` chase rayfield
2021-01-12  0:26         ` Rob Landley
2021-01-12  0:50           ` chase rayfield
2021-01-12 14:37         ` John Paul Adrian Glaubitz
2021-01-11 18:09     ` Rob Landley
2021-01-11 15:04   ` Gerhard Pircher
2021-01-12 14:44     ` John Paul Adrian Glaubitz
2021-01-12 22:46       ` Linus Walleij
2021-01-13  8:09         ` Rob Landley
2021-01-13  8:21           ` Geert Uytterhoeven
2021-01-13 13:25             ` Rob Landley
2021-01-13 12:02           ` Andy Shevchenko
2021-01-13  8:15         ` Geert Uytterhoeven
2021-01-13 10:39         ` Arnd Bergmann
2021-01-14  3:54           ` New platforms: bring out your dead, was " Finn Thain
2021-01-14  9:41         ` John Paul Adrian Glaubitz
2021-01-14  9:48           ` Geert Uytterhoeven
2021-01-14 21:21           ` Arnd Bergmann [this message]
2021-01-14 22:54             ` Undesirable code, was Re: Old platforms etc Finn Thain
2021-01-14 23:09             ` Old platforms: bring out your dead Max Filippov
2021-01-15  8:31               ` Arnd Bergmann
2021-01-13  0:12       ` Old platforms never die, was " Finn Thain
2021-01-16  6:54         ` Rob Landley
2021-01-16 23:22           ` Finn Thain
2021-01-13 11:47       ` Andy Shevchenko
2021-01-11  1:39 ` Daniel Palmer
2021-01-11  9:15   ` John Paul Adrian Glaubitz
2021-01-11  9:20     ` Geert Uytterhoeven
2021-01-11  9:26       ` John Paul Adrian Glaubitz
2021-01-11  9:36         ` Geert Uytterhoeven
2021-01-11  9:50           ` Greg Ungerer
2021-01-11  9:42     ` Daniel Palmer
2021-01-11 10:13   ` Arnd Bergmann
2021-01-11  8:19 ` Geert Uytterhoeven
2021-01-11  8:59   ` Arnd Bergmann
2021-01-11  9:16     ` Geert Uytterhoeven
2021-01-11 10:28       ` Geert Uytterhoeven
2021-01-11 10:37         ` Arnd Bergmann
2021-01-11  9:40     ` Thomas Bogendoerfer
2021-01-11 10:34       ` Arnd Bergmann
2021-01-11  8:40 ` efm32 is dead [Was: Old platforms: bring out your dead] Uwe Kleine-König
2021-01-11 11:10 ` Old platforms: bring out your dead Viresh Kumar
2021-01-11 19:59   ` Arnd Bergmann
2021-01-11 21:15     ` Mattias Wallin
2021-01-11 21:47       ` Arnd Bergmann
2021-01-11 13:13 ` Marc Gonzalez
2021-01-11 17:29   ` Måns Rullgård
2021-01-11 21:50     ` Arnd Bergmann
2021-01-12  8:23       ` Marc Gonzalez
2021-01-11 14:22 ` Mark Salter
2021-01-11 15:00   ` Arnd Bergmann
2021-01-11 14:44 ` Alexander Shiyan
2021-01-11 14:58   ` Arnd Bergmann
2021-01-11 16:23 ` Sylvain Lemieux
2021-01-11 22:17   ` Alexandre Belloni
2021-01-11 19:58 ` Thomas Petazzoni
2021-01-11 20:10   ` Arnd Bergmann
2021-01-11 20:25 ` Song Bao Hua (Barry Song)
2021-01-12  8:41   ` Marc Gonzalez
2021-01-13 10:30 ` Andy Shevchenko
2021-01-13 11:02   ` Arnd Bergmann
2021-01-13 16:14 ` [v2] " Arnd Bergmann
2021-01-13 19:00   ` Krzysztof Hałasa
2021-01-14  8:51     ` Arnd Bergmann
2021-01-15  7:08   ` Wei Xu
2021-01-15  9:26     ` Arnd Bergmann
2021-01-15 11:09       ` Leizhen (ThunderTown)
2021-01-15 12:04         ` Arnd Bergmann
2021-01-18 10:46           ` Wei Xu
2021-01-13 22:27 ` Richard Z
2021-02-05 13:37 ` Alexander Lobakin
2021-01-12  2:05 tedheadster

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=CAK8P3a1+SdAW8VKnvMdXNVcpR-ykNdPoqLqb59uxzB+jNFJRtg@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=arnd@arndb.de \
    --cc=gerhard_pircher@gmx.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=sparclinux@vger.kernel.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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git