Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2304250pxm; Sun, 27 Feb 2022 17:40:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJyWxDL/bgbIhv4ZaIIN5eFdWtwg0Dx51iqYwFKrjQDJh1IXiLY/iV1tupxgtN+kv5WSQ+6I X-Received: by 2002:a17:906:7189:b0:6b6:1ef8:f392 with SMTP id h9-20020a170906718900b006b61ef8f392mr13289985ejk.590.1646012418284; Sun, 27 Feb 2022 17:40:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646012418; cv=none; d=google.com; s=arc-20160816; b=BLlrc6HylszPrgxI1Tp6pZ/FsntAfdi/6VBEVKmbMHM9LsInx8WyhHgYo5S1TUglFt /LxXR6e3F3y3zHcQQ+FhL0IVGx1XF/rdHGGCC6FRfSHR+Rd2E+HSllgjRsqTgQK+ksaL p/YVuaqJL9ZyF9IIouXVdoAY77ElJE3JNvJlE1N2B2bt7TXyGACMGA4b0QTGaN87vUWB ocU1a5gHiIpj2eYC7jPF7de6HgL+3WxgW6e04+71+Wa2PpFqgbsqzaA9E2axcJOhIQFb Tv6F1qZOg4YYhqZ3aQQH7rt/32RLD6DmkKMiaXRGor1f4k2syIEWLHRFFmjJPS0X2geH d7mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:cc:to:subject:from:date; bh=Tu+WkzCbAMTcNrNxsfB66z5Pn9Yq45dOgfWTYV5JVqQ=; b=Ygy7QzMTuCzifg6tFj+S6BA3cN0rKQWhFD3dasRM6dEf/8wgLiPYG0tk5G2yqZqrcw s63ZJVRxFpXDxkv+QMk10o/xCqlFe9YQzxNys2gmB5gvisN+CHvsI0X34JyeDFxNjFAB Qrkg4GDx9VKBcPj/tDHensVKxwFCUC96YmwDu90TZDLnkjVD8+cchtZufnjfEuiyPP+0 yOxqrAenP/5T0e25OG55XAA2NOZu6rm5gT/+hWPcqxvSX+k6SVOvHwZpbgcqUJZ7BkJn RQ6XcPMqrpt4zh6OdK806ePOsi0vokSTkSDU3/8Ho5oTNi7EJaWXi1bVCMbzWV6Nwgpe 9gPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v9-20020a056402174900b00412ec3f5f5asi6177247edx.168.2022.02.27.17.39.44; Sun, 27 Feb 2022 17:40:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230094AbiB0R5U convert rfc822-to-8bit (ORCPT + 99 others); Sun, 27 Feb 2022 12:57:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229650AbiB0R5T (ORCPT ); Sun, 27 Feb 2022 12:57:19 -0500 Received: from aposti.net (aposti.net [89.234.176.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC7B44BFF3 for ; Sun, 27 Feb 2022 09:56:42 -0800 (PST) Date: Sun, 27 Feb 2022 17:56:31 +0000 From: Paul Cercueil Subject: Re: [PATCH -next] misc: rtsx: fix build for CONFIG_PM not set To: Arnd Bergmann Cc: Randy Dunlap , Linux Kernel Mailing List , Wei WANG , Kai-Heng Feng , Greg Kroah-Hartman , "Rafael J. Wysocki" , Jonathan Cameron Message-Id: <7U5Z7R.RNKITPUWCPX32@crapouillou.net> In-Reply-To: References: <20220226222457.13668-1-rdunlap@infradead.org> <449d6ceb-7308-9543-c23c-831bebffda21@infradead.org> <0D5Z7R.NUOWBMRT4GQ2@crapouillou.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le dim., f?vr. 27 2022 at 18:51:38 +0100, Arnd Bergmann a ?crit : > On Sun, Feb 27, 2022 at 6:46 PM Paul Cercueil > wrote: >> Le dim., f?vr. 27 2022 at 18:30:16 +0100, Arnd Bergmann >> >> There could be a DEFINE_DEV_PM_OPS(), but I don't think that's >> really >> needed - you can very well declare your struct dev_pm_ops without >> using >> one of these macros. Just make sure to use the SYSTEM_SLEEP_PM_OPS / >> RUNTIME_PM_OPS macros for the callbacks and pm_ptr() for the >> device.pm >> pointer. > > Ah, of course, so it comes down to > s/SET_SYSTEM_SLEEP_PM_OPS/SYSTEM_SLEEP_PM_OPS/ while > removing all the #ifdef an __maybe_unused annotations. The pm_ptr() > in driver.pm makes this slightly more optimized AFAICT, but has no > effect on behavior, right? The use of SYSTEM_SLEEP_PM_OPS makes sure that the callbacks are dropped if the dev_pm_ops is dead code, and the pm_ptr() must be used for the compiler to know that the dev_pm_ops is dead code. -Paul