Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754331AbdIZEPp (ORCPT ); Tue, 26 Sep 2017 00:15:45 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:37325 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754149AbdIZEPo (ORCPT ); Tue, 26 Sep 2017 00:15:44 -0400 X-Google-Smtp-Source: AOwi7QA3b2G1U/V8vOCREQVftQyLoT4t5jTfwL1D8HOJysddV6iDjjGhXdT5fSQMoAqcuqfqCgxMBj9Im2esvWkRHvs= MIME-Version: 1.0 In-Reply-To: <20170926033539.hxwrjjpqeadkj4ky@x> References: <20170926033539.hxwrjjpqeadkj4ky@x> From: Nick Desaulniers Date: Mon, 25 Sep 2017 21:15:42 -0700 Message-ID: Subject: Re: unneeded internal declaration To: Josh Triplett Cc: Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , kay@vrfy.org, avi@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1151 Lines: 26 Good find, will send a patch with your suggestion. The documentation for x86_match_cpu() says: 25 * Arrays used to match for this should also be declared using 26 * MODULE_DEVICE_TABLE(x86cpu, ...) Will save another patch for a friend, then. On Mon, Sep 25, 2017 at 8:35 PM, Josh Triplett wrote: > On Mon, Sep 25, 2017 at 08:07:41PM -0700, Nick Desaulniers wrote: >> today I noticed I was getting the warning: >> >> arch/x86/kvm/vmx.c:64:32: warning: variable 'vmx_cpu_id' is not needed >> and will not be emitted [-Wunneeded-internal-declaration] >> >> seems like this was added in commit: e9bda3b3d0ce7 "KVM: VMX: >> Auto-load on CPUs with VMX" >> >> seems like other call sites of the MODULE_DEVICE_TABLE typically get >> added to an id_table of various driver structs. Should that be the >> case here, or would a `__unused` modifier be a way forward (if so, >> please confirm, would be a good first bug for a friend)? > > Many of those users seem to have an x86_match_cpu call in their init > function. vmx has its own checks; perhaps it'd make sense to use that > instead, which would also eliminate the warning?