From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [PATCH net-next RFC 7/7] bnxt_en: Add bnxt_en initial port
 params table and register it
Date: Wed, 5 Dec 2018 23:11:20 -0800
Message-ID: <20181205231120.339c5f50@cakuba.netronome.com>
References: <1543989420-14859-1-git-send-email-vasundhara-v.volam@broadcom.com>
        <1543989420-14859-8-git-send-email-vasundhara-v.volam@broadcom.com>
        <20181205153309.3fa92dd5@cakuba.netronome.com>
        <CACKFLikR5G1vca31hyjJ3uZbV1Zq-86a9=qXeUaO1gqosDg9GQ@mail.gmail.com>
        <20181205164203.230c44e8@cakuba.netronome.com>
        <CACKFLinvfruoDiR3_DetmpXdQT4+Sf759nh+C+hJq41YWnMk-g@mail.gmail.com>
        <20181205220038.503d6a92@cakuba.netronome.com>
        <CACKFLi=XjLjqZyWrf+jWPbyAJUe3Obf8NaOpHJDJGvLHPHhf_w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Vasundhara Volam <vasundhara-v.volam@broadcom.com>,
        David Miller <davem@davemloft.net>,
        Jiri Pirko <jiri@mellanox.com>, Netdev <netdev@vger.kernel.org>
To: Michael Chan <michael.chan@broadcom.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt1-f194.google.com ([209.85.160.194]:40643 "EHLO
        mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728294AbeLFHL1 (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 6 Dec 2018 02:11:27 -0500
Received: by mail-qt1-f194.google.com with SMTP id k12so25228007qtf.7
        for <netdev@vger.kernel.org>; Wed, 05 Dec 2018 23:11:26 -0800 (PST)
In-Reply-To: <CACKFLi=XjLjqZyWrf+jWPbyAJUe3Obf8NaOpHJDJGvLHPHhf_w@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, 5 Dec 2018 22:41:43 -0800, Michael Chan wrote:
> > > We do have a parameter in NVRAM that controls default WoL.  I think
> > > this is to expose that parameter so it can be set one way or the
> > > other. There are scenarios where Linux has not booted yet (and so
> > > there is no opportunity to run ethtool -s or any daemons yet) and this
> > > parameter will control whether the machine will wake up or not.  
> >
> > Isn't that set in BIOS/setup?  The config before any OS boots?  Because
> > the BMC or whatnot has to actually configure the board to power
> > appropriate things up.  Please clarify.  
> 
> It will be in the BIOS only for a LOM, I think.  For a NIC, it should
> be in the NIC's NVRAM.

This is all vague.  Could you please clearly state the use case.

> > And *if* it is proven this config is more than just setting the default
> > IMHO the setting belongs in the ethtool API.  We can't just add devlink
> > params for all existing config APIs just because it has persistence.  
> 
> I'm not sure I understand your point.  I believe the NIC firmware will
> set up the NIC's WoL setting right after power up based on this NVRAM
> parameter.  Similar to how the firmware will setup PCIe Gen2 or Gen3
> right after power up, for example.  

We have no PCIe config interface therefore the crutch of devlink params
was allowed there.  We *do* have an existing interface to configure WoL.

> So why would this belong to ethtool?  I understand the confusion that
> ethtool -s has a similar WoL setting.  But again, that's different.

Perhaps you're looking at this from firmware perspective?  FW NVM knob
== devlink param?

> This one is the power up setting that impacts whether a magic packet
> can or cannot wake up the system right after power up (before booting
> up to Linux or other OS).