BMC/Intel-BMC/linux.git/drivers, branch v4.17.12

ACPICA: AML Parser: ignore control method status in module-level code

2018-08-03T05:48:06+00:00

commit 460a53106ac39b74625d1104d9a113e0f3716c18 upstream. Previous change in the AML parser code blindly set all non-successful dispatcher statuses to AE_OK. That approach is incorrect, though, because successful control method invocations from module-level return AE_CTRL_TRANSFER. Overwriting AE_OK to this status causes the AML parser to think that there was no return value from the control method invocation. Fixes: 92c0f4af386 (ACPICA: AML Parser: ignore dispatcher error status during table load) Reported-by: Linus Torvalds Tested-by: Linus Torvalds Tested-by: Oleksandr Natalenko Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation

2018-08-03T05:48:06+00:00

commit 12864ff8545f6b8144fdf1bb89b5663357f29ec4 upstream. Commit a09c59130688 (ACPI / LPSS: Avoid PM quirks on suspend and resume from S3) modified the ACPI driver for Intel SoCs (LPSS) to avoid applying PM quirks on suspend and resume from S3 to address system-wide suspend and resume problems on some systems, but it is reported that the same issue also affects hibernation, so extend the approach used by that commit to cover hibernation as well. Fixes: a09c59130688 (ACPI / LPSS: Avoid PM quirks on suspend and resume from S3) Link: https://bugs.launchpad.net/bugs/1774950 Reported-by: Kai-Heng Feng Cc: 4.15+ # 4.15+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman

cxgb4: Added missing break in ndo_udp_tunnel_{add/del}

2018-08-03T05:48:05+00:00

[ Upstream commit 942a656f1f228f06a37adad0e6c347773cfe7bd6 ] Break statements were missing for Geneve case in ndo_udp_tunnel_{add/del}, thereby raw mac matchall entries were not getting added. Fixes: c746fc0e8b2d("cxgb4: add geneve offload support for T6") Signed-off-by: Arjun Vynipadath Signed-off-by: Ganesh Goudar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

xen-netfront: wait xenbus state change when load module manually

2018-08-03T05:48:05+00:00

[ Upstream commit 822fb18a82abaf4ee7058793d95d340f5dab7bfc ] When loading module manually, after call xenbus_switch_state to initializes the state of the netfront device, the driver state did not change so fast that may lead no dev created in latest kernel. This patch adds wait to make sure xenbus knows the driver is not in closed/unknown state. Current state: [vm]# ethtool eth0 Settings for eth0: Link detected: yes [vm]# modprobe -r xen_netfront [vm]# modprobe xen_netfront [vm]# ethtool eth0 Settings for eth0: Cannot get device settings: No such device Cannot get wake-on-lan settings: No such device Cannot get message level: No such device Cannot get link status: No such device No data available With the patch installed. [vm]# ethtool eth0 Settings for eth0: Link detected: yes [vm]# modprobe -r xen_netfront [vm]# modprobe xen_netfront [vm]# ethtool eth0 Settings for eth0: Link detected: yes Signed-off-by: Xiao Liang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

virtio_net: Fix incosistent received bytes counter

2018-08-03T05:48:05+00:00

[ Upstream commit ecbc42ca5d665e9238a4cdb595024d2e6cf87f2d ] When received packets are dropped in virtio_net driver, received packets counter is incremented but bytes counter is not. As a result, for instance if we drop all packets by XDP, only received is counted and bytes stays 0, which looks inconsistent. IMHO received packets/bytes should be counted if packets are produced by the hypervisor, like what common NICs on physical machines are doing. So fix the bytes counter. Signed-off-by: Toshiaki Makita Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

NET: stmmac: align DMA stuff to largest cache line length

2018-08-03T05:48:05+00:00

[ Upstream commit 9939a46d90c6c76f4533d534dbadfa7b39dc6acc ] As for today STMMAC_ALIGN macro (which is used to align DMA stuff) relies on L1 line length (L1_CACHE_BYTES). This isn't correct in case of system with several cache levels which might have L1 cache line length smaller than L2 line. This can lead to sharing one cache line between DMA buffer and other data, so we can lose this data while invalidate DMA buffer before DMA transaction. Fix that by using SMP_CACHE_BYTES instead of L1_CACHE_BYTES for aligning. Signed-off-by: Eugeniy Paltsev Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: mdio-mux: bcm-iproc: fix wrong getter and setter pair

2018-08-03T05:48:05+00:00

[ Upstream commit b0753408aadf32c7ece9e6b765017881e54af833 ] mdio_mux_iproc_probe() uses platform_set_drvdata() to store md pointer in device, whereas mdio_mux_iproc_remove() restores md pointer by dev_get_platdata(&pdev->dev). This leads to wrong resources release. The patch replaces getter to platform_get_drvdata. Fixes: 98bc865a1ec8 ("net: mdio-mux: Add MDIO mux driver for iProc SoCs") Signed-off-by: Anton Vasilyev Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: lan78xx: fix rx handling before first packet is send

2018-08-03T05:48:04+00:00

[ Upstream commit 136f55f660192ce04af091642efc75d85e017364 ] As long the bh tasklet isn't scheduled once, no packet from the rx path will be handled. Since the tx path also schedule the same tasklet this situation only persits until the first packet transmission. So fix this issue by scheduling the tasklet after link reset. Link: https://github.com/raspberrypi/linux/issues/2617 Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet") Suggested-by: Floris Bos Signed-off-by: Stefan Wahren Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: fix amd-xgbe flow-control issue

2018-08-03T05:48:04+00:00

[ Upstream commit 7f3fc7ddf719cd6faaf787722c511f6918ac6aab ] If we enable or disable xgbe flow-control by ethtool , it does't work.Because the parameter is not properly assigned,so we need to adjust the assignment order of the parameters. Fixes: c1ce2f77366b ("amd-xgbe: Fix flow control setting logic") Signed-off-by: tangpengpeng Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: ena: Fix use of uninitialized DMA address bits field

2018-08-03T05:48:04+00:00

[ Upstream commit 101f0cd4f2216d32f1b8a75a2154cf3997484ee2 ] UBSAN triggers the following undefined behaviour warnings: [...] [ 13.236124] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:468:22 [ 13.240043] shift exponent 64 is too large for 64-bit type 'long long unsigned int' [...] [ 13.744769] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:373:4 [ 13.748694] shift exponent 64 is too large for 64-bit type 'long long unsigned int' [...] When splitting the address to high and low, GENMASK_ULL is used to generate a bitmask with dma_addr_bits field from io_sq (in ena_com_prepare_tx and ena_com_add_single_rx_desc). The problem is that dma_addr_bits is not initialized with a proper value (besides being cleared in ena_com_create_io_queue). Assign dma_addr_bits the correct value that is stored in ena_dev when initializing the SQ. Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Gal Pressman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman