- 04 5月, 2019 24 次提交
-
-
由 Harini Katakam 提交于
[ Upstream commit cd5afa91f078c0787be0a62b5ef90301c00b0271 ] Both PCLK and HCLK are "required" clocks according to macb devicetree documentation. There is a chance that devm_clk_get doesn't return a negative error but just a NULL clock structure instead. In such a case the driver proceeds as usual and uses pclk value 0 to calculate MDC divisor which is incorrect. Hence fix the same in clock initialization. Signed-off-by: NHarini Katakam <harini.katakam@xilinx.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Aditya Pakki 提交于
[ Upstream commit 6a8ca24590a2136921439b376c926c11a6effc0e ] phydm.internal is allocated using kzalloc which is used multiple times without a check for NULL pointer. This patch avoids such a scenario by returning 0, consistent with the failure case. Signed-off-by: NAditya Pakki <pakki001@umn.edu> Reviewed-by: NMukesh Ojha <mojha@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Dan Carpenter 提交于
[ Upstream commit 22c971db7dd4b0ad8dd88e99c407f7a1f4231a2e ] Colin King reported a bug in read_bbreg_hdl(): memcpy(pcmd->rsp, (u8 *)&val, pcmd->rspsz); The problem is that "val" is uninitialized. This code is obviously not useful, but so far as I can tell "pcmd->cmdcode" is never GEN_CMD_CODE(_Read_BBREG) so it's not harmful either. For now the easiest fix is to just call r8712_free_cmd_obj() and return. Fixes: 2865d42c ("staging: r8712u: Add the new driver to the mainline kernel") Reported-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Aditya Pakki 提交于
[ Upstream commit d70d70aec9632679dd00dcc1b1e8b2517e2c7da0 ] skb allocated via dev_alloc_skb can fail and return a NULL pointer. This patch avoids such a scenario and returns, consistent with other invocations. Signed-off-by: NAditya Pakki <pakki001@umn.edu> Reviewed-by: NMukesh Ojha <mojha@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Aditya Pakki 提交于
[ Upstream commit 7671ce0d92933762f469266daf43bd34d422d58c ] hwxmits is allocated via kcalloc and not checked for failure before its dereference. The patch fixes this problem by returning error upstream in rtl8723bs, rtl8188eu. Signed-off-by: NAditya Pakki <pakki001@umn.edu> Acked-by: NMukesh Ojha <mojha@codeaurora.org> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Lukas Wunner 提交于
[ Upstream commit 9624bafa5f6418b9ca5b3f66d1f6a6a2e8bf6d4c ] The ks8851 chip's initial carrier state is down. A Link Change Interrupt is signaled once interrupts are enabled if the carrier is up. The ks8851 driver has it backwards by assuming that the initial carrier state is up. The state is therefore misrepresented if the interface is opened with no cable attached. Fix it. The Link Change interrupt is sometimes not signaled unless the P1MBSR register (which contains the Link Status bit) is read on ->ndo_open(). This might be a hardware erratum. Read the register by calling mii_check_link(), which has the desirable side effect of setting the carrier state to down if the cable was detached while the interface was closed. Signed-off-by: NLukas Wunner <lukas@wunner.de> Cc: Frank Pavlic <f.pavlic@kunbus.de> Cc: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Tristram Ha <Tristram.Ha@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Lukas Wunner 提交于
[ Upstream commit d268f31552794abf5b6aa5af31021643411f25f5 ] The ks8851 driver currently requests the IRQ before registering the net_device. Because the net_device name is used as IRQ name and is still "eth%d" when the IRQ is requested, it's impossibe to tell IRQs apart if multiple ks8851 chips are present. Most other drivers delay requesting the IRQ until the net_device is opened. Do the same. The driver doesn't enable interrupts on the chip before opening the net_device and disables them when closing it, so there doesn't seem to be a need to request the IRQ already on probe. Signed-off-by: NLukas Wunner <lukas@wunner.de> Cc: Frank Pavlic <f.pavlic@kunbus.de> Cc: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Tristram Ha <Tristram.Ha@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Lukas Wunner 提交于
[ Upstream commit 761cfa979a0c177d6c2d93ef5585cd79ae49a7d5 ] Commit 73fdeb82 ("net: ks8851: Add optional vdd_io regulator and reset gpio") amended the ks8851 driver to briefly assert the chip's reset pin on probe. It also amended the probe routine's error path to reassert the reset pin if a subsequent initialization step fails. However the commit misplaced reassertion of the reset pin in the error path such that it is not performed if the check of the Chip ID and Enable Register (CIDER) fails. The error path is therefore slightly asymmetrical to the probe routine's body. Fix it. Signed-off-by: NLukas Wunner <lukas@wunner.de> Cc: Frank Pavlic <f.pavlic@kunbus.de> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Nishanth Menon <nm@ti.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Lukas Wunner 提交于
[ Upstream commit 536d3680fd2dab5c39857d62a3e084198fc74ff9 ] The ks8851 driver lets the chip auto-dequeue received packets once they have been read in full. It achieves that by setting the ADRFE flag in the RXQCR register ("Auto-Dequeue RXQ Frame Enable"). However if allocation of a packet's socket buffer or retrieval of the packet over the SPI bus fails, the packet will not have been read in full and is not auto-dequeued. Such partial retrieval of a packet confuses the chip's RX queue management: On the next RX interrupt, the first packet read from the queue will be the one left there previously and this one can be retrieved without issues. But for any newly received packets, the frame header status and byte count registers (RXFHSR and RXFHBCR) contain bogus values, preventing their retrieval. The chip allows explicitly dequeueing a packet from the RX queue by setting the RRXEF flag in the RXQCR register ("Release RX Error Frame"). This could be used to dequeue the packet in case of an error, but if that error is a failed SPI transfer, it is unknown if the packet was transferred in full and was auto-dequeued or if it was only transferred in part and requires an explicit dequeue. The safest approach is thus to always dequeue packets explicitly and forgo auto-dequeueing. Without this change, I've witnessed packet retrieval break completely when an SPI DMA transfer fails, requiring a chip reset. Explicit dequeueing magically fixes this and makes packet retrieval absolutely robust for me. The chip's documentation suggests auto-dequeuing and uses the RRXEF flag only to dequeue error frames which the driver doesn't want to retrieve. But that seems to be a fair-weather approach. Signed-off-by: NLukas Wunner <lukas@wunner.de> Cc: Frank Pavlic <f.pavlic@kunbus.de> Cc: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Tristram Ha <Tristram.Ha@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Jarkko Nikula 提交于
[ Upstream commit 5cd1c56c42beb6d228cc8d4373fdc5f5ec78a5ad ] Add PCI ID for Intel Comet Lake PCH. Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Guido Kiener 提交于
[ Upstream commit 091dacc3cc10979ab0422f0a9f7fcc27eee97e69 ] Restore the status of ep->stopped in function net2272_dequeue(). When the given request is not found in the endpoint queue the function returns -EINVAL without restoring the state of ep->stopped. Thus the endpoint keeps blocked and does not transfer any data anymore. This fix is only compile-tested, since we do not have a corresponding hardware. An analogous fix was tested in the sibling driver. See "usb: gadget: net2280: Fix net2280_dequeue()" Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Guido Kiener 提交于
[ Upstream commit f1d3fba17cd4eeea20397f1324b7b9c69a6a935c ] When a request must be dequeued with net2280_dequeue() e.g. due to a device clear action and the same request is finished by the function scan_dma_completions() then the function net2280_dequeue() does not find the request in the following search loop and returns the error -EINVAL without restoring the status ep->stopped. Thus the endpoint keeps blocked and does not receive any data anymore. This fix restores the status and does not issue an error message. Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Guido Kiener 提交于
[ Upstream commit 9d6a54c1430647355a5e23434881b2ca3d192b48 ] The OUT endpoint normally blocks (NAK) subsequent packets when a short packet was received and returns an incomplete queue entry to the gadget driver. Thereby the gadget driver can detect a short packet when reading queue entries with a length that is not equal to a multiple of packet size. The start_queue() function enables receiving OUT packets regardless of the content of the OUT FIFO. This results in a race: With the current code, it's possible that the "!ep->is_in && (readl(&ep->regs->ep_stat) & BIT(NAK_OUT_PACKETS))" test in start_dma() will fail, then a short packet will be received, and then start_queue() will call stop_out_naking(). That's what we don't want (OUT naking gets turned off while there is data in the FIFO) because then the next driver request might receive a mixture of old and new packets. With the patch, this race can't occur because the FIFO's state is tested after we know that OUT naking is already turned on, and OUT naking is stopped only when both of the conditions are met. This ensures that all received data is delivered to the gadget driver, which can detect a short packet now before new packets are appended to the last short packet. Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Felipe Balbi 提交于
[ Upstream commit 7ae622c978db6b2e28b4fced6ecd2a174492059d ] This patch simply adds a new PCI Device ID Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Petr Štetiar 提交于
[ Upstream commit 72ff51d8dd262d1fef25baedc2ac35116435be47 ] Andrey has reported on OpenWrt's bug tracking system[1], that he currently can't use ar93xx_uart as pure serial UART without console (CONFIG_SERIAL_8250_CONSOLE and CONFIG_SERIAL_AR933X_CONSOLE undefined), because compilation ends with following error: ar933x_uart.c: In function 'ar933x_uart_console_write': ar933x_uart.c:550:14: error: 'struct uart_port' has no member named 'sysrq' So this patch moves all the code related to console handling behind series of CONFIG_SERIAL_AR933X_CONSOLE ifdefs. 1. https://bugs.openwrt.org/index.php?do=details&task_id=2152 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Andrey Batyiev <batyiev@gmail.com> Reported-by: NAndrey Batyiev <batyiev@gmail.com> Tested-by: NAndrey Batyiev <batyiev@gmail.com> Signed-off-by: NPetr Štetiar <ynezz@true.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Mao Wenan 提交于
[ Upstream commit ac0cdb3d990108df795b676cd0d0e65ac34b2273 ] Add the missing uart_unregister_driver() and i2c_del_driver() before return from sc16is7xx_init() in the error handling case. Signed-off-by: NMao Wenan <maowenan@huawei.com> Reviewed-by: NVladimir Zapolskiy <vz@mleia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Julian Wiedmann 提交于
[ Upstream commit 7221b727f0079a32aca91f657141e1de564d4b97 ] The ucast IP table is utilized by some of the L3-specific sysfs attributes that qeth_l3_create_device_attributes() provides. So initialize the table _before_ registering the attributes. Fixes: ebccc739 ("s390/qeth: add missing hash table initializations") Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Maxim Zhukov 提交于
[ Upstream commit 90cd9bed5adb3e3bd4d3ac4cbcecbc4a8028bbaf ] Add depends on PCI for PCI_MT7621 Signed-off-by: NMaxim Zhukov <mussitantesmortem@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Arnd Bergmann 提交于
[ Upstream commit 1beea6204e2304dd11600791d8dad8e7350af6ad ] When building without CONFIG_OF, the compiler loses track of the flow control in axis_fifo_probe(), and thinks that many variables are used without an initialization even though we actually leave the function before the first use: drivers/staging/axis-fifo/axis-fifo.c: In function 'axis_fifo_probe': drivers/staging/axis-fifo/axis-fifo.c:900:5: error: 'rxd_tdata_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (rxd_tdata_width != 32) { ^ drivers/staging/axis-fifo/axis-fifo.c:907:5: error: 'txd_tdata_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (txd_tdata_width != 32) { ^ drivers/staging/axis-fifo/axis-fifo.c:914:5: error: 'has_tdest' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (has_tdest) { ^ drivers/staging/axis-fifo/axis-fifo.c:919:5: error: 'has_tid' may be used uninitialized in this function [-Werror=maybe-uninitialized] When CONFIG_OF is set, this does not happen, and since the driver cannot work without it, just add that option as a Kconfig dependency. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Aditya Pakki 提交于
[ Upstream commit 5bf7295fe34a5251b1d241b9736af4697b590670 ] netdev_alloc_skb can fail and return a NULL pointer which is dereferenced without a check. The patch avoids such a scenario. Signed-off-by: NAditya Pakki <pakki001@umn.edu> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Aaro Koskinen 提交于
[ Upstream commit 80acbed9f8fca1db3fbe915540b756f048aa0fd7 ] Commit 0e80bdc9 ("stmmac: first frame prep at the end of xmit routine") overlooked jumbo frames when re-ordering the code, and as a result the own bit was not getting set anymore for the first jumbo frame descriptor. Commit 487e2e22ab79 ("net: stmmac: Set OWN bit for jumbo frames") tried to fix this, but now the bit is getting set too early and the DMA may start while we are still setting up the remaining descriptors. And with the chain mode the own bit remains still unset. Fix by setting the own bit at the end of xmit also with jumbo frames. Fixes: 0e80bdc9 ("stmmac: first frame prep at the end of xmit routine") Fixes: 487e2e22ab79 ("net: stmmac: Set OWN bit for jumbo frames") Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com> Acked-by: NJose Abreu <joabreu@synopsys.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Li RongQing 提交于
[ Upstream commit 19b39a25388e71390e059906c979f87be4ef0c71 ] genlmsg_reply can fail, so propagate its return code Signed-off-by: NLi RongQing <lirongqing@baidu.com> Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Kangjie Lu 提交于
[ Upstream commit 2795e8c251614ac0784c9d41008551109f665716 ] In case alloc_ordered_workqueue fails, the fix releases sources and returns -ENOMEM to avoid NULL pointer dereference. Signed-off-by: NKangjie Lu <kjlu@umn.edu> Acked-by: NMichael Hennerich <michael.hennerich@analog.com> Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
-
由 Rafael J. Wysocki 提交于
commit 2c2a2fb1e2a9256714338875bede6b7cbd4b9542 upstream. Revert commit c8b1917c8987 ("ACPICA: Clear status of GPEs before enabling them") that causes problems with Thunderbolt controllers to occur if a dock device is connected at init time (the xhci_hcd and thunderbolt modules crash which prevents peripherals connected through them from working). Commit c8b1917c8987 effectively causes commit ecc1165b ("ACPICA: Dispatch active GPEs at init time") to get undone, so the problem addressed by commit ecc1165b appears again as a result of it. Fixes: c8b1917c8987 ("ACPICA: Clear status of GPEs before enabling them") Link: https://lore.kernel.org/lkml/s5hy33siofw.wl-tiwai@suse.de/T/#u Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1132943Reported-by: NMichael Hirmke <opensuse@mike.franken.de> Reported-by: NTakashi Iwai <tiwai@suse.de> Cc: 4.17+ <stable@vger.kernel.org> # 4.17+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 5月, 2019 16 次提交
-
-
由 Maxim Mikityanskiy 提交于
[ Upstream commit 12fc512f5741443a03adde2ead20724da8ad550a ] xdp_return_frame releases the frame. It leads to releasing the page, so it's not allowed to access xdpi.xdpf->len after that, because xdpi.xdpf is at xdp->data_hard_start after convert_to_xdp_frame. This patch moves the memory access to precede the return of the frame. Fixes: 58b99ee3 ("net/mlx5e: Add support for XDP_REDIRECT in device-out side") Signed-off-by: NMaxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Maxim Mikityanskiy 提交于
[ Upstream commit d460c2718906252a2a69bc6f89b537071f792e6e ] MLX5E_XDP_MAX_MTU was calculated incorrectly. It didn't account for NET_IP_ALIGN and MLX5E_HW2SW_MTU, and it also misused MLX5_SKB_FRAG_SZ. This commit fixes the calculations and adds a brief explanation for the formula used. Fixes: a26a5bdf ("net/mlx5e: Restrict the combination of large MTU and XDP") Signed-off-by: NMaxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Petr Machata 提交于
[ Upstream commit f476b3f809fa02f47af6333ed63715058c3fc348 ] Both Spectrum-1 and Spectrum-2 chips are currently configured such that pairs of TC n (which is used for UC traffic) and TC n+8 (which is used for MC traffic) are feeding into the same subgroup. Strict prioritization is configured between the two TCs, and by enabling MC-aware mode on the switch, the lower-numbered (UC) TCs are favored over the higher-numbered (MC) TCs. On Spectrum-2 however, there is an issue in configuration of the MC-aware mode. As a result, MC traffic is prioritized over UC traffic. To work around the issue, configure the MC TCs with DWRR mode (while keeping the UC TCs in strict mode). With this patch, the multicast-unicast arbitration results in the same behavior on both Spectrum-1 and Spectrum-2 chips. Fixes: 7b819530 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports") Signed-off-by: NPetr Machata <petrm@mellanox.com> Signed-off-by: NIdo Schimmel <idosch@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Ido Schimmel 提交于
[ Upstream commit 1ab3030193d25878b3b1409060e1e0a879800c95 ] During driver initialization the driver sends a reset to the device and waits for the firmware to signal that it is ready to continue. Commit d2f372ba0914 ("mlxsw: pci: Increase PCI SW reset timeout") increased the timeout to 13 seconds due to longer PHY calibration in Spectrum-2 compared to Spectrum-1. Recently it became apparent that this timeout is too short and therefore this patch increases it again to a safer limit that will be reduced in the future. Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC") Fixes: d2f372ba0914 ("mlxsw: pci: Increase PCI SW reset timeout") Signed-off-by: NIdo Schimmel <idosch@mellanox.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jun Xiao 提交于
Commit dfdf26babc98 upstream this patch need merge to 4.19.y stable kernel Fix Conflict:already fixed the confilct dfdf26babc98 with Yonglong Liu stable candidate:user cannot connect to the internet via hns dev by default setting without this patch we have already verified this patch on kunpeng916 platform, and it works well. Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Signed-off-by: NJun Xiao <xiaojun2@hisilicon.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hangbin Liu 提交于
[ Upstream commit 925b0c841e066b488cc3a60272472b2c56300704 ] If we add a bond device which is already the master of the team interface, we will hold the team->lock in team_add_slave() first and then request the lock in team_set_mac_address() again. The functions are called like: - team_add_slave() - team_port_add() - team_port_enter() - team_modeop_port_enter() - __set_port_dev_addr() - dev_set_mac_address() - bond_set_mac_address() - dev_set_mac_address() - team_set_mac_address Although team_upper_dev_link() would check the upper devices but it is called too late. Fix it by adding a checking before processing the slave. v2: Do not split the string in netdev_err() Fixes: 3d249d4c ("net: introduce ethernet teaming device") Acked-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NHangbin Liu <liuhangbin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Su Bao Cheng 提交于
[ Upstream commit e0c1d14a1a3211dccf0540a6703ffbd5d2a75bdb ] Since there are more IOT2040 variants with identical hardware but different asset tags, the asset tag matching should be adjusted to support them. For the board name "SIMATIC IOT2000", currently there are 2 types of hardware, IOT2020 and IOT2040. The IOT2020 is identified by its unique asset tag. Match on it first. If we then match on the board name only, we will catch all IOT2040 variants. In the future there will be no other devices with the "SIMATIC IOT2000" DMI board name but different hardware. Signed-off-by: NSu Bao Cheng <baocheng.su@siemens.com> Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Vinod Koul 提交于
[ Upstream commit b561af36b1841088552464cdc3f6371d92f17710 ] stmmac_check_ether_addr() checks the MAC address and assigns one in driver open(). In many cases when we create slave netdevice, the dev addr is inherited from master but the master dev addr maybe NULL at that time, so move this call to driver probe so that address is always valid. Signed-off-by: NXiaofei Shen <xiaofeis@codeaurora.org> Tested-by: NXiaofei Shen <xiaofeis@codeaurora.org> Signed-off-by: NSneh Shah <snehshah@codeaurora.org> Signed-off-by: NVinod Koul <vkoul@kernel.org> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Erez Alfasi 提交于
[ Upstream commit ace329f4ab3ba434be2adf618073c752d083b524 ] Querying EEPROM high pages data for SFP module is currently not supported by our driver and yet queried, resulting in invalid FW queries. Set the EEPROM ethtool data length to 256 for SFP module will limit the reading for page 0 only and prevent invalid FW queries. Fixes: bb64143e ("net/mlx5e: Add ethtool support for dump module EEPROM") Signed-off-by: NErez Alfasi <ereza@mellanox.com> Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Amit Cohen 提交于
[ Upstream commit 151f0dddbbfe4c35c9c5b64873115aafd436af9d ] If link is down and autoneg is set to on/off, the status in ethtool does not change. The reason is when the link is down the function returns with zero before changing autoneg value. Move the checking of link state (up/down) to be performed after setting autoneg value, in order to be sure that autoneg will change in any case. Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: NAmit Cohen <amitc@mellanox.com> Signed-off-by: NIdo Schimmel <idosch@mellanox.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Yue Haibing 提交于
commit 01ca667133d019edc9f0a1f70a272447c84ec41f upstream. Syzkaller report this: kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 4378 Comm: syz-executor.0 Tainted: G C 5.0.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:__lock_acquire+0x95b/0x3200 kernel/locking/lockdep.c:3573 Code: 00 0f 85 28 1e 00 00 48 81 c4 08 01 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 24 00 00 49 81 7d 00 e0 de 03 a6 41 bc 00 00 RSP: 0018:ffff8881e3c07a40 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000080 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8881e3c07d98 R11: ffff8881c7f21f80 R12: 0000000000000001 R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001 FS: 00007fce2252e700(0000) GS:ffff8881f2400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fffc7eb0228 CR3: 00000001e5bea002 CR4: 00000000007606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: lock_acquire+0xff/0x2c0 kernel/locking/lockdep.c:4211 __mutex_lock_common kernel/locking/mutex.c:925 [inline] __mutex_lock+0xdf/0x1050 kernel/locking/mutex.c:1072 drain_workqueue+0x24/0x3f0 kernel/workqueue.c:2934 destroy_workqueue+0x23/0x630 kernel/workqueue.c:4319 __do_sys_delete_module kernel/module.c:1018 [inline] __se_sys_delete_module kernel/module.c:961 [inline] __x64_sys_delete_module+0x30c/0x480 kernel/module.c:961 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fce2252dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fce2252e6bc R13: 00000000004bcca9 R14: 00000000006f6b48 R15: 00000000ffffffff If alloc_workqueue fails, it should return -ENOMEM, otherwise may trigger this NULL pointer dereference while unloading drivers. Reported-by: NHulk Robot <hulkci@huawei.com> Fixes: 0a38c17a ("fm10k: Remove create_workqueue") Signed-off-by: NYue Haibing <yuehaibing@huawei.com> Tested-by: NAndrew Bowers <andrewx.bowers@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Todd Kjos 提交于
commit 26528be6720bb40bc8844e97ee73a37e530e9c5e upstream. Fixes crash found by syzbot: kernel BUG at drivers/android/binder_alloc.c:LINE! (2) Reported-and-tested-by: syzbot+55de1eb4975dec156d8f@syzkaller.appspotmail.com Signed-off-by: NTodd Kjos <tkjos@google.com> Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org> Cc: stable <stable@vger.kernel.org> # 5.0, 4.19, 4.14 Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shishkin 提交于
commit 91d3f8a629849968dc91d6ce54f2d46abf4feb7f upstream. Commit 9ed3f22223c3 ("intel_th: Don't reference unassigned outputs") fixes a NULL dereference for all masters except the last one ("256+"), which keeps the stale pointer after the output driver had been unassigned. Fix the off-by-one. Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Fixes: 9ed3f22223c3 ("intel_th: Don't reference unassigned outputs") Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Linus Torvalds 提交于
commit baf76f0c58aec435a3a864075b8f6d8ee5d1f17e upstream. This way, slhc_free() accepts what slhc_init() returns, whether that is an error or not. In particular, the pattern in sl_alloc_bufs() is slcomp = slhc_init(16, 16); ... slhc_free(slcomp); for the error handling path, and rather than complicate that code, just make it ok to always free what was returned by the init function. That's what the code used to do before commit 4ab42d78 ("ppp, slip: Validate VJ compression slot parameters completely") when slhc_init() just returned NULL for the error case, with no actual indication of the details of the error. Reported-by: syzbot+45474c076a4927533d2e@syzkaller.appspotmail.com Fixes: 4ab42d78 ("ppp, slip: Validate VJ compression slot parameters completely") Acked-by: NBen Hutchings <ben@decadent.org.uk> Cc: David Miller <davem@davemloft.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Kai-Heng Feng 提交于
commit d7a6c0ce8d26412903c7981503bad9e1cc7c45d2 upstream. USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working after S3: [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110) After some experiments, I found that disabling LPM can workaround the issue. On some platforms, the USB power is cut during S3, so the driver uses reset-resume to resume the device. During port resume, LPM gets enabled twice, by usb_reset_and_verify_device() and usb_port_resume(). Consolidate all checks into new LPM helpers to make sure LPM only gets enabled once. Fixes: de68bab4 ("usb: Don't enable USB 2.0 Link PM by default.”) Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Kai-Heng Feng 提交于
commit 7529b2574a7aaf902f1f8159fbc2a7caa74be559 upstream. Use new helpers to make LPM enabling/disabling more clear. This is a preparation to subsequent patch. Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> # after much soaking Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-