On Wed, 5 Dec 2018 16:01:08 -0800, Michael Chan wrote: > On Wed, Dec 5, 2018 at 3:33 PM Jakub Kicinski > <jakub.kicin...@netronome.com> wrote: > > > > On Wed, 5 Dec 2018 11:27:00 +0530, Vasundhara Volam wrote: > > > Register devlink_port with devlink and create initial port params > > > table for bnxt_en. The table consists of a generic parameter: > > > > > > wake-on-lan: Enables Wake on Lan for this port when magic packet > > > is received with this port's MAC address using ACPI pattern. > > > If enabled, the controller asserts a wake pin upon reception of > > > WoL packet. ACPI (Advanced Configuration and Power Interface) is > > > an industry specification for the efficient handling of power > > > consumption in desktop and mobile computers. > > > > > > Cc: Michael Chan <michael.c...@broadcom.com> > > > Signed-off-by: Vasundhara Volam <vasundhara-v.vo...@broadcom.com> > > > > Why do we need a WoL as a devlink parameter (rather than ethtool -s)? > > I believe ethtool -s for WoL is a non-persistent setting, meaning that > if you power cycle the system, the WoL setting will go back to > default. > > devlink on the other hand is a permanent setting. ethtool should > initially report the default WoL setting and it can then be changed > (in a non permanent way) using ethtool -s.
All network configuration settings in Linux are non-persistent AFAIK. That's why network configuration daemons exist: https://wiki.debian.org/WakeOnLan Perhaps the objective to move more of the network configuration into the firmware? That'd be a bleak scenario, so probably not.. My understanding was the persistent devlink settings are for things which have to be set at device init time. Like say PCI endpoint configuration. FW loading configuration. Besides, the parameter you add is just true/false, when ethtool has multiple options. It feels to me like we moved from ioctls to Netlink, and now even before ethtool was converted to Netlink we may move to unstructured strings. That's not a step forward, if you ask me.
