Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 14 6月, 2016 12 次提交
  3. 10 6月, 2016 1 次提交
    • R
      brcmfmac: rework function picking free BSS index · d02fb8f1
      由 Rafał Miłecki 提交于 
      The old implementation was overcomplicated and slightly bugged in some
corner cases.

Consider following state of BSS-es (limited to 6 for simplification):
drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
drvr->iflist[1]:  (null)
drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }
drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, }
drvr->iflist[4]:  (null)
drvr->iflist[5]:  (null)
In such case the next AP interface should bsscfgidx 4 (we don't use 1 as
it's reserved for P2P).

With old code the loop iterations were following:
[ifidx = 0] [bsscfgidx = 2] [highest = 2]
[ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true
[ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1
[ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1
[ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true
[ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true
There were 2 obvious problems:
1) Having empty BSS at index 1 was resulting in available being always
   set to true, even if we would run out of BSS-es.
2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver
   not being able to create the 4th AP interface.

New code is simpler, placed in file where it's really used, handles
running out of free BSS-es and allows using 4 interfaces at the same
time. It also looks for the first free BSS instead of one after the last
in use. It works well with current driver (which doesn't allow deleting
interfaces) and should be future proof (if we ever allow deleting).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      d02fb8f1
  5. 04 6月, 2016 13 次提交
  7. 03 6月, 2016 3 次提交
    • Y
      qed: Utilize FW 8.10.3.0 · 351a4ded
      由 Yuval Mintz 提交于 
      The New QED firmware contains several fixes, including:
  - Wrong classification of packets in 4-port devices.
  - Anti-spoof interoperability with encapsulated packets.
  - Tx-switching of encapsulated packets.
It also slightly improves Tx performance of the device.

In addition, this firmware contains the necessary logic for
supporting iscsi & rdma, for which we plan on pushing protocol
drivers in the imminent future.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      351a4ded
    • D
      net: vrf: set operstate and mtu at link create · b87ab6b8
      由 David Ahern 提交于 
      The VRF device exists to define L3 domains and guide FIB lookups. As
such its operstate is not relevant. Seeing 'state UNKNOWN' in the
output of 'ip link show' can be confusing, so set operstate at link
create.

Similarly, the MTU for a VRF device is not used; any fragmentation
of the payload is done on the output path based on the real egress
device. An MTU of 1500 on the VRF device while enslaved devices
have a higher MTU can lead to confusion. Since the VRF MTU is not
relevant set to 64k similar to what is done for loopback.
Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b87ab6b8
    • B
      net: ethernet: wiznet: Remove create_workqueue · 41cae08c
      由 Bhaktipriya Shridhar 提交于 
      alloc_workqueue replaces deprecated create_workqueue().

A dedicated workqueue has been used since the workitems are involved
in normal device operation. Workitems &priv->rx_work and &priv->tx_work,
map to w5100_rx_work and w5100_tx_work respectively and are involved in
receiving and transmitting packets. Forward progress under
memory pressure is a requirement here.

create_workqueue has been replaced with alloc_workqueue with max_active
as 0 since there is no need for throttling the number of active work
items.

Since the driver may be used in memory reclaim path,
WQ_MEM_RECLAIM has been set to guarantee forward progress.

flush_workqueue is unnecessary since destroy_workqueue() itself calls
drain_workqueue() which flushes repeatedly till the workqueue
becomes empty. Hence the call to flush_workqueue() has been dropped.
Signed-off-by: NBhaktipriya Shridhar <bhaktipriya96@gmail.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41cae08c
  9. 02 6月, 2016 6 次提交
  11. 01 6月, 2016 5 次提交