From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@armlinux.org.uk>, Linus Walleij <linus.walleij@linaro.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" <linux-samsung-soc@vger.kernel.org>, Olof Johansson <olof@lixom.net>, Kukjin Kim <kgene@kernel.org>, Marek Szyprowski <m.szyprowski@samsung.com>, Sylwester Nawrocki <snawrocki@kernel.org>, Tomasz Figa <tomasz.figa@gmail.com>, Chanwoo Choi <cw00.choi@samsung.com>, Inki Dae <inki.dae@samsung.com>, Cedric Roux <sed@free.fr>, Sam Van Den Berge <sam.van.den.berge@telenet.be>, Lihua Yao <ylhuajnu@outlook.com>, Heiko Stuebner <heiko@sntech.de> Subject: Re: [RFC PATCH] ARM: s3c: mark as deprecated and schedule removal after 2022 Date: Tue, 2 Nov 2021 15:55:26 +0100 [thread overview] Message-ID: <ee51e10d-0fbf-d87f-aa98-a95d97a7e437@canonical.com> (raw) In-Reply-To: <CAK8P3a0KqS-OZoo46ajfaXw1aFXR9HouW2ZezKRWCawMa7yuGA@mail.gmail.com> On 02/11/2021 14:05, Arnd Bergmann wrote: > 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. 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@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 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
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@armlinux.org.uk>, Linus Walleij <linus.walleij@linaro.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" <linux-samsung-soc@vger.kernel.org>, Olof Johansson <olof@lixom.net>, Kukjin Kim <kgene@kernel.org>, Marek Szyprowski <m.szyprowski@samsung.com>, Sylwester Nawrocki <snawrocki@kernel.org>, Tomasz Figa <tomasz.figa@gmail.com>, Chanwoo Choi <cw00.choi@samsung.com>, Inki Dae <inki.dae@samsung.com>, Cedric Roux <sed@free.fr>, Sam Van Den Berge <sam.van.den.berge@telenet.be>, Lihua Yao <ylhuajnu@outlook.com>, Heiko Stuebner <heiko@sntech.de> Subject: Re: [RFC PATCH] ARM: s3c: mark as deprecated and schedule removal after 2022 Date: Tue, 2 Nov 2021 15:55:26 +0100 [thread overview] Message-ID: <ee51e10d-0fbf-d87f-aa98-a95d97a7e437@canonical.com> (raw) In-Reply-To: <CAK8P3a0KqS-OZoo46ajfaXw1aFXR9HouW2ZezKRWCawMa7yuGA@mail.gmail.com> On 02/11/2021 14:05, Arnd Bergmann wrote: > 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. 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@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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-02 14:55 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-02 11:05 [RFC PATCH] ARM: s3c: mark as deprecated and schedule removal after 2022 Krzysztof Kozlowski 2021-11-02 11:05 ` Krzysztof Kozlowski 2021-11-02 11:09 ` Krzysztof Kozlowski 2021-11-02 11:09 ` Krzysztof Kozlowski 2021-11-02 13:05 ` Arnd Bergmann 2021-11-02 13:05 ` Arnd Bergmann 2021-11-02 14:55 ` Krzysztof Kozlowski [this message] 2021-11-02 14:55 ` Krzysztof Kozlowski 2021-11-02 15:00 ` Krzysztof Kozlowski 2021-11-02 15:00 ` Krzysztof Kozlowski 2021-11-02 15:36 ` Arnd Bergmann 2021-11-02 15:36 ` Arnd Bergmann 2021-11-02 16:37 ` Mark Brown 2021-11-02 16:37 ` Mark Brown 2021-11-03 8:27 ` Krzysztof Kozlowski 2021-11-03 8:27 ` Krzysztof Kozlowski 2021-11-03 17:05 ` Mark Brown 2021-11-03 17:05 ` Mark Brown 2021-11-02 17:43 ` Heiko Stübner 2021-11-02 17:43 ` Heiko Stübner 2021-11-03 8:34 ` Tomasz Figa 2021-11-03 8:34 ` Tomasz Figa 2021-11-05 17:49 ` Cedric Roux 2021-11-05 17:49 ` Cedric Roux 2021-11-06 18:20 ` Krzysztof Kozlowski 2021-11-06 18:20 ` Krzysztof Kozlowski 2021-11-06 19:33 ` Heiko Stübner 2021-11-06 19:33 ` Heiko Stübner 2021-11-06 20:13 ` Arnd Bergmann 2021-11-06 20:13 ` Arnd Bergmann 2021-11-07 9:11 ` Krzysztof Kozlowski 2021-11-07 9:11 ` Krzysztof Kozlowski
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=ee51e10d-0fbf-d87f-aa98-a95d97a7e437@canonical.com \ --to=krzysztof.kozlowski@canonical.com \ --cc=arnd@arndb.de \ --cc=cw00.choi@samsung.com \ --cc=heiko@sntech.de \ --cc=inki.dae@samsung.com \ --cc=kgene@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=m.szyprowski@samsung.com \ --cc=olof@lixom.net \ --cc=sam.van.den.berge@telenet.be \ --cc=sed@free.fr \ --cc=snawrocki@kernel.org \ --cc=tomasz.figa@gmail.com \ --cc=ylhuajnu@outlook.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.