From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6835DC433F5 for ; Tue, 2 Nov 2021 14:55:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 46338604D2 for ; Tue, 2 Nov 2021 14:55:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233362AbhKBO6I (ORCPT ); Tue, 2 Nov 2021 10:58:08 -0400 Received: from smtp-relay-internal-0.canonical.com ([185.125.188.122]:59606 "EHLO smtp-relay-internal-0.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233349AbhKBO6F (ORCPT ); Tue, 2 Nov 2021 10:58:05 -0400 Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id DFC693F1C1 for ; Tue, 2 Nov 2021 14:55:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1635864929; bh=1l57wjx0a3onK41N41yLHbCEPI0pyVDuBTZPteBeCAE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WsDpMWK+3JIkFGHGdAYMraiKq9++otzjFsokawn/0ByKJft73+lbashXSNKXEirBV a8g20lGlgrDv/65PRPFH+iVLxmXlR05Jh2HRp+Js1bPCywGuhKMzmaqERHYvx2ybne FqN/gpG90T9R+mt6ZTCcZrLpMHNY+Zo3z/51MrTXp65MFbbX3Ba43RvxfF4gH6zTQh s3X5cSgn8fokCNZSEZROgKVNQ3g2sEeHJI/1nMjhENuqu6Tl6K2Sku3NcHEfQh3fCl ZMyUfgezhuMQTWVGTKi5Je7Hj3N5LyUW2WXepLQYPRL5SJKn7qgRXGvXk4GacMsP+d V61n7jm3xhq4w== Received: by mail-lf1-f71.google.com with SMTP id d10-20020a0565123d0a00b004002359a671so1413003lfv.10 for ; Tue, 02 Nov 2021 07:55:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=1l57wjx0a3onK41N41yLHbCEPI0pyVDuBTZPteBeCAE=; b=qhOCcG6N03TUfoplmKV3v1lyyC0VSWiDMzhvw32wQxnl/bQixNmfKHWv0syeHE/LW9 5bQ697g0GkIhKf01P4WmrlnNzaroQ5NIdmGsbzfGOQ8JSd+RLvsqx66JHnckuLq8KmDF EjQjTIfGEiA7zPUsGVHt2m+Fhh7UFy7SJewxsOUSLR22Cyt8nlfQTIOp3o6rLA5w/jNO CoocLQ27AV3pt8thyQLaa6KWbL2AOJHmB5F1X3D4c0JhZ1rpLp0/efnAHnW/ShCAS/IW 5LtztxAoDSz0t+Wny5vHFxGZzkscbISe+i/1zDP6ngrVE9gdv9kmo9TbMH21BixWdAFo b54w== X-Gm-Message-State: AOAM53043MW6ZXzkHTLeOueb9vRpTC3MKQHSghMUMqQyYjz92IXhmU8x rvtBTUEFPZ/ek+DEibWvCpvDqWuSOS4Ghlp2yby/si+w6OIYkg60vhwW+mD1DAbv0ZWSCb49+tw IEtOZFYzIweKwNcXh4/CP++NdOvTQPszy2+pzh0pKGA== X-Received: by 2002:a05:651c:556:: with SMTP id q22mr26054594ljp.374.1635864928936; Tue, 02 Nov 2021 07:55:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxPoqTSwnlW0IiQfpoSYvz+g+cYGtvYWlgr/XmqB9ie+7blrt7ma1maQXbww/CaUPLHEEg/Mg== X-Received: by 2002:a05:651c:556:: with SMTP id q22mr26054549ljp.374.1635864928572; Tue, 02 Nov 2021 07:55:28 -0700 (PDT) Received: from [192.168.3.67] (89-77-68-124.dynamic.chello.pl. [89.77.68.124]) by smtp.gmail.com with ESMTPSA id i1sm1691248lfr.287.2021.11.02.07.55.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Nov 2021 07:55:28 -0700 (PDT) Message-ID: Date: Tue, 2 Nov 2021 15:55:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [RFC PATCH] ARM: s3c: mark as deprecated and schedule removal after 2022 Content-Language: en-US To: Arnd Bergmann Cc: Russell King , Linus Walleij , Linux ARM , Linux Kernel Mailing List , "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" , Olof Johansson , Kukjin Kim , Marek Szyprowski , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Inki Dae , Cedric Roux , Sam Van Den Berge , Lihua Yao , Heiko Stuebner References: <20211102110519.142434-1-krzysztof.kozlowski@canonical.com> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/11/2021 14:05, Arnd Bergmann wrote: > On Tue, Nov 2, 2021 at 12:05 PM Krzysztof Kozlowski > 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 > > 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