From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754660AbdKNLvI (ORCPT ); Tue, 14 Nov 2017 06:51:08 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:51458 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754493AbdKNLuy (ORCPT ); Tue, 14 Nov 2017 06:50:54 -0500 Date: Tue, 14 Nov 2017 12:50:59 +0100 From: Greg Kroah-Hartman To: Arnd Bergmann Cc: Nicolai Stange , linux-kernel@vger.kernel.org Subject: Re: [PATCH] debugfs: fix debugfs_real_fops() build error Message-ID: <20171114115059.GB26814@kroah.com> References: <20171114114109.257057-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171114114109.257057-1-arnd@arndb.de> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 14, 2017 at 12:40:31PM +0100, Arnd Bergmann wrote: > Some drivers use debugfs_real_fops() even when CONFIG_DEBUG_FS is disabled, > which now leads to a build error: > > In file included from include/linux/list.h:9:0, > from include/linux/wait.h:7, > from include/linux/wait_bit.h:8, > from include/linux/fs.h:6, > from drivers/net/wireless/broadcom/b43legacy/debugfs.c:26: > drivers/net/wireless/broadcom/b43legacy/debugfs.c: In function 'b43legacy_debugfs_read': > drivers/net/wireless/broadcom/b43legacy/debugfs.c:224:23: error: implicit declaration of function 'debugfs_real_fops'; did you mean 'debugfs_create_bool'? [-Werror=implicit-function-declaration] > > My first impulse was to add another 'static inline' dummy function > returning NULL for it, which would work fine. However, most callers > feed the pointer into container_of(), so it seems a little dangerous > here. Since all the callers are inside of a read/write file operation > that gets eliminated in this configuration, so having an 'extern' > declaration seems better here. If it ever gets used in a dangerous > way, that will now result in a link error. Ok, but does your patch really "fix" anything? The linker should now complain, not the compiler, for these types of configurations? thanks, greg k-h