| Message ID | 20180628103623.29103-1-zajec5@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 07b1ae46874949252625c96f309f96ca0f337020 |
| Delegated to: | Kalle Valo |
| Headers | show |
On 6/28/2018 12:36 PM, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > That struct is used when querying firmware for the STA. It seem is has > been changing during the time. Luckily its format seems to be backward > compatible starting with v2 (the only breakage was v1 -> v2). > > The version that was supported by brcmfmac so far was v4. It was what > 43602a1 and 4366b1 firmwares (7.35.177.56 and 10.10.69.3309 accordingly) > were using. It also seems to be used by early 4366c0 firmwares > (10.10.69.6908 and 10.10.69.69017). > > The problem appears when switching to the 10.10.122.20 firmware. It uses > v5 and instead of falling back to v4 when submitted buffer isn't big > enough it fallbacks to the v3. > > To receive all v4 specific info with the newest firmware we have to > submit a struct (buffer) that matches v5. So do you have firmware that actually return v5 in the 'ver' field. I am asking because I see a comment that version 5 is obsoleted and in recent branch we are at version 7. Just curious what the actual version is. If you do not explicitly need version 5 I would prefer to skip it and move to version 6 struct. Otherwise it is... Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > --- > .../net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h > index 9b3a58e89dd1..d5bb81e88762 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h > @@ -174,6 +174,8 @@ > #define BRCMF_MFP_CAPABLE 1 > #define BRCMF_MFP_REQUIRED 2 > > +#define BRCMF_VHT_CAP_MCS_MAP_NSS_MAX 8 > + > /* MAX_CHUNK_LEN is the maximum length for data passing to firmware in each > * ioctl. It is relatively small because firmware has small maximum size input > * playload restriction for ioctls. > @@ -550,6 +552,8 @@ struct brcmf_sta_info_le { > /* w/hi bit set if basic */ > __le32 in; /* seconds elapsed since associated */ > __le32 listen_interval_inms; /* Min Listen interval in ms for STA */ > + > + /* Fields valid for ver >= 3 */ > __le32 tx_pkts; /* # of packets transmitted */ > __le32 tx_failures; /* # of packets failed */ > __le32 rx_ucast_pkts; /* # of unicast packets received */ > @@ -558,6 +562,8 @@ struct brcmf_sta_info_le { > __le32 rx_rate; /* Rate of last successful rx frame */ > __le32 rx_decrypt_succeeds; /* # of packet decrypted successfully */ > __le32 rx_decrypt_failures; /* # of packet decrypted failed */ > + > + /* Fields valid for ver >= 4 */ > __le32 tx_tot_pkts; /* # of tx pkts (ucast + mcast) */ > __le32 rx_tot_pkts; /* # of data packets recvd (uni + mcast) */ > __le32 tx_mcast_pkts; /* # of mcast pkts txed */ > @@ -594,6 +600,14 @@ struct brcmf_sta_info_le { > */ > __le32 rx_pkts_retried; /* # rx with retry bit set */ > __le32 tx_rate_fallback; /* lowest fallback TX rate */ > + > + /* Fields valid for ver >= 5 */ > + struct { > + __le32 count; /* # rates in this set */ > + u8 rates[BRCMF_MAXRATES_IN_SET]; /* rates in 500kbps units w/hi bit set if basic */ > + u8 mcs[BRCMF_MCSSET_LEN]; /* supported mcs index bit map */ > + __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX]; /* supported mcs index bit map per nss */ > + } rateset_adv; > }; > > struct brcmf_chanspec_list { >
On 2018-06-30 20:48, Arend van Spriel wrote: > On 6/28/2018 12:36 PM, Rafał Miłecki wrote: >> From: Rafał Miłecki <rafal@milecki.pl> >> >> That struct is used when querying firmware for the STA. It seem is has >> been changing during the time. Luckily its format seems to be backward >> compatible starting with v2 (the only breakage was v1 -> v2). >> >> The version that was supported by brcmfmac so far was v4. It was what >> 43602a1 and 4366b1 firmwares (7.35.177.56 and 10.10.69.3309 >> accordingly) >> were using. It also seems to be used by early 4366c0 firmwares >> (10.10.69.6908 and 10.10.69.69017). >> >> The problem appears when switching to the 10.10.122.20 firmware. It >> uses >> v5 and instead of falling back to v4 when submitted buffer isn't big >> enough it fallbacks to the v3. >> >> To receive all v4 specific info with the newest firmware we have to >> submit a struct (buffer) that matches v5. > > So do you have firmware that actually return v5 in the 'ver' field. I > am asking because I see a comment that version 5 is obsoleted and in > recent branch we are at version 7. Just curious what the actual > version is. If you do not explicitly need version 5 I would prefer to > skip it and move to version 6 struct. Otherwise it is... Yes. As stated in the commit message, firmware 10.10.122.20 uses v5. I didn't list vendors using that firmware, but if you take a look at the side thread "Research + questions on brcmfmac and support for monitor mode", you'll see that 10.10.122.20 is used in: 1) FW_EA9500v2_EA9500S_2.1.1.183171_prod.img 2) GT-AC5300_3.0.0.4_382_15984-gf481f58_cferom_ubi_0824.w 3) ArcherC5400X(US)_171023.bin That means I explicitly need v5 to make brcmfmac work with any 10.10.122.20 firmware from above images. Unfortunately I didn't find any vendor release their GPL package with Broadcom's SDK using v6 or v7. I hope it's backward compatible and maybe you'll be able to provide patch on top of mine? > Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Thanks!
Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > That struct is used when querying firmware for the STA. It seem is has > been changing during the time. Luckily its format seems to be backward > compatible starting with v2 (the only breakage was v1 -> v2). > > The version that was supported by brcmfmac so far was v4. It was what > 43602a1 and 4366b1 firmwares (7.35.177.56 and 10.10.69.3309 accordingly) > were using. It also seems to be used by early 4366c0 firmwares > (10.10.69.6908 and 10.10.69.69017). > > The problem appears when switching to the 10.10.122.20 firmware. It uses > v5 and instead of falling back to v4 when submitted buffer isn't big > enough it fallbacks to the v3. > > To receive all v4 specific info with the newest firmware we have to > submit a struct (buffer) that matches v5. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Patch applied to wireless-drivers-next.git, thanks. 07b1ae468749 brcmfmac: update STA info struct to the v5
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h index 9b3a58e89dd1..d5bb81e88762 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h @@ -174,6 +174,8 @@ #define BRCMF_MFP_CAPABLE 1 #define BRCMF_MFP_REQUIRED 2 +#define BRCMF_VHT_CAP_MCS_MAP_NSS_MAX 8 + /* MAX_CHUNK_LEN is the maximum length for data passing to firmware in each * ioctl. It is relatively small because firmware has small maximum size input * playload restriction for ioctls. @@ -550,6 +552,8 @@ struct brcmf_sta_info_le { /* w/hi bit set if basic */ __le32 in; /* seconds elapsed since associated */ __le32 listen_interval_inms; /* Min Listen interval in ms for STA */ + + /* Fields valid for ver >= 3 */ __le32 tx_pkts; /* # of packets transmitted */ __le32 tx_failures; /* # of packets failed */ __le32 rx_ucast_pkts; /* # of unicast packets received */ @@ -558,6 +562,8 @@ struct brcmf_sta_info_le { __le32 rx_rate; /* Rate of last successful rx frame */ __le32 rx_decrypt_succeeds; /* # of packet decrypted successfully */ __le32 rx_decrypt_failures; /* # of packet decrypted failed */ + + /* Fields valid for ver >= 4 */ __le32 tx_tot_pkts; /* # of tx pkts (ucast + mcast) */ __le32 rx_tot_pkts; /* # of data packets recvd (uni + mcast) */ __le32 tx_mcast_pkts; /* # of mcast pkts txed */ @@ -594,6 +600,14 @@ struct brcmf_sta_info_le { */ __le32 rx_pkts_retried; /* # rx with retry bit set */ __le32 tx_rate_fallback; /* lowest fallback TX rate */ + + /* Fields valid for ver >= 5 */ + struct { + __le32 count; /* # rates in this set */ + u8 rates[BRCMF_MAXRATES_IN_SET]; /* rates in 500kbps units w/hi bit set if basic */ + u8 mcs[BRCMF_MCSSET_LEN]; /* supported mcs index bit map */ + __le16 vht_mcs[BRCMF_VHT_CAP_MCS_MAP_NSS_MAX]; /* supported mcs index bit map per nss */ + } rateset_adv; }; struct brcmf_chanspec_list {