[RFC v2 06/10] ath10k: htt: High latency RX support

[Peter Oh]

On 06/12/2017 08:03 AM, Erik Stromdahl wrote:
> 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 at gmail.com>
> ---
>
> +static void ath10k_htt_rx_proc_rx_ind_ll(struct ath10k_htt *htt,
> +					 struct htt_rx_indication *rx)
>   {
>   	struct ath10k *ar = htt->ar;
>   	struct htt_rx_indication_mpdu_range *mpdu_ranges;
> @@ -2356,7 +2442,12 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
>   		break;
>   	}
>   	case HTT_T2H_MSG_TYPE_RX_IND:
> -		ath10k_htt_rx_proc_rx_ind(htt, &resp->rx_ind);
> +		if (ar->is_high_latency)
Can we use function pointers at initial time to avoid condition check at 
hot path?
I'm afraid adding more lines on hot path.
> +			return ath10k_htt_rx_proc_rx_ind_hl(htt,
> +							    &resp->rx_ind_hl,
> +							    skb);
> +		else
> +			ath10k_htt_rx_proc_rx_ind_ll(htt, &resp->rx_ind);
>   		break;
>   	case HTT_T2H_MSG_TYPE_PEER_MAP: {
>   		struct htt_peer_map_event ev = {
>