Re: [PATCH] brcmfmac: fix compilation error seen while building only brcmfmac sub-directory

Arend Van Spriel <[email protected]>
Newsgroups dev.linux.lists.brcm80211,org.kernel.vger.linux-wireless
Message-ID <[email protected]>
On April 16, 2025 8:01:58 AM Gokul Sivakumar 
<[email protected]> wrote:

> The function prototypes of brcmf_debug_create_memdump(), 
> brcmf_debugfs_get_devdir()
> and brcmf_debugfs_add_entry() are protected by the "DEBUG" config MACRO in 
> debug.h,
> while the corresponding function definitions remains unprotected in 
> debug.c, so add
> the missing MACRO definition check.
>
> Compilation error seen while building brcmfmac sub-directory with 
> CONFIG_BRCMDBG=y
> is captured below.
>
> $ make M=drivers/net/wireless/broadcom/brcm80211/brcmfmac
>
> make[1]: Entering directory 
> '/root/wireless-next/drivers/net/wireless/broadcom/brcm80211/brcmfmac'
> CC [M]  debug.o
> debug.c:17:5: error: redefinition of ‘brcmf_debug_create_memdump’
> 17 | int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
> |     ^~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from bus.h:12,
>        from debug.c:13:
> debug.h:136:5: note: previous definition of ‘brcmf_debug_create_memdump’ 
> with type
> ‘int(struct brcmf_bus *, const void *, size_t)’ {aka ‘int(struct brcmf_bus 
> *, const void *, long unsigned int)’}
> 136 | int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
> |     ^~~~~~~~~~~~~~~~~~~~~~~~~~
> debug.c:45:16: error: redefinition of ‘brcmf_debugfs_get_devdir’
> 45 | struct dentry *brcmf_debugfs_get_devdir(struct brcmf_pub *drvr)
> |                ^~~~~~~~~~~~~~~~~~~~~~~~
> debug.h:127:30: note: previous definition of ‘brcmf_debugfs_get_devdir’ 
> with type
> ‘struct dentry *(struct brcmf_pub *)’
> 127 | static inline struct dentry *brcmf_debugfs_get_devdir(struct 
> brcmf_pub *drvr)
> |                              ^~~~~~~~~~~~~~~~~~~~~~~~
> debug.c:50:6: error: redefinition of ‘brcmf_debugfs_add_entry’
> 50 | void brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,
> |      ^~~~~~~~~~~~~~~~~~~~~~~
> debug.h:132:6: note: previous definition of ‘brcmf_debugfs_add_entry’ with type
> ‘void(struct brcmf_pub *, const char *, int (*)(struct seq_file *, void *))’
> 132 | void brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,
> |      ^~~~~~~~~~~~~~~~~~~~~~~
> make[3]: *** [/root/wireless-next/scripts/Makefile.build:203: debug.o] Error 1
> make[2]: *** [/root/wireless/wireless-next/Makefile:2006: .] Error 2
> make[1]: *** [/root/wireless/wireless-next/Makefile:248: __sub-make] Error 2
> make[1]: Leaving directory 
> '/root/wireless-next/drivers/net/wireless/broadcom/brcm80211/brcmfmac'
> make: *** [Makefile:248: __sub-make] Error 2

To be honest I am not sure whether to accept this patch or not. The way the 
makefiles are setup was never intended to support this usage. The cause of 
the failure lies within the fact that the makefile in 
drivers/net/wireless/broadcom/brcm80211 passes -DDEBUG to the subdirs. Also 
I recall using the M=<dir> option result in out-of-tree taint. That said 
the following does work:

$ make M=drivers/net/wireless/broadcom/brcm80211 modules

So I tend to discard this patch.

Regards,
Arend

> Signed-off-by: Gokul Sivakumar <[email protected]>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> index eecf8a38d94a..3cb50140eb2f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> @@ -14,6 +14,7 @@
> #include "fweh.h"
> #include "debug.h"
>
> +#ifdef DEBUG
> int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
> size_t len)
> {
> @@ -54,3 +55,4 @@ void brcmf_debugfs_add_entry(struct brcmf_pub *drvr, 
> const char *fn,
> debugfs_create_devm_seqfile(drvr->bus_if->dev, fn,
> drvr->wiphy->debugfsdir, read_fn);
> }
> +#endif
> --
> 2.47.0
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.