[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f15781fe-9d1e-471f-997d-137851c47824@broadcom.com>
Date: Fri, 13 Oct 2023 09:15:37 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Michal Kubecek <mkubecek@...e.cz>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Jonathan Corbet <corbet@....net>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Heiner Kallweit <hkallweit1@...il.com>, Russell King
<linux@...linux.org.uk>, opendmb@...il.com, justin.chen@...adcom.com
Subject: Re: [PATCH net-next 1/2] ethtool: Introduce WAKE_MDA
On 10/12/23 14:18, Andrew Lunn wrote:
>>> But we should clearly define what we expect in terms of ordering and
>>> maybe try to enforce it in the core. Can we make the rxnfc call return
>>> -EBUSY or something and an extack message if WAKE_FILTER has not been
>>> enabled first?
>>
>> It might make sense to do it the other way around, that is you must install
>> filters first and if none are installed by the time we enable WAKE_FILTER in
>> .set_wol(), we error out with -EINVAL?
>
> I was thinking the other way around would be easier for the core to
> enforce. When inserting an rxnfc, it can do an ethtool.get_wol(ndev)
> and check WAKE_FILTER is set. That seems simpler than doing a
> get_rxnfc() and having to look through the results and try to figure
> out which are for WoL?
What you propose would be simpler, but I believe it would be more
logical to:
- install filter(s)
- set ethtool WAKE_FILTER
as the latter acts as a "commit", until that point the filters are
installed, but may not be effective unless WAKE_FILTER is set and gets
translated into the appropriate Wake-on-LAN enable bits. Of course
nothing prevents you from doing the reverse or installing filters after
setting WAkE_FILTER as long as the system does not go into suspend in
between, everything should be working.
>
> Anyway, you seem to be volunteering to implement this, so either is
> fine for me, so long as we do have some central enforcement.
Yes, patches will follow, thanks!
--
Florian
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)
Powered by blists - more mailing lists