James Prestwood <prestwoj@xxxxxxxxx> writes: > On 11/13/23 7:50 AM, Kalle Valo wrote: >> James Prestwood <prestwoj@xxxxxxxxx> 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@xxxxxxxxx> >>> Signed-off-by: Kalle Valo <quic_kvalo@xxxxxxxxxxx> >> 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