Re: [RFC PATCH] ARM: s3c: mark as deprecated and schedule removal after 2022

Arnd Bergmann
2021-11-02T13:06:20Z

On Tue, Nov 2, 2021 at 12:05 PM Krzysztof Kozlowski
<krzysztof.kozlowski@canonical.com> wrote:
>
> The Samsung S3C24xx and S3C64xx platforms are very old designs. S3C2416
> was introduced in 2008 and S3C6410 in 2009/2010. They are not widely
> available anymore - out-of-stock on FriendlyArm (one of manufacturers of
> boards) and only few specialist stores still offer them for quite a high
> price.
>
> The community around these platforms was not very active, so I suspect
> no one really uses them anymore. Maintenance takes precious time so
> there is little sense in keeping them alive if there are no real users.
>
> Let's mark all S3C24xx and S3C64xx platforms as deprecated and mention
> possible removal in one year (after 2022). The deprecation message will
> be as text in Kconfig, build message (not a warning though) and runtime
> print error.
>
> If there are any users, they might respond and postpone the removal.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>

Looks good to me.

We have a couple of platforms that are in a similar state, and we could do
the same there. I'd have to dig through
https://lore.kernel.org/linux-arm-kernel/CAK8P3a2VW8T+yYUG1pn1yR-5eU4jJXe1+M_ot6DAvfr2KyXCzQ@mail.gmail.com/
to see which ones promised to get back to working on the code and
ended up not doing so. ;-)

The ones that would help the most in removing are probably omap1,
pxa, and the strongarm-based platforms: those have a lot of special
cases in the code base. At least a year ago the maintainers wanted
to keep those around, but maybe the 2022 LTS kernel is a better
time for planned EOL. I also still have a backlog of cleanup patches
for omap1 and pxa (similar to the s3c24xx changes I did) that we
should get mainlined if we want to keep them around after all.

At some point later we can also seriously look into removing all
non-DT machine support, which would impact all of these:

$ git grep -w MACHINE_START arch/arm/mach-* | cut -f 3 -d/ | uniq -c
1 mach-cns3xxx
12 mach-davinci
2 mach-dove
19 mach-ep93xx
3 mach-footbridge
6 mach-iop32x
2 mach-ixp4xx
10 mach-mmp
3 mach-mv78xx0
14 mach-omap1
17 mach-orion5x
62 mach-pxa
1 mach-rpc
36 mach-s3c
13 mach-sa1100

> +#pragma message "The platform is deprecated and scheduled in removal (see platform help). " \
> + "Please reach to the maintainers of the platform " \
> + "and linux-samsung-soc@vger.kernel.org if you still use it." \
> + "Without such feedback, the platform will be removed after 2022."
> diff --git a/arch/arm/mach-s3c/s3c64xx.c b/arch/arm/mach-s3c/s3c64xx.c
> index 4dfb648142f2..3e248f0e96a2 100644
> --- a/arch/arm/mach-s3c/s3c64xx.c
> +++ b/arch/arm/mach-s3c/s3c64xx.c
> @@ -425,3 +425,8 @@ static int __init s3c64xx_init_irq_eint(void)
> return 0;
> }
> arch_initcall(s3c64xx_init_irq_eint);
> +
> +#pragma message "The platform is deprecated and scheduled in removal (see platform help). " \
> + "Please reach to the maintainers of the platform " \
> + "and linux-samsung-soc@vger.kernel.org if you still use it." \
> + "Without such feedback, the platform will be removed after 2022."

I don't want these to clutter up my randconfig build output, which I keep
completely empty by default. If you add an

#ifndef CONFIG_COMPILE_TEST

check around them, I'm fine with it though -- it would still catch all
real users
without bothering build-testing bots.
I think even with CONFIG_WERROR, we don't fail the build for #warning,
so that would also work in place of #pragma message.

Arnd