Message ID | 20220117115440.60296-1-miquel.raynal@bootlin.com (mailing list archive) |
---|---|
Headers | show |
Series | IEEE 802.15.4 scan support | expand |
Hi, On Mon, 17 Jan 2022 at 06:54, Miquel Raynal <miquel.raynal@bootlin.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
Hi Alexander, > > 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. Do you have any advises regarding this issue? That is the only technical point that is left unaddressed IMHO. > > 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 Works for me. I just wanted to give the big picture but I'll split the series. Also sorry for forgetting the 'wpan-next' subject prefix. > we try to bring the patches upstream in this order. > > Thanks. > > - Alex Thanks, Miquèl
Hi, On Tue, 18 Jan 2022 at 05:40, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > > > 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. > > Do you have any advises regarding this issue? That is the only > technical point that is left unaddressed IMHO. > module_get()/module_put() or I don't see where the problem here is. You can avoid module unloading with it. Which module is the problem here? > > > 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 > > Works for me. I just wanted to give the big picture but I'll split the > series. > maybe also put some "symbol duration" series into it if it's getting too large? It is difficult to review 40 patches... in one step. > Also sorry for forgetting the 'wpan-next' subject prefix. > no problem. I really appreciate your work and your willingness to work on all outstanding issues. I am really happy to see something that we can use for mlme-commands and to separate it from the hotpath transmission... It is good to see architecture for that which I think goes in the right direction. - Alex
Hi Alexander, alex.aring@gmail.com wrote on Tue, 18 Jan 2022 18:12:49 -0500: > Hi, > > On Tue, 18 Jan 2022 at 05:40, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > > > 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. > > > > Do you have any advises regarding this issue? That is the only > > technical point that is left unaddressed IMHO. > > > > module_get()/module_put() or I don't see where the problem here is. > You can avoid module unloading with it. Which module is the problem > here? I'll give it another try, maybe when I first tried that I was missing a few mental peaces and did not understood the puzzle correctly. > > > > 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 > > > > Works for me. I just wanted to give the big picture but I'll split the > > series. > > > > maybe also put some "symbol duration" series into it if it's getting > too large? It is difficult to review 40 patches... in one step. Yep, I truly understand (and now 50+). > > > Also sorry for forgetting the 'wpan-next' subject prefix. > > > > no problem. > > I really appreciate your work and your willingness to work on all > outstanding issues. I am really happy to see something that we can use > for mlme-commands and to separate it from the hotpath transmission... > It is good to see architecture for that which I think goes in the > right direction. That is very stirring to read :) Thanks, Miquèl