Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Wed, 2024-04-24 at 12:26 +0530, Karthikeyan Periyasamy wrote: >> Currently, hardware state is not protected across the reconfigure >> operations. However, in single wiphy models, multiple radio/links is >> exposed as a MAC hardware (ieee80211_hw) through the driver hardware >> abstraction (ath12k_hw) layer. In such scenario, we need to protect >> hardware state across the multiple radio/link at the driver hardware >> abstraction (ath12k_hw) layer. Therefore, introduce a new mutex in >> the ath12k_hw layer. >> > > It's your driver, but ... it would seem _simpler_ to do locking across > the hw with a single wiphy model, because everything (except currently > for ath12k_core_reset and ath12k_core_restart) already holds the wiphy > mutex. You can probably move those to wiphy work. > > I'd avoid doing lock explosion like we had in mac80211, it's going to > come back and bite you eventually :) 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. One way to solve that might be to convert WMI event handling to use wiphy work but didn't have the time to work on that so I put it on the backborner. I should resurrect that branch and submit it as RFC. But for the time being I think we need to add another mutex to ath12k, I don't want to block Karthikeyan for too long. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
