From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Kaehlcke Subject: Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro Date: Mon, 9 Oct 2017 10:29:17 -0700 Message-ID: <20171009172917.GR173745@google.com> References: <1507140439.4434.14.camel@perches.com> <20171004184957.GO173745@google.com> <20171004152203.2a4f564d@cakuba.netronome.com> <20171004231649.GP173745@google.com> <20171004162550.20edf18c@cakuba.netronome.com> <20171004175603.4ba68737@cakuba.netronome.com> <20171004190621.4f0a8f83@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Jakub Kicinski , Joe Perches , "David S . Miller" , Simon Horman , Dirk van der Merwe , oss-drivers@netronome.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Renato Golin , Guenter Roeck , Doug Anderson To: Manoj Gupta Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org El Wed, Oct 04, 2017 at 07:13:26PM -0700 Manoj Gupta ha dit: > On Wed, Oct 4, 2017 at 7:06 PM, Jakub Kicinski > wrote: > > On Wed, 4 Oct 2017 18:50:04 -0700, Manoj Gupta wrote: > >> On Wed, Oct 4, 2017 at 5:56 PM, Jakub Kicinski wrote: > >> > On Wed, 4 Oct 2017 17:38:22 -0700, Manoj Gupta wrote: > >> >> On Wed, Oct 4, 2017 at 4:25 PM, Jakub Kicinski wrote: > >> >> > On Wed, 4 Oct 2017 16:16:49 -0700, Matthias Kaehlcke wrote: > >> >> >> > > Thanks for the suggestion. This seems a viable alternative if David > >> >> >> > > and the NFP owners can live without the extra checking provided by > >> >> >> > > __BF_FIELD_CHECK. > >> >> >> > > >> >> >> > The reason the __BF_FIELD_CHECK refuses to compile non-constant masks > >> >> >> > is that it will require runtime ffs on the mask, which is potentially > >> >> >> > costly. I would also feel quite stupid adding those macros to the nfp > >> >> >> > driver, given that I specifically created the bitfield.h header to not > >> >> >> > have to reimplement these in every driver I write/maintain. > >> >> >> > >> >> >> That make sense, thanks for providing more context. > >> >> >> > >> >> >> > Can you please test the patch I provided in the other reply? > >> >> >> > >> >> >> With this patch there are no errors when building the kernel with > >> >> >> clang. > >> >> > > >> >> > Cool, thanks for checking! I will run it through full tests and queue > >> >> > for upstreaming :) > >> >> > >> >> Just to let you know, using __BF_FIELD_CHECK macro will not Link with > >> >> -O0 (GCC or Clang) since references to __compiletime_assert_xxx will > >> >> not be cleaned up. > >> > > >> > Do you mean the current nfp_eth_set_bit_config() will not work with -O0 > >> > on either complier, or any use of __BF_FIELD_CHECK() will not compile > >> > with -O0? > >> > >> Any use of __BF_FIELD_CHECK. The code will compile but not link since > >> calls to ____compiletime_assert_xxx (added by compiletime_assert > >> macro) will not be removed in -O0. > > > > Why would that be, it's just a macro? Does it by extension mean any > > use of BUILD_BUG_ON_MSG() will not compile with -O0? > > You have to look at the the code added once the macro is expanded :). > Please look at implementation of compiletime_assert at > http://elixir.free-electrons.com/linux/v4.12.14/source/include/linux/compiler.h#L507 > It creates a call to __compiler_assert_xxx inside a loop which is not > cleaned up in -O0. I just saw that v4.14 will have a fix for that: commit c03567a8e8d5cf2aaca40e605c48f319dc2ead57 Author: Joe Stringer Date: Thu Aug 31 16:15:33 2017 -0700 include/linux/compiler.h: don't perform compiletime_assert with -O0 Obviously this means that the checks aren't performed, however that shouldn't be an issue since AFAIK the kernel doesn't officially support -O0 builds in the first place.