Re: [PATCH v2 1/1] wiphy: fix regdom change wiphy dump logic

[Denis Kenzior <denkenz@gmail.com>]

Hi James,

>> NAK.  Please stop right there.  genl is already a queue.  There's no sense 
>> adding queuing on top of it in this particular case.  If l_genl_family_cancel 
>> isn't doing the right thing, then fix that instead.
> 
> Well l_genl_family_cancel really cant do anything about it. Once the dump hits 
> the kernel you cant cancel it (this is why we added l_genl_family_request_sent). 

This was done for a different reason.  In the case of CMD_REMAIN_ON_CHANNEL we 
must wait for the ack to obtain the cookie.  We can cancel the ROC only if we 
know the cookie.  Otherwise, even if we call l_genl_family_cancel, the ROC would 
still go ahead.

What you have here is a different and simpler case.

> So the only alternative I can think of, if we cant do it in IWD, would be to 
> make l_genl queue dumps and not issue more dumps until the previous one 
> finishes. This is obviously a significant behavioral change.

I'm lost?  That is what is supposed to happen and happens already today.  If you 
issue two dumps like:

l_genl_family_dump(..., msg1, ...);
l_genl_family_dump(..., msg2, ...);

Then msg2 will not be sent to the kernel until NLMSG_DONE flagged message is 
received.  So what exactly would be the behavioral change you are referring to?

Anyway, looking at l_genl_family_cancel, it is doing the wrong thing, so that 
should be fixed.

Regards,
-Denis