netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Michael Chan <michael.chan@broadcom.com>
Cc: Vasundhara Volam <vasundhara-v.volam@broadcom.com>,
	David Miller <davem@davemloft.net>,
	Jiri Pirko <jiri@mellanox.com>, Netdev <netdev@vger.kernel.org>
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	[thread overview]
Message-ID: <20181205231120.339c5f50@cakuba.netronome.com> (raw)
In-Reply-To: <CACKFLi=XjLjqZyWrf+jWPbyAJUe3Obf8NaOpHJDJGvLHPHhf_w@mail.gmail.com>

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).

  reply	other threads:[~2018-12-06  7:11 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05  5:56 [PATCH net-next RFC 0/7] Add configuration parameters support for devlink_port Vasundhara Volam
2018-12-05  5:56 ` [PATCH net-next RFC 1/7] devlink: Add devlink_param for port register and unregister Vasundhara Volam
2018-12-05 11:47   ` Jiri Pirko
2018-12-06  6:02     ` Vasundhara Volam
2018-12-06  7:06       ` Jiri Pirko
2018-12-06  7:26         ` Vasundhara Volam
2018-12-10  9:21     ` Vasundhara Volam
2018-12-10 11:29       ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 2/7] devlink: Add port param get command Vasundhara Volam
2018-12-05 11:51   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 3/7] devlink: Add port param set command Vasundhara Volam
2018-12-05 12:13   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 4/7] devlink: Add support for get/set driverinit value for devlink_port Vasundhara Volam
2018-12-05 12:59   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 5/7] devlink: Add devlink notifications support for port params Vasundhara Volam
2018-12-05 13:02   ` Jiri Pirko
2018-12-05  5:56 ` [PATCH net-next RFC 6/7] devlink: Add a boolean generic port parameter Vasundhara Volam
2018-12-05 13:04   ` Jiri Pirko
2018-12-05  5:57 ` [PATCH net-next RFC 7/7] bnxt_en: Add bnxt_en initial port params table and register it Vasundhara Volam
2018-12-05 13:05   ` Jiri Pirko
2018-12-05 23:33   ` Jakub Kicinski
2018-12-06  0:01     ` Michael Chan
2018-12-06  0:42       ` Jakub Kicinski
2018-12-06  1:18         ` Michael Chan
2018-12-06  6:00           ` Jakub Kicinski
2018-12-06  6:41             ` Michael Chan
2018-12-06  7:11               ` Jakub Kicinski [this message]
2018-12-06  8:57                 ` Michael Chan
2018-12-06  9:03                   ` Jiri Pirko
2018-12-06 10:31                     ` Vasundhara Volam
2018-12-06 11:11                       ` Jiri Pirko
2018-12-06 10:36                   ` Jakub Kicinski
2018-12-06 11:00                     ` Michael Chan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181205231120.339c5f50@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=davem@davemloft.net \
    --cc=jiri@mellanox.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=vasundhara-v.volam@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).