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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALzJLG9cLY8qqjFHGx6i=Gi-TH5EZ2Mq+TQOusX7=EoRDvx1tw@mail.gmail.com>
Date:   Sat, 22 Apr 2017 03:34:06 +0300
From:   Saeed Mahameed <saeedm@....mellanox.co.il>
To:     Ian Kumlien <ian.kumlien@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [RFC] change the default Kconfig value of mlx5_en

On Sat, Apr 22, 2017 at 2:10 AM, Ian Kumlien <ian.kumlien@...il.com> wrote:
> Sorry,
>
> Back again, fighting cold, hot whiskey has been consumed...
>
> Something like this would perhaps be a better solution:
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> index 60154a175bd3..fe192e247601 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> @@ -1139,6 +1139,10 @@ static int mlx5_load_one(struct mlx5_core_dev
> *dev, struct mlx5_priv *priv,
>
>  #ifdef CONFIG_MLX5_CORE_EN
>         mlx5_eswitch_attach(dev->priv.eswitch);
> +#else
> +       if (MLX5_CAP_GEN(dev, port_type) == MLX5_CAP_PORT_TYPE_ETH) {
> +               dev_info(&pdev->dev, "Ethernet device discovered but
> support not enabled in kernel.");
> +       }
>  #endif
>

Currently both MLX5_CORE=n and MLX5_CORE_EN=n as a default, the issue
you are seeing can occur only if you explicitly  set MLX5_CORE=y and
MLX5_CORE=n, Why would someone do this if he knows he wants Ethernet
support as well ? IMHO this print is redundant .

Anyway, Are you looking for RDMA support over ethernet (RoCE) ? and
you are not interested to have ethernet netdev support ?

if yes, I think this is something that can be achieved, but the
question is do we really need this ?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ