summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/acpica/evxfregn.c
diff options
context:
space:
mode:
authorInaky Perez-Gonzalez <inaky@linux.intel.com>2009-05-08 14:02:32 -0700
committerInaky Perez-Gonzalez <inaky@linux.intel.com>2009-05-14 18:00:32 -0700
commit4e5b6d006b61b6b998e15da850d959520f811b4c (patch)
tree7c169744bfc0474ed76ff79c4136493057e1a39b /drivers/acpi/acpica/evxfregn.c
parente1cc1c578055d20d36e084e324001fb5e0355a71 (diff)
downloadblackbird-op-linux-4e5b6d006b61b6b998e15da850d959520f811b4c.tar.gz
blackbird-op-linux-4e5b6d006b61b6b998e15da850d959520f811b4c.zip
wimax/i2400m: fix device crash: fix optimization in _roq_queue_update_ws
When the i2400m receives data and the device indicates there has to be reordering, we keep an sliding window implementation to sort the packets before sending them to the network stack. One of the "operations" that the device indicates is "queue a packet and update the window start". When the queue is empty, this is equivalent to "deliver the packet and update the window start". That case was optimized in i2400m_roq_queue_update_ws() so that we would not pointlessly queue and dequeue a packet. However, when the optimization was active, it wasn't updating the window start. That caused the reorder management code to get confused later on with what seemed to be wrong reorder requests from the device. Thus the fix implemented is to do the right thing and update the window start in both cases, when the queue is empty (and the optimization is done) and when not. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Diffstat (limited to 'drivers/acpi/acpica/evxfregn.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud