summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-11-24Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds3-24/+28
Pull last minute virtio bugfixes from Michael Tsirkin: "Minor bugfixes all over the place" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: virtio_balloon: fix shrinker count virtio_balloon: fix shrinker scan number of pages virtio_console: allocate inbufs in add_port() only if it is needed virtio_ring: fix return code on DMA mapping fails
2019-11-23Merge branch 'for-linus' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fix from Dmitry Torokhov: "Just a single revert as RMI mode should not have been enabled for this model [yet?]" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Revert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"
2019-11-23Revert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"Lyude Paul1-1/+0
This reverts commit 68b9c5066e39af41d3448abfc887c77ce22dd64d. Ugh, I really dropped the ball on this one :\. So as it turns out RMI4 works perfectly fine on the X1 Extreme Gen 2 except for one thing I didn't notice because I usually use the trackpoint: clicking with the touchpad. Somehow this is broken, in fact we don't even seem to indicate BTN_LEFT as a valid event type for the RMI4 touchpad. And, I don't even see any RMI4 events coming from the touchpad when I press down on it. This only seems to work for PS/2 mode. Since that means we have a regression, and PS/2 mode seems to work fine for the time being - revert this for now. We'll have to do a more thorough investigation on this. Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20191119234534.10725-1-lyude@redhat.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2019-11-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds34-143/+231
Pull networking fixes from David Miller: 1) Validate tunnel options length in act_tunnel_key, from Xin Long. 2) Fix DMA sync bug in gve driver, from Adi Suresh. 3) TSO kills performance on some r8169 chips due to HW issues, disable by default in that case, from Corinna Vinschen. 4) Fix clock disable mismatch in fec driver, from Chubong Yuan. 5) Fix interrupt status bits define in hns3 driver, from Huazhong Tan. 6) Fix workqueue deadlocks in qeth driver, from Julian Wiedmann. 7) Don't napi_disable() twice in r8152 driver, from Hayes Wang. 8) Fix SKB extension memory leak, from Florian Westphal. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits) r8152: avoid to call napi_disable twice MAINTAINERS: Add myself as maintainer of virtio-vsock udp: drop skb extensions before marking skb stateless net: rtnetlink: prevent underflows in do_setvfinfo() can: m_can_platform: remove unnecessary m_can_class_resume() call can: m_can_platform: set net_device structure as driver data hv_netvsc: Fix send_table offset in case of a host bug hv_netvsc: Fix offset usage in netvsc_send_table() net-ipv6: IPV6_TRANSPARENT - check NET_RAW prior to NET_ADMIN sfc: Only cancel the PPS workqueue if it exists nfc: port100: handle command failure cleanly net-sysfs: fix netdev_queue_add_kobject() breakage r8152: Re-order napi_disable in rtl8152_close net: qca_spi: Move reset_count to struct qcaspi net: qca_spi: fix receive buffer size check net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode Revert "net/ibmvnic: Fix EOI when running in XIVE mode" net/mlxfw: Verify FSM error code translation doesn't exceed array size net/mlx5: Update the list of the PCI supported devices net/mlx5: Fix auto group size calculation ...
2019-11-22r8152: avoid to call napi_disable twiceHayes Wang1-8/+20
Call napi_disable() twice would cause dead lock. There are three situations may result in the issue. 1. rtl8152_pre_reset() and set_carrier() are run at the same time. 2. Call rtl8152_set_tunable() after rtl8152_close(). 3. Call rtl8152_set_ringparam() after rtl8152_close(). For #1, use the same solution as commit 84811412464d ("r8152: Re-order napi_disable in rtl8152_close"). For #2 and #3, add checking the flag of IFF_UP and using napi_disable/napi_enable during mutex. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-22Merge tag 'drm-fixes-2019-11-22' of git://anongit.freedesktop.org/drm/drmLinus Torvalds16-32/+183
Pull drm fixes from Dave Airlie: "Two sets of fixes in here, one for amdgpu, and one for i915. The amdgpu ones are pretty small, i915's CI system seems to have a few problems in the last week or so, there is one major regression fix for fb_mmap, but there are a bunch of other issues fixed in there as well, oops, screen flashes and rcu related. amdgpu: - Remove experimental flag for navi14 - Fix confusing power message failures on older VI parts - Hang fix for gfxoff when using the read register interface - Two stability regression fixes for Raven i915: - Fix kernel oops on dumb_create ioctl on no crtc situation - Fix bad ugly colored flash on VLV/CHV related to gamma LUT update - Fix unity of the frequencies reported on PMU - Fix kernel oops on set_page_dirty using better locks around it - Protect the request pointer with RCU to prevent it being freed while we might need still - Make pool objects read-only - Restore physical addresses for fb_map to avoid corrupted page table" * tag 'drm-fixes-2019-11-22' of git://anongit.freedesktop.org/drm/drm: drm/i915/fbdev: Restore physical addresses for fb_mmap() Revert "drm/amd/display: enable S/G for RAVEN chip" drm/amdgpu: disable gfxoff on original raven drm/amdgpu: disable gfxoff when using register read interface drm/amd/powerplay: correct fine grained dpm force level setting drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs drm/amdgpu: remove experimental flag for Navi14 drm/i915: make pool objects read-only drm/i915: Protect request peeking with RCU drm/i915/userptr: Try to acquire the page lock around set_page_dirty() drm/i915/pmu: "Frequency" is reported as accumulated cycles drm/i915: Preload LUTs if the hw isn't currently using them drm/i915: Don't oops in dumb_create ioctl if we have no crtcs
2019-11-22can: m_can_platform: remove unnecessary m_can_class_resume() callPankaj Sharma1-2/+0
The function m_can_runtime_resume() is getting recursively called from m_can_class_resume(). This results in a lock up. We need not call m_can_class_resume() during m_can_runtime_resume(). Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Signed-off-by: Pankaj Sharma <pankj.sharma@samsung.com> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> Acked-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2019-11-22can: m_can_platform: set net_device structure as driver dataPankaj Sharma1-1/+1
The current code is failing during clock prepare enable because of not getting proper clock from platform device. [ 0.852089] Call trace: [ 0.854516] 0xffff0000fa22a668 [ 0.857638] clk_prepare+0x20/0x34 [ 0.861019] m_can_runtime_resume+0x2c/0xe4 [ 0.865180] pm_generic_runtime_resume+0x28/0x38 [ 0.869770] __rpm_callback+0x16c/0x1bc [ 0.873583] rpm_callback+0x24/0x78 [ 0.877050] rpm_resume+0x428/0x560 [ 0.880517] __pm_runtime_resume+0x7c/0xa8 [ 0.884593] m_can_clk_start.isra.9.part.10+0x1c/0xa8 [ 0.889618] m_can_class_register+0x138/0x370 [ 0.893950] m_can_plat_probe+0x120/0x170 [ 0.897939] platform_drv_probe+0x4c/0xa0 [ 0.901924] really_probe+0xd8/0x31c [ 0.905477] driver_probe_device+0x58/0xe8 [ 0.909551] device_driver_attach+0x68/0x70 [ 0.913711] __driver_attach+0x9c/0xf8 [ 0.917437] bus_for_each_dev+0x50/0xa0 [ 0.921251] driver_attach+0x20/0x28 [ 0.924804] bus_add_driver+0x148/0x1fc [ 0.928617] driver_register+0x6c/0x124 [ 0.932431] __platform_driver_register+0x48/0x50 [ 0.937113] m_can_plat_driver_init+0x18/0x20 [ 0.941446] do_one_initcall+0x4c/0x19c [ 0.945259] kernel_init_freeable+0x1d0/0x280 [ 0.949591] kernel_init+0x10/0x100 [ 0.953057] ret_from_fork+0x10/0x18 [ 0.956614] Code: 00000000 00000000 00000000 00000000 (fa22a668) [ 0.962681] ---[ end trace 881f71bd609de763 ]--- [ 0.967301] Kernel panic - not syncing: Attempted to kill init! A device driver for CAN controller hardware registers itself with the Linux network layer as a network device. So, the driver data for m_can should ideally be of type net_device. Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Signed-off-by: Pankaj Sharma <pankj.sharma@samsung.com> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> Acked-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2019-11-22hv_netvsc: Fix send_table offset in case of a host bugHaiyang Zhang1-2/+14
If negotiated NVSP version <= NVSP_PROTOCOL_VERSION_6, the offset may be wrong (too small) due to a host bug. This can cause missing the end of the send indirection table, and add multiple zero entries from leading zeros before the data region. This bug adds extra burden on channel 0. So fix the offset by computing it from the data structure sizes. This will ensure netvsc driver runs normally on unfixed hosts, and future fixed hosts. Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)") Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-22hv_netvsc: Fix offset usage in netvsc_send_table()Haiyang Zhang2-9/+20
To reach the data region, the existing code adds offset in struct nvsp_5_send_indirect_table on the beginning of this struct. But the offset should be based on the beginning of its container, struct nvsp_message. This bug causes the first table entry missing, and adds an extra zero from the zero pad after the data region. This can put extra burden on the channel 0. So, correct the offset usage. Also add a boundary check to ensure not reading beyond data region. Fixes: 5b54dac856cb ("hyperv: Add support for virtual Receive Side Scaling (vRSS)") Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-22Merge tag 'drm-intel-fixes-2019-11-21' of ↵Dave Airlie9-18/+141
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix kernel oops on dumb_create ioctl on no crtc situation - Fix bad ugly colored flash on VLV/CHV related to gamma LUT update - Fix unity of the frequencies reported on PMU - Fix kernel oops on set_page_dirty using better locks around it - Protect the request pointer with RCU to prevent it being freed while we might need still - Make pool objects read-only - Restore physical addresses for fb_map to avoid corrupted page table Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191121165339.GA23920@intel.com
2019-11-21sfc: Only cancel the PPS workqueue if it existsMartin Habets1-1/+2
The workqueue only exists for the primary PF. For other functions we hit a WARN_ON in kernel/workqueue.c. Fixes: 7c236c43b838 ("sfc: Add support for IEEE-1588 PTP") Signed-off-by: Martin Habets <mhabets@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-21Merge tag 'for-linus-20191121' of git://git.kernel.dk/linux-blockLinus Torvalds1-0/+1
Pull block fix from Jens Axboe: "Just a single fix for an issue in nbd introduced in this cycle" * tag 'for-linus-20191121' of git://git.kernel.dk/linux-block: nbd:fix memory leak in nbd_get_socket()
2019-11-21Merge tag 'gpio-v5.4-5' of ↵Linus Torvalds3-6/+23
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "A last set of small fixes for GPIO, this cycle was quite busy. - Fix debounce delays on the MAX77620 GPIO expander - Use the correct unit for debounce times on the BD70528 GPIO expander - Get proper deps for parallel builds of the GPIO tools - Add a specific ACPI quirk for the Terra Pad 1061" * tag 'gpio-v5.4-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist tools: gpio: Correctly add make dependencies for gpio_utils gpio: bd70528: Use correct unit for debounce times gpio: max77620: Fixup debounce delays
2019-11-21nfc: port100: handle command failure cleanlyOliver Neukum1-1/+1
If starting the transfer of a command suceeds but the transfer for the reply fails, it is not enough to initiate killing the transfer for the command may still be running. You need to wait for the killing to finish before you can reuse URB and buffer. Reported-and-tested-by: syzbot+711468aa5c3a1eabf863@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-21drm/i915/fbdev: Restore physical addresses for fb_mmap()Chris Wilson1-4/+5
fbdev uses the physical address of our framebuffer for its fb_mmap() routine. While we need to adapt this address for the new io BAR, we have to fix v5.4 first! The simplest fix is to restore the smem back to v5.3 and we will then probably have to implement our fbops->fb_mmap() callback to handle local memory. Reported-by: Neil MacLeod <freedesktop@nmacleod.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256 Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: Neil MacLeod <freedesktop@nmacleod.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk (cherry picked from commit abc5520704ab438099fe352636b30b05c1253bea) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 9faf5fa4d3dad3b0c0fa6e67689c144981a11c27) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-11-21Revert "drm/amd/display: enable S/G for RAVEN chip"Alex Deucher2-2/+2
This reverts commit 1c4259159132ae4ceaf7c6db37a6cf76417f73d9. S/G display is not stable with the IOMMU enabled on some platforms. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523 Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-11-21drm/amdgpu: disable gfxoff on original ravenAlex Deucher1-2/+7
There are still combinations of sbios and firmware that are not stable. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=204689 Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-11-21drm/amdgpu: disable gfxoff when using register read interfaceAlex Deucher1-1/+5
When gfxoff is enabled, accessing gfx registers via MMIO can lead to a hang. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205497 Acked-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-11-21drm/amd/powerplay: correct fine grained dpm force level settingEvan Quan1-0/+6
For fine grained dpm, there is only two levels supported. However to reflect correctly the current clock frequency, there is an intermediate level faked. Thus on forcing level setting, we need to treat level 2 correctly as level 1. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Kevin Wang <kevin1.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-21drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICsEvan Quan1-5/+18
Otherwise, the error message prompted will confuse user. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-11-21drm/amdgpu: remove experimental flag for Navi14Alex Deucher1-4/+4
5.4 and newer works fine with navi14. Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-20Merge tag 'mlx5-fixes-2019-11-20' of ↵David S. Miller12-56/+67
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== Mellanox, mlx5 fixes 2019-11-20 This series introduces some fixes to mlx5 driver. Please pull and let me know if there is any problem. For -stable v4.9: ('net/mlx5e: Fix set vf link state error flow') For -stable v4.14 ('net/mlxfw: Verify FSM error code translation doesn't exceed array size') For -stable v4.19 ('net/mlx5: Fix auto group size calculation') For -stable v5.3 ('net/mlx5e: Fix error flow cleanup in mlx5e_tc_tun_create_header_ipv4/6') ('net/mlx5e: Do not use non-EXT link modes in EXT mode') ('net/mlx5: Update the list of the PCI supported devices') ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20r8152: Re-order napi_disable in rtl8152_closePrashant Malani1-1/+1
Both rtl_work_func_t() and rtl8152_close() call napi_disable(). Since the two calls aren't protected by a lock, if the close function starts executing before the work function, we can get into a situation where the napi_disable() function is called twice in succession (first by rtl8152_close(), then by set_carrier()). In such a situation, the second call would loop indefinitely, since rtl8152_close() doesn't call napi_enable() to clear the NAPI_STATE_SCHED bit. The rtl8152_close() function in turn issues a cancel_delayed_work_sync(), and so it would wait indefinitely for the rtl_work_func_t() to complete. Since rtl8152_close() is called by a process holding rtnl_lock() which is requested by other processes, this eventually leads to a system deadlock and crash. Re-order the napi_disable() call to occur after the work function disabling and urb cancellation calls are issued. Change-Id: I6ef0b703fc214998a037a68f722f784e1d07815e Reported-by: http://crbug.com/1017928 Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net: qca_spi: Move reset_count to struct qcaspiStefan Wahren2-5/+5
The reset counter is specific for every QCA700x chip. So move this into the private driver struct. Otherwise we get unpredictable reset behavior in setups with multiple QCA700x chips. Fixes: 291ab06ecf67 (net: qualcomm: new Ethernet over SPI driver for QCA7000) Signed-off-by: Stefan Wahren <stefan.wahren@in-tech.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net: qca_spi: fix receive buffer size checkMichael Heimpold1-1/+1
When receiving many or larger packets, e.g. when doing a file download, it was observed that the read buffer size register reports up to 4 bytes more than the current define allows in the check. If this is the case, then no data transfer is initiated to receive the packets (and thus to empty the buffer) which results in a stall of the interface. These 4 bytes are a hardware generated frame length which is prepended to the actual frame, thus we have to respect it during our check. Fixes: 026b907d58c4 ("net: qca_spi: Add available buffer space verification") Signed-off-by: Michael Heimpold <michael.heimpold@in-tech.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE modeJuliet Kim1-1/+4
Reversion of commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab (“net/ibmvnic: Fix EOI when running in XIVE mode.”) leaves us calling H_EOI even in XIVE mode. That will fail with H_FUNCTION because H_EOI is not supported in that mode. That failure is harmless. Ignore it so we can use common code for both XICS and XIVE. Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20Revert "net/ibmvnic: Fix EOI when running in XIVE mode"Juliet Kim1-3/+5
This reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab (“net/ibmvnic: Fix EOI when running in XIVE mode.”) since that has the unintended effect of changing the interrupt priority and emits warning when running in legacy XICS mode. Signed-off-by: Juliet Kim <julietk@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net/mlxfw: Verify FSM error code translation doesn't exceed array sizeEran Ben Elisha1-0/+2
Array mlxfw_fsm_state_err_str contains value to string translation, when values are provided by mlxfw_dev. If value is larger than MLXFW_FSM_STATE_ERR_MAX, return "unknown error" as expected instead of reading an address than exceed array size. Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5: Update the list of the PCI supported devicesShani Shapp1-0/+1
Add the upcoming ConnectX-6 LX device ID. Fixes: 85327a9c4150 ("net/mlx5: Update the list of the PCI supported devices") Signed-off-by: Shani Shapp <shanish@mellanox.com> Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5: Fix auto group size calculationMaor Gottlieb2-4/+7
Once all the large flow groups (defined by the user when the flow table is created - max_num_groups) were created, then all the following new flow groups will have only one flow table entry, even though the flow table has place to larger groups. Fix the condition to prefer large flow group. Fixes: f0d22d187473 ("net/mlx5_core: Introduce flow steering autogrouped flow table") Signed-off-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5e: Add missing capability bit check for IP-in-IPMarina Varshaver1-1/+4
Device that doesn't support IP-in-IP offloads has to filter csum and gso offload support, otherwise kernel will conclude that device is capable of offloading csum and gso for IP-in-IP tunnels and that might result in IP-in-IP tunnel not functioning. Fixes: 25948b87dda2 ("net/mlx5e: Support TSO and TX checksum offloads for IP-in-IP") Signed-off-by: Marina Varshaver <marinav@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5e: Do not use non-EXT link modes in EXT modeEran Ben Elisha1-6/+6
On some old Firmwares, connector type value was not supported, and value read from FW was 0. For those, driver used link mode in order to set connector type in link_ksetting. After FW exposed the connector type, driver translated the value to ethtool definitions. However, as 0 is a valid value, before returning PORT_OTHER, driver run the check of link mode in order to maintain backward compatibility. Cited patch added support to EXT mode. With both features (connector type and EXT link modes) ,if connector_type read from FW is 0 and EXT mode is set, driver mistakenly compare EXT link modes to non-EXT link mode. Fixed that by skipping this comparison if we are in EXT mode, as connector type value is valid in this scenario. Fixes: 6a897372417e ("net/mlx5: ethtool, Add ethtool support for 50Gbps per lane link modes") Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com> Reviewed-by: Aya Levin <ayal@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5e: Fix set vf link state error flowRoi Dayan1-1/+1
Before this commit the ndo always returned success. Fix that. Fixes: 1ab2068a4c66 ("net/mlx5: Implement vports admin state backup/restore") Signed-off-by: Roi Dayan <roid@mellanox.com> Reviewed-by: Vlad Buslov <vladbu@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5: DR, Limit STE hash table enlarge based on bytemaskAlex Vesker2-20/+15
When an ste hash table has too many collision we enlarge it to a bigger hash table (rehash). Rehashing collision improvement depends on the bytemask value. The more 1 bits we have in bytemask means better spreading in the table. Without this fix tables can grow in size without providing any improvement which can lead to memory depletion and failures. This patch will limit table rehash to reduce memory and improve the performance. Fixes: 41d07074154c ("net/mlx5: DR, Expose steering rule functionality") Signed-off-by: Alex Vesker <valex@mellanox.com> Reviewed-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5: DR, Skip rehash for tables with byte mask zeroAlex Vesker1-1/+1
The byte mask fields affect on the hash index distribution, when the byte mask is zero, the hash calculation will always be equal to the same index. To avoid unneeded rehash of hash tables mark the table to skip rehash. This is needed by the next patch which will limit table rehash to reduce memory consumption. Fixes: 41d07074154c ("net/mlx5: DR, Expose steering rule functionality") Signed-off-by: Alex Vesker <valex@mellanox.com> Reviewed-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5: DR, Fix invalid EQ vector number on CQ creationAlex Vesker1-1/+3
When creating a CQ, the CPU id is used for the vector value. This would fail in-case the CPU id was higher than the maximum vector value. Fixes: 297cccebdc5a ("net/mlx5: DR, Expose an internal API to issue RDMA operations") Signed-off-by: Alex Vesker <valex@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Reviewed-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5e: Reorder mirrer action parsing to check for encap firstVlad Buslov1-14/+14
Mirred action parsing code in parse_tc_fdb_actions() first checks if out_dev has same parent id, and only verifies that there is a pending encap action that was parsed before. Recent change in vxlan module made function netdev_port_same_parent_id() to return true when called for mlx5 eswitch representor and vxlan device created explicitly on mlx5 representor device (vxlan devices created with "external" flag without explicitly specifying parent interface are not affected). With call to netdev_port_same_parent_id() returning true, incorrect code path is chosen and encap rules fail to offload because vxlan dev is not a valid eswitch forwarding dev. Dmesg log of error: [ 1784.389797] devices ens1f0_0 vxlan1 not on same switch HW, can't offload forwarding In order to fix the issue, rearrange conditional in parse_tc_fdb_actions() to check for pending encap action before checking if out_dev has the same parent id. Fixes: 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level") Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5e: Fix ingress rate configuration for representorsEli Cohen1-2/+1
Current code uses the old method of prio encoding in flow_cls_common_offload. Fix to follow the changes introduced in commit ef01adae0e43 ("net: sched: use major priority number as hardware priority"). Fixes: fcb64c0f5640 ("net/mlx5: E-Switch, add ingress rate support") Signed-off-by: Eli Cohen <eli@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20net/mlx5e: Fix error flow cleanup in mlx5e_tc_tun_create_header_ipv4/6Eli Cohen1-6/+12
Be sure to release the neighbour in case of failures after successful route lookup. Fixes: 101f4de9dd52 ("net/mlx5e: Move TC tunnel offloading code to separate source file") Signed-off-by: Eli Cohen <eli@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
2019-11-20s390/qeth: return proper errno on IO errorJulian Wiedmann1-5/+5
When propagating IO errors back to userspace, one error path in qeth_irq() currently returns '1' instead of a proper errno. Fixes: 54daaca7024d ("s390/qeth: cancel cmd on early error") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20s390/qeth: fix potential deadlock on workqueue flushJulian Wiedmann3-8/+28
The L2 bridgeport code uses the coarse 'conf_mutex' for guarding access to its configuration state. This can result in a deadlock when qeth_l2_stop_card() - called under the conf_mutex - blocks on flush_workqueue() to wait for the completion of pending bridgeport workers. Such workers would also need to aquire the conf_mutex, stalling indefinitely. Introduce a lock that specifically guards the bridgeport configuration, so that the workers no longer need the conf_mutex. Wrapping qeth_l2_promisc_to_bridge() in this fine-grained lock then also fixes a theoretical race against a concurrent qeth_bridge_port_role_store() operation. Fixes: c0a2e4d10d93 ("s390/qeth: conclude all event processing before offlining a card") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20virtio_balloon: fix shrinker countWei Wang1-1/+1
Instead of multiplying by page order, virtio balloon divided by page order. The result is that it can return 0 if there are a bit less than MAX_ORDER - 1 pages in use, and then shrinker scan won't be called. Cc: stable@vger.kernel.org Fixes: 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") Signed-off-by: Wei Wang <wei.w.wang@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com>
2019-11-20virtio_balloon: fix shrinker scan number of pagesMichael S. Tsirkin1-6/+12
virtio_balloon_shrinker_scan should return number of system pages freed, but because it's calling functions that deal with balloon pages, it gets confused and sometimes returns the number of balloon pages. It does not matter practically as the exact number isn't used, but it seems better to be consistent in case someone starts using this API. Further, if we ever tried to iteratively leak pages as virtio_balloon_shrinker_scan tries to do, we'd run into issues - this is because freed_pages was accumulating total freed pages, but was also subtracted on each iteration from pages_to_free, which can result in either leaking less memory than we were supposed to free, or more if pages_to_free underruns. On a system with 4K pages we are lucky that we are never asked to leak more than 128 pages while we can leak up to 256 at a time, but it looks like a real issue for systems with page size != 4K. Fixes: 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") Reported-by: Khazhismel Kumykov <khazhy@google.com> Reviewed-by: Wei Wang <wei.w.wang@intel.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-11-20mdio_bus: Fix init if CONFIG_RESET_CONTROLLER=nGeert Uytterhoeven1-1/+1
Commit 1d4639567d97 ("mdio_bus: Fix PTR_ERR applied after initialization to constant") accidentally changed a check from -ENOTSUPP to -ENOSYS, causing failures if reset controller support is not enabled. E.g. on r7s72100/rskrza1: sh-eth e8203000.ethernet: MDIO init failed: -524 sh-eth: probe of e8203000.ethernet failed with error -524 Seen on r8a7740/armadillo, r7s72100/rskrza1, and r7s9210/rza2mevb. Fixes: 1d4639567d97 ("mdio_bus: Fix PTR_ERR applied after initialization to constant") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: YueHaibing <yuehaibing@huawei.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20Revert "mdio_bus: fix mdio_register_device when RESET_CONTROLLER is disabled"David S. Miller1-2/+1
This reverts commit 075e238d12c21c8bde700d21fb48be7a3aa80194. Going to go with Geert's fix instead, which also has a correct Fixes tag. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net: hns3: fix a wrong reset interrupt status maskHuazhong Tan1-1/+1
According to hardware user manual, bits5~7 in register HCLGE_MISC_VECTOR_INT_STS means reset interrupts status, but HCLGE_RESET_INT_M is defined as bits0~2 now. So it will make hclge_reset_err_handle() read the wrong reset interrupt status. This patch fixes this wrong bit mask. Fixes: 2336f19d7892 ("net: hns3: check reset interrupt status when reset fails") Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net: fec: fix clock count mis-matchChuhong Yuan1-4/+11
pm_runtime_put_autosuspend in probe will call runtime suspend to disable clks automatically if CONFIG_PM is defined. (If CONFIG_PM is not defined, its implementation will be empty, then runtime suspend will not be called.) Therefore, we can call pm_runtime_get_sync to runtime resume it first to enable clks, which matches the runtime suspend. (Only when CONFIG_PM is defined, otherwise pm_runtime_get_sync will also be empty, then runtime resume will not be called.) Then it is fine to disable clks without causing clock count mis-match. Fixes: c43eab3eddb4 ("net: fec: add missed clk_disable_unprepare in remove") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Acked-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net: phylink: fix link mode modification in PHY modeRussell King1-9/+16
Modifying the link settings via phylink_ethtool_ksettings_set() and phylink_ethtool_set_pauseparam() didn't always work as intended for PHY based setups, as calling phylink_mac_config() would result in the unresolved configuration being committed to the MAC, rather than the configuration with the speed and duplex setting. This would work fine if the update caused the link to renegotiate, but if no settings have changed, phylib won't trigger a renegotiation cycle, and the MAC will be left incorrectly configured. Avoid calling phylink_mac_config() unless we are using an inband mode in phylink_ethtool_ksettings_set(), and use phy_set_asym_pause() as introduced in 4.20 to set the PHY settings in phylink_ethtool_set_pauseparam(). Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20net: phylink: update documentation on create and destroyRussell King1-0/+4
Update the documentation on phylink's create and destroy functions to explicitly state that the rtnl lock must not be held while calling these. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-15 01:14:23 +0300