[PATCH 2/2] nvme: keyring: fix conditional compilation

[Arnd Bergmann]

On Wed, Oct 25, 2023, at 10:12, Hannes Reinecke wrote:
> From: Arnd Bergmann <arnd at arndb.de>
>
> The keyring and auth functions can be called from both the host and
> the target side and are controlled by Kconfig options for each of the
> combinations, but the declarations are controlled by #ifdef checks
> on the shared Kconfig symbols.
>
> This leads to link failures in combinations where one of the frontends
> is built-in and the other one is a module, and the keyring code
> ends up in a module that is not reachable from the builtin code:
>
> ld: drivers/nvme/host/core.o: in function `nvme_core_exit':
> core.c:(.exit.text+0x4): undefined reference to `nvme_keyring_exit'
> ld: drivers/nvme/host/core.o: in function `nvme_core_init':
> core.c:(.init.text+0x94): undefined reference to `nvme_keyring_init
>
> ld: drivers/nvme/host/tcp.o: in function `nvme_tcp_setup_ctrl':
> tcp.c:(.text+0x4c18): undefined reference to `nvme_tls_psk_default'
>
> Address this by moving nvme_auth_init()/nvme_auth_exit() into
> module init/exit functions for the keyring module.
>
> Fixes: be8e82caa6859 ("nvme-tcp: enable TLS handshake upcall")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Hannes Reinecke <hare at suse.de>

Your patch looks good to me, and I think this fixes a
separate problem with missing the initialization of the
keyring when the kernel has only the target driver but
no host support, but it has nothing to do with the changelog
I wrote above and does not fix the build regression
I described.

     Arnd