On 20/10/2023 18.59, Arend van Spriel wrote:
On 10/19/2023 3:42 AM, Daniel Berlin wrote:
From: Hector Martin <marcan@xxxxxxxxx>
The structures are compatible and just add fields, so we can just treat
it as always v112. If we start using new fields, that will have to be
gated on the version.
Seems EHT is creeping in here.
Having doubts about compatibility statement (see below)...
Signed-off-by: Hector Martin <marcan@xxxxxxxxx>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 5 ++-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 37 +++++++++++++++++--
2 files changed, 36 insertions(+), 6 deletions(-)
@@ -323,28 +324,56 @@ struct brcmf_bss_info_le {
__le16 capability; /* Capability information */
u8 SSID_len;
u8 SSID[32];
+ u8 bcnflags; /* additional flags w.r.t. beacon */
Ehm. Coming back to your statement "structures are compatible and just
add fields". How are they compatible? You now treat v109 struct as v112
so fields below are shifted because of bcnflags. So you read invalid
information. This does not fly or I am missing something here.
bcmflags was previously an implied padding byte. If you actually check
the offsets of the subsequent fields, you'll see they haven't changed.
In fact this was added at some point in the past and just missing here,
and is a general case of "padding bytes were not explicitly specified"
which is arguably an anti-pattern and should never have been the case.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature