From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chavva, Chandrakala" <Chandrakala.Chavva@cavium.com>
Subject: Re: [PATCH v12 03/10] netdev: cavium: octeon: Add Octeon III BGX
 Ethernet Nexus
Date: Fri, 29 Jun 2018 03:30:51 +0000
Message-ID: <BYAPR07MB4325916FAAE80A23219174C2E14E0@BYAPR07MB4325.namprd07.prod.outlook.com>
References: <1530134719-19407-4-git-send-email-steven.hill@cavium.com>
        <20180628084156.GF16727@lunn.ch>
        <f09305d1-8477-ed79-0289-05a629cef994@cavium.com>,<20180629.111905.863023692523959153.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "andrew@lunn.ch" <andrew@lunn.ch>,
        "Hill, Steven" <Steven.Hill@cavium.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>
To: David Miller <davem@davemloft.net>,
        "Munoz, Carlos" <Carlos.Munoz@cavium.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-sn1nam01on0057.outbound.protection.outlook.com ([104.47.32.57]:55598
        "EHLO NAM01-SN1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S932140AbeF2Da7 (ORCPT <rfc822;netdev@vger.kernel.org>);
        Thu, 28 Jun 2018 23:30:59 -0400
In-Reply-To: <20180629.111905.863023692523959153.davem@davemloft.net>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

David,

How can we support NFS boot if pass the parameters via devlink. Basically t=
his determines what phy to use from device tree.

Chandra

________________________________________
From: David Miller <davem@davemloft.net>
Sent: Thursday, June 28, 2018 7:19:05 PM
To: Munoz, Carlos
Cc: andrew@lunn.ch; Hill, Steven; netdev@vger.kernel.org; Chavva, Chandraka=
la
Subject: Re: [PATCH v12 03/10] netdev: cavium: octeon: Add Octeon III BGX E=
thernet Nexus

External Email

From: Carlos Munoz <cmunoz@cavium.com>
Date: Thu, 28 Jun 2018 14:20:05 -0700

>
>
> On 06/28/2018 01:41 AM, Andrew Lunn wrote:
>> External Email
>>
>>> +static char *mix_port;
>>> +module_param(mix_port, charp, 0444);
>>> +MODULE_PARM_DESC(mix_port, "Specifies which ports connect to MIX inter=
faces.");
>>> +
>>> +static char *pki_port;
>>> +module_param(pki_port, charp, 0444);
>>> +MODULE_PARM_DESC(pki_port, "Specifies which ports connect to the PKI."=
);
>> Module parameters are generally not liked. Can you do without them?
>
> These parameters change the kernel port assignment required by user
> space applications. We rather keep them as they simplify the
> process.

This is actually a terrible user experience.

Please provide a way to do this by performing operations on a device object
after the driver loads.

Use something like devlink or similar if you have to.