Re: [PATCH] wifi: ath10k: add support to allow broadcast action from RX

From: Kalle Valo <kvalo@kernel.org>
To: James Prestwood <prestwoj@gmail.com>
Cc: linux-wireless@vger.kernel.org,  ath10k@lists.infradead.org
Subject: Re: [PATCH] wifi: ath10k: add support to allow broadcast action from RX
Date: Tue, 14 Nov 2023 10:20:10 +0200	[thread overview]
Message-ID: <87wmuk926d.fsf@kernel.org> (raw)
In-Reply-To: <2033c16c-4d9a-4592-bb81-7a9ad7821576@gmail.com> (James Prestwood's message of "Mon, 13 Nov 2023 09:27:59 -0800")

James Prestwood <prestwoj@gmail.com> writes:

> On 11/13/23 7:50 AM, Kalle Valo wrote:
>> James Prestwood <prestwoj@gmail.com> wrote:
>> 
>>> Advertise support for multicast frame registration and update the RX
>>> filter with FIF_MCAST_ACTION to allow broadcast action frames to be
>>> received. Broadcast action frames are needed for the Device
>>> Provisioning Protocol (DPP) for Presence and PKEX Exchange requests.
>>>
>>> Signed-off-by: James Prestwood <prestwoj@gmail.com>
>>> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
>> On what hardware and firmware did you test with this? As there's so
>> many
>> different combinations in ath10k we use Tested-on tag to document that.
>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches#tested-on_tag
>> As ath10k hardware and firmware can work very differently from each
>> other I'm
>> suspicious if this feature really work in all of them.
>
> I only tested on a QCA6174 (and I'll add Tested-on for that). This
> makes sense and maybe enabling unconditionally for all ath10k hardware
> is the wrong way to go about it.
>
> Since I don't have the ability to test every hardware combination
> hopefully someone from atheros can chime in.

Heh, Atheros is long gone. But your comment made me remember the good
old times and smile :)

> Is there some firmware/driver value that can be queried which tells me
> if broadcast RX is supported?

A good question for which I don't have an answer. Does anyone else know?

Do you have a simple test case for this? It would help if people could
test this feature on their ath10k devices and send us results.

> Or if not is checking ar->hw_rev == ATH10K_HW_QCA6174 good enough? 

BTW instead of checking ar->hw_rev our preference is to add a new
boolean to struct ath10k_hw_params. That way it's easier to enable and
disable the feature per hardware version.

> Or are there sub-variants that may or may not support this?

There are several QCA6174 variants and you can check the variants from
ath10k_hw_params_list. For example, hw2.1 or SDIO firmware may very well
behave different from the PCI firmware. To be on the safe side I think it's
best to enable the feature only on the hardware versions we have
verified to work.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k