Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2235546pxb; Sat, 7 Nov 2020 14:35:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJztkj2zLS7QfDm/zLeEtR7u6vUg6cSe5S74+6HkL38pVpStF9sZtaa44hdFz3UpPHQKBZy3 X-Received: by 2002:a17:907:2712:: with SMTP id w18mr7905365ejk.130.1604788502427; Sat, 07 Nov 2020 14:35:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604788502; cv=none; d=google.com; s=arc-20160816; b=EGG9a9N1DfsSyKOHK+hBnqYZfDsdVb4r4zBDL0nnfVQoz3Hy4EUUeB2oRRKmNJx7gP 4LKKWIi8N1sbLDRNO9IjnLyMEGrgItYsu7WxfrluAAW8YNLiB1hmrsg/JS/1qm7mCbHE Ll47r1bcdIE3Zv44qhaplp3c8hFJwh8emvOSRUBCAVoahCgACWpVAjvtN5NiIysgS185 s5HyU/yK+UnDyJ9+KuD1FZVqfQjw7B8ZYqOM36j5z3DBZZwQ1ShuhXqrNnTYkhZzT3Z9 5BwgC6wXnhOtlZ+OXE8osCu0wnR/1Y6jlNCrKw11s39uAN6Ug2/0Xo/ugZCzFQC8zcxX VzNg== 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; bh=hWecBqZoRkzQjfyFivKgVQPHm9Tj2iPF5AnULnCJEto=; b=dB+qanWlZq4AIbFeRfS2CSv6yDEgxHqqd8bhZjQd82kNWT1c5u1/GOssBNZuxBsYfg R7gN0Ai7xNbdahh5E3S3h7/jVwEUCwt0/D5wess86p+9qNZXeshGHVtie/CWu2Ktn9A4 dBAbUV/TeVb4/d5nH87w54SZzTtheuEC2c5/IHHINq8BiEXRYEXKk0IUwLP5mzcE37lC SvxODJGaoO+e9Q6SSILMFsAEp4P/ioENBhCC6hItlZ2JrwixPg3xjMyAHxQpFsZIiF7n t4iI1DE2VL9j/ZbLr2yx2xZ4esxQ/xezyQlY+wuvFKn4ecfu5Jl3imzfOUfc3ZJLIuni n/3A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q25si3941292edr.215.2020.11.07.14.34.36; Sat, 07 Nov 2020 14:35:02 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726607AbgKGWdN (ORCPT + 99 others); Sat, 7 Nov 2020 17:33:13 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:41118 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725838AbgKGWdN (ORCPT ); Sat, 7 Nov 2020 17:33:13 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kbWlZ-005qOv-8H; Sat, 07 Nov 2020 23:33:01 +0100 Date: Sat, 7 Nov 2020 23:33:01 +0100 From: Andrew Lunn To: Joe Perches Cc: Alex Shi , Florian Fainelli , Vivien Didelot , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net/dsa: remove unused macros to tame gcc warning Message-ID: <20201107223301.GY933237@lunn.ch> References: <1604641050-6004-1-git-send-email-alex.shi@linux.alibaba.com> <20201106141820.GP933237@lunn.ch> <24690741-cc10-eec1-33c6-7960c8b7fac6@gmail.com> <6ed68a7898c5505d3106223b7ad47950a0c79dc3.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6ed68a7898c5505d3106223b7ad47950a0c79dc3.camel@perches.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 07, 2020 at 09:39:42AM -0800, Joe Perches wrote: > On Sat, 2020-11-07 at 20:54 +0800, Alex Shi wrote: > > 在 2020/11/7 上午12:39, Florian Fainelli 写道: > > > > It is good to remember that there are multiple readers of source > > > > files. There is the compiler which generates code from it, and there > > > > is the human trying to understand what is going on, what the hardware > > > > can do, how we could maybe extend the code in the future to make use > > > > of bits are currently don't, etc. > > > > > > > > The compiler has no use of these macros, at the moment. But i as a > > > > human do. It is valuable documentation, given that there is no open > > > > datasheet for this hardware. > > > > > > > > I would say these warnings are bogus, and the code should be left > > > > alone. > > > Agreed, these definitions are intended to document what the hardware > > > does. These warnings are getting too far. > > > > Thanks for all comments! I agree these info are much meaningful. > > Is there other way to tame the gcc warning? like put them into a .h file > > or covered by comments? > > Does _any_ version of gcc have this warning on by default? > > I still think my proposal of moving the warning from W=2 to W=3 > quite reasonable. > > Another possibility is to turn the warning off altogether. Lets tern the question around first. How many real bugs have you found with this warning? Places where the #define should of been used, but was not? Then we can get an idea of the value of this warning. My guess would be, its value is ~ 0 for the kernel. If so, we should just turn it off. Andrew