From: David S. Miller Date: Mon, 8 Aug 2016 22:38:27 +0000 (-0700) Subject: Merge branch 'be2net-next' X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=874e1b75f554eb4be6260c30a7b1335d23ed9512;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git Merge branch 'be2net-next' Sathya Perla says: ==================== be2net: patch set Patch 1 fixes the driver to workaournd a bug in the Lancer FW in the vlan-config cmd processing. The FW in some cases clears the vlan-promisc setting even if it cannot apply the vlan filter. The driver has no means of knowing if the vlan-promisc setting has been cleared or not. This patch now explicitly clears the vlan-promisc setting via the RX-Filter cmd and then tries to program the vlan-list. Patch 2 fixes the failure path in the vlan vid add code. The driver currently removes a new vid from the adapter->vids[] array if be_vid_config() returns an error, which occurs when there is an error in HW/FW. This is wrong. After the HW/FW error is recovered from, we need the complete vids[] array to re-program the vlan list. Patch 3 fixes the ndo_set_rx_mode() path to avoid unnecessary multicast list updates to the FW. Each time the ndo_set_rx_mode() routine is called, the driver programs the multicast list in the adapter without checking if there are any changes to the list. This leads to a flood of RX_FILTER cmds when a number of vlan interfaces are configured over the device, as the ndo_ gets called for each vlan interface. To avoid this, we now use __dev_mc_sync() and __dev_uc_sync() API, but only to detect if there is a change in the mc/uc lists. Now that we use this API, the code has to be-designed to issue these API calls for each invocation of the ndo_ call. Patch 4 replaces polling with sleeping in the FW completion path. The ndo_set_rx_mode() and ndo_add/del_vxlan_port() calls may be called with BHs disabled. The driver currently issues the required cmds to the FW in these contexts and polls on completions from the FW, while BHs remain disabled. This can cause either packet loss or packet reception to be delayed on that CPU. This patch defers processing of the above cmds to a separate workqueue. With this change, FW cmds are now issued only in process context. Now that the FW cmds are issued only in process context, they can sleep waiting for a completion instead of polling. ==================== Signed-off-by: David S. Miller --- 874e1b75f554eb4be6260c30a7b1335d23ed9512