From: Florian Fainelli
Date: Fri, 3 Aug 2018 12:58:12 -0700
> For instance, in the current HW, you can program 128 filters through
> the switch, but only 8 of those could be wake-up capable at the
> CPU/management (SYSTEM PORT) level.
Yes, I noticed this in the driver patches.
> Let me cook som
On 08/03/2018 12:07 PM, David Miller wrote:
> From: Florian Fainelli
> Date: Fri, 3 Aug 2018 10:57:13 -0700
>
>> Does the current approach of specifying a bitmask of filters looks
>> reasonable to you though?
>
> So, in order to answer that, I need some clarification.
>
> The mask, as I see it,
From: Florian Fainelli
Date: Fri, 3 Aug 2018 10:57:13 -0700
> Does the current approach of specifying a bitmask of filters looks
> reasonable to you though?
So, in order to answer that, I need some clarification.
The mask, as I see it, is a bit map of 48 possible positions
(SOPASS_MAX * bits_pe
On 08/01/2018 09:32 AM, David Miller wrote:
> From: Florian Fainelli
> Date: Mon, 30 Jul 2018 15:26:24 -0700
>
>> On 07/17/2018 08:36 AM, Florian Fainelli wrote:
>>> Allow re-purposing the wol->sopass storage area to specify a bitmask of
>>> filters
>>> (programmed previously via ethtool::rxnfc)
From: Florian Fainelli
Date: Mon, 30 Jul 2018 15:26:24 -0700
> On 07/17/2018 08:36 AM, Florian Fainelli wrote:
>> Allow re-purposing the wol->sopass storage area to specify a bitmask of
>> filters
>> (programmed previously via ethtool::rxnfc) to be used as wake-up patterns.
>
> John, David, can
> One usability issue with this approach is that one cannot specify
> wake-on-LAN using WAKE_MAGICSECURE *and* WAKE_FILTER at the same time,
> since it uses the same location in the ioctl() structure that is being
> passed. Do you see this as a problem?
Hi Florian
I think you missed adding a chec
> The thing is that I need this now, but when Michal's work on ethtool
> being migrated to netlink settles, we should have have any issues adding
> a proper storage area for specifying filters anymore. The issue here is
> of course that the size and layout of ethtool_wolinfo is largely fixed
> and
On 07/30/2018 03:30 PM, Andrew Lunn wrote:
>> One usability issue with this approach is that one cannot specify
>> wake-on-LAN using WAKE_MAGICSECURE *and* WAKE_FILTER at the same time,
>> since it uses the same location in the ioctl() structure that is being
>> passed. Do you see this as a problem
> One usability issue with this approach is that one cannot specify
> wake-on-LAN using WAKE_MAGICSECURE *and* WAKE_FILTER at the same time,
> since it uses the same location in the ioctl() structure that is being
> passed. Do you see this as a problem?
Hi Florian
Maybe you can think ahead to whe
On 07/17/2018 08:36 AM, Florian Fainelli wrote:
> Allow re-purposing the wol->sopass storage area to specify a bitmask of
> filters
> (programmed previously via ethtool::rxnfc) to be used as wake-up patterns.
John, David, can you provide some feedback if the approach is
acceptable? I will address
Allow re-purposing the wol->sopass storage area to specify a bitmask of filters
(programmed previously via ethtool::rxnfc) to be used as wake-up patterns.
Signed-off-by: Florian Fainelli
---
ethtool-copy.h | 1 +
ethtool.c | 35 ++-
2 files changed, 35 inser
11 matches
Mail list logo
