All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Wen Gong <quic_wgong@quicinc.com>
Cc: <ath11k@lists.infradead.org>,  <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v4 2/5] wifi: ath11k: store cur_regulatory_info for each radio
Date: Wed, 02 Aug 2023 14:30:55 +0300	[thread overview]
Message-ID: <878ratwuj4.fsf@kernel.org> (raw)
In-Reply-To: <20230607094810.26707-3-quic_wgong@quicinc.com> (Wen Gong's message of "Wed, 7 Jun 2023 05:48:07 -0400")

Wen Gong <quic_wgong@quicinc.com> writes:

> The regulatory info of WMI_REG_CHAN_LIST_CC_EXT_EVENTID is not saved
> in ath11k now, the info should be saved in ath11k. Save the info for
> each radio and support switch regulatory rules dynamically.
>
> Tested-on: WCN6855 hw2.0 PCI
> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <quic_wgong@quicinc.com>

[...]

> +enum wmi_vdev_type ath11k_mac_get_ar_vdev_type(struct ath11k *ar)
> +{
> +	struct ath11k_vif *arvif;
> +
> +	list_for_each_entry(arvif, &ar->arvifs, list) {
> +		return arvif->vdev_type;
> +	}
> +
> +	return WMI_VDEV_TYPE_UNSPEC;
> +}

This function looks odd to me and there are no comments to clarify.
What's the idea of using list_for_each_entry() and then immediately
return with the first entry? I guess the assumption here is that every
arvif has the same type? Can we really trust that? And at least it
should be documented here.

Also wouldn't list_first_entry_or_null() be more intuitive?

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

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

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@kernel.org>
To: Wen Gong <quic_wgong@quicinc.com>
Cc: <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v4 2/5] wifi: ath11k: store cur_regulatory_info for each radio
Date: Wed, 02 Aug 2023 14:30:55 +0300	[thread overview]
Message-ID: <878ratwuj4.fsf@kernel.org> (raw)
In-Reply-To: <20230607094810.26707-3-quic_wgong@quicinc.com> (Wen Gong's message of "Wed, 7 Jun 2023 05:48:07 -0400")

Wen Gong <quic_wgong@quicinc.com> writes:

> The regulatory info of WMI_REG_CHAN_LIST_CC_EXT_EVENTID is not saved
> in ath11k now, the info should be saved in ath11k. Save the info for
> each radio and support switch regulatory rules dynamically.
>
> Tested-on: WCN6855 hw2.0 PCI
> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
>
> Signed-off-by: Wen Gong <quic_wgong@quicinc.com>

[...]

> +enum wmi_vdev_type ath11k_mac_get_ar_vdev_type(struct ath11k *ar)
> +{
> +	struct ath11k_vif *arvif;
> +
> +	list_for_each_entry(arvif, &ar->arvifs, list) {
> +		return arvif->vdev_type;
> +	}
> +
> +	return WMI_VDEV_TYPE_UNSPEC;
> +}

This function looks odd to me and there are no comments to clarify.
What's the idea of using list_for_each_entry() and then immediately
return with the first entry? I guess the assumption here is that every
arvif has the same type? Can we really trust that? And at least it
should be documented here.

Also wouldn't list_first_entry_or_null() be more intuitive?

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

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

  reply	other threads:[~2023-08-02 11:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-07  9:48 [PATCH v4 0/5] fix wrong TX power and frequency in regdomain by dynamic switch 6 GHz reg rules of LPI/SP/VLP for station mode Wen Gong
2023-06-07  9:48 ` Wen Gong
2023-06-07  9:48 ` [PATCH v4 1/5] wifi: ath11k: add support to select 6 GHz Regulatory type Wen Gong
2023-06-07  9:48   ` Wen Gong
2023-08-02 11:45   ` Kalle Valo
2023-08-02 11:45     ` Kalle Valo
2023-06-07  9:48 ` [PATCH v4 2/5] wifi: ath11k: store cur_regulatory_info for each radio Wen Gong
2023-06-07  9:48   ` Wen Gong
2023-08-02 11:30   ` Kalle Valo [this message]
2023-08-02 11:30     ` Kalle Valo
2023-08-02 11:36   ` Kalle Valo
2023-08-02 11:36     ` Kalle Valo
2023-06-07  9:48 ` [PATCH v4 3/5] wifi: ath11k: fix a possible dead lock caused by ab->base_lock Wen Gong
2023-06-07  9:48   ` Wen Gong
2023-06-07  9:48 ` [PATCH v4 4/5] wifi: ath11k: update regulatory rules when interface added Wen Gong
2023-06-07  9:48   ` Wen Gong
2023-08-02 11:44   ` Kalle Valo
2023-08-02 11:44     ` Kalle Valo
2023-08-02 11:46   ` Kalle Valo
2023-08-02 11:46     ` Kalle Valo
2023-06-07  9:48 ` [PATCH v4 5/5] wifi: ath11k: update regulatory rules when connect to AP on 6 GHz band for station Wen Gong
2023-06-07  9:48   ` Wen Gong

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=878ratwuj4.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath11k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=quic_wgong@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.