On October 31, 2023 3:04:12 PM Daniel Berlin <dberlin@xxxxxxxxxxx> wrote:
On Fri, Oct 20, 2023 at 1:31 PM Daniel Berlin <dberlin@xxxxxxxxxxx> wrote:So, at least in the example code I have, all variants of the 109 and 112 structures both have bcnflags in that place - it was always missing here. For example, see https://android.googlesource.com/kernel/google-modules/wlan/bcmdhd/bcm4398/+/refs/heads/android-gs-shusky-5.15-u-qpr1-beta2/include/wlioctl.h and compare v109 and v112 of bssinfo. As such, the 109 and 112 structures are compatible given these definitions. I don't know if what is there right now is wrong, or it is "yet another variant" of the 109 structure that we need to handle. Any idea what the ground truth is?Circling back to this - i have checked other sources as well - infineon also has u8 (though it's marked as padding) there, etc. As far as i can tell, the structure should have that u8 there in all versions i can find. Nevertheless, I think I can make it not matter ;) I'm going to post an RFC of some patches that handle this and other structure versioning things through function pointer structures that we set based on interface versions available. So instead of setting feature flags, we query the various iovars/firmware info for the right interface versions, and set up the structures/function pointers to handle the versions we will get from the firmware
The feature flag approach was a concern and the above is more or less what I had in mind so curious to see how this takes shape.
Regards, Arend
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
