Received: by 2002:a05:6512:2355:0:0:0:0 with SMTP id p21csp205325lfu; Wed, 30 Mar 2022 20:54:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+bSOG8QhV6gxWhVHKHtQ5zT5dF8L4ZjqDICJrEXCJa02jewk80PEhYYpFQal88WI3w6it X-Received: by 2002:a17:90b:4ad2:b0:1c7:cee:b126 with SMTP id mh18-20020a17090b4ad200b001c70ceeb126mr3624565pjb.219.1648698855308; Wed, 30 Mar 2022 20:54:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648698855; cv=none; d=google.com; s=arc-20160816; b=d5jzQIugEHPlfN2/rCPUppkhHFHUni19g8R9F9ujtMvw+RP+T+cnPHKBcu3LwU+3og i2k0QHy03z1TtZn4uSaD6qS/czfsXOLbB/n3WxkVKp72Xs450gEPVT4gTPaiIw2pzUj0 yPLfnyUw79BygbfeqDq1OLH56+QMTg3+EGqz/pYVffRJcSwn3oZkXV7OhEvrnGJCHw5q KJc1WnGvkR9nvweASnav6GWKyxjhtau1/nH/iwRhJRgK792/sjp7yGDKSKqgXW6Ay0S8 gTnk4AYtdjTf1xtxD6QWp0+0r3lfLUItGIJ4TXYVIM5NZneIe4RgUhBAgOmDBS5ROkUx HMfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=nc9z3j2jxi+FrRfNGDqS68SB0aTB8VlUDCgHaat1Zms=; b=A4gHdmMjMFBz5VnjbXCe6AV4p2tmzNtSH2UJZkmekr3VB6TONzgW3yI6XUm0DyTBUA vpoYwXbM6KdiWMY9dF/USzCcWMt/8Y8HrrUy8KGPh6awNGe5dmnDFqVLjubhnNbv7sC+ YtxAFfw2Gf1rKV3HLBH28M1CiWfWk/KxQqAYpzRViF+yLYcdaPOF95bbW9GEVBfIz6y7 q4kz3XwnsxW6yNagYDFVhsDif37KJi6cMayS0c/NYOHSHyQPGCv1vGvIUxd03q/++qDL wG/LAkDw9lyVjPXowL4qh4VFAzR/uw5e7CwlntyC+xbyCv8OZn+NTa1DR4Nze6MTgLNY dxnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=bjse9zTw; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=oV1YFtiJ; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id y3-20020a1709029b8300b00153b2d16586si20577955plp.398.2022.03.30.20.54.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 20:54:15 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=bjse9zTw; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=oV1YFtiJ; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 82FB715B99A; Wed, 30 Mar 2022 20:06:49 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349049AbiC3Web (ORCPT + 99 others); Wed, 30 Mar 2022 18:34:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242973AbiC3Wea (ORCPT ); Wed, 30 Mar 2022 18:34:30 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3BFB75BE46 for ; Wed, 30 Mar 2022 15:32:44 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1648679562; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nc9z3j2jxi+FrRfNGDqS68SB0aTB8VlUDCgHaat1Zms=; b=bjse9zTwIphvNyS4pc9RJ9csKA8bs18yjT2OUC0lE9Gs6TSkCVs+4HirONEIpSm/1mnIs4 VR1Qvf8eaSP5GUKDU6uywSnY+X6ndEl78cfuEELNtkyBaHP0PC0AkyZu73A3gbMzKdMhJQ CL0RIXtlc6IjJtsPomQstitlNnQn+Qhf/c2fKkmH8Q0nO8Mt3dTpVUSBhjDzNyoqw4cD4J 50R4fk6dWPqyC1j8/UkcZYxU+pzkxXRatX4+P+yImULQL/Ud7i7jy4f/7ISnjFRUXAT5ul 2DlAMDC5d5b3WAvDC49k/RkeqyP+wT8zH1bYMGEV4o8sYR1RQIjQxSbR5gThZA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1648679562; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nc9z3j2jxi+FrRfNGDqS68SB0aTB8VlUDCgHaat1Zms=; b=oV1YFtiJk/VZcX4CXrMCwe+VBuHk2bq65de5apEEtvaqQT3ZuInnvnE4alKeEgfMXkTkDX FdiFAue3yRrSNqCg== To: Andy Shevchenko , Dave Hansen Cc: Neil Armstrong , mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: undef REG_IN/REG_OUT to avoid define collisions In-Reply-To: References: <20220330152808.1461758-1-narmstrong@baylibre.com> Date: Thu, 31 Mar 2022 00:32:41 +0200 Message-ID: <8735iznkae.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 30 2022 at 18:54, Andy Shevchenko wrote: > On Wed, Mar 30, 2022 at 08:33:26AM -0700, Dave Hansen wrote: >> On 3/30/22 08:28, Neil Armstrong wrote: >> > diff --git a/arch/x86/include/asm/arch_hweight.h b/arch/x86/include/asm/arch_hweight.h >> > index ba88edd0d58b..139a4b0a2a14 100644 >> > --- a/arch/x86/include/asm/arch_hweight.h >> > +++ b/arch/x86/include/asm/arch_hweight.h >> > @@ -52,4 +52,7 @@ static __always_inline unsigned long __arch_hweight64(__u64 w) >> > } >> > #endif /* CONFIG_X86_32 */ >> > >> > +#undef REG_IN >> > +#undef REG_OUT >> >> Wouldn't it be a bit less hackish to give these a more qualified name >> like HWEIGHT_REG_IN? Absolutely. > Either way, would it be good to undef them here anyway? No. Unconditional #undef is a guarantee for hard to diagnose trouble because it papers over namespace collisions. You can end up with the wrong constants in your binary which might work well except for the once in the blue moon corner case. Been there and stared at such nonsense for weeks... Name spaces exist for a reason and we are not short of characters here. Thanks, tglx