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