On Tue, 11 Dec 2018 23:35:31 -0800, Michael Chan wrote:

On Tue, Dec 11, 2018 at 10:18 AM Jakub Kicinski wrote:

quoted

On Tue, 11 Dec 2018 14:16:47 +0530, Vasundhara Volam wrote:  

quoted

wake-on-lan - Enables Wake on Lan for this port. If enabled,
the controller asserts a wake pin based on the wake-on-lan type.

Cc: Jiri Pirko <redacted>
Signed-off-by: Vasundhara Volam <redacted>  

As explained previously I think it's a very bad idea to add existing
configuration options to devlink, just because devlink has the ability
to persist the setting in NVM.  Especially that for WoL you have to get
the link up so you potentially have all link config stuff as well.  And
that n-tuple filters are one of the WoL options, meaning we'd need the
ability to persist n-tuple filters via devlink.  

As I said before, firmware will automatically set the link to autoneg
up to the speed supported by Vaux if WoL is enabled.  No special link
setting is needed as I said before.  I don't think n-tuple is suitable
for the default power-up WoL setting.  n-tuple requires ip address.
The ip address belongs to the system, not to the card that can move
from system to system.  The n-tuple WoL packet should be a transient
setting set by the OS that won't persist a power down.  The default
power-up WoL packet types should be the most basic magic packet and
other basic types.  So I really don't think there is a need to persist
n-tuple WoL packet types.

Sure your firmware sets the link to autoneg today, and your driver does
not allow n-tuple filter WoL.  How about we step back and think about
the API as a whole rather than exposing ad hoc FW knobs via delink
params :/

Also what gives you the idea that n-tuple filters require an ip address?