linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit
@ 2018-07-30 15:39 Sven Eckelmann
  2018-07-30 18:50 ` Arend van Spriel
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Sven Eckelmann @ 2018-07-30 15:39 UTC (permalink / raw)
  To: ath10k; +Cc: linux-wireless, Sven Eckelmann

Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in
the RX and TX path. These filtered channel can in theory still be used by
the hardware but the signal strength is reduced so much that it makes no
sense.

There is already a DT property to limit the available channels but ath10k
has to manually call this functionality to limit the currrently set wiphy
channels further.

Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 95243b48a179..8ed37ffd320f 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -18,6 +18,7 @@
 
 #include "mac.h"
 
+#include <net/cfg80211.h>
 #include <net/mac80211.h>
 #include <linux/etherdevice.h>
 #include <linux/acpi.h>
@@ -8306,6 +8307,7 @@ int ath10k_mac_register(struct ath10k *ar)
 		ar->hw->wiphy->bands[NL80211_BAND_5GHZ] = band;
 	}
 
+	wiphy_read_of_freq_limits(ar->hw->wiphy);
 	ath10k_mac_setup_ht_vht_cap(ar);
 
 	ar->hw->wiphy->interface_modes =
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit
  2018-07-30 15:39 [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit Sven Eckelmann
@ 2018-07-30 18:50 ` Arend van Spriel
  2018-08-24 11:46   ` Kalle Valo
  2018-07-30 18:54 ` Arend van Spriel
  2018-08-28 13:51 ` Kalle Valo
  2 siblings, 1 reply; 6+ messages in thread
From: Arend van Spriel @ 2018-07-30 18:50 UTC (permalink / raw)
  To: Sven Eckelmann, ath10k; +Cc: linux-wireless, Rafał Miłecki

+ Rafał

On 7/30/2018 5:39 PM, Sven Eckelmann wrote:
> Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in
> the RX and TX path. These filtered channel can in theory still be used by
> the hardware but the signal strength is reduced so much that it makes no
> sense.
>
> There is already a DT property to limit the available channels but ath10k
> has to manually call this functionality to limit the currrently set wiphy
> channels further.

Wondering whether we can call it in wiphy_register() like below. Not 
sure why we did not explore that with the introduction of it by Rafał. 
Maybe he remembers. I did not find something in that direction in 
patchwork, but may have missed it. I know mt76 drops the band reference 
if it ends up with all channels disabled. Maybe that was the reason.

Regards,
Arend
---
diff --git a/net/wireless/core.c b/net/wireless/core.c
index a88551f..2e00cb1 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -742,6 +742,8 @@ int wiphy_register(struct wiphy *wiphy)
	if (res)
		return res;

+	wiphy_read_of_freq_limits(wiphy);
+
	/* sanity check supported bands/channels */
	for (band = 0; band < NUM_NL80211_BANDS; band++) {
		u16 types = 0;

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit
  2018-07-30 15:39 [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit Sven Eckelmann
  2018-07-30 18:50 ` Arend van Spriel
@ 2018-07-30 18:54 ` Arend van Spriel
  2018-07-30 18:56   ` Arend van Spriel
  2018-08-28 13:51 ` Kalle Valo
  2 siblings, 1 reply; 6+ messages in thread
From: Arend van Spriel @ 2018-07-30 18:54 UTC (permalink / raw)
  To: Sven Eckelmann, ath10k; +Cc: linux-wireless, Rafał Miłecki

+ Rafał

On 7/30/2018 5:39 PM, Sven Eckelmann wrote:
> Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in
> the RX and TX path. These filtered channel can in theory still be used by
> the hardware but the signal strength is reduced so much that it makes no
> sense.
>
> There is already a DT property to limit the available channels but ath10k
> has to manually call this functionality to limit the currrently set wiphy
> channels further.

Wondering whether we can call it in wiphy_register() like below. Not 
sure why we did not explore that with the introduction of it by Rafał. 
Maybe he remembers. I did not find something in that direction in 
patchwork, but may have missed it. I know mt76 drops the band reference 
if it ends up with all channels disabled. Maybe that was the reason.

Regards,
Arend
---
diff --git a/net/wireless/core.c b/net/wireless/core.c
index a88551f..2e00cb1 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -742,6 +742,8 @@ int wiphy_register(struct wiphy *wiphy)
	if (res)
		return res;

+	wiphy_read_of_freq_limits(wiphy);
+
	/* sanity check supported bands/channels */
	for (band = 0; band < NUM_NL80211_BANDS; band++) {
		u16 types = 0;

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit
  2018-07-30 18:54 ` Arend van Spriel
@ 2018-07-30 18:56   ` Arend van Spriel
  0 siblings, 0 replies; 6+ messages in thread
From: Arend van Spriel @ 2018-07-30 18:56 UTC (permalink / raw)
  To: Sven Eckelmann, ath10k; +Cc: linux-wireless, Rafał Miłecki

On 7/30/2018 8:54 PM, Arend van Spriel wrote:
> + Rafał
>
> On 7/30/2018 5:39 PM, Sven Eckelmann wrote:
>> Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special
>> filters in
>> the RX and TX path. These filtered channel can in theory still be used by
>> the hardware but the signal strength is reduced so much that it makes no
>> sense.
>>
>> There is already a DT property to limit the available channels but ath10k
>> has to manually call this functionality to limit the currrently set wiphy
>> channels further.
>
> Wondering whether we can call it in wiphy_register() like below. Not
> sure why we did not explore that with the introduction of it by Rafał.
> Maybe he remembers. I did not find something in that direction in
> patchwork, but may have missed it. I know mt76 drops the band reference
> if it ends up with all channels disabled. Maybe that was the reason.

Sorry for sending this twice. My wifi connection was quirky.

Gr. AvS

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit
  2018-07-30 18:50 ` Arend van Spriel
@ 2018-08-24 11:46   ` Kalle Valo
  0 siblings, 0 replies; 6+ messages in thread
From: Kalle Valo @ 2018-08-24 11:46 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: Sven Eckelmann, ath10k, Rafał Miłecki, linux-wireless

Arend van Spriel <arend.vanspriel@broadcom.com> writes:

> + Rafa=C5=82
>
> On 7/30/2018 5:39 PM, Sven Eckelmann wrote:
>> Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters=
 in
>> the RX and TX path. These filtered channel can in theory still be used by
>> the hardware but the signal strength is reduced so much that it makes no
>> sense.
>>
>> There is already a DT property to limit the available channels but ath10k
>> has to manually call this functionality to limit the currrently set wiphy
>> channels further.
>
> Wondering whether we can call it in wiphy_register() like below. Not
> sure why we did not explore that with the introduction of it by Rafa=C5=
=82.
> Maybe he remembers. I did not find something in that direction in
> patchwork, but may have missed it. I know mt76 drops the band
> reference if it ends up with all channels disabled. Maybe that was the
> reason.
>
> Regards,
> Arend
> ---
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index a88551f..2e00cb1 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -742,6 +742,8 @@ int wiphy_register(struct wiphy *wiphy)
> 	if (res)
> 		return res;
>
> +	wiphy_read_of_freq_limits(wiphy);
> +
> 	/* sanity check supported bands/channels */
> 	for (band =3D 0; band < NUM_NL80211_BANDS; band++) {
> 		u16 types =3D 0;

Nobody commented to this, so not sure what to do. Maybe it's best to
apply Sven's patch now and we can later move the call to cfg80211 if
needed. Sounds good?

--=20
Kalle Valo

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit
  2018-07-30 15:39 [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit Sven Eckelmann
  2018-07-30 18:50 ` Arend van Spriel
  2018-07-30 18:54 ` Arend van Spriel
@ 2018-08-28 13:51 ` Kalle Valo
  2 siblings, 0 replies; 6+ messages in thread
From: Kalle Valo @ 2018-08-28 13:51 UTC (permalink / raw)
  To: Sven Eckelmann; +Cc: ath10k, linux-wireless, Sven Eckelmann

Sven Eckelmann <sven.eckelmann@openmesh.com> wrote:

> Tri-band devices (1x 2.4GHz + 2x 5GHz) often incorporate special filters in
> the RX and TX path. These filtered channel can in theory still be used by
> the hardware but the signal strength is reduced so much that it makes no
> sense.
> 
> There is already a DT property to limit the available channels but ath10k
> has to manually call this functionality to limit the currrently set wiphy
> channels further.
> 
> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

34d5629d2ca8 ath10k: limit available channels via DT ieee80211-freq-limit

-- 
https://patchwork.kernel.org/patch/10549245/

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-08-28 17:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-30 15:39 [PATCH] ath10k: Limit available channels via DT ieee80211-freq-limit Sven Eckelmann
2018-07-30 18:50 ` Arend van Spriel
2018-08-24 11:46   ` Kalle Valo
2018-07-30 18:54 ` Arend van Spriel
2018-07-30 18:56   ` Arend van Spriel
2018-08-28 13:51 ` Kalle Valo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).