Date:   Mon, 17 Jan 2022 18:02:06 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        "linux-wireless@...r.kernel.org Wireless" 
        <linux-wireless@...r.kernel.org>,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v3 00/41] IEEE 802.15.4 scan support

Hi,

On Mon, 17 Jan 2022 at 06:54, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Hello,
>
>         *** TLDR ***
>
> Here is a series attempting to bring support for scans in the
> IEEE 802.15.4 stack. A number of improvements had to be made, including:
> * a better handling of the symbol durations
> * a few changes in Kconfig
> * a better handling of the tx queues
> * a synchronous Tx API
>
> Active and passive scans can be locally tested only with hwsim.
>
> Sorry for the big series, might be split in the near future.
>
>         ************
>
> A second series aligning the tooling with these changes is related,
> bringing support for a number of new features such as:
>
> * Sending (or stopping) beacons. Intervals ranging from 0 to 14 are
>   valid for passively sending beacons at regular intervals. An interval
>   of 15 would request the core to answer to received BEACON_REQ.
>   # iwpan dev wpan0 beacons send interval 2 # send BEACON at a fixed rate
>   # iwpan dev wpan0 beacons send interval 15 # answer BEACON_REQ only
>   # iwpan dev wpan0 beacons stop # apply to both cases
>
> * Scanning all the channels or only a subset:
>   # iwpan dev wpan1 scan type passive duration 3 # will not trigger BEACON_REQ
>   # iwpan dev wpan1 scan type active duration 3 # will trigger BEACON_REQ
>
> * If a beacon is received during a scan, the internal PAN list is
>   updated and can be dumped, flushed and configured with:
>   # iwpan dev wpan1 pans dump
>   PAN 0xffff (on wpan1)
>       coordinator 0x2efefdd4cdbf9330
>       page 0
>       channel 13
>       superframe spec. 0xcf22
>       LQI 0
>       seen 7156ms ago
>   # iwpan dev wpan1 pans flush
>   # iwpan dev wpan1 set max_pan_entries 100
>   # iwpan dev wpan1 set pans_expiration 3600
>
> * It is also possible to monitor the events with:
>   # iwpan event
>
> * As well as triggering a non blocking scan:
>   # iwpan dev wpan1 scan trigger type passive duration 3
>   # iwpan dev wpan1 scan done
>   # iwpan dev wpan1 scan abort
>
> The PAN list gets automatically updated by dropping the expired PANs
> each time the user requests access to the list.
>
> Internally, both requests (scan/beacons) are handled periodically by
> delayed workqueues when relevant.
>
> So far the only technical point that is missing in this series is the
> possibility to grab a reference over the module driving the net device
> in order to prevent module unloading during a scan or when the beacons
> work is ongoing.
>
> Finally, this series is a deep reshuffle of David Girault's original
> work, hence the fact that he is almost systematically credited, either
> by being the only author when I created the patches based on his changes
> with almost no modification, or with a Co-developped-by tag whenever the
> final code base is significantly different than his first proposal while
> still being greatly inspired from it.
>

can you please split this patch series, what I see is now:

1. cleanup patches
2. sync tx handling for mlme commands
3. scan support

we try to bring the patches upstream in this order.

Thanks.

- Alex

Powered by blists - more mailing lists