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

[Krzysztof Kozlowski]

On 02/11/2021 14:05, Arnd Bergmann wrote:
> On Tue, Nov 2, 2021 at 12:05 PM Krzysztof Kozlowski
> <krzysztof.kozlowski at 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 at 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.

If the maintainers or users expressed wish to keep them alive, let's
keep them. In fact there might be some industrial machine working for 20
more years...

If you did not receive any feedback about your queries, I am happy to
add similar deprecation-warning notes to these as well. Just let me know
which one should be affected.

> 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 at 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 at 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 like that idea, I'll use it in v2. No one really should build a real
config with COMPILE_TEST and I want to nag and find the real users.

> I think even with CONFIG_WERROR, we don't fail the build for #warning,
> so that would also work in place of #pragma message.

It fails, I tried it. That's why #pragma.

Best regards,
Krzysztof