Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp53054pxu; Mon, 5 Oct 2020 23:54:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoWy13hEcGVCvF+es2/Ad1/gdLToc1kMVLyXRI/i/5JcwhMHcvrVxJm8xtj8NEP57NUoGw X-Received: by 2002:a17:906:791:: with SMTP id l17mr3552421ejc.361.1601967283182; Mon, 05 Oct 2020 23:54:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601967283; cv=none; d=google.com; s=arc-20160816; b=qrOezQTx2B1R/uWZcGS1BAi3YzBpty45sZ3MV7gHCtda7pw9IZvSU/ToOgLxbvNSIa RQXOiyrdXgBOW/6bT1hh4hW2iqxrF+/DheKMH/AAgRjcNrVz92pZST/zcoZ3j1arKgvN 9Bzi5arZHpkYSXY1G5dvitj8iC8Wq3OSooywyx9y9HdgdKAxBUys+SofmCTR19aF880k atbhn9l3BFD9GDr4t1HYUzLHWXrTIvOdBQygf89nnMjre/NXyRte7MTa+ZCjmfa9HTKG Xji59OKA5nAZZiqHdOef94L1PJz135jX8EyUMYmsNXE7A+PzwFOT9JTIG6KY3NR9supx 5nCg== 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:from:date:dkim-signature; bh=aXzg8jiyuQTiAqmu/XuvmpavXYdKtRsp/UTQZG95Smw=; b=s3l2Eo8CtyRMqeqs3krlt/oyOUHTC9+B3SCwElBOa2H0tAxOoYwGeZiOzajj44bqSS NdOocWvXYD12bObrwy3jp9VvSabWS83OY7RUZct8pjS7QENgwHGGO4cPgQoFFuWDM9af czLW9+6B+LW6JkYMROd455h5DA4K0K0G14xDF2Ff4CKHy0GYNeVwizu24IXNDEh78Xnv ii0Ynn3AIx/K23KWSrVPY15F9e4mg1W1PUOneH5B2LxHAMvd8nbEra2p7szu9MP0vfeV S5k4hH6aRrDm9NvihRvHPhsYaQyi5vu0XP9S/GAY7NdIybvhe5id5sadCicKs4JjpOXH huRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=pPgf1JCf; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c14si1786975edw.305.2020.10.05.23.54.20; Mon, 05 Oct 2020 23:54:43 -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=@linaro.org header.s=google header.b=pPgf1JCf; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726875AbgJFGxR (ORCPT + 99 others); Tue, 6 Oct 2020 02:53:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725962AbgJFGxR (ORCPT ); Tue, 6 Oct 2020 02:53:17 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F734C0613A7 for ; Mon, 5 Oct 2020 23:53:17 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id l15so1526668wmh.1 for ; Mon, 05 Oct 2020 23:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=aXzg8jiyuQTiAqmu/XuvmpavXYdKtRsp/UTQZG95Smw=; b=pPgf1JCfjmJPkigztvFLycNQEqLNvGaDmU8v4vDNDOiqpolMjDdoAlZCwzZ0TezAem 96XB+H5QoLZUFzmiGUv4qpJSCrUVIwx+iNfdvku0YZm558HIKBnN2z0gypIu+70WEcRX BcflYfuhTXwiHO0G+nq+RVT93rOV3mzT0xnpIdzpCKcb8Y8kw3X59Sxdk+Wfdudc+GEZ YmWBUg8YoRgD5S6G+vYhrKqz9mdnoVB83wAnDiavTXcrhpl/10l5y+Y3US13xEc9wTfC xLavQGcOM6fAXnKN75j9qi7OpLSrtAkwyIqrmuv9ML+gE9eR9kHn9J++EtZ4LLvuanla 5UYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=aXzg8jiyuQTiAqmu/XuvmpavXYdKtRsp/UTQZG95Smw=; b=q4BxSasmIbf2Mag2DA665XxSmptuP79g6raDs5zG+OgiwFT14XJT8OLC4tCejH+cb6 xc1JINRDU/LTc9F2pNxT/e54e0mFQcpBcvRN9zb4vXhWA2INKQ9X6ogPviL+mJAVDvQo vPxpTWiQVapCk1LYTXTBzjzSYNKftHfnxEEV9wEwqCPLYSvItDccZVIYSstCEI/lrFOU nmZ2blFUZH7LPhzaiP8vhxkpg7MTMawaD0QodY/iKOAPE+aJZHsiqZNIcivPi/wjs624 sc8k+uMfjCgEBEW0nN/aqASi7j6r4OjkRohxNX/Z2NHw8JDecD4cP/V9xH3LOyb2JB0D XcgA== X-Gm-Message-State: AOAM531YrWtBctDLkw52++Ur0cat34xW/824ZsTKABZNdk1XL3CcnhgW CFL9pwmHU191ZeBDe9paeCjusw== X-Received: by 2002:a05:600c:216:: with SMTP id 22mr2954681wmi.149.1601967195504; Mon, 05 Oct 2020 23:53:15 -0700 (PDT) Received: from dell ([91.110.221.236]) by smtp.gmail.com with ESMTPSA id l11sm1893529wrt.54.2020.10.05.23.53.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Oct 2020 23:53:14 -0700 (PDT) Date: Tue, 6 Oct 2020 07:53:13 +0100 From: Lee Jones To: Michael Brunner Cc: "mibru@gmx.de" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mfd: kempld-core: Mark kempld-acpi_table as __maybe_unused Message-ID: <20201006065313.GW6148@dell> References: <37c55c13f9042dde06fd67c829b06765286d0580.camel@kontron.com> <20201002070134.GR6148@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 05 Oct 2020, Michael Brunner wrote: > On Fri, 2020-10-02 at 08:01 +0100, Lee Jones wrote: > > On Thu, 01 Oct 2020, Michael Brunner wrote: > > > > > The Intel 0-DAY CI Kernel Test Service reports an unused variable > > > warning when compiling with clang for PowerPC: > > > > > > > > drivers/mfd/kempld-core.c:556:36: warning: unused variable > > > > > 'kempld_acpi_table' [-Wunused-const-variable] > > > static const struct acpi_device_id kempld_acpi_table[] = { > > > > > > The issue can be fixed by marking kempld_acpi_table as > > > __maybe_unused. > > > > > > Fixes: e8299c7313af ("[PATCH] mfd: Add ACPI support to Kontron PLD > > > driver") > > > > > > Reported-by: kernel test robot > > > Signed-off-by: Michael Brunner > > > --- > > > drivers/mfd/kempld-core.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c > > > index 1dfe556df038..273481dfaad4 100644 > > > --- a/drivers/mfd/kempld-core.c > > > +++ b/drivers/mfd/kempld-core.c > > > @@ -553,7 +553,7 @@ static int kempld_remove(struct platform_device > > > *pdev) > > > return 0; > > > } > > > > > > -static const struct acpi_device_id kempld_acpi_table[] = { > > > +static const struct acpi_device_id __maybe_unused > > > kempld_acpi_table[] = { > > > { "KEM0001", (kernel_ulong_t)&kempld_platform_data_generic }, > > > {} > > > }; > > > > This is not the right fix. Better just to compile it out completely > > in these circumstances. I already have a fix for this in soak. > > Ok - thank you for the other fix you submitted! > > But just out of curiosity - in process/coding-style.rst is written that > __maybe_unused should be preferred over wrapping in preprocessor > conditionals, if a function or variable may potentially go unused in a > particular configuration. So why is my patch not the right one here? At > least in my tests it seemed to solve the issue. It's a bone of contention for sure. In these kinds of scenarios (i.e. ACPI and OF tables) it is way more common to wrap them: $ git grep -B3 'acpi_device_id\|of_device_id' | grep 'CONFIG_ACPI\|CONFIG_OF' | wc -l 596 $ git grep -B3 'acpi_device_id\|of_device_id' | grep __maybe_unused | wc -l 63 Parsing them out completely, also has the benefit of saving space, reducing the size of the finalised binary. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog