linux-kernel - Re: [PATCH ath-next 5/6] wifi: ath11k: Register DBR event handler for CFR data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0d7e89b1-b676-434c-bea3-fbf6f5788448@oss.qualcomm.com>
Date: Fri, 31 Oct 2025 10:59:14 +0800
From: Baochen Qiang <baochen.qiang@....qualcomm.com>
To: "Yu Zhang(Yuriy)" <yu.zhang@....qualcomm.com>, jjohnson@...nel.org
Cc: linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
        ath11k@...ts.infradead.org
Subject: Re: [PATCH ath-next 5/6] wifi: ath11k: Register DBR event handler for
 CFR data



On 10/30/2025 12:31 PM, Yu Zhang(Yuriy) wrote:

> +
> +/* Correlate and relay: This function correlate the data coming from
> + * WMI_PDEV_DMA_RING_BUF_RELEASE_EVENT(DBR event) and
> + * WMI_PEER_CFR_CAPTURE_EVENT(Tx capture event).
> + * If both the events are received and PPDU id matches from both the
> + * events, return CORRELATE_STATUS_RELEASE which means relay the
> + * correlated data to user space. Otherwise return CORRELATE_STATUS_HOLD
> + * which means wait for the second event to come.
> + *
> + * It also check for the pending DBR events and clear those events
> + * in case of corresponding TX capture event is not received for
> + * the PPDU.
> + */

please check comment style

> +
> +static enum ath11k_cfr_correlate_status
> +ath11k_cfr_correlate_and_relay(struct ath11k *ar,
> +			       struct ath11k_look_up_table *lut,
> +			       u8 event_type)
> +{
> +	enum ath11k_cfr_correlate_status status;
> +	struct ath11k_cfr *cfr = &ar->cfr;
> +	u64 diff;
> +
> +	if (event_type == ATH11K_CORRELATE_TX_EVENT) {
> +		if (lut->tx_recv)
> +			cfr->cfr_dma_aborts++;
> +		cfr->tx_evt_cnt++;
> +		lut->tx_recv = true;
> +	} else if (event_type == ATH11K_CORRELATE_DBR_EVENT) {
> +		cfr->dbr_evt_cnt++;
> +		lut->dbr_recv = true;
> +	}
> +
> +	if (lut->dbr_recv && lut->tx_recv) {
> +		if (lut->dbr_ppdu_id == lut->tx_ppdu_id) {
> +			/* We are using 64-bit counters here. So, it may take
> +			 * several year to hit wraparound. Hence, not handling
> +			 * the wraparound condition.
> +			 */

and here

> +			cfr->last_success_tstamp = lut->dbr_tstamp;
> +			if (lut->dbr_tstamp > lut->txrx_tstamp) {
> +				diff = lut->dbr_tstamp - lut->txrx_tstamp;
> +				ath11k_dbg(ar->ab, ATH11K_DBG_CFR,
> +					   "txrx event -> dbr event delay = %u ms",
> +					   jiffies_to_msecs(diff));
> +			} else if (lut->txrx_tstamp > lut->dbr_tstamp) {
> +				diff = lut->txrx_tstamp - lut->dbr_tstamp;
> +				ath11k_dbg(ar->ab, ATH11K_DBG_CFR,
> +					   "dbr event -> txrx event delay = %u ms",
> +					   jiffies_to_msecs(diff));
> +			}
> +
> +			ath11k_cfr_free_pending_dbr_events(ar);
> +
> +			cfr->release_cnt++;
> +			status = ATH11K_CORRELATE_STATUS_RELEASE;
> +		} else {
> +			/* When there is a ppdu id mismatch, discard the TXRX
> +			 * event since multiple PPDUs are likely to have same
> +			 * dma addr, due to ucode aborts.
> +			 */

and here

> +
> +			ath11k_dbg(ar->ab, ATH11K_DBG_CFR,
> +				   "Received dbr event twice for the same lut entry");
> +			lut->tx_recv = false;
> +			lut->tx_ppdu_id = 0;
> +			cfr->clear_txrx_event++;
> +			cfr->cfr_dma_aborts++;
> +			status = ATH11K_CORRELATE_STATUS_HOLD;
> +		}
> +	} else {
> +		status = ATH11K_CORRELATE_STATUS_HOLD;
> +	}
> +
> +	return status;
> +}
> +