aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-02-20RDMA/rw: Fix error flow during RDMA context initializationMax Gurtovoy1-11/+20
In case the SGL was mapped for P2P DMA operation, we must unmap it using pci_p2pdma_unmap_sg during the error unwind of rdma_rw_ctx_init() Fixes: 7f73eac3a713 ("PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Max Gurtovoy <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-20phy: ti: gmii-sel: do not fail in case of gmiiGrygorii Strashko1-0/+1
The "gmii" PHY interface mode is supported on TI AM335x/437x/5xx SoCs, so don't fail if it's selected. Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2020-02-20phy: ti: gmii-sel: fix set of copy-paste errorsGrygorii Strashko1-5/+4
- under PHY_INTERFACE_MODE_MII the 'mode' func parameter is assigned instead of 'gmii_sel_mode' and it's working only because the default value 'gmii_sel_mode' is set to 0. - console outputs use 'rgmii_id' and 'mode' values to print PHY mode instead of using 'submode' value which is representing PHY interface mode now. This patch fixes above two cases. Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2020-02-20Merge branch 'linux-5.6' of git://github.com/skeggsb/linux into drm-fixesDave Airlie5-0/+48
Nothing major here, another TU1xx modesetting fix, and hooking up ACR/GR support on TU11x now that NVIDIA have made the firmware available. Signed-off-by: Dave Airlie <[email protected]> From: Ben Skeggs <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv64yBq4KHJ8D-5HQ5eeotApJSMiD+V2ut4f3BonUggf0Q@mail.gmail.com
2020-02-19hwmon: (acpi_power_meter) Fix lockdep splatGuenter Roeck1-8/+8
Damien Le Moal reports a lockdep splat with the acpi_power_meter, observed with Linux v5.5 and later. ====================================================== WARNING: possible circular locking dependency detected 5.6.0-rc2+ #629 Not tainted ------------------------------------------------------ python/1397 is trying to acquire lock: ffff888619080070 (&resource->lock){+.+.}, at: show_power+0x3c/0xa0 [acpi_power_meter] but task is already holding lock: ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (kn->count#119){++++}: __kernfs_remove+0x626/0x7e0 kernfs_remove_by_name_ns+0x41/0x80 remove_attrs+0xcb/0x3c0 [acpi_power_meter] acpi_power_meter_notify+0x1f7/0x310 [acpi_power_meter] acpi_ev_notify_dispatch+0x198/0x1f3 acpi_os_execute_deferred+0x4d/0x70 process_one_work+0x7c8/0x1340 worker_thread+0x94/0xc70 kthread+0x2ed/0x3f0 ret_from_fork+0x24/0x30 -> #0 (&resource->lock){+.+.}: __lock_acquire+0x20be/0x49b0 lock_acquire+0x127/0x340 __mutex_lock+0x15b/0x1350 show_power+0x3c/0xa0 [acpi_power_meter] dev_attr_show+0x3f/0x80 sysfs_kf_seq_show+0x216/0x410 seq_read+0x407/0xf90 vfs_read+0x152/0x2c0 ksys_read+0xf3/0x1d0 do_syscall_64+0x95/0x1010 entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(kn->count#119); lock(&resource->lock); lock(kn->count#119); lock(&resource->lock); *** DEADLOCK *** 4 locks held by python/1397: #0: ffff8890242d64e0 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x9b/0xb0 #1: ffff889040be74e0 (&p->lock){+.+.}, at: seq_read+0x6b/0xf90 #2: ffff8890448eb880 (&of->mutex){+.+.}, at: kernfs_seq_start+0x47/0x160 #3: ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160 stack backtrace: CPU: 10 PID: 1397 Comm: python Not tainted 5.6.0-rc2+ #629 Hardware name: Supermicro Super Server/X11DPL-i, BIOS 3.1 05/21/2019 Call Trace: dump_stack+0x97/0xe0 check_noncircular+0x32e/0x3e0 ? print_circular_bug.isra.0+0x1e0/0x1e0 ? unwind_next_frame+0xb9a/0x1890 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe ? graph_lock+0x79/0x170 ? __lockdep_reset_lock+0x3c0/0x3c0 ? mark_lock+0xbc/0x1150 __lock_acquire+0x20be/0x49b0 ? mark_held_locks+0xe0/0xe0 ? stack_trace_save+0x91/0xc0 lock_acquire+0x127/0x340 ? show_power+0x3c/0xa0 [acpi_power_meter] ? device_remove_bin_file+0x10/0x10 ? device_remove_bin_file+0x10/0x10 __mutex_lock+0x15b/0x1350 ? show_power+0x3c/0xa0 [acpi_power_meter] ? show_power+0x3c/0xa0 [acpi_power_meter] ? mutex_lock_io_nested+0x11f0/0x11f0 ? lock_downgrade+0x6a0/0x6a0 ? kernfs_seq_start+0x47/0x160 ? lock_acquire+0x127/0x340 ? kernfs_seq_start+0x6a/0x160 ? device_remove_bin_file+0x10/0x10 ? show_power+0x3c/0xa0 [acpi_power_meter] show_power+0x3c/0xa0 [acpi_power_meter] dev_attr_show+0x3f/0x80 ? memset+0x20/0x40 sysfs_kf_seq_show+0x216/0x410 seq_read+0x407/0xf90 ? security_file_permission+0x16f/0x2c0 vfs_read+0x152/0x2c0 Problem is that reading an attribute takes the kernfs lock in the kernfs code, then resource->lock in the driver. During an ACPI notification, the opposite happens: The resource lock is taken first, followed by the kernfs lock when sysfs attributes are removed and re-created. Presumably this is now seen due to some locking related changes in kernfs after v5.4, but it was likely always a problem. Fix the problem by not blindly acquiring the lock in the notification function. It is only needed to protect the various update functions. However, those update functions are called anyway when sysfs attributes are read. This means that we can just stop calling those functions from the notifier, and the resource lock in the notifier function is no longer needed. That leaves two situations: First, METER_NOTIFY_CONFIG removes and re-allocates capability strings. While it did so under the resource lock, _displaying_ those strings was not protected, creating a race condition. To solve this problem, selectively protect both removal/creation and reporting of capability attributes with the resource lock. Second, removing and re-creating the attribute files is no longer protected by the resource lock. That doesn't matter since access to each individual attribute is protected by the kernfs lock. Userspace may get messed up if attributes disappear and reappear under its nose, but that is not different than today, and there is nothing we can do about it without major driver restructuring. Last but not least, when removing the driver, remove attribute functions first, then release capability strings. This avoids yet another race condition. Reported-by: Damien Le Moal <[email protected]> Cc: Damien Le Moal <[email protected]> Cc: [email protected] # v5.5+ Tested-by: Damien Le Moal <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-02-20Merge tag 'drm-msm-fixes-2020-02-16' of ↵Dave Airlie9-100/+170
https://gitlab.freedesktop.org/drm/msm into drm-fixes + fix UBWC on GPU and display side for sc7180 + fix DSI suspend/resume issue encountered on sc7180 + fix some breakage on so called "linux-android" devices (fallout from sc7180/a618 support, not seen earlier due to bootloader/firmware differences) + couple other misc fixes Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGshz5K3tJd=NsBSHq6HGT-ZRa67qt+iN=U2ZFO2oD8kuw@mail.gmail.com
2020-02-20Merge tag 'amd-drm-fixes-5.6-2020-02-19' of ↵Dave Airlie7-13/+55
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.6-2020-02-19: amdgpu: - HDCP fixes - xclk fix for raven - GFXOFF fixes Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-19backlight: add led-backlight driverTomi Valkeinen3-0/+268
This patch adds a led-backlight driver (led_bl), which is similar to pwm_bl except the driver uses a LED class driver to adjust the brightness in the HW. Multiple LEDs can be used for a single backlight. Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Jean-Jacques Hiblot <[email protected]> Acked-by: Pavel Machek <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Acked-by: Lee Jones <[email protected]> Acked-by: Tony Lindgren <[email protected]> Tested-by: Tony Lindgren <[email protected]> Tested-by: Guido Günther <[email protected]> Signed-off-by: Pavel Machek <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2020-02-19RDMA/core: Fix use of logical OR in get_new_ppsNathan Chancellor1-1/+1
Clang warns: ../drivers/infiniband/core/security.c:351:41: warning: converting the enum constant to a boolean [-Wint-in-bool-context] if (!(qp_attr_mask & (IB_QP_PKEY_INDEX || IB_QP_PORT)) && qp_pps) { ^ 1 warning generated. A bitwise OR should have been used instead. Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in get_pkey_idx_qp_list") Link: https://lore.kernel.org/r/[email protected] Link: https://github.com/ClangBuiltLinux/linux/issues/889 Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-19ice: Wait for VF to be reset/ready before configurationBrett Creeley2-61/+76
The configuration/command below is failing when the VF in the xml file is already bound to the host iavf driver. pci_0000_af_0_0.xml: <interface type='hostdev' managed='yes'> <source> <address type='pci' domain='0x0000' bus='0xaf' slot='0x0' function='0x0'/> </source> <mac address='00:de:ad:00:11:01'/> </interface> > virsh attach-device domain_name pci_0000_af_0_0.xml error: Failed to attach device from pci_0000_af_0_0.xml error: Cannot set interface MAC/vlanid to 00:de:ad:00:11:01/0 for ifname ens1f1 vf 0: Device or resource busy This is failing because the VF has not been completely removed/reset after being unbound (via the virsh command above) from the host iavf driver and ice_set_vf_mac() checks if the VF is disabled before waiting for the reset to finish. Fix this by waiting for the VF remove/reset process to happen before checking if the VF is disabled. Also, since many functions for VF administration on the PF were more or less calling the same 3 functions (ice_wait_on_vf_reset(), ice_is_vf_disabled(), and ice_check_vf_init()) move these into the helper function ice_check_vf_ready_for_cfg(). Then call this function in any flow that attempts to configure/query a VF from the PF. Lastly, increase the maximum wait time in ice_wait_on_vf_reset() to 800ms, and modify/add the #define(s) that determine the wait time. This was done for robustness because in rare/stress cases VF removal can take a max of ~800ms and previously the wait was a max of ~300ms. Signed-off-by: Brett Creeley <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2020-02-19ice: Don't tell the OS that link is going downMichal Swiatkowski1-7/+0
Remove code that tell the OS that link is going down when user change flow control via ethtool. When link is up it isn't certain that link goes down after 0x0605 aq command. If link doesn't go down, OS thinks that link is down, but physical link is up. To reset this state user have to take interface down and up. If link goes down after 0x0605 command, FW send information about that and after that driver tells the OS that the link goes down. So this code in ethtool is unnecessary. Signed-off-by: Michal Swiatkowski <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2020-02-19ice: Don't reject odd values of usecs set by userBrett Creeley2-12/+39
Currently if a user sets an odd [tx|rx]-usecs value through ethtool, the request is denied because the hardware is set to have an ITR granularity of 2us. This caused poor customer experience. Fix this by aligning to a register allowed value, which results in rounding down. Also, print a once per ring container type message to be clear about our intentions. Also, change the ITR_TO_REG define to be the bitwise and of the ITR setting and the ICE_ITR_MASK. This makes the purpose of ITR_TO_REG more obvious. Signed-off-by: Brett Creeley <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2020-02-19nfc: pn544: Fix occasional HW initialization failureDmitry Osipenko1-0/+1
The PN544 driver checks the "enable" polarity during of driver's probe and it's doing that by turning ON and OFF NFC with different polarities until enabling succeeds. It takes some time for the hardware to power-down, and thus, to deassert the IRQ that is raised by turning ON the hardware. Since the delay after last power-down of the polarity-checking process is missed in the code, the interrupt may trigger immediately after installing the IRQ handler (right after the checking is done), which results in IRQ handler trying to touch the disabled HW and ends with marking NFC as 'DEAD' during of the driver's probe: pn544_hci_i2c 1-002a: NFC: nfc_en polarity : active high pn544_hci_i2c 1-002a: NFC: invalid len byte shdlc: llc_shdlc_recv_frame: NULL Frame -> link is dead This patch fixes the occasional NFC initialization failure on Nexus 7 device. Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-19Revert "RDMA/cma: Simplify rdma_resolve_addr() error flow"Parav Pandit1-4/+11
This reverts commit 219d2e9dfda9431b808c28d5efc74b404b95b638. The call chain below requires the cm_id_priv's destination address to be setup before performing rdma_bind_addr(). Otherwise source port allocation fails as cma_port_is_unique() no longer sees the correct tuple to allow duplicate users of the source port. rdma_resolve_addr() cma_bind_addr() rdma_bind_addr() cma_get_port() cma_alloc_any_port() cma_port_is_unique() <- compared with zero daddr This can result in false failures to connect, particularly if the source port range is restricted. Fixes: 219d2e9dfda9 ("RDMA/cma: Simplify rdma_resolve_addr() error flow") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Parav Pandit <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-19Merge tag 'iommu-fixes-v5.6-rc2' of ↵Linus Torvalds4-36/+50
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Compile warning fix for the Intel IOMMU driver - Fix kdump boot with Intel IOMMU enabled and in passthrough mode - Disable AMD IOMMU on a Laptop/Embedded platform because the delay it introduces in DMA transactions causes screen flickering there with 4k monitors - Make domain_free function in QCOM IOMMU driver robust and not leak memory/dereference NULL pointers - Fix ARM-SMMU module parameter prefix names * tag 'iommu-fixes-v5.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/arm-smmu: Restore naming of driver parameter prefix iommu/qcom: Fix bogus detach logic iommu/amd: Disable IOMMU on Stoney Ridge systems iommu/vt-d: Simplify check in identity_mapping() iommu/vt-d: Remove deferred_attach_domain() iommu/vt-d: Do deferred attachment in iommu_need_mapping() iommu/vt-d: Move deferred device attachment into helper function iommu/vt-d: Add attach_deferred() helper iommu/vt-d: Fix compile warning from intel-svm.h
2020-02-20nvme: Fix uninitialized-variable warningKeith Busch1-1/+1
gcc may detect a false positive on nvme using an unintialized variable if setting features fails. Since this is not a fast path, explicitly initialize this variable to suppress the warning. Reported-by: Arnd Bergmann <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2020-02-19s390/qdio: fill SBALEs with absolute addressesJulian Wiedmann4-18/+19
sbale->addr holds an absolute address (or for some FCP usage, an opaque request ID), and should only be used with proper virt/phys translation. Signed-off-by: Julian Wiedmann <[email protected]> Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2020-02-19s390/qdio: fill SL with absolute addressesJulian Wiedmann2-13/+13
As the comment says, sl->sbal holds an absolute address. qeth currently solves this through wild casting, while zfcp doesn't care. Handle this properly in the code that actually builds the SL. Signed-off-by: Julian Wiedmann <[email protected]> Reviewed-by: Alexandra Winter <[email protected]> Reviewed-by: Steffen Maier <[email protected]> [for qdio] Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2020-02-19drm/amdgpu/display: clean up hdcp workqueue handlingAlex Deucher1-4/+6
Use the existence of the workqueue itself to determine when to enable HDCP features rather than sprinkling asic checks all over the code. Also add a check for the existence of the hdcp workqueue in the irq handling on the off chance we get and HPD RX interrupt with the CP bit set. This avoids a crash if the driver doesn't support HDCP for a particular asic. Fixes: 96a3b32e67236f ("drm/amd/display: only enable HDCP for DCN+") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206519 Reviewed-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-19drm/amdgpu: add is_raven_kicker judgement for raven1changzhu1-2/+9
The rlc version of raven_kicer_rlc is different from the legacy rlc version of raven_rlc. So it needs to add a judgement function for raven_kicer_rlc and avoid disable GFXOFF when loading raven_kicer_rlc. Signed-off-by: changzhu <[email protected]> Reviewed-by: Huang Rui <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-02-20nvme-pci: Use single IRQ vector for old Apple modelsAndy Shevchenko1-1/+2
People reported that old Apple machines are not working properly if the non-first IRQ vector is in use. Set quirk for that models to limit IRQ to use first vector only. Based on original patch by GitHub user npx001. Link: https://github.com/Dunedan/mbp-2016-linux/issues/9 Cc: Benjamin Herrenschmidt <[email protected]> Cc: Leif Liddy <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2020-02-20nvme/pci: Add sleep quirk for Samsung and Toshiba drivesShyjumon N1-0/+12
The Samsung SSD SM981/PM981 and Toshiba SSD KBG40ZNT256G on the Lenovo C640 platform experience runtime resume issues when the SSDs are kept in sleep/suspend mode for long time. This patch applies the 'Simple Suspend' quirk to these configurations. With this patch, the issue had not been observed in a 1+ day test. Reviewed-by: Jon Derrick <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Shyjumon N <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2020-02-19iommu/arm-smmu: Restore naming of driver parameter prefixWill Deacon1-2/+2
Extending the Arm SMMU driver to allow for modular builds changed KBUILD_MODNAME to be "arm_smmu_mod" so that a single module could be built from the multiple existing object files without the need to rename any source files. This inadvertently changed the name of the driver parameters, which may lead to runtime issues if bootloaders are relying on the old names for correctness (e.g. "arm-smmu.disable_bypass=0"). Although MODULE_PARAM_PREFIX can be overridden to restore the old naming for builtin parameters, only the new name is matched by modprobe and so loading the driver as a module would cause parameters specified on the kernel command line to be ignored. Instead, rename "arm_smmu_mod" to "arm_smmu". Whilst it's a bit of a bodge, this allows us to create a single module without renaming any files and makes use of the fact that underscores and hyphens can be used interchangeably in parameter names. Cc: Robin Murphy <[email protected]> Cc: Russell King <[email protected]> Reported-by: Li Yang <[email protected]> Fixes: cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module") Signed-off-by: Will Deacon <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-02-19iommu/qcom: Fix bogus detach logicRobin Murphy1-16/+12
Currently, the implementation of qcom_iommu_domain_free() is guaranteed to do one of two things: WARN() and leak everything, or dereference NULL and crash. That alone is terrible, but in fact the whole idea of trying to track the liveness of a domain via the qcom_domain->iommu pointer as a sanity check is full of fundamentally flawed assumptions. Make things robust and actually functional by not trying to be quite so clever. Reported-by: Brian Masney <[email protected]> Tested-by: Brian Masney <[email protected]> Reported-by: Naresh Kamboju <[email protected]> Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Signed-off-by: Robin Murphy <[email protected]> Tested-by: Stephan Gerhold <[email protected]> Cc: [email protected] # v4.14+ Signed-off-by: Joerg Roedel <[email protected]>
2020-02-19phy: core: Fix phy_get() to not return error on link creation failureKishon Vijay Abraham I1-12/+6
commit 987351e1ea77 ("phy: core: Add consumer device link support") added device link support between PHY consumer and PHY provider. However certain peripherals (DWC3 ULPI) have cyclic dependency between the PHY provider and PHY consumer causing the device link creation to fail. Instead of erroring out on failure to create device link, only add a debug print to indicate device link creation failed to get USB working again in multiple platforms. Fixes: 987351e1ea77 ("phy: core: Add consumer device link support") Cc: Alexandre Torgue <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]> Reviewed-by: Alexandre TORGUE <[email protected]>
2020-02-19phy: mapphone-mdm6600: Fix write timeouts with shorter GPIO toggle intervalTony Lindgren1-1/+8
I've noticed that when writing data to the modem the writes can time out at some point eventually. Looks like kicking the modem idle GPIO every 600 ms instead of once a second fixes the issue. Note that this rate is different from our runtime PM autosuspend rate MDM6600_MODEM_IDLE_DELAY_MS that we still want to keep at 1 second, so let's add a separate define for PHY_MDM6600_IDLE_KICK_MS. Fixes: f7f50b2a7b05 ("phy: mapphone-mdm6600: Add runtime PM support for n_gsm on USB suspend") Cc: Marcel Partap <[email protected]> Cc: Merlijn Wajer <[email protected]> Cc: Michael Scott <[email protected]> Cc: NeKit <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Sebastian Reichel <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2020-02-19iommu/amd: Disable IOMMU on Stoney Ridge systemsKai-Heng Feng1-1/+12
Serious screen flickering when Stoney Ridge outputs to a 4K monitor. Use identity-mapping and PCI ATS doesn't help this issue. According to Alex Deucher, IOMMU isn't enabled on Windows, so let's do the same here to avoid screen flickering on 4K monitor. Cc: Alex Deucher <[email protected]> Bug: https://gitlab.freedesktop.org/drm/amd/issues/961 Signed-off-by: Kai-Heng Feng <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-02-19dmaengine: idxd: correct reserved token calculationDave Jiang1-1/+1
The calcuation for limit of reserved token did not take into account the change the user wanted vs the current group reserved token. This causes changing of the reserved token to be possible only after we set the value of the reserved token back to 0. Fix calculation so we can set a value that is non zero for reserved token. Fixes: c52ca478233c ("dmaengine: idxd: add configuration component of driver") Reported-by: Jerry Chen <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/158204471889.37789.7749177228265869168.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <[email protected]>
2020-02-19dmaengine: ti: k3-udma: Fix terminated transfer handlingPeter Ujfalusi1-14/+15
When we receive back the descriptor of the terminated transfer the cookie must be marked as completed to make sure that the accounting is correct. In udma_tx_status() the status should be marked as completed if the channel is no longer running (it can only happen if the channel is not yet started for the first time, or after a channel termination). Fixes: 25dcb5dd7b7ce ("dmaengine: ti: New driver for K3 UDMA") Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-02-19dmaengine: ti: k3-udma: Use the channel direction in pause/resume functionsPeter Ujfalusi1-9/+3
It should be possible to pause, resume and check the pause state of a channel even if we do not have active transfer. udma_is_chan_paused() can trigger NULL pointer reference in it's current form when the status is checked while uc->desc is NULL. Fixes: 25dcb5dd7b7ce ("dmaengine: ti: New driver for K3 UDMA") Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-02-19dmaengine: ti: k3-udma: Use the TR counter helper for slave_sg and cyclicPeter Ujfalusi1-42/+88
Use the generic TR setup function to get the TR counters for both cyclic and slave_sg transfers. This way the period_size for cyclic and sg_dma_len() for slave_sg can be as large as (SZ_64K - 1) * (SZ_64K - 1) and we can handle cases when the length is >SZ_64K and a prime number. Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-02-19dmaengine: ti: k3-udma: Move the TR counter calculation to helper functionPeter Ujfalusi1-23/+51
Move the TR counter parameter configuration code out from the prep_memcpy callback to a helper function to allow a generic re-usable code for other TR based transfers. Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-02-19dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peerPeter Ujfalusi1-17/+151
When a channel is asked to be stopped (teardown) and we do not have active descriptor to receive stale data buffered on the remote side then the teardown will not complete as UDMA needs a descriptor to be able to flush out the DMA pipe. The peer is trying to push the data to UDMA in teardown, but UDMA is pushing back because it has no descriptor which would allow it to drain the data. The workaround is to create 1K 'trashcan' to receive the discarded data and set up descriptors for packet and TR mode channels. When a channel is stopped and there is no active descriptor then a descriptor is pushed to the ring for UDMA before the teardown is initiated. Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-02-19dmaengine: ti: k3-udma: Use ktime/usleep_range based TX completion checkVignesh Raghavendra1-27/+53
In some cases (McSPI for example) the jiffie and delayed_work based workaround can cause big throughput drop. Switch to use ktime/usleep_range based implementation to be able to sustain speed for PDMA based peripherals. Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-02-18net/mlx5: DR, Handle reformat capability over sw-steering tablesErez Shitrit1-2/+7
On flow table creation, send the relevant flags according to what the FW currently supports. When FW doesn't support reformat option over SW-steering managed table, the driver shouldn't pass this. Fixes: 988fd6b32d07 ("net/mlx5: DR, Pass table flags at creation to lower layer") Signed-off-by: Erez Shitrit <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-02-18net/mlx5: Fix lowest FDB pool sizePaul Blakey1-1/+1
The pool sizes represent the pool sizes in the fw. when we request a pool size from fw, it will return the next possible group. We track how many pools the fw has left and start requesting groups from the big to the small. When we start request 4k group, which doesn't exists in fw, fw wants to allocate the next possible size, 64k, but will fail since its exhausted. The correct smallest pool size in fw is 128 and not 4k. Fixes: 39ac237ce009 ("net/mlx5: E-Switch, Refactor chains and priorities") Signed-off-by: Paul Blakey <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-02-18net/mlx5e: Don't clear the whole vf config when switching modesDmytro Linkin2-3/+7
There is no need to reset all vf config (except link state) between legacy and switchdev modes changes. Also, set link state to AUTO, when legacy enabled. Fixes: 3b83b6c2e024 ("net/mlx5e: Clear VF config when switching modes") Signed-off-by: Dmytro Linkin <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-02-18net/mlx5: DR, Fix matching on vport gvmiHamdan Igbaria1-1/+4
Set vport gvmi in the tag, only when source gvmi is set in the bit mask. Fixes: 26d688e3 ("net/mlx5: DR, Add Steering entry (STE) utilities") Signed-off-by: Hamdan Igbaria <[email protected]> Reviewed-by: Alex Vesker <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-02-18net/mlx5e: Fix crash in recovery flow without devlink reporterAya Levin1-1/+1
When health reporters are not supported, recovery function is invoked directly, not via devlink health reporters. In this direct flow, the recover function input parameter was passed incorrectly and is causing a kernel oops. This patch is fixing the input parameter. Following call trace is observed on rx error health reporting. Internal error: Oops: 96000007 [#1] PREEMPT SMP Process kworker/u16:4 (pid: 4584, stack limit = 0x00000000c9e45703) Call trace: mlx5e_rx_reporter_err_rq_cqe_recover+0x30/0x164 [mlx5_core] mlx5e_health_report+0x60/0x6c [mlx5_core] mlx5e_reporter_rq_cqe_err+0x6c/0x90 [mlx5_core] mlx5e_rq_err_cqe_work+0x20/0x2c [mlx5_core] process_one_work+0x168/0x3d0 worker_thread+0x58/0x3d0 kthread+0x108/0x134 Fixes: c50de4af1d63 ("net/mlx5e: Generalize tx reporter's functionality") Signed-off-by: Aya Levin <[email protected]> Signed-off-by: Parav Pandit <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-02-18net/mlx5e: Reset RQ doorbell counter before moving RQ state from RST to RDYAya Levin4-9/+43
Initialize RQ doorbell counters to zero prior to moving an RQ from RST to RDY state. Per HW spec, when RQ is back to RDY state, the descriptor ID on the completion is reset. The doorbell record must comply. Fixes: 8276ea1353a4 ("net/mlx5e: Report and recover from CQE with error on RQ") Signed-off-by: Aya Levin <[email protected]> Reported-by: Tariq Toukan <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-02-18net/mlx5: Fix sleep while atomic in mlx5_eswitch_get_vepaHuy Nguyen1-11/+3
rtnl_bridge_getlink is protected by rcu lock, so mlx5_eswitch_get_vepa cannot take mutex lock. Two possible issues can happen: 1. User at the same time change vepa mode via RTM_SETLINK command. 2. User at the same time change the switchdev mode via devlink netlink interface. Case 1 cannot happen because rtnl executes one message in order. Case 2 can happen but we do not expect user to change the switchdev mode when changing vepa. Even if a user does it, so he will read a value which is no longer valid. Fixes: 8da202b24913 ("net/mlx5: E-Switch, Add support for VEPA in legacy mode.") Signed-off-by: Huy Nguyen <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-02-18net: phy: broadcom: Fix a typo ("firsly")Jonathan Neuschäfer1-2/+2
Signed-off-by: Jonathan Neuschäfer <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-18qede: Fix race between rdma destroy workqueue and link change eventMichal Kalderon2-1/+30
If an event is added while the rdma workqueue is being destroyed it could lead to several races, list corruption, null pointer dereference during queue_work or init_queue. This fixes the race between the two flows which can occur during shutdown. A kref object and a completion object are added to the rdma_dev structure, these are initialized before the workqueue is created. The refcnt is used to indicate work is being added to the workqueue and ensures the cleanup flow won't start while we're in the middle of adding the event. Once the work is added, the refcnt is decreased and the cleanup flow is safe to run. Fixes: cee9fbd8e2e ("qede: Add qedr framework") Signed-off-by: Ariel Elior <[email protected]> Signed-off-by: Michal Kalderon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-18iommu/vt-d: Simplify check in identity_mapping()Joerg Roedel1-1/+1
The function only has one call-site and there it is never called with dummy or deferred devices. Simplify the check in the function to account for that. Fixes: 1ee0186b9a12 ("iommu/vt-d: Refactor find_domain() helper") Cc: [email protected] # v5.5 Reviewed-by: Jerry Snitselaar <[email protected]> Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-02-18iommu/vt-d: Remove deferred_attach_domain()Joerg Roedel1-8/+3
The function is now only a wrapper around find_domain(). Remove the function and call find_domain() directly at the call-sites. Fixes: 1ee0186b9a12 ("iommu/vt-d: Refactor find_domain() helper") Cc: [email protected] # v5.5 Reviewed-by: Jerry Snitselaar <[email protected]> Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-02-18iommu/vt-d: Do deferred attachment in iommu_need_mapping()Joerg Roedel1-3/+7
The attachment of deferred devices needs to happen before the check whether the device is identity mapped or not. Otherwise the check will return wrong results, cause warnings boot failures in kdump kernels, like WARNING: CPU: 0 PID: 318 at ../drivers/iommu/intel-iommu.c:592 domain_get_iommu+0x61/0x70 [...] Call Trace: __intel_map_single+0x55/0x190 intel_alloc_coherent+0xac/0x110 dmam_alloc_attrs+0x50/0xa0 ahci_port_start+0xfb/0x1f0 [libahci] ata_host_start.part.39+0x104/0x1e0 [libata] With the earlier check the kdump boot succeeds and a crashdump is written. Fixes: 1ee0186b9a12 ("iommu/vt-d: Refactor find_domain() helper") Cc: [email protected] # v5.5 Reviewed-by: Jerry Snitselaar <[email protected]> Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-02-18iommu/vt-d: Move deferred device attachment into helper functionJoerg Roedel1-8/+12
Move the code that does the deferred device attachment into a separate helper function. Fixes: 1ee0186b9a12 ("iommu/vt-d: Refactor find_domain() helper") Cc: [email protected] # v5.5 Reviewed-by: Jerry Snitselaar <[email protected]> Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-02-18iommu/vt-d: Add attach_deferred() helperJoerg Roedel1-4/+8
Implement a helper function to check whether a device's attach process is deferred. Fixes: 1ee0186b9a12 ("iommu/vt-d: Refactor find_domain() helper") Cc: [email protected] # v5.5 Reviewed-by: Jerry Snitselaar <[email protected]> Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-02-18HID: hid-bigbenff: fix race condition for scheduled work during removalHanno Zulla1-0/+6
It's possible that there is scheduled work left while the device is already being removed, which can cause a kernel crash. Adding a flag will avoid this. Signed-off-by: Hanno Zulla <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]>
2020-02-18HID: hid-bigbenff: call hid_hw_stop() in case of errorHanno Zulla1-5/+10
It's required to call hid_hw_stop() once hid_hw_start() was called previously, so error cases need to handle this. Also, hid_hw_close() is not necessary during removal. Signed-off-by: Hanno Zulla <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.