From: Brian Norris <briannorris@chromium.org>
To: Youghandhar Chintala <youghand@codeaurora.org>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, pillair@codeaurora.org,
dianders@chromium.org, kuabhs@chromium.org,
mpubbise@codeaurora.org
Subject: Re: [PATCH v5 0/2] mac80211: Trigger disconnect for STA during target hardware restart
Date: Tue, 8 Mar 2022 10:13:30 -0800 [thread overview]
Message-ID: <Yiecyl7Dd6AXJhN+@google.com> (raw)
In-Reply-To: <20220308115325.5246-1-youghand@codeaurora.org>
On Tue, Mar 08, 2022 at 05:23:23PM +0530, Youghandhar Chintala wrote:
> Currently in case of target hardware restart ,we just reconfig and
> re-enable the security keys and enable the network queues to start
> data traffic back from where it was interrupted.
>
> Many ath10k wifi chipsets have sequence numbers for the data
> packets assigned by firmware and the mac sequence number will
> restart from zero after target hardware restart leading to mismatch
> in the sequence number expected by the remote peer vs the sequence
> number of the frame sent by the target firmware.
>
> This mismatch in sequence number will cause out-of-order packets
> on the remote peer and all the frames sent by the device are dropped
> until we reach the sequence number which was sent before we restarted
> the target hardware
>
> In order to fix this, we trigger a disconnect in case of hardware
> restart. After this there will be a fresh connection and thereby
> avoiding the dropping of frames by remote peer.
>
> The right fix would be to pull the entire data path into the host
> which is not feasible or would need lots of complex/inefficient
> datapath changes.
>
> ---
> Changes from v3:
> - Fixed commit text errors
> - Remove excess space in "hardware restart"
> - Removed blank line between the function description and the arguments
For whatever it's worth, the series looks good to me:
Reviewed-by: Brian Norris <briannorris@chromium.org>
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: Youghandhar Chintala <youghand@codeaurora.org>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, pillair@codeaurora.org,
dianders@chromium.org, kuabhs@chromium.org,
mpubbise@codeaurora.org
Subject: Re: [PATCH v5 0/2] mac80211: Trigger disconnect for STA during target hardware restart
Date: Tue, 8 Mar 2022 10:13:30 -0800 [thread overview]
Message-ID: <Yiecyl7Dd6AXJhN+@google.com> (raw)
In-Reply-To: <20220308115325.5246-1-youghand@codeaurora.org>
On Tue, Mar 08, 2022 at 05:23:23PM +0530, Youghandhar Chintala wrote:
> Currently in case of target hardware restart ,we just reconfig and
> re-enable the security keys and enable the network queues to start
> data traffic back from where it was interrupted.
>
> Many ath10k wifi chipsets have sequence numbers for the data
> packets assigned by firmware and the mac sequence number will
> restart from zero after target hardware restart leading to mismatch
> in the sequence number expected by the remote peer vs the sequence
> number of the frame sent by the target firmware.
>
> This mismatch in sequence number will cause out-of-order packets
> on the remote peer and all the frames sent by the device are dropped
> until we reach the sequence number which was sent before we restarted
> the target hardware
>
> In order to fix this, we trigger a disconnect in case of hardware
> restart. After this there will be a fresh connection and thereby
> avoiding the dropping of frames by remote peer.
>
> The right fix would be to pull the entire data path into the host
> which is not feasible or would need lots of complex/inefficient
> datapath changes.
>
> ---
> Changes from v3:
> - Fixed commit text errors
> - Remove excess space in "hardware restart"
> - Removed blank line between the function description and the arguments
For whatever it's worth, the series looks good to me:
Reviewed-by: Brian Norris <briannorris@chromium.org>
next prev parent reply other threads:[~2022-03-08 18:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-08 11:53 [PATCH v5 0/2] mac80211: Trigger disconnect for STA during target hardware restart Youghandhar Chintala
2022-03-08 11:53 ` Youghandhar Chintala
2022-03-08 11:53 ` [PATCH v5 1/2] mac80211: Add support to trigger sta disconnect on " Youghandhar Chintala
2022-03-08 11:53 ` Youghandhar Chintala
2022-03-08 11:53 ` [PATCH v5 2/2] ath10k: Trigger " Youghandhar Chintala
2022-03-08 11:53 ` Youghandhar Chintala
2022-03-08 18:13 ` Brian Norris [this message]
2022-03-08 18:13 ` [PATCH v5 0/2] mac80211: Trigger disconnect for STA during target " Brian Norris
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=Yiecyl7Dd6AXJhN+@google.com \
--to=briannorris@chromium.org \
--cc=ath10k@lists.infradead.org \
--cc=dianders@chromium.org \
--cc=kuabhs@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mpubbise@codeaurora.org \
--cc=pillair@codeaurora.org \
--cc=youghand@codeaurora.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.