Re: [PATCH wpan-next v3 0/6] IEEE 802.15.4 passive scan support

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

Hi Stefan,

stefan@datenfreihafen.org wrote on Wed, 4 Jan 2023 13:28:44 +0100:

> Hello Miquel.
> 
> On 04.01.23 13:20, Miquel Raynal wrote:
> > Hi Stefan,
> > 
> > stefan@datenfreihafen.org wrote on Tue, 3 Jan 2023 20:43:02 +0100:
> >   
> >> Hello Miquel.
> >>
> >> On 03.01.23 17:56, Miquel Raynal wrote:  
> >>> Hello,
> >>>
> >>> We now have the infrastructure to report beacons/PANs, we also have the
> >>> capability to transmit MLME commands synchronously. It is time to use
> >>> these to implement a proper scan implementation.
> >>>
> >>> There are a few side-changes which are necessary for the soft MAC scan
> >>> implementation to compile/work, but nothing big. The two main changes
> >>> are:
> >>> * The introduction of a user API for managing scans.
> >>> * The soft MAC implementation of a scan.
> >>>
> >>> In all the past, current and future submissions, David and Romuald from
> >>> Qorvo are credited in various ways (main author, co-author,
> >>> suggested-by) depending of the amount of rework that was involved on
> >>> each patch, reflecting as much as possible the open-source guidelines we
> >>> follow in the kernel. All this effort is made possible thanks to Qorvo
> >>> Inc which is pushing towards a featureful upstream WPAN support.
> >>>
> >>> Example of output:
> >>>
> >>> 	# iwpan monitor
> >>> 	coord1 (phy #1): scan started
> >>> 	coord1 (phy #1): beacon received: PAN 0xabcd, addr 0xb2bcc36ac5570abe
> >>> 	coord1 (phy #1): scan finished
> >>> 	coord1 (phy #1): scan started
> >>> 	coord1 (phy #1): scan aborted  
> >>
> >> These patches have been applied to the wpan-next tree and will be
> >> part of the next pull request to net-next. Thanks!
> >>
> >> Before I would add them to a pull request to net-next I would like to have an updated patchset for iwpan to reflect these scan changes. We would need something to verify the kernel changes and try to coordinate a new iwpan release with this functionality with the major kernel release bringing the feature.  
> > 
> > So far I did not made a single change for the scan, but a common
> > changeset for scan+beaconing (which I am about to send), should I split
> > it or should we assume we could introduce scanning and beaconing in the
> > same kernel release?  
> 
>  From my side I do not mind to introduce scanning and beaconing in the same release. I just want to make you aware that scanning would slip if beaconing slips and we have no support in iwpan to test and release together.
> 
> If you have the beaconing patchset ready, let's start with it and if it turns out it will not be ready for the next release (let's hope it will) you can think again if you want to have the scan part split of to release that earlier.

It was easier to split than I thought, so I've sent the userspace
changes a minute ago:
https://lore.kernel.org/linux-wpan/20230106111831.692202-1-miquel.raynal@bootlin.com/T/#t

Thanks,
Miquèl