Linux-Wireless Archive on lore.kernel.org
 help / Atom feed
* [PATCH] brcmfmac: support monitor frames with hardware/ucode header
@ 2019-01-22 11:08 Rafał Miłecki
  2019-01-25  8:51 ` Arend Van Spriel
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Rafał Miłecki @ 2019-01-22 11:08 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list, Rafał Miłecki

From: Rafał Miłecki <rafal@milecki.pl>

The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
monitor frames with radiotap header but it doesn't seem to be the case.
Testing the latest release resulted in discovering a new format being
used. It seems (almost?) identical to the one known from ucode used in
SoftMAC devices which is most likely the same codebase anyway.

While radiotap support was meant to be announced with the "rtap" fw
capability string it seems no alternative was added for the hw/ucode
format. It means each firmware requires a feature mapping quirk.

As for now only an empty radiotap is being created. Adding support for
extracting some info (band, channel, signal, etc.) is planned for the
future.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 .../broadcom/brcm80211/brcmfmac/core.c        | 55 +++++++++++++++++++
 .../broadcom/brcm80211/brcmfmac/feature.c     |  4 ++
 .../broadcom/brcm80211/brcmfmac/feature.h     |  4 +-
 3 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 860a4372cb56..e772c0845638 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -43,6 +43,36 @@
 
 #define BRCMF_BSSIDX_INVALID			-1
 
+#define	RXS_PBPRES				BIT(2)
+
+#define	D11_PHY_HDR_LEN				6
+
+struct d11rxhdr_le {
+	__le16 RxFrameSize;
+	u16 PAD;
+	__le16 PhyRxStatus_0;
+	__le16 PhyRxStatus_1;
+	__le16 PhyRxStatus_2;
+	__le16 PhyRxStatus_3;
+	__le16 PhyRxStatus_4;
+	__le16 PhyRxStatus_5;
+	__le16 RxStatus1;
+	__le16 RxStatus2;
+	__le16 RxTSFTime;
+	__le16 RxChan;
+	u8 unknown[12];
+} __packed;
+
+struct wlc_d11rxhdr {
+	struct d11rxhdr_le rxhdr;
+	__le32 tsf_l;
+	s8 rssi;
+	s8 rxpwr0;
+	s8 rxpwr1;
+	s8 do_rssi_ma;
+	s8 rxpwr[4];
+} __packed;
+
 char *brcmf_ifname(struct brcmf_if *ifp)
 {
 	if (!ifp)
@@ -409,6 +439,31 @@ void brcmf_netif_mon_rx(struct brcmf_if *ifp, struct sk_buff *skb)
 {
 	if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_RADIOTAP)) {
 		/* Do nothing */
+	} else if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR)) {
+		struct wlc_d11rxhdr *wlc_rxhdr = (struct wlc_d11rxhdr *)skb->data;
+		struct ieee80211_radiotap_header *radiotap;
+		unsigned int offset;
+		u16 RxStatus1;
+
+		RxStatus1 = le16_to_cpu(wlc_rxhdr->rxhdr.RxStatus1);
+
+		offset = sizeof(struct wlc_d11rxhdr);
+		/* MAC inserts 2 pad bytes for a4 headers or QoS or A-MSDU
+		 * subframes
+		 */
+		if (RxStatus1 & RXS_PBPRES)
+			offset += 2;
+		offset += D11_PHY_HDR_LEN;
+
+		skb_pull(skb, offset);
+
+		/* TODO: use RX header to fill some radiotap data */
+		radiotap = skb_push(skb, sizeof(*radiotap));
+		memset(radiotap, 0, sizeof(*radiotap));
+		radiotap->it_len = cpu_to_le16(sizeof(*radiotap));
+
+		/* TODO: 4 bytes with receive status? */
+		skb->len -= 4;
 	} else {
 		struct ieee80211_radiotap_header *radiotap;
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 4c5a3995dc35..b91b7ecbfedf 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -103,6 +103,10 @@ static const struct brcmf_feat_fwfeat brcmf_feat_fwfeat_map[] = {
 	{ "01-6cb8e269", BIT(BRCMF_FEAT_MONITOR) },
 	/* brcmfmac4366b-pcie.bin from linux-firmware.git commit 52442afee990 */
 	{ "01-c47a91a4", BIT(BRCMF_FEAT_MONITOR) },
+	/* brcmfmac4366b-pcie.bin from linux-firmware.git commit 211de1679a68 */
+	{ "01-801fb449", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) },
+	/* brcmfmac4366c-pcie.bin from linux-firmware.git commit 211de1679a68 */
+	{ "01-d2cbb8fd", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) },
 };
 
 static void brcmf_feat_firmware_overrides(struct brcmf_pub *drv)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index 0b4974df353a..5e88a7f16ad2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -35,6 +35,7 @@
  * FWSUP: Firmware supplicant.
  * MONITOR: firmware can pass monitor packets to host.
  * MONITOR_FMT_RADIOTAP: firmware provides monitor packets with radiotap header
+ * MONITOR_FMT_HW_RX_HDR: firmware provides monitor packets with hw/ucode header
  */
 #define BRCMF_FEAT_LIST \
 	BRCMF_FEAT_DEF(MBSS) \
@@ -52,7 +53,8 @@
 	BRCMF_FEAT_DEF(GSCAN) \
 	BRCMF_FEAT_DEF(FWSUP) \
 	BRCMF_FEAT_DEF(MONITOR) \
-	BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP)
+	BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP) \
+	BRCMF_FEAT_DEF(MONITOR_FMT_HW_RX_HDR)
 
 /*
  * Quirks:
-- 
2.20.1


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] brcmfmac: support monitor frames with hardware/ucode header
  2019-01-22 11:08 [PATCH] brcmfmac: support monitor frames with hardware/ucode header Rafał Miłecki
@ 2019-01-25  8:51 ` Arend Van Spriel
  2019-01-25  9:11   ` Rafał Miłecki
  2019-02-07 16:36 ` Kalle Valo
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 9+ messages in thread
From: Arend Van Spriel @ 2019-01-25  8:51 UTC (permalink / raw)
  To: Rafał Miłecki, Kalle Valo
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	Rafał Miłecki

On 1/22/2019 12:08 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
> monitor frames with radiotap header but it doesn't seem to be the case.

I was not aware that this was supposed to. I did not build a radiotap 
variant to keep it feature-wise similar to 4366b0 firmware.

> Testing the latest release resulted in discovering a new format being
> used. It seems (almost?) identical to the one known from ucode used in
> SoftMAC devices which is most likely the same codebase anyway.

I am a bit confused. How many formats are there? It is either ucode 
format or radiotap, right?

> While radiotap support was meant to be announced with the "rtap" fw
> capability string it seems no alternative was added for the hw/ucode
> format. It means each firmware requires a feature mapping quirk.

I thought we only needed a quirk for the firmware that provide radiotap 
but do not announce it. For the others we can assume ucode format if 
monitor mode is supported. Probably missing something.

Regards,
Arend

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] brcmfmac: support monitor frames with hardware/ucode header
  2019-01-25  8:51 ` Arend Van Spriel
@ 2019-01-25  9:11   ` Rafał Miłecki
  2019-01-25  9:32     ` Arend Van Spriel
  0 siblings, 1 reply; 9+ messages in thread
From: Rafał Miłecki @ 2019-01-25  9:11 UTC (permalink / raw)
  To: Arend Van Spriel
  Cc: Rafał Miłecki, Kalle Valo, linux-wireless,
	brcm80211-dev-list.pdl, brcm80211-dev-list

On 2019-01-25 09:51, Arend Van Spriel wrote:
> On 1/22/2019 12:08 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>> 
>> The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
>> monitor frames with radiotap header but it doesn't seem to be the 
>> case.
> 
> I was not aware that this was supposed to. I did not build a radiotap
> variant to keep it feature-wise similar to 4366b0 firmware.

Well, then apparently I got confused :( When you wrote:

On Mon, 11 Jun 2018 at 12:48, Arend van Spriel 
<arend.vanspriel@broadcom.com> wrote:
> Looking into our firmware repo it there are two flags, ie. WL_MONITOR
> and WL_RADIOTAP. It seems both are set for firmware containing -stamon-
> feature. Your list below confirms that. I still plan to add indication
> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be
> used for older firmwares.

I assumed you'll add "rtap" cap value (to the internal wl code 
repository?)
because you mean to release a firmware using it.

Maybe you just meant it to be for your customers compiling firmwares on
their own?


>> Testing the latest release resulted in discovering a new format being
>> used. It seems (almost?) identical to the one known from ucode used in
>> SoftMAC devices which is most likely the same codebase anyway.
> 
> I am a bit confused. How many formats are there? It is either ucode
> format or radiotap, right?

So far we got two formats:
1) 802.11 frames (with frame (sub)type & all addresses)
2) 802.11 frames with the radiotap header
and now we also have:
3) 802.11 frames with the ucode header

For more info please check my original post:
Research + questions on brcmfmac and support for monitor mode
https://www.spinics.net/lists/linux-wireless/msg173573.html


>> While radiotap support was meant to be announced with the "rtap" fw
>> capability string it seems no alternative was added for the hw/ucode
>> format. It means each firmware requires a feature mapping quirk.
> 
> I thought we only needed a quirk for the firmware that provide
> radiotap but do not announce it. For the others we can assume ucode
> format if monitor mode is supported. Probably missing something.

802.11 frames with ucode header is something entirely new, I didn't see 
any
Asus/Linksys/Netgear/TP-LINK firmware using it.

As the old firmwares were providing frames without any header (also 
making
it impossible to e.g. read signal strength) we need this new flag to
distinguish firmwares with ucode header from them.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] brcmfmac: support monitor frames with hardware/ucode header
  2019-01-25  9:11   ` Rafał Miłecki
@ 2019-01-25  9:32     ` Arend Van Spriel
  0 siblings, 0 replies; 9+ messages in thread
From: Arend Van Spriel @ 2019-01-25  9:32 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Rafał Miłecki, Kalle Valo, linux-wireless,
	brcm80211-dev-list.pdl, brcm80211-dev-list

On 1/25/2019 10:11 AM, Rafał Miłecki wrote:
> On 2019-01-25 09:51, Arend Van Spriel wrote:
>> On 1/22/2019 12:08 PM, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
>>> monitor frames with radiotap header but it doesn't seem to be the case.
>>
>> I was not aware that this was supposed to. I did not build a radiotap
>> variant to keep it feature-wise similar to 4366b0 firmware.
> 
> Well, then apparently I got confused :( When you wrote:
> 
> On Mon, 11 Jun 2018 at 12:48, Arend van Spriel 
> <arend.vanspriel@broadcom.com> wrote:
>> Looking into our firmware repo it there are two flags, ie. WL_MONITOR
>> and WL_RADIOTAP. It seems both are set for firmware containing -stamon-
>> feature. Your list below confirms that. I still plan to add indication
>> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be
>> used for older firmwares.
> 
> I assumed you'll add "rtap" cap value (to the internal wl code repository?)
> because you mean to release a firmware using it.
> 
> Maybe you just meant it to be for your customers compiling firmwares on
> their own?

and for customer for whom we compile firmwares based on their feature 
requirements. Anyway, I could build a new firmware for 4366b1/4366c0 
including radiotap. However, end-users may get to use firmware that is 
not supporting it.

>>> Testing the latest release resulted in discovering a new format being
>>> used. It seems (almost?) identical to the one known from ucode used in
>>> SoftMAC devices which is most likely the same codebase anyway.
>>
>> I am a bit confused. How many formats are there? It is either ucode
>> format or radiotap, right?
> 
> So far we got two formats:
> 1) 802.11 frames (with frame (sub)type & all addresses)
> 2) 802.11 frames with the radiotap header
> and now we also have:
> 3) 802.11 frames with the ucode header
> 
> For more info please check my original post:
> Research + questions on brcmfmac and support for monitor mode
> https://www.spinics.net/lists/linux-wireless/msg173573.html

I did read that before, but apparently did miss some details.

>>> While radiotap support was meant to be announced with the "rtap" fw
>>> capability string it seems no alternative was added for the hw/ucode
>>> format. It means each firmware requires a feature mapping quirk.
>>
>> I thought we only needed a quirk for the firmware that provide
>> radiotap but do not announce it. For the others we can assume ucode
>> format if monitor mode is supported. Probably missing something.
> 
> 802.11 frames with ucode header is something entirely new, I didn't see any
> Asus/Linksys/Netgear/TP-LINK firmware using it.
> 
> As the old firmwares were providing frames without any header (also making
> it impossible to e.g. read signal strength) we need this new flag to
> distinguish firmwares with ucode header from them.

Right. Thanks for explaining (again).

Regards,
Arend

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] brcmfmac: support monitor frames with hardware/ucode header
  2019-01-22 11:08 [PATCH] brcmfmac: support monitor frames with hardware/ucode header Rafał Miłecki
  2019-01-25  8:51 ` Arend Van Spriel
@ 2019-02-07 16:36 ` Kalle Valo
       [not found] ` <20190207163638.53A20607DF@smtp.codeaurora.org>
  2019-02-08  6:42 ` [PATCH V2] brcmfmac: support monitor frames with the " Rafał Miłecki
  3 siblings, 0 replies; 9+ messages in thread
From: Kalle Valo @ 2019-02-07 16:36 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list, Rafał Miłecki

Rafał Miłecki wrote:

> From: Rafał Miłecki <rafal@milecki.pl>
> 
> The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
> monitor frames with radiotap header but it doesn't seem to be the case.
> Testing the latest release resulted in discovering a new format being
> used. It seems (almost?) identical to the one known from ucode used in
> SoftMAC devices which is most likely the same codebase anyway.
> 
> While radiotap support was meant to be announced with the "rtap" fw
> capability string it seems no alternative was added for the hw/ucode
> format. It means each firmware requires a feature mapping quirk.
> 
> As for now only an empty radiotap is being created. Adding support for
> extracting some info (band, channel, signal, etc.) is planned for the
> future.
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

It's unclear what I should do with this patch, take it?

-- 
https://patchwork.kernel.org/patch/10775371/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] brcmfmac: support monitor frames with hardware/ucode header
       [not found] ` <20190207163638.53A20607DF@smtp.codeaurora.org>
@ 2019-02-08  6:41   ` Rafał Miłecki
  0 siblings, 0 replies; 9+ messages in thread
From: Rafał Miłecki @ 2019-02-08  6:41 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Arend van Spriel, linux-wireless,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
	brcm80211-dev-list, Rafał Miłecki

On Thu, 7 Feb 2019 at 17:36, Kalle Valo <kvalo@codeaurora.org> wrote:
> Rafał Miłecki wrote:
>
> > From: Rafał Miłecki <rafal@milecki.pl>
> >
> > The new FullMAC firmwares for 4366b1/4366c0 were supposed to provide
> > monitor frames with radiotap header but it doesn't seem to be the case.
> > Testing the latest release resulted in discovering a new format being
> > used. It seems (almost?) identical to the one known from ucode used in
> > SoftMAC devices which is most likely the same codebase anyway.
> >
> > While radiotap support was meant to be announced with the "rtap" fw
> > capability string it seems no alternative was added for the hw/ucode
> > format. It means each firmware requires a feature mapping quirk.
> >
> > As for now only an empty radiotap is being created. Adding support for
> > extracting some info (band, channel, signal, etc.) is planned for the
> > future.
> >
> > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>
> It's unclear what I should do with this patch, take it?

It seems to me there are no objections regarding the code. It was only
my commit message that was a bit confusing. I'll send V2 with updated
commit message.

-- 
Rafał

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH V2] brcmfmac: support monitor frames with the hardware/ucode header
  2019-01-22 11:08 [PATCH] brcmfmac: support monitor frames with hardware/ucode header Rafał Miłecki
                   ` (2 preceding siblings ...)
       [not found] ` <20190207163638.53A20607DF@smtp.codeaurora.org>
@ 2019-02-08  6:42 ` " Rafał Miłecki
  2019-02-08  8:17   ` Arend Van Spriel
  2019-02-08 15:27   ` Kalle Valo
  3 siblings, 2 replies; 9+ messages in thread
From: Rafał Miłecki @ 2019-02-08  6:42 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list, Rafał Miłecki

From: Rafał Miłecki <rafal@milecki.pl>

So far there were two monitor frame formats:
1) 802.11 frames (with frame (sub)type & all addresses)
2) 802.11 frames with the radiotap header

Testing the latest FullMAC firmwares for 4366b1/4366c0 resulted in
discovering a new format being used. It seems (almost?) identical to the
one known from ucode used in SoftMAC devices which is most likely the
same codebase anyway.

While new firmwares will /announce/ radiotap header support using the
"rtap" fw capability string it seems no string was added for the new
ucode header format.

All above means that:
1) We need new format support when dealing with a received frame
2) A new feature bit & mapping quirks have to be added manually

As for now only an empty radiotap is being created. Adding support for
extracting some info (band, channel, signal, etc.) is planned for the
future.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Update commit message (only):
    1) Don't say the new firmwares were expected to provide radiotap
       frames. That was my misinterpretation of adding "rtap" string.
    2) List all monitor frame formats as it apparently got a bit
       confusing at this point (there are 3 different ones!).
---
 .../broadcom/brcm80211/brcmfmac/core.c        | 55 +++++++++++++++++++
 .../broadcom/brcm80211/brcmfmac/feature.c     |  4 ++
 .../broadcom/brcm80211/brcmfmac/feature.h     |  4 +-
 3 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 860a4372cb56..e772c0845638 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -43,6 +43,36 @@
 
 #define BRCMF_BSSIDX_INVALID			-1
 
+#define	RXS_PBPRES				BIT(2)
+
+#define	D11_PHY_HDR_LEN				6
+
+struct d11rxhdr_le {
+	__le16 RxFrameSize;
+	u16 PAD;
+	__le16 PhyRxStatus_0;
+	__le16 PhyRxStatus_1;
+	__le16 PhyRxStatus_2;
+	__le16 PhyRxStatus_3;
+	__le16 PhyRxStatus_4;
+	__le16 PhyRxStatus_5;
+	__le16 RxStatus1;
+	__le16 RxStatus2;
+	__le16 RxTSFTime;
+	__le16 RxChan;
+	u8 unknown[12];
+} __packed;
+
+struct wlc_d11rxhdr {
+	struct d11rxhdr_le rxhdr;
+	__le32 tsf_l;
+	s8 rssi;
+	s8 rxpwr0;
+	s8 rxpwr1;
+	s8 do_rssi_ma;
+	s8 rxpwr[4];
+} __packed;
+
 char *brcmf_ifname(struct brcmf_if *ifp)
 {
 	if (!ifp)
@@ -409,6 +439,31 @@ void brcmf_netif_mon_rx(struct brcmf_if *ifp, struct sk_buff *skb)
 {
 	if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_RADIOTAP)) {
 		/* Do nothing */
+	} else if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR)) {
+		struct wlc_d11rxhdr *wlc_rxhdr = (struct wlc_d11rxhdr *)skb->data;
+		struct ieee80211_radiotap_header *radiotap;
+		unsigned int offset;
+		u16 RxStatus1;
+
+		RxStatus1 = le16_to_cpu(wlc_rxhdr->rxhdr.RxStatus1);
+
+		offset = sizeof(struct wlc_d11rxhdr);
+		/* MAC inserts 2 pad bytes for a4 headers or QoS or A-MSDU
+		 * subframes
+		 */
+		if (RxStatus1 & RXS_PBPRES)
+			offset += 2;
+		offset += D11_PHY_HDR_LEN;
+
+		skb_pull(skb, offset);
+
+		/* TODO: use RX header to fill some radiotap data */
+		radiotap = skb_push(skb, sizeof(*radiotap));
+		memset(radiotap, 0, sizeof(*radiotap));
+		radiotap->it_len = cpu_to_le16(sizeof(*radiotap));
+
+		/* TODO: 4 bytes with receive status? */
+		skb->len -= 4;
 	} else {
 		struct ieee80211_radiotap_header *radiotap;
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 4c5a3995dc35..b91b7ecbfedf 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -103,6 +103,10 @@ static const struct brcmf_feat_fwfeat brcmf_feat_fwfeat_map[] = {
 	{ "01-6cb8e269", BIT(BRCMF_FEAT_MONITOR) },
 	/* brcmfmac4366b-pcie.bin from linux-firmware.git commit 52442afee990 */
 	{ "01-c47a91a4", BIT(BRCMF_FEAT_MONITOR) },
+	/* brcmfmac4366b-pcie.bin from linux-firmware.git commit 211de1679a68 */
+	{ "01-801fb449", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) },
+	/* brcmfmac4366c-pcie.bin from linux-firmware.git commit 211de1679a68 */
+	{ "01-d2cbb8fd", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) },
 };
 
 static void brcmf_feat_firmware_overrides(struct brcmf_pub *drv)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index 0b4974df353a..5e88a7f16ad2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -35,6 +35,7 @@
  * FWSUP: Firmware supplicant.
  * MONITOR: firmware can pass monitor packets to host.
  * MONITOR_FMT_RADIOTAP: firmware provides monitor packets with radiotap header
+ * MONITOR_FMT_HW_RX_HDR: firmware provides monitor packets with hw/ucode header
  */
 #define BRCMF_FEAT_LIST \
 	BRCMF_FEAT_DEF(MBSS) \
@@ -52,7 +53,8 @@
 	BRCMF_FEAT_DEF(GSCAN) \
 	BRCMF_FEAT_DEF(FWSUP) \
 	BRCMF_FEAT_DEF(MONITOR) \
-	BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP)
+	BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP) \
+	BRCMF_FEAT_DEF(MONITOR_FMT_HW_RX_HDR)
 
 /*
  * Quirks:
-- 
2.20.1


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH V2] brcmfmac: support monitor frames with the hardware/ucode header
  2019-02-08  6:42 ` [PATCH V2] brcmfmac: support monitor frames with the " Rafał Miłecki
@ 2019-02-08  8:17   ` Arend Van Spriel
  2019-02-08 15:27   ` Kalle Valo
  1 sibling, 0 replies; 9+ messages in thread
From: Arend Van Spriel @ 2019-02-08  8:17 UTC (permalink / raw)
  To: Rafał Miłecki, Kalle Valo
  Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	Rafał Miłecki

On 2/8/2019 7:42 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> So far there were two monitor frame formats:
> 1) 802.11 frames (with frame (sub)type & all addresses)
> 2) 802.11 frames with the radiotap header
> 
> Testing the latest FullMAC firmwares for 4366b1/4366c0 resulted in
> discovering a new format being used. It seems (almost?) identical to the
> one known from ucode used in SoftMAC devices which is most likely the
> same codebase anyway.
> 
> While new firmwares will /announce/ radiotap header support using the
> "rtap" fw capability string it seems no string was added for the new
> ucode header format.
> 
> All above means that:
> 1) We need new format support when dealing with a received frame
> 2) A new feature bit & mapping quirks have to be added manually
> 
> As for now only an empty radiotap is being created. Adding support for
> extracting some info (band, channel, signal, etc.) is planned for the
> future.

Probably V1 was missing an ACK hence the confusion so to be sure...

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> V2: Update commit message (only):
>      1) Don't say the new firmwares were expected to provide radiotap
>         frames. That was my misinterpretation of adding "rtap" string.
>      2) List all monitor frame formats as it apparently got a bit
>         confusing at this point (there are 3 different ones!).
> ---
>   .../broadcom/brcm80211/brcmfmac/core.c        | 55 +++++++++++++++++++
>   .../broadcom/brcm80211/brcmfmac/feature.c     |  4 ++
>   .../broadcom/brcm80211/brcmfmac/feature.h     |  4 +-
>   3 files changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 860a4372cb56..e772c0845638 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -43,6 +43,36 @@
>   
>   #define BRCMF_BSSIDX_INVALID			-1
>   
> +#define	RXS_PBPRES				BIT(2)
> +
> +#define	D11_PHY_HDR_LEN				6
> +
> +struct d11rxhdr_le {
> +	__le16 RxFrameSize;
> +	u16 PAD;
> +	__le16 PhyRxStatus_0;
> +	__le16 PhyRxStatus_1;
> +	__le16 PhyRxStatus_2;
> +	__le16 PhyRxStatus_3;
> +	__le16 PhyRxStatus_4;
> +	__le16 PhyRxStatus_5;
> +	__le16 RxStatus1;
> +	__le16 RxStatus2;
> +	__le16 RxTSFTime;
> +	__le16 RxChan;
> +	u8 unknown[12];
> +} __packed;
> +
> +struct wlc_d11rxhdr {
> +	struct d11rxhdr_le rxhdr;
> +	__le32 tsf_l;
> +	s8 rssi;
> +	s8 rxpwr0;
> +	s8 rxpwr1;
> +	s8 do_rssi_ma;
> +	s8 rxpwr[4];
> +} __packed;
> +
>   char *brcmf_ifname(struct brcmf_if *ifp)
>   {
>   	if (!ifp)
> @@ -409,6 +439,31 @@ void brcmf_netif_mon_rx(struct brcmf_if *ifp, struct sk_buff *skb)
>   {
>   	if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_RADIOTAP)) {
>   		/* Do nothing */
> +	} else if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR)) {
> +		struct wlc_d11rxhdr *wlc_rxhdr = (struct wlc_d11rxhdr *)skb->data;
> +		struct ieee80211_radiotap_header *radiotap;
> +		unsigned int offset;
> +		u16 RxStatus1;
> +
> +		RxStatus1 = le16_to_cpu(wlc_rxhdr->rxhdr.RxStatus1);
> +
> +		offset = sizeof(struct wlc_d11rxhdr);
> +		/* MAC inserts 2 pad bytes for a4 headers or QoS or A-MSDU
> +		 * subframes
> +		 */
> +		if (RxStatus1 & RXS_PBPRES)
> +			offset += 2;
> +		offset += D11_PHY_HDR_LEN;
> +
> +		skb_pull(skb, offset);
> +
> +		/* TODO: use RX header to fill some radiotap data */
> +		radiotap = skb_push(skb, sizeof(*radiotap));
> +		memset(radiotap, 0, sizeof(*radiotap));
> +		radiotap->it_len = cpu_to_le16(sizeof(*radiotap));
> +
> +		/* TODO: 4 bytes with receive status? */
> +		skb->len -= 4;
>   	} else {
>   		struct ieee80211_radiotap_header *radiotap;
>   
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> index 4c5a3995dc35..b91b7ecbfedf 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
> @@ -103,6 +103,10 @@ static const struct brcmf_feat_fwfeat brcmf_feat_fwfeat_map[] = {
>   	{ "01-6cb8e269", BIT(BRCMF_FEAT_MONITOR) },
>   	/* brcmfmac4366b-pcie.bin from linux-firmware.git commit 52442afee990 */
>   	{ "01-c47a91a4", BIT(BRCMF_FEAT_MONITOR) },
> +	/* brcmfmac4366b-pcie.bin from linux-firmware.git commit 211de1679a68 */
> +	{ "01-801fb449", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) },
> +	/* brcmfmac4366c-pcie.bin from linux-firmware.git commit 211de1679a68 */
> +	{ "01-d2cbb8fd", BIT(BRCMF_FEAT_MONITOR_FMT_HW_RX_HDR) },
>   };
>   
>   static void brcmf_feat_firmware_overrides(struct brcmf_pub *drv)
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
> index 0b4974df353a..5e88a7f16ad2 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
> @@ -35,6 +35,7 @@
>    * FWSUP: Firmware supplicant.
>    * MONITOR: firmware can pass monitor packets to host.
>    * MONITOR_FMT_RADIOTAP: firmware provides monitor packets with radiotap header
> + * MONITOR_FMT_HW_RX_HDR: firmware provides monitor packets with hw/ucode header
>    */
>   #define BRCMF_FEAT_LIST \
>   	BRCMF_FEAT_DEF(MBSS) \
> @@ -52,7 +53,8 @@
>   	BRCMF_FEAT_DEF(GSCAN) \
>   	BRCMF_FEAT_DEF(FWSUP) \
>   	BRCMF_FEAT_DEF(MONITOR) \
> -	BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP)
> +	BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP) \
> +	BRCMF_FEAT_DEF(MONITOR_FMT_HW_RX_HDR)
>   
>   /*
>    * Quirks:
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH V2] brcmfmac: support monitor frames with the hardware/ucode header
  2019-02-08  6:42 ` [PATCH V2] brcmfmac: support monitor frames with the " Rafał Miłecki
  2019-02-08  8:17   ` Arend Van Spriel
@ 2019-02-08 15:27   ` Kalle Valo
  1 sibling, 0 replies; 9+ messages in thread
From: Kalle Valo @ 2019-02-08 15:27 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Arend van Spriel, linux-wireless, brcm80211-dev-list.pdl,
	brcm80211-dev-list, Rafał Miłecki

Rafał Miłecki wrote:

> From: Rafał Miłecki <rafal@milecki.pl>
> 
> So far there were two monitor frame formats:
> 1) 802.11 frames (with frame (sub)type & all addresses)
> 2) 802.11 frames with the radiotap header
> 
> Testing the latest FullMAC firmwares for 4366b1/4366c0 resulted in
> discovering a new format being used. It seems (almost?) identical to the
> one known from ucode used in SoftMAC devices which is most likely the
> same codebase anyway.
> 
> While new firmwares will /announce/ radiotap header support using the
> "rtap" fw capability string it seems no string was added for the new
> ucode header format.
> 
> All above means that:
> 1) We need new format support when dealing with a received frame
> 2) A new feature bit & mapping quirks have to be added manually
> 
> As for now only an empty radiotap is being created. Adding support for
> extracting some info (band, channel, signal, etc.) is planned for the
> future.
> 
> 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.

e665988be29c brcmfmac: support monitor frames with the hardware/ucode header

-- 
https://patchwork.kernel.org/patch/10802433/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-22 11:08 [PATCH] brcmfmac: support monitor frames with hardware/ucode header Rafał Miłecki
2019-01-25  8:51 ` Arend Van Spriel
2019-01-25  9:11   ` Rafał Miłecki
2019-01-25  9:32     ` Arend Van Spriel
2019-02-07 16:36 ` Kalle Valo
     [not found] ` <20190207163638.53A20607DF@smtp.codeaurora.org>
2019-02-08  6:41   ` Rafał Miłecki
2019-02-08  6:42 ` [PATCH V2] brcmfmac: support monitor frames with the " Rafał Miłecki
2019-02-08  8:17   ` Arend Van Spriel
2019-02-08 15:27   ` Kalle Valo

Linux-Wireless Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-wireless/0 linux-wireless/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-wireless linux-wireless/ https://lore.kernel.org/linux-wireless \
		linux-wireless@vger.kernel.org linux-wireless@archiver.kernel.org
	public-inbox-index linux-wireless


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-wireless


AGPL code for this site: git clone https://public-inbox.org/ public-inbox