[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <30ce4245-c98c-4e4d-9e2c-5119d23d1afc@lunn.ch>
Date: Thu, 12 Oct 2023 23:18:37 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <florian.fainelli@...adcom.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
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
> > 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?
Anyway, you seem to be volunteering to implement this, so either is
fine for me, so long as we do have some central enforcement.
Andrew
Powered by blists - more mailing lists