From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5300C3815CE for ; Thu, 19 Mar 2026 22:21:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773958870; cv=none; b=r687EoYq0axfgW9p6r2DCzUs1lpUKi3mYRykpZ3Sc2ZJaSd/jWOYTAbK5YKNJh0lm9aDABw2euFRcoTtaL4yoGKp+JEJFGObBoLO/i0P+o0z+I4d+FB9etuMUxbuIgNyqIbaMxO4JBegH9DEetrokBADOMLlAw526evuKvbOjYM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773958870; c=relaxed/simple; bh=ZBH6NS3ja5+c+YNg5rCrzPVnOSo36P3Iy+l5/5xqIYI=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=q0ZEx/tfVXVuNi4IHzPRUaDwe35TDOmjl7PMOjP4xULPRXyumfqkZZ7PRz0F8kAN0KE5U1uQAqiTgONhOnoCdc3vf7B3BNTKA6c5DuyThsUexLBfLA8TGKV5tsUpLu+U4GNSr3L2eWDJOJoRce49et6pLTCaDEFK0C6czkPeugM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lah0f46P; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lah0f46P" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-486fe655187so3780895e9.2 for ; Thu, 19 Mar 2026 15:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773958867; x=1774563667; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=qlrYoKxU1+2i+RAnVyvubSDpYIvMgPyLxmBALMH7/EY=; b=lah0f46PxYUE96FDaKt9sRDQO3c+eQTeoy16qTYD+rRoZovaqq9Ava1AMowd50nPFt F2eZ3NBs/VEVi92jrIq6DRzXl9PG5hJtSxOc/rb5ldJltw+RxpuzVy7S2ZUR3kE267uw iZVAs6wF0co9kOXCjtnrlwqsH23qo0lbTsA2bdCmd0UwpPOMGIEFeD5KsY0tKE3rMD3W llQnP2GrMJZldU4TSq6TpPyG42/pwlW5m/SRAI2QCTauYO0QnQT8ltDir6n40J/CpB8o Kpdl1LHFotZv09uRgMXe3FidU8P3v/z8ffBhkc/zHVk9tIO8FVo8XyCNdCq9oVY8Nt3A CcXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773958867; x=1774563667; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qlrYoKxU1+2i+RAnVyvubSDpYIvMgPyLxmBALMH7/EY=; b=C3ofF0m2WHgleSefoZ4e15fBWL6KxEmyD5DsW+yVYZXSVMsjrwj2FRPo0Ba5sKHlOp dSTIp+J5Jtn0u0Fmb5vhUFmioEhLx64NKLa0uzA6oy1zUoBNVRft8DQbOj3hyK9V/9AZ uJQpWFDx+DEmfb+7hAKAIEiDKHYUD7TVlyR0I8w68Pbpr58qYa4yCoRTuv71e2VMNEQz bQkUVdCvQ4h3HHX3qnuq3eLo7Jm03KdGqBCKh2jjuFtSBoVZvm+SEeF0ZmIGRZo7Us9h OSXXzWcEblR5agT1Sktz4h7VZwlN6VV63zA53pXiowh+fQI8BNzgVlPW5cCAMG0svJhP kWqg== X-Forwarded-Encrypted: i=1; AJvYcCUh/sBpSxmp2rbi+k9IQSgo8FcJRNc7Xmbo8mS2/LiPnVEF71IWHvoh3/SVjFkkFECa6cj1dnHH0+jVKkA=@vger.kernel.org X-Gm-Message-State: AOJu0Yyai060FHLXywg4T1ssT/lKVCBDjcftk4tD74uA7mnQNa+mbdOL DFcY8LwvsuXJIIG1ekpK6hn+LSald1Wa23r3PhwOWgTDTGmw2buXH+/e X-Gm-Gg: ATEYQzwCQHlzDb8XZ/q+3y8wA2n2CPTZYOCKdeNLIO6Eow7lO4kEPujWUAD0o45B13M phVdFq0P209uX8t7X216RdsYiZHTrukm7AXZUGgupojzDq+Zqr5CWql5g0DzuMC3fir2TLqzLAy jHZDfof6Pkp+UlCjpVqzOZ3BBrBWr9waKVXmbuyJpuP+zAyGRmzcSnY/tK+wYpFjWCrSXt4o7RC LLa/zWtJfkYEmYQjKWy6kDj7CAbqB33AMm590qzxoTZN4xjW/Bkqr51ZBeo9fjDedYOorIWdm3+ NIoNY3bpvsT9ulRjx7PFOVd8QtGLzeOevsHVtTMQ4IAguob08d9VbYE4S/j3i/THTKIA5K9pmPC PuoMjypTPcNYFqKQXLsDKFYARPZpO6b8zw8PBeZmx6C+QZR6XMfqI6RSlHDbem36lWyT+JDEvOe tMZ8oVqC9nGJNO1QmjnvX8Ek7+XDWPkID9In8Q7SHbV305PPUpjY7YEVmeLvNNpaEODsdC8o/eL 24yL0dKcQ== X-Received: by 2002:a05:600d:8401:b0:485:35a4:939f with SMTP id 5b1f17b1804b1-486fee297bcmr8481075e9.28.1773958866366; Thu, 19 Mar 2026 15:21:06 -0700 (PDT) Received: from ?IPV6:2a01:e11:5402:d840:f1ee:c5d:74e4:6e19? ([2a01:e11:5402:d840:f1ee:c5d:74e4:6e19]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486fe889652sm7216775e9.2.2026.03.19.15.21.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Mar 2026 15:21:06 -0700 (PDT) Message-ID: Date: Thu, 19 Mar 2026 23:20:59 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Aldo Conte Subject: Re: [PATCH] perf/x86/intel/p4: Fix unused variable warning in p4_pmu_init() To: Dave Hansen , peterz@infradead.org, mingo@redhat.com, acme@kernel.org, namhyung@kernel.org, tglx@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com Cc: mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, james.clark@linaro.org, hpa@zytor.com, x86@kernel.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org References: <20260319152210.210854-1-aldocontelk@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/19/26 4:30 PM, Dave Hansen wrote: > On 3/19/26 08:22, Aldo Conte wrote: >> This patch prints the full content of Model-Specific Register >> via `pr_cont` and so both the low and high part. It is also >> very useful to have the contents of MSR_IA32_MISC_ENABLE >> in dmesg for debugging purposes. > > I'd probably just switch it over to rdmsrq(): > > unsigned int misc; > > rdmsr(MSR_IA32_MISC_ENABLE, misc); > > if (!(misc & MSR_IA32_MISC_ENABLE_EMON)) { > ... > > I'm kinda surprised the compiler is complaining, though. I suspect we've > got a ton of these around where one of the registers isn't used. Okay, your comment actually caught my attention. I looked into it further and noticed that `rdmsr` is defined as a macro in both `arch/x86/include/asm/msr.h` and `/arch/x86/include/asm/paravirt.h`. In the first header, however, the expansion shows that high and low are evaluated as follows: (void)((low) = (u32)__val); \ (void)((high) = (u32)(__val >> 32)); \ so with a sort of warning suppressor, whereas in the second header, the (void) is not used. Now, the file `arch/x86/events/intel/p4.c` includes `msr.h` and thus the expansion of `rdmsr`, which in theory contains `void`. However, scrolling through the msr.h file, you can see that if the CONFIG_PARAVIRT_XXL configuration parameter is defined, then the second header (paravirt.h) is included, which then causes rdmsr to expand to #define rdmsr(msr, val1, val2) \ do { \ u64 _l = paravirt_read_msr(msr); \ val1 = (u32)_l; \ val2 = _l >> 32; \ } while (0) Since there is no (void) in front of val1 and val2, this will trigger a warning. I admit I'm a novice in this field, so what do you suggest is the best fix at this point? Should I use the “warning suppressor" with something like (void) val1 = (u32)_l; \ (void) val2 = _l >> 32; \ or implement the solution you suggested?