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@xxxxxxxxxxxx>
