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

[Arnd Bergmann]

On Tue, Nov 2, 2021 at 12:05 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>

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@xxxxxxxxxxxxxx/
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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx 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