All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Karthikeyan Periyasamy <quic_periyasa@quicinc.com>
Cc: <ath12k@lists.infradead.org>,  <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] wifi: ath12k: Introduce the container for mac80211 hw
Date: Mon, 15 Jan 2024 18:08:43 +0200	[thread overview]
Message-ID: <87bk9m7f5g.fsf@kernel.org> (raw)
In-Reply-To: <20240112024214.3481840-3-quic_periyasa@quicinc.com> (Karthikeyan Periyasamy's message of "Fri, 12 Jan 2024 08:12:14 +0530")

Karthikeyan Periyasamy <quic_periyasa@quicinc.com> writes:

> To support multi link operation, we need to combine all the link/pdev
> under a single wiphy. This avoids the overhead of synchronization
> across multiple hardware instances in both the cfg80211 and mac80211
> layers. Currently, each link/pdev is registered as separate wiphy,
> tightly coupled with link/pdev/radio (ar) structure. To enable single
> wiphy registration within the chip, we decouple the wiphy data entity from
> the link/pdev/radio (ar) structure and move it under the chip (ab)
> structure with a new data container (ath12k_hw) structure. This approach
> improves scalability for future multi link operation support.

What about struct ath12k_pdev? Do we need it still or should it be removed?

>  static void ath12k_mac_op_cancel_hw_scan(struct ieee80211_hw *hw,
>  					 struct ieee80211_vif *vif)
>  {
> -	struct ath12k *ar = hw->priv;
> +	struct ath12k_hw *ah = ath12k_hw_to_ah(hw);
> +	struct ath12k *ar;
> +
> +	mutex_lock(&ah->conf_mutex);
> +
> +	ar = ath12k_ah_to_ar(ah);
>  
>  	mutex_lock(&ar->conf_mutex);
>  	ath12k_scan_abort(ar);
>  	mutex_unlock(&ar->conf_mutex);
>  
> +	mutex_unlock(&ah->conf_mutex);
> +
>  	cancel_delayed_work_sync(&ar->scan.timeout);
>  }

Do we really need two mutexes? I don't see any analysis about that. And
even if we do, I feel that it should be added in a separate patch.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


  parent reply	other threads:[~2024-01-15 16:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12  2:42 [PATCH v2 0/2] wifi: ath12k: Introduce hw abstraction Karthikeyan Periyasamy
2024-01-12  2:42 ` [PATCH v2 1/2] wifi: ath12k: Refactor the mac80211 hw access from link/radio Karthikeyan Periyasamy
2024-01-12 16:38   ` Jeff Johnson
2024-01-12  2:42 ` [PATCH v2 2/2] wifi: ath12k: Introduce the container for mac80211 hw Karthikeyan Periyasamy
2024-01-12 16:39   ` Jeff Johnson
2024-01-15 16:08   ` Kalle Valo [this message]
2024-01-16  5:14     ` Karthikeyan Periyasamy
2024-01-16 12:38       ` Kalle Valo
2024-01-16  4:26   ` kernel test robot
2024-01-15 16:19 ` [PATCH v2 0/2] wifi: ath12k: Introduce hw abstraction Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bk9m7f5g.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath12k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=quic_periyasa@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.