netdev - Re: [PATCH] [net-next] net/mlx5e: select CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK8P3a1R3jP-qes5ZbbM4xETGvrCzdNahXENPqmXyh9+Xy-ipw@mail.gmail.com>
Date:   Thu, 29 Jun 2017 09:48:57 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        Linux Netdev List <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [net-next] net/mlx5e: select CONFIG_MLXFW

On Thu, Jun 29, 2017 at 5:47 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> On Wed, Jun 28, 2017 at 11:10 PM, Arnd Bergmann <arnd@...db.de> wrote:
>> With the introduction of mlx5 firmware flash support, we get a link
>> error with CONFIG_MLXFW=m and CONFIG_MLX5_CORE=y:
>>
>> drivers/net/ethernet/mellanox/mlx5/core/fw.o: In function `mlx5_firmware_flash':
>> fw.c:(.text+0x9d4): undefined reference to `mlxfw_firmware_flash'
>
> Thanks Arnd, I got a report on that from Jakub but you were before me here..
>
>> We could have a more elaborate method to force MLX5 to be a loadable
>> module in this case, but the easiest fix seems to be to always enable
>> MLXFW as well, like we do for CONFIG_MLXSW_SPECTRUM, which is the other
>> user of mlxfw_firmware_flash.
>
> We would not want to force mlx5 users to build mlxfw.
>
> So lets either use the more elaborate method or maybe instead of using
> IS_ENABLED in mlxfw.h use IS_REACHABLE (this was suggested by Jakub)

Sure, that works. I generally try to avoid IS_REACHABLE(), as I find it more
confusing than adding a dependency like

           depends on MLXFW || MLXFW=n

(and yes, I was the one who introduced IS_REACHABLE() ;-) ).

      Arnd