Re: [RFC wpan-next 2/2] net: mac802154: set filter at drv_start()

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Alexander,

aahringo@redhat.com wrote on Sun, 4 Sep 2022 21:10:55 -0400:

> Hi,
> 
> On Sun, Sep 4, 2022 at 9:09 PM Alexander Aring <aahringo@redhat.com> wrote:
> >
> > The current filtering level is set on the first interface up on a wpan
> > phy. If we support scan functionality we need to change the filtering
> > level on the fly on an operational phy and switching back again.
> >
> > This patch will move the receive mode parameter e.g. address filter and
> > promiscuous mode to the drv_start() functionality to allow changing the
> > receive mode on an operational phy not on first ifup only. In future this
> > should be handled on driver layer because each hardware has it's own way
> > to enter a specific filtering level. However this should offer to switch
> > to mode IEEE802154_FILTERING_NONE and back to
> > IEEE802154_FILTERING_4_FRAME_FIELDS.
> >
> > Only IEEE802154_FILTERING_4_FRAME_FIELDS and IEEE802154_FILTERING_NONE
> > are somewhat supported by current hardware. All other filtering levels
> > can be supported in future but will end in IEEE802154_FILTERING_NONE as
> > the receive part can kind of "emulate" those receive paths by doing
> > additional filtering routines.
> >
> > Signed-off-by: Alexander Aring <aahringo@redhat.com>
> > ---
> >
> > RFC as code snippet as requested to somehow deal with the current
> > driver-ops and switching between filters with address filtering (AACK on)
> > and non-address filtering (AACK off) which is necessary for scanning in
> > this case it will be NONE because that's what we currently support and I
> > hope it can useful for scanning receive mode.
> >  
> 
> based on wpan-next/master with:
> 
> [PATCH wpan-next v2 01/11] net: mac802154: Introduce filtering levels
> 
> applied.

Excellent! That was very helpful. I think I've found a nice way to use
those filtering levels, it's not something that we need for the scan to
work so I've queued those patches later, but in the end you were right,
it's much better than the ->promiscuous callback alone.

I've integrated your patches, let me come up with a final submission,
no worries about the v2, please just check v3 which will be much more
interesting.

Thanks,
Miquèl