All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC v3 06/11] ath10k: htt: High latency RX support
Date: Fri, 22 Dec 2017 15:32:09 +0000	[thread overview]
Message-ID: <87k1xeaidi.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20170917194013.8658-7-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Sun, 17 Sep 2017 21:40:08 +0200")

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> Special HTT RX handling for high latency interfaces.
>
> Since no DMA physical addresses are used in the RX ring
> config message (this is not supported by the high latency
> devices), no RX ring is allocated.
> All RX skb's are allocated by the driver and passed directly
> to mac80211 in the HTT RX indication handler.
>
> A nice side effect of this is that no huge buffer will be
> allocated with dma_alloc_coherent. On embedded systems with
> limited memory resources, the allocation of the RX ring is
> prone to fail.
>
> Some tweaks made to "make it work":
>
> Removal of protected bit in 802.11 header frame control field.
> The chipset seems to do hw decryption but the frame_control
> protected bit is still set.
>
> This is necessary for mac80211 not to drop the frame.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.c    |  27 ++++---
>  drivers/net/wireless/ath/ath10k/htt.h     |  47 ++++++++++++
>  drivers/net/wireless/ath/ath10k/htt_rx.c  | 119 +++++++++++++++++++++++++++++-
>  drivers/net/wireless/ath/ath10k/rx_desc.h |  15 ++++
>  4 files changed, 195 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index c21227a74996..1880570989ae 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -2083,10 +2083,12 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
>  	ar->htt.rx_ring.in_ord_rx = !!(test_bit(WMI_SERVICE_RX_FULL_REORDER,
>  						ar->wmi.svc_map));
>  
> -	status = ath10k_htt_rx_alloc(&ar->htt);
> -	if (status) {
> -		ath10k_err(ar, "failed to alloc htt rx: %d\n", status);
> -		goto err_htt_tx_detach;
> +	if (!ar->is_high_latency) {
> +		status = ath10k_htt_rx_alloc(&ar->htt);
> +		if (status) {
> +			ath10k_err(ar, "failed to alloc htt rx: %d\n", status);
> +			goto err_htt_tx_detach;
> +		}
>  	}

Wouldn't it be cleaner code to have the is_high_latency check within
ath10k_htt_rx_alloc() call?

> @@ -2203,10 +2205,13 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
>  		}
>  	}
>  
> -	status = ath10k_htt_rx_ring_refill(ar);
> -	if (status) {
> -		ath10k_err(ar, "failed to refill htt rx ring: %d\n", status);
> -		goto err_hif_stop;
> +	if (!ar->is_high_latency) {
> +		status = ath10k_htt_rx_ring_refill(ar);
> +		if (status) {
> +			ath10k_err(ar, "failed to refill htt rx ring: %d\n",
> +				   status);
> +			goto err_hif_stop;
> +		}
>  	}

Ditto.

> @@ -2235,7 +2240,8 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
>  err_hif_stop:
>  	ath10k_hif_stop(ar);
>  err_htt_rx_detach:
> -	ath10k_htt_rx_free(&ar->htt);
> +	if (!ar->is_high_latency)
> +		ath10k_htt_rx_free(&ar->htt);
>  err_htt_tx_detach:
>  	ath10k_htt_tx_free(&ar->htt);
>  err_wmi_detach:

Ditto.

> @@ -2280,7 +2286,8 @@ void ath10k_core_stop(struct ath10k *ar)
>  
>  	ath10k_hif_stop(ar);
>  	ath10k_htt_tx_stop(&ar->htt);
> -	ath10k_htt_rx_free(&ar->htt);
> +	if (!ar->is_high_latency)
> +		ath10k_htt_rx_free(&ar->htt);
>  	ath10k_wmi_detach(ar);
>  	ar->is_started = false;
>  }

Ditto.

> +	/* Not entirely sure about this, but all frames from the chipset has
> +	 * the protected flag set even though they have already been decrypted.
> +	 * Unmasking this flag is necessary in order for mac80211 not to drop
> +	 * the frame.
> +	 * TODO: Verify this is always the case or find out a way to check
> +	 * if there has been hw decryption.
> +	 */
> +	if (ieee80211_has_protected(hdr->frame_control)) {
> +		hdr->frame_control &= ~__cpu_to_le16(IEEE80211_FCTL_PROTECTED);
> +		rx_status->flag |= RX_FLAG_DECRYPTED |
> +				   RX_FLAG_IV_STRIPPED |
> +				   RX_FLAG_MMIC_STRIPPED;
> +	}
> +
> +	local_bh_disable();
> +	ieee80211_rx(ar->hw, skb);
> +	local_bh_enable();

ieee80211_rx_ni()?

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC v3 06/11] ath10k: htt: High latency RX support
Date: Fri, 22 Dec 2017 15:32:09 +0000	[thread overview]
Message-ID: <87k1xeaidi.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20170917194013.8658-7-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Sun, 17 Sep 2017 21:40:08 +0200")

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> Special HTT RX handling for high latency interfaces.
>
> Since no DMA physical addresses are used in the RX ring
> config message (this is not supported by the high latency
> devices), no RX ring is allocated.
> All RX skb's are allocated by the driver and passed directly
> to mac80211 in the HTT RX indication handler.
>
> A nice side effect of this is that no huge buffer will be
> allocated with dma_alloc_coherent. On embedded systems with
> limited memory resources, the allocation of the RX ring is
> prone to fail.
>
> Some tweaks made to "make it work":
>
> Removal of protected bit in 802.11 header frame control field.
> The chipset seems to do hw decryption but the frame_control
> protected bit is still set.
>
> This is necessary for mac80211 not to drop the frame.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.c    |  27 ++++---
>  drivers/net/wireless/ath/ath10k/htt.h     |  47 ++++++++++++
>  drivers/net/wireless/ath/ath10k/htt_rx.c  | 119 ++++++++++++++++++++++++=
+++++-
>  drivers/net/wireless/ath/ath10k/rx_desc.h |  15 ++++
>  4 files changed, 195 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireles=
s/ath/ath10k/core.c
> index c21227a74996..1880570989ae 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -2083,10 +2083,12 @@ int ath10k_core_start(struct ath10k *ar, enum ath=
10k_firmware_mode mode,
>  	ar->htt.rx_ring.in_ord_rx =3D !!(test_bit(WMI_SERVICE_RX_FULL_REORDER,
>  						ar->wmi.svc_map));
> =20
> -	status =3D ath10k_htt_rx_alloc(&ar->htt);
> -	if (status) {
> -		ath10k_err(ar, "failed to alloc htt rx: %d\n", status);
> -		goto err_htt_tx_detach;
> +	if (!ar->is_high_latency) {
> +		status =3D ath10k_htt_rx_alloc(&ar->htt);
> +		if (status) {
> +			ath10k_err(ar, "failed to alloc htt rx: %d\n", status);
> +			goto err_htt_tx_detach;
> +		}
>  	}

Wouldn't it be cleaner code to have the is_high_latency check within
ath10k_htt_rx_alloc() call?

> @@ -2203,10 +2205,13 @@ int ath10k_core_start(struct ath10k *ar, enum ath=
10k_firmware_mode mode,
>  		}
>  	}
> =20
> -	status =3D ath10k_htt_rx_ring_refill(ar);
> -	if (status) {
> -		ath10k_err(ar, "failed to refill htt rx ring: %d\n", status);
> -		goto err_hif_stop;
> +	if (!ar->is_high_latency) {
> +		status =3D ath10k_htt_rx_ring_refill(ar);
> +		if (status) {
> +			ath10k_err(ar, "failed to refill htt rx ring: %d\n",
> +				   status);
> +			goto err_hif_stop;
> +		}
>  	}

Ditto.

> @@ -2235,7 +2240,8 @@ int ath10k_core_start(struct ath10k *ar, enum ath10=
k_firmware_mode mode,
>  err_hif_stop:
>  	ath10k_hif_stop(ar);
>  err_htt_rx_detach:
> -	ath10k_htt_rx_free(&ar->htt);
> +	if (!ar->is_high_latency)
> +		ath10k_htt_rx_free(&ar->htt);
>  err_htt_tx_detach:
>  	ath10k_htt_tx_free(&ar->htt);
>  err_wmi_detach:

Ditto.

> @@ -2280,7 +2286,8 @@ void ath10k_core_stop(struct ath10k *ar)
> =20
>  	ath10k_hif_stop(ar);
>  	ath10k_htt_tx_stop(&ar->htt);
> -	ath10k_htt_rx_free(&ar->htt);
> +	if (!ar->is_high_latency)
> +		ath10k_htt_rx_free(&ar->htt);
>  	ath10k_wmi_detach(ar);
>  	ar->is_started =3D false;
>  }

Ditto.

> +	/* Not entirely sure about this, but all frames from the chipset has
> +	 * the protected flag set even though they have already been decrypted.
> +	 * Unmasking this flag is necessary in order for mac80211 not to drop
> +	 * the frame.
> +	 * TODO: Verify this is always the case or find out a way to check
> +	 * if there has been hw decryption.
> +	 */
> +	if (ieee80211_has_protected(hdr->frame_control)) {
> +		hdr->frame_control &=3D ~__cpu_to_le16(IEEE80211_FCTL_PROTECTED);
> +		rx_status->flag |=3D RX_FLAG_DECRYPTED |
> +				   RX_FLAG_IV_STRIPPED |
> +				   RX_FLAG_MMIC_STRIPPED;
> +	}
> +
> +	local_bh_disable();
> +	ieee80211_rx(ar->hw, skb);
> +	local_bh_enable();

ieee80211_rx_ni()?

--=20
Kalle Valo=

  reply	other threads:[~2017-12-22 15:32 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-17 19:40 [RFC v3 00/11] ath10k high latency Erik Stromdahl
2017-09-17 19:40 ` Erik Stromdahl
2017-09-17 19:40 ` [RFC v3 01/11] ath10k: high_latency detection Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:06   ` Kalle Valo
2017-12-22 15:06     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 02/11] ath10k: htt: RX ring config HL support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-09-17 19:40 ` [RFC v3 03/11] ath10k: per target configurablity of various items Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:19   ` Kalle Valo
2017-12-22 15:19     ` Kalle Valo
2017-12-28 12:43     ` Erik Stromdahl
2017-12-28 12:43       ` Erik Stromdahl
2018-01-08 13:41       ` Kalle Valo
2018-01-08 13:41         ` Kalle Valo
2018-01-08 14:03         ` Govind Singh
2018-01-08 14:03           ` Govind Singh
2017-09-17 19:40 ` [RFC v3 04/11] ath10k: add start_once support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:25   ` Kalle Valo
2017-12-22 15:25     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 05/11] ath10k: htt: High latency TX support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:26   ` Kalle Valo
2017-12-22 15:26     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 06/11] ath10k: htt: High latency RX support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:32   ` Kalle Valo [this message]
2017-12-22 15:32     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 07/11] ath10k: various fixes for high latency devices Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:43   ` Kalle Valo
2017-12-22 15:43     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 08/11] ath10k: add QCA9377 usb hw_param item Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:46   ` Kalle Valo
2017-12-22 15:46     ` Kalle Valo
2017-12-22 15:49   ` Kalle Valo
2017-12-22 15:49     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 09/11] ath10k: add QCA9377 sdio " Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:47   ` Kalle Valo
2017-12-22 15:47     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 10/11] ath10k: wmi: disable softirq's while calling ieee80211_rx Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:47   ` Kalle Valo
2017-12-22 15:47     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 11/11] ath10k: remove htt pending TX count for high latency Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:55 ` [RFC v3 00/11] ath10k " Kalle Valo
2017-12-22 15:55   ` 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=87k1xeaidi.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=ath10k@lists.infradead.org \
    --cc=erik.stromdahl@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /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.