Received-SPF: pass (google.com: domain of linux-wireless+bounces-6762-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <3dc4339f5c3f603027c2214058e7e3251652a7f0.camel@sipsolutions.net>
Subject: Re: [PATCH v2 3/3] wifi: ath12k: Add lock to protect the hardware
 state
From: Johannes Berg <johannes@sipsolutions.net>
To: Kalle Valo <kvalo@kernel.org>
Cc: Karthikeyan Periyasamy <quic_periyasa@quicinc.com>, 
	ath12k@lists.infradead.org, linux-wireless@vger.kernel.org
Date: Wed, 24 Apr 2024 11:43:58 +0200
In-Reply-To: <87il07t7zq.fsf@kernel.org>
References: <20240424065646.1666166-1-quic_periyasa@quicinc.com>
	 <20240424065646.1666166-4-quic_periyasa@quicinc.com>
	 <517caf852d37b3803bcf087a6b575f2ecdb5ba10.camel@sipsolutions.net>
	 <87il07t7zq.fsf@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Wed, 2024-04-24 at 12:39 +0300, Kalle Valo wrote:
>=20
> Exactly. Swithing to use wiphy_lock() definitely one of my longterm
> goals in ath12k. I already started working on switching ath12k to use
> wiphy_lock() but IIRC I got blocked by not being able to call
> wiphy_delayed_work_cancel() without taking wiphy_lock.

That's because I didn't want to have an async version, but theoretically
we could have a version of it that just cancels the timer. If you don't
hold the wiphy mutex already you could even wait for it to finish. It
just adds more complexity there, and I was trying to make it all a lot
more obvious :)

johannes