On Fri, 2019-06-14 at 13:16 +0000, Hodaszi, Robert wrote: > This reverts commit 96cce12ff6e0bc9d9fcb2235e08b7fc150f96fd2. > > Re-triggering a reg_process_hint with the last request on all events, > can make the regulatory domain fail in case of multiple WiFi modules. On > slower boards (espacially with mdev), enumeration of the WiFi modules > can end up in an intersected regulatory domain, and user cannot set it > with 'iw reg set' anymore. > > This is happening, because: > - 1st module enumerates, queues up a regulatory request > - request gets processed by __reg_process_hint_driver(): > - checks if previous was set by CORE -> yes > - checks if regulator domain changed -> yes, from '00' to e.g. 'US' > -> sends request to the 'crda' > - 2nd module enumerates, queues up a regulator request (which triggers > the reg_todo() work) > - reg_todo() -> reg_process_pending_hints() sees, that the last request > is not processed yet, so it tries to process it again. > __reg_process_hint driver() will run again, and: > - checks if the last request's initiator was the core -> no, it was > the driver (1st WiFi module) > - checks, if the previous initiator was the driver -> yes > - checks if the regulator domain changed -> yes, it was '00' (set by > core, and crda call did not return yet), and should be changed to 'US' > > ------> __reg_process_hint_driver calls an intersect > > Besides, the reg_process_hint call with the last request is meaningless > since the crda call has a timeout work. If that timeout expires, the > first module's request will lost. It's pointless to resend when I still have the original patch pending, at least without any changes. That said, I looked at this today and I'm not sure how the code doesn't now have the original issue again? johannes
