From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sipsolutions.net (s3.sipsolutions.net [168.119.38.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01A12343D64; Fri, 5 Jun 2026 07:28:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=168.119.38.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780644499; cv=none; b=jy+C7c6I1EyhChYYusIBSZW8Jpw8CibYmIExkOAboFpH8UFmuhjFULPA+w2GQ0JLPCRGpn1N7Ahry6baibT7NDOI9J4Q2dIch6EZG3fNalKVLON4seUVCJRWK5bYhSgKb7l9jn0ARk/nwnfab5S0vF28PJB1F6big7NAIRrb7DI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780644499; c=relaxed/simple; bh=0HROfVI/XiLF1xWKlzwUMuR0jmWMYLR3uT5U1EcQFAU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=KgtffAj9z0x43KcWVQswuF7zxb9LjfzwMfNP9A1WUNb5PzOlxIe5uk0pjFbsCZrTp4nx2b2f7NAUbJetbrwedP2ORHKqC6bY5QD+TgncnMJ2gcNLLH5o6F0+12K9Y74e9mTS/3IHVFK632SkkTq16vbGfjLomeE/aKnhnC5gySI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=permerror header.from=sipsolutions.net; spf=none smtp.mailfrom=sipsolutions.net; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b=HX7TcGac; arc=none smtp.client-ip=168.119.38.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=permerror header.from=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=sipsolutions.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sipsolutions.net header.i=@sipsolutions.net header.b="HX7TcGac" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=kg7vhdOMXN34+VP2Kqesep7JkjcC00cEgmM2EsqRbs8=; t=1780644496; x=1781854096; b=HX7TcGacX+QPJhYFctqFIcOa451L3yKQc1JJu8FEs3SCoCw x+yVUxz9A7PLAOPmoPU6A10UEXSVGQXDvQPaUYSA4evoNRybC9EzhDZcUw9di3SsGpM323ZcZYPEx L/qG2UxSikQaaYf3Out3Uo5fo92ZOGbg3gUj2FY51YFb+IWif93ZuQ9vqNc9GYyX9Pt0v0a9p07xA ptMX10CFzk2HkqNt5TXX5umneJuPdFMKfbLo6GZhspRhYGVXmpPJ/yzkUxQswWib1yquI8PUbUNR6 1RYClCoxVgmhysHIwqwH3hK5x+mLJpIpMD7OC1ujeQZSmTmVNMrJdG6HmM9K8zPQ==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.98.2) (envelope-from ) id 1wVOyQ-0000000248T-3Esx; Fri, 05 Jun 2026 09:28:11 +0200 Message-ID: <93fee0ae9311d6c1e0d72c2c6b15be2de70f3d20.camel@sipsolutions.net> Subject: Re: [PATCH wireless-next v2 12/31] wifi: mm81x: add mac.c From: Johannes Berg To: Lachlan Hodges Cc: Dan Callaghan , Arien Judge , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , ayman.grais@morsemicro.com, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Date: Fri, 05 Jun 2026 09:28:09 +0200 In-Reply-To: (sfid-20260605_082632_698815_0923094C) References: <20260430045615.334669-1-lachlan.hodges@morsemicro.com> <20260430045615.334669-13-lachlan.hodges@morsemicro.com> (sfid-20260605_082632_698815_0923094C) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-malware-bazaar: not-scanned On Fri, 2026-06-05 at 16:26 +1000, Lachlan Hodges wrote: > Hi Johannes, just having a think about how to do this: >=20 > On Thu, Jun 04, 2026 at 01:46:32PM +0200, Johannes Berg wrote: > >=20 > > > +static void mm81x_mac_ops_flush(struct ieee80211_hw *hw, > > > + struct ieee80211_vif *vif, u32 queues, > > > + bool drop) > > > +{ > > > + struct mm81x *mors =3D hw->priv; > > > + > > > + /* We don't support IEEE80211_HW_QUEUE_CONTROL so flush all queues = */ > > > + if (drop) { > > > + /* > > > + * No need to call mm81x_skbq_stop_tx_queues as mac80211 > > > + * has already cancelled each queue prior to calling .flush() > > > + */ > > > + mm81x_skbq_data_traffic_pause(mors); > > > + > > > + flush_work(&mors->hif_work); > > > + flush_work(&mors->tx_stale_work); > > > + > > > + mm81x_hif_clear_events(mors); > > > + mm81x_hif_flush_tx_data(mors); > > > + mm81x_hif_flush_cmds(mors); > > > + > > > + /* Reenable data, not that there will be any */ > > > + mm81x_skbq_data_traffic_resume(mors); > > > + } > > > +} > >=20 > > Doing nothing in the !drop case seems questionable - mac80211 uses this > > sometimes to e.g. make sure a deauth frame really went out before > > shutting down the hardware. >=20 > What is the consensus=C2=A0 No idea ;-) > (or I guess your opinion) on using > read_poll_timeout() with a function that isn't really doing any real > I/O but rather just reading software queue state? [snip] > It is fairly easy to opencode something similar, but this looks nice :) > though I can't see many examples of using it like this so I am > a bit cautious. I think the more common way to do this would be to have an explicit waitq so you don't have to poll, and trigger that whenever the queues become empty. With hardware you often don't have a signal so you have to poll, though in some cases if you have an interrupt you'd prefer that too. johannes