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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 09AB7C00140 for ; Fri, 12 Aug 2022 22:29:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=X34mQV+cHqLukSkkM3kEtSAXCX/8EbOwq23w8x7w/0A=; b=qm+4fBY3d9zK/3 GcfitqJXHSduymDKzwfuzRvkPjImwFZzmkyah7Y48sSfJ5DoMTZJs4hv5T/Y5FaReRoOn2VBC/XxV JNtj9XlOyTmDbBYmwzjJ+ocbHn0EtcW9a2hkioVk9yEenMbgC64Uhu0Jx3eDOSa9DWeOMLmWK0bzD CcBKMaTti79oce3tyy/NYxoLnDQyhDMNIxKfxrqdtfqI7zEP6UOumz63bc9PsZpVbXDylaGch85/q NGAM5GF37jaJafQFF588qE2oOyq1H7CCCoyZe1IZ12JB1uiZZLe652meGg6+HyTtcgfWSiQw0ykG0 uZxbQQjgWQ7Qp17zxYJw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oMd8o-00GKAF-QA; Fri, 12 Aug 2022 22:28:30 +0000 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oMd3a-00FeoH-3e for linux-arm-kernel@lists.infradead.org; Fri, 12 Aug 2022 22:23:21 +0000 Received: by mail-qk1-x730.google.com with SMTP id m5so1838051qkk.1 for ; Fri, 12 Aug 2022 15:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=sW9hnKe3PhL/Umb988XscvuO/sNSE1um1bW+MnXhWus=; b=J5FtUxwOJSF75TAcrJRoMnQtXL5c7loYkQCFP1u3P6IwwcrI06PVP5haZ1yXX+UgkR CzgrkA2RPKKBX2DX/idC49STf/d/0x29dESCYsr7Gzh3fHWnnWr9+ddnhXWeBaTQl7u2 EGgzH+w5WNTUpdqIZaWQTEH/IxsQAIbJWrY0oGt+76QXSveZJUiytlu6CiaocAFcYYHx urvUjygl+fYsUxlO2yP4NoteQCcV+LsTI5ei7iovq0+6lWv12S1SjNZcCxYNBwW1A9KB OZszwh077kL4sJBM8tsuH4DnX+BhHQUaWoO7gyMvNgLnVwdSzeJhu+7NLVio4L1kYFat Ob5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=sW9hnKe3PhL/Umb988XscvuO/sNSE1um1bW+MnXhWus=; b=ExLgNYNssIcsH6Di4vDZsWUDVuoVmdgNnqBBYXYmIkdA0dckjl6puTDcHHLIwQI54A aNLzXUqxHYL/9RDunqV0SAiBmZMZL+3Ioa0vw7BGz1zri2Mar9xYY+GAzYPfKhx8by1C 4zWEruvrhYF38vM2Jg8pi4h0kgHkCANs7HQXvLcaWXWpGJwMfRtjDQKXPcvfe+Duq+mF VthOdeqEEtcIBnhY7FhldblZKGJNWn7eHmCqSj+t8fHmWUJeb/UGyzm2wXWZRmWvxTfD xXM5ezUs7np2YDOp2S/RcUMbQflhkE88yVK8p2I8hUJOzF5N0UqeX0i0KBCShKlRvjrR SwWQ== X-Gm-Message-State: ACgBeo1n9eGDsKbv9gHOwKrA0y6Xei52u+5tQemNkA6xq5K66r7pKTyW JxyRCRIl1/4DfChQHIkzuiw= X-Google-Smtp-Source: AA6agR73OgaSYcBb88BYiZ0fBxAC6nCOw2FRiSsESxntACfgwGjaVSC8g+jLMOBhRgJTwLjzwhbuug== X-Received: by 2002:a05:620a:461e:b0:6b5:f9b9:5f70 with SMTP id br30-20020a05620a461e00b006b5f9b95f70mr4542519qkb.631.1660342984353; Fri, 12 Aug 2022 15:23:04 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.googlemail.com with ESMTPSA id bn12-20020a05622a1dcc00b0031eb5648b86sm2524908qtb.41.2022.08.12.15.22.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Aug 2022 15:23:03 -0700 (PDT) Message-ID: <90d37d6e-52df-149e-5691-ae7a91521482@gmail.com> Date: Fri, 12 Aug 2022 15:22:54 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v3 3/3] memory: Add Broadcom STB memory controller driver Content-Language: en-US To: Krzysztof Kozlowski , Florian Fainelli , linux-kernel@vger.kernel.org Cc: Broadcom internal kernel review list , Rob Herring , Krzysztof Kozlowski , "moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" References: <20220801220931.181531-1-f.fainelli@gmail.com> <20220801220931.181531-4-f.fainelli@gmail.com> <26ad247d-a4b3-4051-b8d9-505c09b76f6b@linaro.org> <375eac04-dbfd-080a-3003-cae3eda1f42b@gmail.com> From: Florian Fainelli In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220812_152319_486263_D04980DF X-CRM114-Status: GOOD ( 27.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 8/12/22 11:41, Krzysztof Kozlowski wrote: > On 12/08/2022 20:52, Florian Fainelli wrote: > >>>> unless you also implied enclosing those functions under an #if >>>> IS_ENABLED(CONFIG_PM) or something which is IMHO less preferable. >>> >>> Are you sure you added also pm_ptr()? I don't see such warnings with W=1 >>> and final object does not have the functions (for a different driver but >>> same principle). >> >> Yes I am sure I added pm_ptr() see the v4 I just submitted. I don't see >> how the compiler cannot warn about the functions being unused the day >> they stop being referenced by the pm_ops structure which is eliminated? > > I don't have the answer how it exactly works (or which gcc version > introduced it), but I tested it and the functions were not present in > the object file, thus of course no warnings. > > The driver change I am referring to is: > https://lore.kernel.org/all/20220808174107.38676-15-paul@crapouillou.net/ > > I think the only difference against your v4 is: > DEFINE_SIMPLE_DEV_PM_OPS > and lack of __maybe_unused on the functions. > > The DEFINE_SIMPLE_DEV_PM_OPS itself adds __maybe_unused for !CONFIG_PM > case, but I don't think it is relevant. It definitively is relevant here. SIMPLE_DEV_PM_OPS without __maybe_unused results in the following pre-processed code: static int brcmstb_memc_suspend(struct device *dev) { struct brcmstb_memc *memc = dev_get_drvdata(dev); void *cfg = memc->ddr_ctrl + memc->srpd_offset; u32 val; if (memc->timeout_cycles == 0) return 0; val = ({ u32 __r = (( __u32)(__le32)(( __le32) __raw_readl(cfg))); __r; }); val &= ~((((1UL))) << (16)); __raw_writel(( u32) (( __le32)(__u32)(val)),cfg); (void)({ u32 __r = (( __u32)(__le32)(( __le32) __raw_readl(cfg))); __r; }); return 0; } static int brcmstb_memc_resume(struct device *dev) { struct brcmstb_memc *memc = dev_get_drvdata(dev); if (memc->timeout_cycles == 0) return 0; return brcmstb_memc_srpd_config(memc, memc->timeout_cycles); } static const struct dev_pm_ops __attribute__((__unused__)) brcmstb_memc_pm_ops = { } ; static struct platform_driver brcmstb_memc_driver = { .probe = brcmstb_memc_probe, .remove = brcmstb_memc_remove, .driver = { .name = "brcmstb_memc", .of_match_table = brcmstb_memc_of_match, .pm = ((1) ? ((&brcmstb_memc_pm_ops)) : ((void *)0)), }, }; Now with DEFINE_SIMPLE_PM_OPS, we get the following instead: static const struct dev_pm_ops brcmstb_memc_pm_ops = { .suspend = ((0) ? ((brcmstb_memc_suspend)) : ((void *)0)), .resume = ((0) ? ((brcmstb_memc_resume)) : ((void *)0)), .freeze = ((0) ? ((brcmstb_memc_suspend)) : ((void *)0)), .thaw = ((0) ? ((brcmstb_memc_resume)) : ((void *)0)), .poweroff = ((0) ? ((brcmstb_memc_suspend)) : ((void *)0)), .restore = ((0) ? ((brcmstb_memc_resume)) : ((void *)0)), .runtime_suspend = ((void *)0), .runtime_resume = ((void *)0), .runtime_idle = ((void *)0), } ; static struct platform_driver brcmstb_memc_driver = { .probe = brcmstb_memc_probe, .remove = brcmstb_memc_remove, .driver = { .name = "brcmstb_memc", .of_match_table = brcmstb_memc_of_match, .pm = ((1) ? ((&brcmstb_memc_pm_ops)) : ((void *)0)), }, }; so we will continue to reference the functions, but eventually we will eliminate those at the optimization stage by figuring out that this is dead code, therefore it can be eliminated. Note that in both cases the object does not contain brcmstb_memc_{resume,suspend} which makes sense because the warnings are generated at the time the code is processed, and the dead code elimination at one of the optimization stages. I can spin a v5 with DEFINE_SIMPLE_PM_OPS if you prefer to get rid of the __maybe_unused. -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel