Hi, On Fri, 7 Jan 2022 at 06:02, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > ... > > > > > > > Okay, I will look at this code closely regarding whenever multiple > > wpan_devs are running. > > The "scanning" boolean is stored as a wpan_phy member (IIRC) so we > should be good on this regard (now that I have a clearer picture of the > dependencies). > ok. > > You should also check for possible stop of all possible wpan dev > > transmit queues, if it's not already done. > > I forgot about this path. Indeed I'll add a check in the transmit path > as well, of course. > What I mean is look into the functions "ieee802154_stop_queue()" and "ieee802154_wake_queue()". > > I suppose a scan can take a > > long time and we should not send some data frames out. I am thinking > > about the long time scan operation... if we stop the queue for a long > > time I think we will drop a lot, however the scan can only be > > triggered by the right permissions and the user should be aware of the > > side effects. Proper reliable upper layer protocols will care or non > > reliable will not care about this. > > > > There still exists the driver "ca8210" which is the mentioned HardMAC > > transceiver in SoftMAC. There should somehow be a flag that it cannot > > do a scan and the operation should not be allowed as the xmit callback > > allows dataframes only. > > So it cannot do an active scan, but a passive scan would be allowed > (there is no transmission, and the beacons are regular valid frames, > I suppose they should not be filtered out by the hardware). > > So we actually need these hooks back :-) Because the right thing to do > here is to use the "FYI here is the scan op that is starting" message > from the mac to the drivers and this driver should return "nope, > -ENOTSUPP". The mac would react in this case by canceling the > operation and returning an error to the caller. Same when sending > beacons if we consider beacons as !dataframes. > I believe that a HardMAC transceiver will handle a lot of the scan process on the transceiver side and is only capable of dumping what it's stored and start/stop scan? This is one reason why the scan/dump/etc cfg802154 interface should be close to the standard (MLME). At the end it should from userspace make no difference if at the end is a HardMAC or SoftMAC. Although there will always be a limitation and a SoftMAC is probably always "more" powerful than a HardMAC, but at some point there is a "minimum" of capable functionality... and SoftMAC transceivers might always have "some" things which they might offload to the hardware. - Alex
