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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8393DC433DF for ; Mon, 17 Aug 2020 08:43:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 64B2D2072D for ; Mon, 17 Aug 2020 08:43:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="pCpD/3JX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727998AbgHQIn6 (ORCPT ); Mon, 17 Aug 2020 04:43:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726925AbgHQInx (ORCPT ); Mon, 17 Aug 2020 04:43:53 -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 D88CCC061388 for ; Mon, 17 Aug 2020 01:43:52 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id p14so12554762wmg.1 for ; Mon, 17 Aug 2020 01:43:52 -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=D1UjIIuxlByyuNbDhVDjp8frAQhVC4jXQISXzhYCeyY=; b=pCpD/3JXsVs5IP+p+ECYZCn74rRmRLfvblZjANzhSXMrphOOrXPQddul+iuWq/PzxU KtoPNFawOpX4lVcn/zJMKoWN6dKFtIEHFChWG3oJapMcMB+3M1Exgp+1utBPrZ2ItdGI 8iKJxvt3AL8zxcQPcvmfQ5ZYEFfVtj84EUiP1d6saNS/W/WuQmLdTjZD7kSDseJeimoZ KV23YUYbit3ZSGP4sna9htwJvRueZrgvM+kbJJ+f4NFliUSg7BXkUs+l0jtaDoXMLqZ+ nS8YZVrZhg0d8ilpLoBOtY+R9Liq9wN9FPAunz3UZ6DIoR9awpRW6Kh5076jYiRH6r7m CaHg== 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=D1UjIIuxlByyuNbDhVDjp8frAQhVC4jXQISXzhYCeyY=; b=kzU60NFLjUBi3AMoFtpW3j1gr1yMvsbBl/j+YByi/CKJivUwmM7vYxU1ES046Qd3iJ jZpYq1UGrMxgYh/NANzfdsCo3M+dchLPhKsXlvkzNlGTq3xDLdMaBStUuX2Gyg3gc1Vr FgcTT7jYjVuecP583JbBL1qWy/05rFdVoUJY5qgrCE35bTJ6S2vtGmEAF87sG+pdP/u8 1JvqHhzfJ8nNHPBKNvDAp3VB61Z7kL7aktdMpMuJnshubtZvGz5tdwkBFSwSUzPwdw6F HMPrk+KLlWlHs2UrITmFKoxwJS68PBm3RDEwPfAluZ3BYyiSUOGYHtm5fRHOkae15S89 1sow== X-Gm-Message-State: AOAM53149oZU5gxaswGH6vhBHd29stYbjrRiFdU/y0xWAWrbhg383nDD H/zreLzv7u8PPYrLNeyUkJwTmw== X-Google-Smtp-Source: ABdhPJyFMeTzYrQ25C/SOkBGds8oWQIcltw8DNk0rq7lyOF6TjCsCEwFGHehTztaqxs4yqkU9K5XMA== X-Received: by 2002:a1c:770c:: with SMTP id t12mr14515197wmi.65.1597653831551; Mon, 17 Aug 2020 01:43:51 -0700 (PDT) Received: from dell ([95.149.164.62]) by smtp.gmail.com with ESMTPSA id r11sm29259984wrw.78.2020.08.17.01.43.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2020 01:43:50 -0700 (PDT) Date: Mon, 17 Aug 2020 09:43:49 +0100 From: Lee Jones To: Christian Lamparter Cc: davem@davemloft.net, kuba@kernel.org, linux-kernel@vger.kernel.org, Christian Lamparter , Kalle Valo , Johannes Berg , linux-wireless@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as __maybe_unused Message-ID: <20200817084349.GS4354@dell> References: <20200814113933.1903438-1-lee.jones@linaro.org> <20200814113933.1903438-9-lee.jones@linaro.org> <7ef231f2-e6d3-904f-dc3a-7ef82beda6ef@gmail.com> <20200814164046.GO4354@dell> <0a144311-2085-60b5-ea36-554c6efbf7e9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0a144311-2085-60b5-ea36-554c6efbf7e9@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 14 Aug 2020, Christian Lamparter wrote: > On 2020-08-14 18:40, Lee Jones wrote: > > On Fri, 14 Aug 2020, Christian Lamparter wrote: > > > > > On 2020-08-14 13:39, Lee Jones wrote: > > > > 'ar9170_qmap' is used in some source files which include carl9170.h, > > > > but not all of them. Mark it as __maybe_unused to show that this is > > > > not only okay, it's expected. > > > > > > > > Fixes the following W=1 kernel build warning(s) > > > > > > Is this W=1 really a "must" requirement? I find it strange having > > > > Clean W=1 warnings is the dream, yes. > But is it a requirement? Depends how you define a requirement. This is required to successfully and usefully enable W=1 warnings in our testing builds without being overloaded with current issues. Something I know a great number of maintainers have been either trying to do, or at least wanting to do for a long time. Being able to enable W=1 builds at the subsystem level is extremely helpful in order to keep the kernel clean(er). As most subsystems don't (can't) have them enabled presently (due to being overwhelmed) they will likely creep/increase. So far, the following subsystems have been on-board with this (and are now clean, or very nearly clean, as a result): ASoC backlight cpufreq dmaengine gpio hwmon iio mfd misc mmc pinctrl pwm regulator remoteproc scsi spi usb video > > I would have thought most Maintainers would be on-board with this. > From what I know: It's no changes For changes' sake. Because otherwise this > would be pretty broken for maintainers. They could just write and revert the > same code over and over to prob up their LOC and commit counter. Wouldn't > you agree there? I don't agree at all. Why would anyone revert a fix? That act would be intentionally add a warning? A fools errand I think. > > The ones I've worked with thus far have certainly been thankful. Many > > had this on their own TODO lists. > Question is, do you really want to be just the cleanup crew there? Since > semantic patches came along and a lot of this has been automated. I'm happy to put in the work. Most people have been very grateful. If this work can be automated, than that would be wonderful. However, 18000 warnings (now down to 15000) tell me that this can not be the case. > I'm of course after something else. Like: "Isn't there a better way than > manually slapping __maybe_unused there to suppress the warning and call it a > day?" If you already went down these avenues and can confirm that there's no > alternative than this, then "fine". But if there is a better > method of doing this, then "let's go with that!". So for these kinds of issues we have a choice. In order of preference: 1. Genuinely unused; remove it 2. Used in a single location; move it to that location 3. Used in multiple, but not all locations: a. Mark as __maybe_unused b. Locate or create a special header file between users b. Duplicate it and place it in all used locations I went for 3a here, as 1 and 2 aren't valid. > > > __maybe_unused in header files as this "suggests" that the > > > definition is redundant. > > > > Not true. > > > > If it were redundant then we would remove the line entirely. > So, why adding __maybe_unused then? I find it not very helpful to > tell the compiler to "shut up" when you want it's opinion... > This was the vibe I got from gcc's attribute unused help text. Effectively, you're telling the compiler that it's not correct in certain circumstances, like this one. Here the variable is being used, but not by all users who share the header file. In other valid cases of its use the variable may only be used when a given CONFIG_* is enabled. __always_unused however does just tell the compiler to shut-up. :) If you have any better solutions, other than to let the compiler spout useless warnings which taint the build log and hide other, more important issues, then I'd be happy to hear them. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog