Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp1319297pxx; Fri, 30 Oct 2020 07:25:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCfGlXQ+N1vUSBy2xSiC+vIkVO/WsrAKdJRQPA40cgnCh7APX5bP3euIwmbYHlLBB7F9MA X-Received: by 2002:aa7:c608:: with SMTP id h8mr2605079edq.16.1604067922980; Fri, 30 Oct 2020 07:25:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1604067922; cv=none; d=google.com; s=arc-20160816; b=I2c02MOdQC2HYXotqSjqXcW7kFLJNdjm4OC/BVTKe+IoN3J9R6vdHfmco3t03NQ7sQ IMjFMZFsKveVYeVhtl7n7nZQCEZldygFqUM8lbmt54j4nkqVscnLqXmXlv1HuS7Dr5IU E/2DBLXuQZXbha4KOq/GtJxVmEBmh2djF9XG898VE9ZjknzJ0qr3Zx3uLVWreK18/NN1 MHZw/HxIXHSbUBhl76gL/bROkihUyllMVPH7v+WObzTdj8Xb0eXky9+ArqewTmzbpdeP XvD3D33nu/ssubQ0W3xUVkO9zYLx4i23HIyDJFmSR0iSHjtlHABP+TtgM0oAXueTUoKH DW9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:date:from:dkim-signature; bh=cEh0z2QaIyWyWgXHUZ4JK/bshMZzjcuaFOqXK8gUuYc=; b=0lLtlkktqmfW7rI4YwclI5g2274+O2CVhZHBQqVWsSPEBjRWlKm9Pfye52JMAJiPru EyIEsK+htfmygCTrCwq5UJz4P6roLNhynS78RH3IYkI5mmGZEP87XHnZqFdaYElCZjL8 pJbtII1AFKYwAtpLnjshj0ggO0E0TFEcxM5HQxtdTTYOFvNHMEXq+FV8kV2+0eXKpRTv a5FnDDph95CU9ztPg4YX9lxuh2Q7zP61ATNyhZEFG8MQKPzSB1//5alrH0Ko8HboGrNZ 2THLlNgQcKzubcD7ePW7RaypiiGOjS117BPvv/SlIA/ISgGlzilmv1S5PeeQVBzy2igL 4UXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oDxqWuIS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h10si4145135ejl.239.2020.10.30.07.24.59; Fri, 30 Oct 2020 07:25:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=oDxqWuIS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726654AbgJ3OXZ (ORCPT + 99 others); Fri, 30 Oct 2020 10:23:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725834AbgJ3OXZ (ORCPT ); Fri, 30 Oct 2020 10:23:25 -0400 Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C3FEC0613CF for ; Fri, 30 Oct 2020 07:23:25 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id n16so5316525pgv.13 for ; Fri, 30 Oct 2020 07:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=cEh0z2QaIyWyWgXHUZ4JK/bshMZzjcuaFOqXK8gUuYc=; b=oDxqWuIS8ID0QYyixwqfp11FwFGgtKEgz8N1otPs3YvMU7oYhErwXUGeJMScLXEBjz bUGDQfquO1h/VNeNeO6cyo5OCmX3C2uEyvRZOn05gsWJA8ksSTeVBKSNALcqsfSdp7Ux /EiVlH7VoxsKk/dD6bams+Y3trjVmgy6d8vGGh45US9ukYUrmIZffJBImOufAffB0f6w 48LXwV3jd44K8dtdMhMCRshRwa6J78G5J1KqzYUEKPPElPl6WqsnN7McxxVvfNnTdfrs EwZHlfNmWY9XE2OalFTvemof28BWP1iFfpTTZy7aBmYrwFC+agLiAPPE8PxsVjFv32tn Nyww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=cEh0z2QaIyWyWgXHUZ4JK/bshMZzjcuaFOqXK8gUuYc=; b=ONXge8y53tq21Y+GqE3i0ctLJ/PWlF4YAzVdzKofR0VvnfLkKPR0NdfudzRfQUJ5Bx fQIzP8fvH7Qo7ZzIaV7ibdtm2VzHFNCxJAg3emYpWDDLvN04xyMheRfcG5jF46zLFOTP TffNDvGfIIInJnJ27hEu0dm+nosCjlnwzGIEjAHnFBxUyGdlgbjQEUs/hGP7xOtgz5IT ttPsMhf5R5Hc3pjialrWfne9snd6uduotlLDPH1wz+Z9ocbX2KMhlZE4pGGNQYQ6HOKl XPukJV9qzpfHAyfpKPQ+pTMZdUtuP1wehRRVZN1GdiczNuA+10XfX+lltJF/pDC3EGNv GRyw== X-Gm-Message-State: AOAM533DrQzTwIRGln7uI47wrfoltc17NSsJg2YdZ4saD/PiFAUvX7QQ RsFlLWTKp9ZPasmlvscfPsE= X-Received: by 2002:a17:90a:9313:: with SMTP id p19mr3261369pjo.90.1604067804955; Fri, 30 Oct 2020 07:23:24 -0700 (PDT) Received: from localhost ([240e:472:3d00:779:b01a:f9a7:6a68:30ac]) by smtp.gmail.com with ESMTPSA id z10sm6176358pff.218.2020.10.30.07.23.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Oct 2020 07:23:24 -0700 (PDT) From: Coiby Xu X-Google-Original-From: Coiby Xu Date: Fri, 30 Oct 2020 22:22:42 +0800 To: Andy Shevchenko Cc: Lee Jones , Andy Shevchenko , Andy Shevchenko , open list Subject: Re: [PATCH 3/9] mfd: intel_soc_pmic: remove unnecessary CONFIG_PM_SLEEP Message-ID: <20201030142242.r4jqhvtzh7hnahuv@Rk> References: <20201029100647.233361-1-coiby.xu@gmail.com> <20201029100647.233361-3-coiby.xu@gmail.com> <20201029110029.GF4077@smile.fi.intel.com> <20201029142911.p54mbwbfaeymrqy5@Rk> <20201029152719.GC4127@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 29, 2020 at 07:04:44PM +0200, Andy Shevchenko wrote: >On Thu, Oct 29, 2020 at 5:27 PM Lee Jones wrote: >> On Thu, 29 Oct 2020, Coiby Xu wrote: >> > On Thu, Oct 29, 2020 at 01:00:29PM +0200, Andy Shevchenko wrote: >> > > On Thu, Oct 29, 2020 at 06:06:41PM +0800, Coiby Xu wrote: >> > > > SIMPLE_DEV_PM_OPS has already took good care of CONFIG_PM_CONFIG. >> > > >> > > Have you compiled this with >> > > % make W=1 ... >> > > ? >> > > >> > >> > Sorry my bad. I thought I had run "make modules" with CONFIG_PM_SLEEP >> > disabled. I'll run "make W=1 M=..." for each driver after adding >> > __maybe_unused in v2. >> >> No, thank you. Just keep it as it is. >> >> The current code is space saving. > >Perhaps you need to go thru __maybe_unused handling. >There are pros and cons of each approach, but not above. > Can you elaborate on the pros and cons of each approach? There's convincing reason to prefer __maybe_unused over CONFIG_PM_SLEEP according to Arnd Bergmann [1], > > By and large, drivers handle this by using a CONFIG_PM_SLEEP ifdef. > > > > Unless you can make an extremely convincing argument why not to do > > so here, I'd like you to handle it that way instead. > > [adding linux-pm to Cc] > > The main reason is that everyone gets the #ifdef wrong, I run into > half a dozen new build regressions with linux-next every week on > average, the typical problems being: > > - testing CONFIG_PM_SLEEP instead of CONFIG_PM, leading to an unused > function warning > - testing CONFIG_PM instead of CONFIG_PM_SLEEP, leading to a build > failure > - calling a function outside of the #ifdef only from inside an > otherwise correct #ifdef, again leading to an unused function > warning > - causing a warning inside of the #ifdef but only testing if that > is disabled, leading to a problem if the macro is set (this is > rare these days for CONFIG_PM as that is normally enabled) > > Using __maybe_unused avoids all of the above. You option is valuable to me because I'm making a tree-wide change. Currently there are 929 drivers having device PM callbacks, $ grep -rI "\.pm = &" --include=*.c? ./|wc -l 929 I put all files having device PM callbacks into four categories based on weather a file has CONFIG_PM_SLEEP or PM macro like SET_SYSTEM_SLEEP_PM_OPS, here are the statistics, ? 1. have both CONFIG_PM_SLEEP and PM_OPS macro: 213 ? 2. have CONFIG_PM_SLEEP but no PM_OPS macro: 19 ? 3. have PM macro but not CONFIG_PM_SLEEP: 347 ? 4. no PM macro or CONFIG_PM_SLEEP: 302 [1] https://lore.kernel.org/patchwork/comment/919944/ >-- >With Best Regards, >Andy Shevchenko -- Best regards, Coiby