Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3245398pxb; Fri, 12 Feb 2021 13:06:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJyeXLPMmNzVpz0Y/LOpqQtgiOyiErhPzscHfM/MWCrb2yQ8yvRCRAo3Ryi59zH/O1J3jpvE X-Received: by 2002:aa7:d98f:: with SMTP id u15mr5265619eds.267.1613164000202; Fri, 12 Feb 2021 13:06:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613164000; cv=none; d=google.com; s=arc-20160816; b=PyaVgT2T+Ar3RB8llr3NL0HHcERdmwcH11QLeHDjs3PI1vxNP0roiFn+HXqY6YZtzT jaTvyuTYP8E+sXfTzyrOdTwNmVXZX0RmRSmPdAT7H0pvmswsQhukKb0IxbNGRJkvk4Nt SOXTz8/i+dW6kVSxNQaqvD57KgCmTuukoWNzzZpIyqP+qEjnPeC9kYmnbtDHMakryGkP M+TGKk18mx+P86TJfWZGUeb2HOCSlImS2Fhs58pDBpvJDcIfJ+87Ivr08EC1MFJC9L0L WdPUgyeBEM3n1b/uPFhRHPpFHmu2a43V29tcUdC5o+HHLe8yCBHeWdFzNs8XqNMhJnyl ck+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:date:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version :dkim-signature; bh=5ZNOuzrCABImHtzkirjyyy2xPODlN9fwiVLuSOeJLII=; b=sggz3QSNKzN5+fjvdzvq2hQ1w5Eb7lDG3DsDyfCIZkIYeSiSl4c6is8+jx+Y8p6aCB +zVjYMZt529cTFdVkpBx2U+sWaMKiKXNwsGT3aerR8jX9fmZ5fiBgx3/S9q371WcwwbN iuiNJeVh9VMLjGihBI037pW032hDDvEseg7tenk5Fh/uIBwCJ4LdP1Hl7+gA05rbuoup BJ440dK7UT+sNSykE/EPOrN9tAV8qzzLr5o0m8AIJaJXs+3uFM4fcQ1gt1kjgRQMqagH 8oZQXh35iD2TUN2NCdm27PB/5MQvcdWjBsmqIFAMGZzMcIMGyMoABCqwK/MjgdgSH7Md MiiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=L8vv2t4t; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id zh15si6797984ejb.424.2021.02.12.13.06.15; Fri, 12 Feb 2021 13:06:40 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=L8vv2t4t; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231513AbhBLVDO (ORCPT + 99 others); Fri, 12 Feb 2021 16:03:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:58032 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231289AbhBLVDD (ORCPT ); Fri, 12 Feb 2021 16:03:03 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 77F8864E05; Fri, 12 Feb 2021 21:02:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613163742; bh=W+5rNCA1AtqnGKfforyDrX1jEmPAq1AoeUYShAARidk=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=L8vv2t4t8eAuoCqn8NxiLKXPHOLn2qbZG/rTldBEck1qE3UJ9ZQgBMmDyAS+LCWPW EzmQrYymjIjWzdM9L/7FXHZGGuj4mL3xtQEcEf8CqaYplO6L5RYs8XX06VCEcsrfdR DnZefkSwJ3C/7GBHqDkPzplqR/1x05jRlJKJ6qT2qfEMeI8gZgeYtGj7iTUFb1gaWJ 0ewKJtGcnZgMY3nAWLZLIyhSM+nXjoN/Oz5tcLNPp2ONVxpr8E+MxgzJz7ExgeG7/5 lQhWIt1CShxke8FA18oo80Hy1k04ysgkM9gd+JOi/WRC9EeZrRZTWgw/1ZKPKae8Jz RI+6N32IPbIKg== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20210212092016.GF4572@dell> References: <20210126124540.3320214-1-lee.jones@linaro.org> <161307643148.1254594.6590013599999468609@swboyd.mtv.corp.google.com> <20210211211054.GD4572@dell> <161309925025.1254594.6210738031889810500@swboyd.mtv.corp.google.com> <20210212092016.GF4572@dell> Subject: Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock From: Stephen Boyd Cc: linux-kernel@vger.kernel.org, Ahmad Fatoum , Andy Gross , Avi Fishman , Benjamin Fair , Bjorn Andersson , Boris BREZILLON , Chen-Yu Tsai , Emilio =?utf-8?q?L=C3=B3pez?= , Fabio Estevam , Geert Uytterhoeven , Jan Kotas , Jernej Skrabec , Jonathan Hunter , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-omap@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org, Loc Ho , Maxime Ripard , Michael Turquette , Michal Simek , Nancy Yuen , Nuvoton Technologies , NXP Linux Team , openbmc@lists.ozlabs.org, Patrick Venture , Pengutronix Kernel Team , Peter De Schrijver , Philipp Zabel , Prashant Gaikwad , Rajan Vaja , Rajeev Kumar , Richard Woodruff , Russell King , Sascha Hauer , Shawn Guo , Shiraz Hashim , =?utf-8?q?S=C3=B6ren?= Brinkmann , Tali Perry , Tero Kristo , Thierry Reding , Tomer Maimon , Viresh Kumar To: Lee Jones Date: Fri, 12 Feb 2021 13:02:21 -0800 Message-ID: <161316374113.1254594.14156657225822268891@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Lee Jones (2021-02-12 01:20:16) > On Thu, 11 Feb 2021, Stephen Boyd wrote: >=20 > > Quoting Lee Jones (2021-02-11 13:10:54) > > > On Thu, 11 Feb 2021, Stephen Boyd wrote: > > >=20 > > > > Quoting Lee Jones (2021-01-26 04:45:19) > > > > > This set is part of a larger effort attempting to clean-up W=3D1 > > > > > kernel builds, which are currently overwhelmingly riddled with > > > > > niggly little warnings. > > > > >=20 > > > > > This is the last set. Clock is clean after this. > > > >=20 > > > > Is it possible to slam in some patch that makes W=3D1 the default f= or the > > > > clk directory? I'm trying to avoid seeing this patch series again. > > >=20 > > > One of my main goals of this project is that everyone (contributors, > > > maintainers auto-builder robots etc) will be enabling W=3D1 builds > > > *locally*. > > >=20 > > > This isn't something you'll want to do at a global (i.e. in Mainline) > > > level. That's kinda the point of W=3D1. > > >=20 > >=20 > > Agreed, but is it possible to pass W=3D1 in the drivers/clk/Makefile? >=20 > That would circumvent the point of W=3D1. Level-1 warnings are deemed, > and I'm paraphrasing/making this up "not worth rejecting pull-requests > over". In contrast, if Linus catches any W=3D0 warnings at pull-time, > he will reject the pull-request as 'untested'. >=20 > W=3D1 is defiantly something you'll want to enable locally though, and > subsequently push back on contributors submitting code adding new > ones. >=20 Why should I install a land mine for others to trip over? Won't that just take them more time because they won't know to compile with W=3D1 and then will have to go for another round of review while I push back on them submitting new warnings?