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
