summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-05-21dmaengine: mediatek-cqdma: sleeping in atomic contextDan Carpenter1-2/+2
The mtk_cqdma_poll_engine_done() function takes a true/false parameter where true means it's called from atomic context. There are a couple places where it was set to false but it's actually in atomic context so it should be true. All the callers for mtk_cqdma_hard_reset() are holding a spin_lock and in mtk_cqdma_free_chan_resources() we take a spin_lock before calling the mtk_cqdma_poll_engine_done() function. Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-05-21dmaengine: dw-axi-dmac: fix null dereference when pointer first is nullColin Ian King1-1/+2
In the unlikely event that axi_desc_get returns a null desc in the very first iteration of the while-loop the error exit path ends up calling axi_desc_put on a null pointer 'first' and this causes a null pointer dereference. Fix this by adding a null check on pointer 'first' before calling axi_desc_put. Addresses-Coverity: ("Explicit null dereference") Fixes: 1fe20f1b8454 ("dmaengine: Introduce DW AXI DMAC driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner1322-0/+1322
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21treewide: Add SPDX license identifier for more missed filesThomas Gleixner341-0/+341
Add SPDX license identifiers to all files which: - Have no license information of any form - Have MODULE_LICENCE("GPL*") inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21treewide: Add SPDX license identifier for missed filesThomas Gleixner52-0/+52
Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an ↵Murray McAllister1-1/+2
invalid read If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID of SVGA3D_INVALID_ID, and a shader type of SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot will be 4294967295, leading to an out-of-bounds read in vmw_binding_loc() when the offset is calculated. Cc: <stable@vger.kernel.org> Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support") Signed-off-by: Murray McAllister <murray.mcallister@gmail.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2019-05-21drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define()Murray McAllister1-0/+4
If SVGA_3D_CMD_DX_DEFINE_RENDERTARGET_VIEW is called with a surface ID of SVGA3D_INVALID_ID, the srf struct will remain NULL after vmw_cmd_res_check(), leading to a null pointer dereference in vmw_view_add(). Cc: <stable@vger.kernel.org> Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support") Signed-off-by: Murray McAllister <murray.mcallister@gmail.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2019-05-21drm/vmwgfx: Use the dma scatter-gather iterator to get dma addressesThomas Hellstrom2-21/+8
Use struct sg_dma_page_iter in favour struct of sg_page_iter, which fairly recently was declared useless for obtaining dma addresses. With a struct sg_dma_page_iter we can't call sg_page_iter_page() so when the page is needed, use the same page lookup mechanism as for the non-sg dma modes instead of calling sg_dma_page_iter. Note, the fixes tag doesn't really point to a commit introducing a failure / regression, but rather to a commit that implemented a simple workaround for this problem. Cc: Jason Gunthorpe <jgg@mellanox.com> Fixes: d901b2760dc6 ("lib/scatterlist: Provide a DMA page iterator") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
2019-05-21drm/vmwgfx: Fix compat mode shader operationThomas Hellstrom1-0/+13
In compat mode, we allowed host-backed user-space with guest-backed kernel / device. In this mode, set shader commands was broken since no relocations were emitted. Fix this. Cc: <stable@vger.kernel.org> Fixes: e8c66efbfe3a ("drm/vmwgfx: Make user resource lookups reference-free during validation") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2019-05-21drm/vmwgfx: Fix user space handle equal to zeroThomas Hellstrom1-1/+1
User-space handles equal to zero are interpreted as uninitialized or illegal by some drm systems (most notably kms). This means that a dumb buffer or surface with a zero user-space handle can never be used as a kms frame-buffer. Cc: <stable@vger.kernel.org> Fixes: c7eae62666ad ("drm/vmwgfx: Make the object handles idr-generated") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-05-21drm/vmwgfx: Don't send drm sysfs hotplug events on initial master setThomas Hellstrom1-1/+7
This may confuse user-space clients like plymouth that opens a drm file descriptor as a result of a hotplug event and then generates a new event... Cc: <stable@vger.kernel.org> Fixes: 5ea1734827bb ("drm/vmwgfx: Send a hotplug event at master_set") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-05-21USB: rio500: simplify lockingOliver Neukum1-27/+16
Admitting that there can be only one device allows us to drop any pretense about locking one device or a table of devices. Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21USB: rio500: fix memory leak in close after disconnectOliver Neukum1-2/+15
If a disconnected device is closed, rio_close() must free the buffers. Signed-off-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21USB: rio500: refuse more than one device at a timeOliver Neukum1-6/+18
This driver is using a global variable. It cannot handle more than one device at a time. The issue has been existing since the dawn of the driver. Signed-off-by: Oliver Neukum <oneukum@suse.com> Reported-by: syzbot+35f04d136fc975a70da4@syzkaller.appspotmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usbip: usbip_host: fix BUG: sleeping function called from invalid contextShuah Khan1-22/+43
stub_probe() and stub_disconnect() call functions which could call sleeping function in invalid context whil holding busid_lock. Fix the problem by refining the lock holds to short critical sections to change the busid_priv fields. This fix restructures the code to limit the lock holds in stub_probe() and stub_disconnect(). stub_probe(): [15217.927028] BUG: sleeping function called from invalid context at mm/slab.h:418 [15217.927038] in_atomic(): 1, irqs_disabled(): 0, pid: 29087, name: usbip [15217.927044] 5 locks held by usbip/29087: [15217.927047] #0: 0000000091647f28 (sb_writers#6){....}, at: vfs_write+0x191/0x1c0 [15217.927062] #1: 000000008f9ba75b (&of->mutex){....}, at: kernfs_fop_write+0xf7/0x1b0 [15217.927072] #2: 00000000872e5b4b (&dev->mutex){....}, at: __device_driver_lock+0x3b/0x50 [15217.927082] #3: 00000000e74ececc (&dev->mutex){....}, at: __device_driver_lock+0x46/0x50 [15217.927090] #4: 00000000b20abbe0 (&(&busid_table[i].busid_lock)->rlock){....}, at: get_busid_priv+0x48/0x60 [usbip_host] [15217.927103] CPU: 3 PID: 29087 Comm: usbip Tainted: G W 5.1.0-rc6+ #40 [15217.927106] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013 [15217.927109] Call Trace: [15217.927118] dump_stack+0x63/0x85 [15217.927127] ___might_sleep+0xff/0x120 [15217.927133] __might_sleep+0x4a/0x80 [15217.927143] kmem_cache_alloc_trace+0x1aa/0x210 [15217.927156] stub_probe+0xe8/0x440 [usbip_host] [15217.927171] usb_probe_device+0x34/0x70 stub_disconnect(): [15279.182478] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 [15279.182487] in_atomic(): 1, irqs_disabled(): 0, pid: 29114, name: usbip [15279.182492] 5 locks held by usbip/29114: [15279.182494] #0: 0000000091647f28 (sb_writers#6){....}, at: vfs_write+0x191/0x1c0 [15279.182506] #1: 00000000702cf0f3 (&of->mutex){....}, at: kernfs_fop_write+0xf7/0x1b0 [15279.182514] #2: 00000000872e5b4b (&dev->mutex){....}, at: __device_driver_lock+0x3b/0x50 [15279.182522] #3: 00000000e74ececc (&dev->mutex){....}, at: __device_driver_lock+0x46/0x50 [15279.182529] #4: 00000000b20abbe0 (&(&busid_table[i].busid_lock)->rlock){....}, at: get_busid_priv+0x48/0x60 [usbip_host] [15279.182541] CPU: 0 PID: 29114 Comm: usbip Tainted: G W 5.1.0-rc6+ #40 [15279.182543] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013 [15279.182546] Call Trace: [15279.182554] dump_stack+0x63/0x85 [15279.182561] ___might_sleep+0xff/0x120 [15279.182566] __might_sleep+0x4a/0x80 [15279.182574] __mutex_lock+0x55/0x950 [15279.182582] ? get_busid_priv+0x48/0x60 [usbip_host] [15279.182587] ? reacquire_held_locks+0xec/0x1a0 [15279.182591] ? get_busid_priv+0x48/0x60 [usbip_host] [15279.182597] ? find_held_lock+0x94/0xa0 [15279.182609] mutex_lock_nested+0x1b/0x20 [15279.182614] ? mutex_lock_nested+0x1b/0x20 [15279.182618] kernfs_remove_by_name_ns+0x2a/0x90 [15279.182625] sysfs_remove_file_ns+0x15/0x20 [15279.182629] device_remove_file+0x19/0x20 [15279.182634] stub_disconnect+0x6d/0x180 [usbip_host] [15279.182643] usb_unbind_device+0x27/0x60 Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21USB: sisusbvga: fix oops in error path of sisusb_probeOliver Neukum1-7/+8
The pointer used to log a failure of usb_register_dev() must be set before the error is logged. v2: fix that minor is not available before registration Signed-off-by: oliver Neukum <oneukum@suse.com> Reported-by: syzbot+a0cbdbd6d169020c8959@syzkaller.appspotmail.com Fixes: 7b5cd5fefbe02 ("USB: SisUSB2VGA: Convert printk to dev_* macros") Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21USB: Add LPM quirk for Surface Dock GigE adapterMaximilian Luz1-0/+3
Without USB_QUIRK_NO_LPM ethernet will not work and rtl8152 will complain with r8152 <device...>: Stop submitting intr, status -71 Adding the quirk resolves this. As the dock is externally powered, this should not have any drawbacks. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21media: usb: siano: Fix general protection fault in smsusbAlan Stern1-13/+20
The syzkaller USB fuzzer found a general-protection-fault bug in the smsusb part of the Siano DVB driver. The fault occurs during probe because the driver assumes without checking that the device has both IN and OUT endpoints and the IN endpoint is ep1. By slightly rearranging the driver's initialization code, we can make the appropriate checks early on and thus avoid the problem. If the expected endpoints aren't present, the new code safely returns -ENODEV from the probe routine. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+53f029db71c19a47325a@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21usb: mtu3: fix up undefined reference to usb_debug_rootChunfeng Yun1-2/+1
When CONFIG_USB is not set, and CONFIG_USB_GADGET is set, there is an issue: ld: drivers/usb/mtu3/mtu3_debugfs.o: in function 'ssusb_debugfs_create_root': mtu3_debugfs.c:(.text+0xba3): undefined reference to 'usb_debug_root' usb_debug_root is only built when CONFIG_USB is enabled, so here drop it and use NULL instead. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21USB: Fix slab-out-of-bounds write in usb_get_bos_descriptorAlan Stern1-2/+2
The syzkaller USB fuzzer found a slab-out-of-bounds write bug in the USB core, caused by a failure to check the actual size of a BOS descriptor. This patch adds a check to make sure the descriptor is at least as large as it is supposed to be, so that the code doesn't inadvertently access memory beyond the end of the allocated region when assigning to dev->bos->desc->bNumDeviceCaps later on. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+71f1e64501a309fcc012@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21dmaengine: fsl-qdma: Add improvementPeng Ma1-3/+1
When an error occurs we should clean the error register then to return Signed-off-by: Peng Ma <peng.ma@nxp.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-05-21dmaengine: jz4780: Fix transfers being ACKed too soonPaul Cercueil1-11/+21
When a multi-descriptor DMA transfer is in progress, the "IRQ pending" flag will apparently be set for that channel as soon as the last descriptor loads, way before the IRQ actually happens. This behaviour has been observed on the JZ4725B, but maybe other SoCs are affected. In the case where another DMA transfer is running into completion on a separate channel, the IRQ handler would then run the completion handler for our previous channel even if the transfer didn't actually finish. Fix this by checking in the completion handler that we're indeed done; if not the interrupted DMA transfer will simply be resumed. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-05-21libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY overheadDan Williams1-2/+8
Jeff discovered that performance improves from ~375K iops to ~519K iops on a simple psync-write fio workload when moving the location of 'struct page' from the default PMEM location to DRAM. This result is surprising because the expectation is that 'struct page' for dax is only needed for third party references to dax mappings. For example, a dax-mapped buffer passed to another system call for direct-I/O requires 'struct page' for sending the request down the driver stack and pinning the page. There is no usage of 'struct page' for first party access to a file via read(2)/write(2) and friends. However, this "no page needed" expectation is violated by CONFIG_HARDENED_USERCOPY and the check_copy_size() performed in copy_from_iter_full_nocache() and copy_to_iter_mcsafe(). The check_heap_object() helper routine assumes the buffer is backed by a slab allocator (DRAM) page and applies some checks. Those checks are invalid, dax pages do not originate from the slab, and redundant, dax_iomap_actor() has already validated that the I/O is within bounds. Specifically that routine validates that the logical file offset is within bounds of the file, then it does a sector-to-pfn translation which validates that the physical mapping is within bounds of the block device. Bypass additional hardened usercopy overhead and call the 'no check' versions of the copy_{to,from}_iter operations directly. Fixes: 0aed55af8834 ("x86, uaccess: introduce copy_from_iter_flushcache...") Cc: <stable@vger.kernel.org> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Matthew Wilcox <willy@infradead.org> Reported-and-tested-by: Jeff Smits <jeff.smits@intel.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Jan Kara <jack@suse.cz> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2019-05-21drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry()Dan Carpenter1-1/+3
"ret" is uninitialized on this path but it should be -EINVAL. Fixes: 930c8dfea4b8 ("drm/i915/gvt: Check if get_next_pt_type() always returns a valid value") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardwareYan Zhao1-15/+0
the vGPU write on TRTTE and 0x4dfc is now write to vreg first. their values all be restored hardware when context switching. Fixes: e39c5add3221 ("drm/i915/gvt: vGPU MMIO virtualization") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: add 0x4dfc to gen9 save-restore listYan Zhao1-0/+1
0x4dfc is in-context mmio for gen9+, but each vm have different settings need to add it to save-restore list along with other trtt registers Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+Yan Zhao1-6/+6
TRVATTL3PTRDW(0x4de0-0x4de4), TRNULLDETCT(0x4de8), TRINVTILEDETCT(0x4dec), TRTTE(0x4df0), TRVADR(0x4df4) are in-context mmios for gen9+ Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platformYan Zhao3-15/+13
for restore-inhibit context, hardware will not load in-context mmios (engine context part) to hardware, but hardware will save the mmio values in hardware back to context image. So, in order to save correct values of vGPU back to context image, values of vGPU mmios have to be loaded into hardware first for restore-inhibit context. In this patch, the mechanism is applied to all gen9 platform. The reason excluding gen8 platforms is only because of lacking of testing on those platforms. v3: for mocs registers, goto in-context mmios save-restore path for skl platform as well (weinan li) v2: update vreg when scanning indirect context for inhibit context for gen9 Cc: Weinan Li <weinan.z.li@intel.com> Acked-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/i915/gvt: emit init breadcrumb for gvt requestWeinan1-0/+19
"To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced past the start of this request." It means all the request which timeline's has_init_breadcrumb is true, then the emit_init_breadcrumb process must have before emitting the real commands, otherwise, the scheduler might get a wrong state of this request during reset. If the request is exactly the guilty one, the scheduler won't terminate it with the wrong state. To avoid this, do emit_init_breadcrumb for all the requests from gvt. v2: cc to stable kernel Fixes: 8547444137ec ("drm/i915: Identify active requests") Cc: stable@vger.kernel.org Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Weinan <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-05-21drm/amdkfd: Fix compute profile switchingHarish Kasiviswanathan3-5/+29
Fix compute profile switching on process termination. Add a dedicated reference counter to keep track of entry/exit to/from compute profile. This enables switching compute profiles for other reasons than process creation or termination. Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Eric Huang <JinhuiEric.Huang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-21net: stmmac: dma channel control register need to be init firstWeifeng Voon1-4/+4
stmmac_init_chan() needs to be called before stmmac_init_rx_chan() and stmmac_init_tx_chan(). This is because if PBLx8 is to be used, "DMA_CH(#i)_Control.PBLx8" needs to be set before programming "DMA_CH(#i)_TX_Control.TxPBL" and "DMA_CH(#i)_RX_Control.RxPBL". Fixes: 47f2a9ce527a ("net: stmmac: dma channel init prepared for multiple queues") Reviewed-by: Zhang, Baoli <baoli.zhang@intel.com> Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Weifeng Voon <weifeng.voon@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-21net: stmmac: fix ethtool flow control not able to get/setTan, Tee Min1-2/+2
Currently ethtool was not able to get/set the flow control due to a missing "!". It will always return -EOPNOTSUPP even the device is flow control supported. This patch fixes the condition check for ethtool flow control get/set function for ETHTOOL_LINK_MODE_Asym_Pause_BIT. Fixes: 3c1bcc8614db (“net: ethernet: Convert phydev advertize and supported from u32 to link mode”) Signed-off-by: Tan, Tee Min <tee.min.tan@intel.com> Reviewed-by: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Voon, Weifeng <weifeng.voon@intel.com@intel.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-21fddi: fix typos in code commentsWeitao Hou1-2/+2
fix abord to abort Signed-off-by: Weitao Hou <houweitaoo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-212/2] net: xilinx_emaclite: use readx_poll_timeout() in mdio wait functionKurt Kanzenbach1-10/+6
On loaded systems with a preemptible kernel the mdio_wait() function may report an error while everything is working fine: xemaclite_mdio_wait(): xemaclite_readl() -> chip not ready --> interrupt here (other work for some time / chip become ready) if (time_before_eq(end, jiffies)) --> false positive error report Replace the current code with readx_poll_timeout() which takes care of the situation. Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-211/2] net: axienet: use readx_poll_timeout() in mdio wait functionKurt Kanzenbach2-10/+11
On loaded systems with a preemptible kernel the mdio_wait() function may report an error while everything is working fine: axienet_mdio_wait_until_ready(): axienet_ior() -> chip not ready --> interrupt here (other work for some time / chip become ready) if (time_before_eq(end, jiffies)) --> false positive error report Replace the current code with readx_poll_timeout() which take care of the situation. Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-21dax: Arrange for dax_supported check to span multiple devicesDan Williams6-37/+91
Pankaj reports that starting with commit ad428cdb525a "dax: Check the end of the block-device capacity with dax_direct_access()" device-mapper no longer allows dax operation. This results from the stricter checks in __bdev_dax_supported() that validate that the start and end of a block-device map to the same 'pagemap' instance. Teach the dax-core and device-mapper to validate the 'pagemap' on a per-target basis. This is accomplished by refactoring the bdev_dax_supported() internals into generic_fsdax_supported() which takes a sector range to validate. Consequently generic_fsdax_supported() is suitable to be used in a device-mapper ->iterate_devices() callback. A new ->dax_supported() operation is added to allow composite devices to split and route upper-level bdev_dax_supported() requests. Fixes: ad428cdb525a ("dax: Check the end of the block-device...") Cc: <stable@vger.kernel.org> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Reported-by: Pankaj Gupta <pagupta@redhat.com> Reviewed-by: Pankaj Gupta <pagupta@redhat.com> Tested-by: Pankaj Gupta <pagupta@redhat.com> Tested-by: Vaibhav Jain <vaibhav@linux.ibm.com> Reviewed-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2019-05-21libnvdimm: Fix compilation warnings with W=1Qian Cai3-4/+4
Several places (dimm_devs.c, core.c etc) include label.h but only label.c uses NSINDEX_SIGNATURE, so move its definition to label.c instead. In file included from drivers/nvdimm/dimm_devs.c:23: drivers/nvdimm/label.h:41:19: warning: 'NSINDEX_SIGNATURE' defined but not used [-Wunused-const-variable=] Also, some places abuse "/**" which is only reserved for the kernel-doc. drivers/nvdimm/bus.c:648: warning: cannot understand function prototype: 'struct attribute_group nd_device_attribute_group = ' drivers/nvdimm/bus.c:677: warning: cannot understand function prototype: 'struct attribute_group nd_numa_attribute_group = ' Those are just some member assignments for the "struct attribute_group" instances and it can't be expressed in the kernel-doc. Reviewed-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2019-05-20macvlan: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/net/macvlan.c: In function ‘macvlan_do_ioctl’: drivers/net/macvlan.c:839:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!net_eq(dev_net(dev), &init_net)) ^ drivers/net/macvlan.c:841:2: note: here case SIOCGHWTSTAMP: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-20net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages queryErez Alfasi2-6/+3
Querying EEPROM high pages data for SFP module is currently not supported by our driver but is still tried, resulting in invalid FW queries. Set the EEPROM ethtool data length to 256 for SFP module to limit the reading for page 0 only and prevent invalid FW queries. Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool support") Signed-off-by: Erez Alfasi <ereza@mellanox.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-20drm/amdgpu: skip fw pri bo alloc for SRIOVYintian Tao1-7/+10
PSP fw primary buffer is not used under SRIOV. Under SRIOV, VBIOS or hypervisor driver will load psp sos and psp sysdrv. Therefore, we don't need to allocate memory for it. v2: remove superfluous check for amdgpu_bo_free_kernel(). Signed-off-by: Yintian Tao <yttao@amd.com> Signed-off-by: Monk Liu <Monk.Liu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-20drm/amd/powerplay: fix locking in smu_feature_set_supported()Dan Carpenter1-1/+1
There is a typo so the code unlocks twice instead of taking the lock and then releasing it. Fixes: f14a323db5b0 ("drm/amd/powerplay: implement update enabled feature state to smc for smu11") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-20drm/amdgpu/gmc9: set vram_width properly for SR-IOVAlex Deucher1-1/+9
For SR-IOV, vram_width can't be read from ATOM as RAVEN, and DF related registers is not readable, so hardcord is the only way to set the correct vram_width. Reviewed-by: Yintian Tao <yttao@amd.com> Signed-off-by: Trigger Huang <Trigger.Huang@amd.com> Signed-off-by: Yintian Tao <yttao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-20drm/amdgpu/soc15: skip reset on initAlex Deucher1-0/+5
Not necessary on soc15 and breaks driver reload on server cards. Acked-by: Amber Lin <Amber.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-05-20drm/amdgpu: keep stolen memory on picassoFlora Cui1-0/+1
otherwise screen corrupts during modprobe. Signed-off-by: Flora Cui <flora.cui@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-05-20drm/amdkfd: Add missing Polaris10 IDKent Russell1-0/+1
This was added to amdgpu but was missed in amdkfd Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.rg
2019-05-20drm/amd/display: Don't load DMCU for Raven 1Harry Wentland1-2/+10
[WHY] Some early Raven boards had a bad SBIOS that doesn't play nicely with the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU load but that doesn't seem to be the case. We've still seen reports of users unable to boot their systems at all. [HOW] Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-05-20drm/amd/display: Add ASICREV_IS_PICASSOHarry Wentland1-3/+4
[WHY] We only want to load DMCU FW on Picasso and Raven 2, not on Raven 1. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-05-20drm/i915: Truly bump ready tasks ahead of busywaitsChris Wilson1-19/+12
In commit b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits"), I tried cutting a corner in order to not install a signal for each of our dependencies, and only listened to requests on which we were intending to busywait. The compromise that was made was that instead of then being able to promote the request with a full NOSEMAPHORE like its non-busywaiting brethren, as we had not ensured we had cleared the semaphore chain, we settled for only using the NEWCLIENT boost. With an over saturated system with multiple NEWCLIENTS in flight at any time, this was found to be an inadequate promotion and left us with a much poorer scheduling order than prior to using semaphores. The outcome of this patch, is that all requests have NOSEMAPHORE priority when they have no dependencies and are ready to run and not busywait, restoring the pre-semaphore ordering on saturated systems. We can demonstrate the effect of poor scheduling order by oversaturating the system using gem_wsim on a system with multiple vcs engines (i.e running the same workloads across more clients than required for peak throughput, e.g. media_load_balance_17i7.wsim -c4 -b context): x v5.1 (normalized) + tip * fix +------------------------------------------------------------------------+ | x | | x | | x | | x | | %x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %%x | | %#x | | %#x | | %#x | | %#x | | %#x | | + %#xx | | + %#xx | | + %%#xx | | + %%#xx | | + %%#xx | | + %%#xx | | + %%##x | | +++ %%##x | | +++ %%##x | | +++ %%##x | | ++++ %%##x | | ++++ %%##x | | ++++ %%##xx | | ++++ %###xx | | ++++ %###xx | | ++++ %###xx | | ++++ %###xx | | ++++ + %#O#xx | | ++++ + %#O#xx | | ++++++ + %#O#xx | | ++++++++++ %OOOxxx| | ++++++++++ + %#OOO#xx| | + ++++++++++++ ++ +++++ + ++ @@OOOO#xx| | |A_| | ||__________M_______A____________________| | | |A_| | +------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 120 0.99456 1.00628 0.999985 1.0001545 0.0024387139 + 120 0.873021 1.00037 0.884134 0.90148752 0.039190862 Difference at 99.5% confidence -0.098667 +/- 0.0110762 -9.86517% +/- 1.10745% (Student's t, pooled s = 0.0277657) % 120 0.990207 1.00165 0.9970265 0.99699748 0.0021024 Difference at 99.5% confidence -0.003157 +/- 0.000908245 -0.315651% +/- 0.0908105% (Student's t, pooled s = 0.00227678) Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Dmitry Ermilov <dmitry.ermilov@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190515130052.4475-2-chris@chris-wilson.co.uk (cherry picked from commit 17db337f5098d29415314c4a588b842fc684394b) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-05-20drm/i915: Downgrade NEWCLIENT to non-preemptiveChris Wilson3-5/+4
Commit 1413b2bc0717 ("drm/i915: Trim NEWCLIENT boosting") had the intended consequence of not allowing a sequence of work that merely crossed into a new engine the privilege to be promoted to NEWCLIENT status. It also had the unintended consequence of actually making NEWCLIENT effective on heavily oversubscribed transcode machines and impacting upon their throughput. If we consider a client packet composed of (rcsA, rcsB, vcs) and 30 of those clients, using the NEWCLIENT boost that will be scheduled as rcsA x 30, (rcsB, vcs) x 30 where as before it would have been (rcsA, rcsB, vcs) x 30 That is with NEWCLIENT only boosting the first request of each client, we would execute all rcsA requests prior to running on the vcs engines; acruing a lot of dead time as compared to the previous case where the vcs engine would be started in parallel to processing the second client. The previous patch has the effect of delaying submission until it is required by a third party (either the user with an explicit wait, or by another client/engine). We reduce the NEWCLIENT bump to a mere WAIT, which has the effect of removing its preemptive grant and reducing it to the same level as any other user interaction -- that it will not be promoted above the interengine dependencies, and so preventing NEWCLIENTS from starving other engines. This a large nerf to the rrul properties of the current NEWCLIENT, but it still does give prioritised submission to new requests from light workloads. References: b16c765122f9 ("drm/i915: Priority boost for new clients") Fixes: 1413b2bc0717 ("drm/i915: Trim NEWCLIENT boosting") # customer impact Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Dmitry Ermilov <dmitry.ermilov@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190515130052.4475-4-chris@chris-wilson.co.uk (cherry picked from commit 68fc728b01fcc93b26d52f6e884e738962a49a66) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-05-20drm/i915: Bump signaler priority on adding a waiterChris Wilson4-14/+21
The handling of the no-preemption priority level imposes the restriction that we need to maintain the implied ordering even though preemption is disabled. Otherwise we may end up with an AB-BA deadlock across multiple engine due to a real preemption event reordering the no-preemption WAITs. To resolve this issue we currently promote all requests to WAIT on unsubmission, however this interferes with the timeslicing requirement that we do not apply any implicit promotion that will defeat the round-robin timeslice list. (If we automatically promote the active request it will go back to the head of the queue and not the tail!) So we need implicit promotion to prevent reordering around semaphores where we are not allowed to preempt, and we must avoid implicit promotion on unsubmission. So instead of at unsubmit, if we apply that implicit promotion on adding the dependency, we avoid the semaphore deadlock and we also reduce the gains made by the promotion for user space waiting. Furthermore, by keeping the earlier dependencies at a higher level, we reduce the search space for timeslicing without altering runtime scheduling too badly (no dependencies at all will be assigned a higher priority for rrul). v2: Limit the bump to external edges (as originally intended) i.e. between contexts and out to the user. Testcase: igt/gem_concurrent_blit Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190515130052.4475-3-chris@chris-wilson.co.uk (cherry picked from commit 6e7eb7a80769e7250e31652b96918cf7f3e0d285) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-04 01:17:37 +0300