summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-01-07net/mlx5: Use port_num 1 instead of 0 when delete a RoCE addressMark Zhang1-1/+1
In multi-port mode, FW reports syndrome 0x2ea48 (invalid vhca_port_number) if the port_num is not 1 or 2. Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic") Signed-off-by: Mark Zhang <markzhang@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-01-07net/mlx5e: Add missing capability check for uplink followAya Levin1-1/+2
Expose firmware indication that it supports setting eswitch uplink state to follow (follow the physical link). Condition setting the eswitch uplink admin-state with this capability bit. Older FW may not support the uplink state setting. Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-01-07net/mlx5: Check if lag is supported before creating oneMark Zhang1-6/+5
This patch fixes a memleak issue by preventing to create a lag and add PFs if lag is not supported. comm “python3”, pid 349349, jiffies 4296985507 (age 1446.976s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<000000005b216ae7>] mlx5_lag_add+0x1d5/0×3f0 [mlx5_core] [<000000000445aa55>] mlx5e_nic_enable+0x66/0×1b0 [mlx5_core] [<00000000c56734c3>] mlx5e_attach_netdev+0x16e/0×200 [mlx5_core] [<0000000030439d1f>] mlx5e_attach+0x5c/0×90 [mlx5_core] [<0000000018fd8615>] mlx5e_add+0x1a4/0×410 [mlx5_core] [<0000000068bc504b>] mlx5_add_device+0x72/0×120 [mlx5_core] [<000000009fce51f9>] mlx5_register_device+0x77/0xb0 [mlx5_core] [<00000000d0d81ff3>] mlx5_load_one+0xc58/0×1eb0 [mlx5_core] [<0000000045077adc>] init_one+0x3ea/0×920 [mlx5_core] [<0000000043287674>] pci_device_probe+0xcd/0×150 [<00000000dafd3279>] really_probe+0x1c9/0×4b0 [<00000000f06bdd84>] driver_probe_device+0x5d/0×140 [<00000000e3d508b6>] device_driver_attach+0x4f/0×60 [<0000000084fba0f0>] bind_store+0xbf/0×120 [<00000000bf6622b3>] kernfs_fop_write+0x114/0×1b0 Fixes: 9b412cc35f00 ("net/mlx5e: Add LAG warning if bond slave is not lag master") Signed-off-by: Mark Zhang <markzhang@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-01-07Merge tag 'spi-fix-v5.11-rc2' of ↵Linus Torvalds4-21/+104
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A couple of core fixes here, both to do with handling of drivers which don't report their maximum speed since we factored some of the handling for transfer speeds out into the core in the previous release. There's also some driver specific fixes, including a relatively large set for some races around timeouts in spi-geni-qcom" * tag 'spi-fix-v5.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: fix the divide by 0 error when calculating xfer waiting time spi: Fix the clamping of spi->max_speed_hz spi: altera: fix return value for altera_spi_txrx() spi: stm32: FIFO threshold level - fix align packet size spi: spi-geni-qcom: Print an error when we timeout setting the CS spi: spi-geni-qcom: Don't try to set CS if an xfer is pending spi: spi-geni-qcom: Fail new xfers if xfer/cancel/abort pending spi: spi-geni-qcom: Fix geni_spi_isr() NULL dereference in timeout case
2021-01-07Merge tag 'regulator-fix-v5.11-rc2' of ↵Linus Torvalds4-3/+65
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "A few minor driver specific fixes, mostly DT bindings document bits, plus a new device ID" * tag 'regulator-fix-v5.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: qcom-rpmh: add QCOM_COMMAND_DB dependency regulator: qcom-rpmh-regulator: correct hfsmps515 definition dt-bindings: regulator: qcom,rpmh-regulator: add pm8009 revision regulator: bd718x7: Add enable times regulator: pf8x00: Use specific compatible strings for devices
2021-01-07Merge tag 'regmap-fix-v5.11-rc2' of ↵Linus Torvalds1-2/+7
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fixes from Mark Brown: "A couple of small fixes for leaks when attaching a device to a preexisting regmap" * tag 'regmap-fix-v5.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: debugfs: Fix a reversed if statement in regmap_debugfs_init() regmap: debugfs: Fix a memory leak when calling regmap_attach_dev
2021-01-07misc: pvpanic: Check devm_ioport_map() for NULLAndy Shevchenko1-4/+15
Inconveniently devm_ioport_map() and devm_ioremap_resource() return errors differently, i.e. former uses simply NULL pointer, while the latter an error pointer. Due to this, we have to check each of them separately. Fixes: f104060813fe ("misc: pvpanic: Combine ACPI and platform drivers") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201228184313.57610-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-07drm/msm: Only enable A6xx LLCC code on A6xxKonrad Dybcio2-9/+17
Using this code on A5xx (and probably older too) causes a smmu bug. Fixes: 474dadb8b0d5 ("drm/msm/a6xx: Add support for using system cache(LLC)") Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-07cpufreq: intel_pstate: remove obsolete functionsLukas Bulwahn1-10/+0
percent_fp() was used in intel_pstate_pid_reset(), which was removed in commit 9d0ef7af1f2d ("cpufreq: intel_pstate: Do not use PID-based P-state selection") and hence, percent_fp() is unused since then. percent_ext_fp() was last used in intel_pstate_update_perf_limits(), which was refactored in commit 1a4fe38add8b ("cpufreq: intel_pstate: Remove max/min fractions to limit performance"), and hence, percent_ext_fp() is unused since then. make CC=clang W=1 points us those unused functions: drivers/cpufreq/intel_pstate.c:79:23: warning: unused function 'percent_fp' [-Wunused-function] static inline int32_t percent_fp(int percent) ^ drivers/cpufreq/intel_pstate.c:94:23: warning: unused function 'percent_ext_fp' [-Wunused-function] static inline int32_t percent_ext_fp(int percent) ^ Remove those obsolete functions. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-07drm/msm: Add modparam to allow vram carveoutIskren Chernev5-6/+17
Using the GPU with a VRAM Carveout is a security vulnerability. Nevertheless it is sometimes required, especially when no IOMMU implementation is available for a certain platform. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-07drm/msm: Call msm_init_vram before binding the gpuCraig Tatlor1-4/+4
vram.size is needed when binding a gpu without an iommu and is defined in msm_init_vram(), so run that before binding it. Signed-off-by: Craig Tatlor <ctatlor97@gmail.com> Reviewed-by: Brian Masney <masneyb@onstation.org> Tested-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-07drm/msm/dp: postpone irq_hpd event during connection pending stateKuogee Hsieh2-3/+16
irq_hpd event can only be executed at connected state. Therefore irq_hpd event should be postponed if it happened at connection pending state. This patch also make sure both link rate and lane are valid before start link training. Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-01-07device property: add description of fwnode casesBard Liao1-0/+7
There are only four valid fwnode cases which are - primary --> secondary --> -ENODEV - primary --> NULL - secondary --> -ENODEV - NULL dev->fwnode should be converted between the 4 cases above no matter how/when set_primary_fwnode() and set_secondary_fwnode() are called. Describe it in the code so people will keep it in mind. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> [ rjw: Comment edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-07Revert "device property: Keep secondary firmware node secondary by type"Bard Liao1-1/+1
While commit d5dcce0c414f ("device property: Keep secondary firmware node secondary by type") describes everything correct in its commit message, the change it made does the opposite and original commit c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") was fully correct. Revert the former one here and improve documentation in the next patch. Fixes: d5dcce0c414f ("device property: Keep secondary firmware node secondary by type") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-07ACPI: Update Kconfig help text for items that are no longer modularPeter Robinson1-6/+0
The CONTAINER and HOTPLUG_MEMORY options mention modules but are bool only, so if selected are always built in. Drop the help text about modules. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-07ACPI: PM: s2idle: Drop unused local variables and related codeRafael J. Wysocki1-13/+1
Two local variables in drivers/acpi/x86/s2idle.c are never read, so drop them along with the code updating their values (in vain). Fixes: fef98671194b ("ACPI: PM: s2idle: Move x86-specific code to the x86 directory") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-07cpufreq: powernow-k8: pass policy rather than use cpufreq_cpu_get()Colin Ian King1-6/+3
Currently there is an unlikely case where cpufreq_cpu_get() returns a NULL policy and this will cause a NULL pointer dereference later on. Fix this by passing the policy to transition_frequency_fidvid() from the caller and hence eliminating the need for the cpufreq_cpu_get() and cpufreq_cpu_put(). Thanks to Viresh Kumar for suggesting the fix. Addresses-Coverity: ("Dereference null return") Fixes: b43a7ffbf33b ("cpufreq: Notify all policy->cpus in cpufreq_notify_transition()") Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-07cpufreq: intel_pstate: Use HWP capabilities in intel_cpufreq_adjust_perf()Rafael J. Wysocki1-2/+3
If turbo P-states cannot be used, either due to the configuration of the processor, or because intel_pstate is not allowed to used them, the maximum available P-state with HWP enabled corresponds to the HWP_CAP.GUARANTEED value which is not static. It can be adjusted by an out-of-band agent or during an Intel Speed Select performance level change, so long as it remains less than or equal to HWP_CAP.MAX. However, if turbo P-states cannot be used, intel_cpufreq_adjust_perf() always uses pstate.max_pstate (set during the initialization of the driver only) as the maximum available P-state, so it may miss a change of the HWP_CAP.GUARANTEED value. Prevent that from happening by modifyig intel_cpufreq_adjust_perf() to always read the "guaranteed" and "maximum turbo" performance levels from the cached HWP_CAP value. Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2021-01-07iommu/vt-d: Fix ineffective devTLB invalidation for subdevicesLiu Yi L1-16/+37
iommu_flush_dev_iotlb() is called to invalidate caches on a device but only loops over the devices which are fully-attached to the domain. For sub-devices, this is ineffective and can result in invalid caching entries left on the device. Fix the missing invalidation by adding a loop over the subdevices and ensuring that 'domain->has_iotlb_device' is updated when attaching to subdevices. Fixes: 67b8e02b5e76 ("iommu/vt-d: Aux-domain specific domain attach/detach") Signed-off-by: Liu Yi L <yi.l.liu@intel.com> Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/1609949037-25291-4-git-send-email-yi.l.liu@intel.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-07iommu/vt-d: Fix general protection fault in aux_detach_device()Liu Yi L1-24/+71
The aux-domain attach/detach are not tracked, some data structures might be used after free. This causes general protection faults when multiple subdevices are created and assigned to a same guest machine: | general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] SMP NOPTI | RIP: 0010:intel_iommu_aux_detach_device+0x12a/0x1f0 | [...] | Call Trace: | iommu_aux_detach_device+0x24/0x70 | vfio_mdev_detach_domain+0x3b/0x60 | ? vfio_mdev_set_domain+0x50/0x50 | iommu_group_for_each_dev+0x4f/0x80 | vfio_iommu_detach_group.isra.0+0x22/0x30 | vfio_iommu_type1_detach_group.cold+0x71/0x211 | ? find_exported_symbol_in_section+0x4a/0xd0 | ? each_symbol_section+0x28/0x50 | __vfio_group_unset_container+0x4d/0x150 | vfio_group_try_dissolve_container+0x25/0x30 | vfio_group_put_external_user+0x13/0x20 | kvm_vfio_group_put_external_user+0x27/0x40 [kvm] | kvm_vfio_destroy+0x45/0xb0 [kvm] | kvm_put_kvm+0x1bb/0x2e0 [kvm] | kvm_vm_release+0x22/0x30 [kvm] | __fput+0xcc/0x260 | ____fput+0xe/0x10 | task_work_run+0x8f/0xb0 | do_exit+0x358/0xaf0 | ? wake_up_state+0x10/0x20 | ? signal_wake_up_state+0x1a/0x30 | do_group_exit+0x47/0xb0 | __x64_sys_exit_group+0x18/0x20 | do_syscall_64+0x57/0x1d0 | entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix the crash by tracking the subdevices when attaching and detaching aux-domains. Fixes: 67b8e02b5e76 ("iommu/vt-d: Aux-domain specific domain attach/detach") Co-developed-by: Xin Zeng <xin.zeng@intel.com> Signed-off-by: Xin Zeng <xin.zeng@intel.com> Signed-off-by: Liu Yi L <yi.l.liu@intel.com> Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/1609949037-25291-3-git-send-email-yi.l.liu@intel.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-07iommu/vt-d: Move intel_iommu info from struct intel_svm to struct intel_svm_devLiu Yi L1-4/+5
'struct intel_svm' is shared by all devices bound to a give process, but records only a single pointer to a 'struct intel_iommu'. Consequently, cache invalidations may only be applied to a single DMAR unit, and are erroneously skipped for the other devices. In preparation for fixing this, rework the structures so that the iommu pointer resides in 'struct intel_svm_dev', allowing 'struct intel_svm' to track them in its device list. Fixes: 1c4f88b7f1f9 ("iommu/vt-d: Shared virtual address in scalable mode") Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Raj Ashok <ashok.raj@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Reported-by: Guo Kaijie <Kaijie.Guo@intel.com> Reported-by: Xin Zeng <xin.zeng@intel.com> Signed-off-by: Guo Kaijie <Kaijie.Guo@intel.com> Signed-off-by: Xin Zeng <xin.zeng@intel.com> Signed-off-by: Liu Yi L <yi.l.liu@intel.com> Tested-by: Guo Kaijie <Kaijie.Guo@intel.com> Cc: stable@vger.kernel.org # v5.0+ Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/1609949037-25291-2-git-send-email-yi.l.liu@intel.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-07iommu/arm-smmu-qcom: Initialize SCTLR of the bypass contextBjorn Andersson1-0/+2
On SM8150 it's occasionally observed that the boot hangs in between the writing of SMEs and context banks in arm_smmu_device_reset(). The problem seems to coincide with a display refresh happening after updating the stream mapping, but before clearing - and there by disabling translation - the context bank picked to emulate translation bypass. Resolve this by explicitly disabling the bypass context already in cfg_probe. Fixes: f9081b8ff593 ("iommu/arm-smmu-qcom: Implement S2CR quirk") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210106005038.4152731-1-bjorn.andersson@linaro.org Signed-off-by: Will Deacon <will@kernel.org>
2021-01-07iommu/vt-d: Fix lockdep splat in sva bind()/unbind()Lu Baolu1-6/+8
Lock(&iommu->lock) without disabling irq causes lockdep warnings. ======================================================== WARNING: possible irq lock inversion dependency detected 5.11.0-rc1+ #828 Not tainted -------------------------------------------------------- kworker/0:1H/120 just changed the state of lock: ffffffffad9ea1b8 (device_domain_lock){..-.}-{2:2}, at: iommu_flush_dev_iotlb.part.0+0x32/0x120 but this lock took another, SOFTIRQ-unsafe lock in the past: (&iommu->lock){+.+.}-{2:2} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&iommu->lock); local_irq_disable(); lock(device_domain_lock); lock(&iommu->lock); <Interrupt> lock(device_domain_lock); *** DEADLOCK *** Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20201231005323.2178523-5-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-07Revert "iommu: Add quirk for Intel graphic devices in map_sg"Lu Baolu1-27/+0
This reverts commit 65f746e8285f0a67d43517d86fedb9e29ead49f2. As commit 8a473dbadccf ("drm/i915: Fix DMA mapped scatterlist walks") and commit 934941ed5a30 ("drm/i915: Fix DMA mapped scatterlist lookup") fixed the DMA scatterlist limitations in the i915 driver, remove this temporary workaround. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tom Murphy <murphyt7@tcd.ie> Cc: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20201231005323.2178523-4-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-07iommu/vt-d: Fix misuse of ALIGN in qi_flush_piotlb()Lu Baolu1-2/+2
Use IS_ALIGNED() instead. Otherwise, an unaligned address will be ignored. Fixes: 33cd6e642d6a ("iommu/vt-d: Flush PASID-based iotlb for iova over first level") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20201231005323.2178523-1-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2021-01-07drm/ttm: unexport ttm_pool_init/finiChristian König1-2/+0
Drivers are not supposed to use this directly any more. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/412156/
2021-01-07drm/radeon: stop re-init the TTM page poolChristian König1-3/+0
Drivers are not supposed to init the page pool directly any more. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/412153/
2021-01-07usb: dwc3: gadget: Clear wait flag on dequeueThinh Nguyen1-0/+2
If an active transfer is dequeued, then the endpoint is freed to start a new transfer. Make sure to clear the endpoint's transfer wait flag for this case. Fixes: e0d19563eb6c ("usb: dwc3: gadget: Wait for transfer completion") Cc: stable@vger.kernel.org Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b81cd5b5281cfbfdadb002c4bcf5c9be7c017cfd.1609828485.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-07usb: typec: Send uevent for num_altmodes updatePrashant Malani1-0/+2
Generate a change uevent when the "number_of_alternate_modes" sysfs file for partners and plugs is updated by a port driver. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Benson Leung <bleung@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20210107034904.4112029-1-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-07usb: typec: Fix copy paste error for NVIDIA alt-mode descriptionPeter Robinson1-1/+1
The name of the module for the NVIDIA alt-mode is incorrect as it looks to be a copy-paste error from the entry above, update it to the correct typec_nvidia module name. Cc: Ajay Gupta <ajayg@nvidia.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20210106001605.167917-1-pbrobinson@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-07usb: gadget: enable super speed plustaehyun.cho1-2/+2
Enable Super speed plus in configfs to support USB3.1 Gen2. This ensures that when a USB gadget is plugged in, it is enumerated as Gen 2 and connected at 10 Gbps if the host and cable are capable of it. Many in-tree gadget functions (fs, midi, acm, ncm, mass_storage, etc.) already have SuperSpeed Plus support. Tested: plugged gadget into Linux host and saw: [284907.385986] usb 8-2: new SuperSpeedPlus Gen 2 USB device number 3 using xhci_hcd Tested-by: Lorenzo Colitti <lorenzo@google.com> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: taehyun.cho <taehyun.cho@samsung.com> Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Link: https://lore.kernel.org/r/20210106154625.2801030-1-lorenzo@google.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-07kcov, usb: hide in_serving_softirq checks in __usb_hcd_giveback_urbAndrey Konovalov1-5/+3
Done opencode in_serving_softirq() checks in in_serving_softirq() to avoid cluttering the code, hide them in kcov helpers instead. Fixes: aee9ddb1d371 ("kcov, usb: only collect coverage from __usb_hcd_giveback_urb in softirq") Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Link: https://lore.kernel.org/r/aeb430c5bb90b0ccdf1ec302c70831c1a47b9c45.1609876340.git.andreyknvl@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-07dmabuf: fix use-after-free of dmabuf's file->f_inodeCharan Teja Reddy1-4/+17
It is observed 'use-after-free' on the dmabuf's file->f_inode with the race between closing the dmabuf file and reading the dmabuf's debug info. Consider the below scenario where P1 is closing the dma_buf file and P2 is reading the dma_buf's debug info in the system: P1 P2 dma_buf_debug_show() dma_buf_put() __fput() file->f_op->release() dput() .... dentry_unlink_inode() iput(dentry->d_inode) (where the inode is freed) mutex_lock(&db_list.lock) read 'dma_buf->file->f_inode' (the same inode is freed by P1) mutex_unlock(&db_list.lock) dentry->d_op->d_release()--> dma_buf_release() ..... mutex_lock(&db_list.lock) removes the dmabuf from the list mutex_unlock(&db_list.lock) In the above scenario, when dma_buf_put() is called on a dma_buf, it first frees the dma_buf's file->f_inode(=dentry->d_inode) and then removes this dma_buf from the system db_list. In between P2 traversing the db_list tries to access this dma_buf's file->f_inode that was freed by P1 which is a use-after-free case. Since, __fput() calls f_op->release first and then later calls the d_op->d_release, move the dma_buf's db_list removal from d_release() to f_op->release(). This ensures that dma_buf's file->f_inode is not accessed after it is released. Cc: <stable@vger.kernel.org> # 5.4.x- Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops") Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Charan Teja Reddy <charante@codeaurora.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1609857399-31549-1-git-send-email-charante@codeaurora.org
2021-01-07can: rcar: Kconfig: update help description for CAN_RCAR configLad Prabhakar1-2/+2
The rcar_can driver also supports RZ/G SoC's, update the description to reflect this. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210104090327.6547-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-07can: mcp251xfd: mcp251xfd_handle_rxif_ring(): first increment RX tail ↵Marc Kleine-Budde1-4/+4
pointer in HW, then in driver The previous patch fixes a TEF vs. TX race condition, by first updating the TEF tail pointer in hardware, and then updating the driver internal pointer. The same pattern exists in the RX-path, too. This should be no problem, as the driver accesses the RX-FIFO from the interrupt handler only, thus the access is properly serialized. Fix the order here, too, so that the TEF- and RX-path look similar. Fixes: 1f652bb6bae7 ("can: mcp25xxfd: rx-path: reduce number of SPI core requests to set UINC bit") Link: https://lore.kernel.org/r/20210105214138.3150886-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-07can: mcp251xfd: mcp251xfd_handle_tefif(): fix TEF vs. TX race conditionMarc Kleine-Budde1-5/+4
The mcp251xfd driver uses a TX FIFO for sending CAN frames and a TX Event FIFO (TEF) for completed TX-requests. The TEF event handling in the mcp251xfd_handle_tefif() function has a race condition. It first increments the tx-ring's tail counter to signal that there's room in the TX and TEF FIFO, then it increments the TEF FIFO in hardware. A running mcp251xfd_start_xmit() on a different CPU might not stop the txqueue (as the tx-ring still shows free space). The next mcp251xfd_start_xmit() will push a message into the chip and the TX complete event might overflow the TEF FIFO. This patch changes the order to fix the problem. Fixes: 68c0c1c7f966 ("can: mcp251xfd: tef-path: reduce number of SPI core requests to set UINC bit") Link: https://lore.kernel.org/r/20210105214138.3150886-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-07Merge tag 'drm-intel-fixes-2021-01-07' of ↵Daniel Vetter7-29/+22
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.11-rc3: - Use per-connector PM QoS tracking for DP aux communication - GuC firmware fix for older Cometlakes - Clear the gpu reloc and shadow batches Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/877dop18zf.fsf@intel.com
2021-01-07Merge tag 'amd-drm-fixes-5.11-2021-01-06' of ↵Daniel Vetter27-113/+200
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.11-2021-01-06: amdgpu: - Telemetry fix for VGH - Powerplay fixes for RV - Powerplay fixes for RN - RAS fixes for Sienna Cichlid - Blank screen regression fix - Drop DCN support for aarch64 - Misc other fixes Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210106222721.3934-1-alexander.deucher@amd.com
2021-01-07can: tcan4x5x: fix bittiming const, use common bittiming from m_can driverMarc Kleine-Budde1-26/+0
According to the TCAN4550 datasheet "SLLSF91 - DECEMBER 2018" the tcan4x5x has the same bittiming constants as a m_can revision 3.2.x/3.3.0. The tcan4x5x chip I'm using identifies itself as m_can revision 3.2.1, so remove the tcan4x5x specific bittiming values and rely on the values in the m_can driver, which are selected according to core revision. Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Cc: Dan Murphy <dmurphy@ti.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20201215103238.524029-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-07can: m_can: m_can_class_unregister(): remove erroneous m_can_clk_stop()Marc Kleine-Budde1-2/+0
In m_can_class_register() the clock is started, but stopped on exit. When calling m_can_class_unregister(), the clock is stopped a second time. This patch removes the erroneous m_can_clk_stop() in m_can_class_unregister(). Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Cc: Dan Murphy <dmurphy@ti.com> Cc: Sriram Dash <sriram.dash@samsung.com> Reviewed-by: Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20201215103238.524029-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-01-06ptp: ptp_ines: prevent build when HAS_IOMEM is not setRandy Dunlap1-0/+1
ptp_ines.c uses devm_platform_ioremap_resource(), which is only built/available when CONFIG_HAS_IOMEM is enabled. CONFIG_HAS_IOMEM is not enabled for arch/s390/, so builds on S390 have a build error: s390-linux-ld: drivers/ptp/ptp_ines.o: in function `ines_ptp_ctrl_probe': ptp_ines.c:(.text+0x17e6): undefined reference to `devm_platform_ioremap_resource' Prevent builds of ptp_ines.c when HAS_IOMEM is not set. Fixes: bad1eaa6ac31 ("ptp: Add a driver for InES time stamping IP core.") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202101031125.ZEFCUiKi-lkp@intel.com Acked-by: Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/20210106042531.1351-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-06net: dsa: fix led_classdev build errorsRandy Dunlap1-0/+1
Fix build errors when LEDS_CLASS=m and NET_DSA_HIRSCHMANN_HELLCREEK=y. This limits the latter to =m when LEDS_CLASS=m. microblaze-linux-ld: drivers/net/dsa/hirschmann/hellcreek_ptp.o: in function `hellcreek_ptp_setup': (.text+0xf80): undefined reference to `led_classdev_register_ext' microblaze-linux-ld: (.text+0xf94): undefined reference to `led_classdev_register_ext' microblaze-linux-ld: drivers/net/dsa/hirschmann/hellcreek_ptp.o: in function `hellcreek_ptp_free': (.text+0x1018): undefined reference to `led_classdev_unregister' microblaze-linux-ld: (.text+0x1024): undefined reference to `led_classdev_unregister' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202101060655.iUvMJqS2-lkp@intel.com Cc: Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20210106021815.31796-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-06net: bareudp: add missing error handling for bareudp_link_config()Jakub Kicinski1-8/+14
.dellink does not get called after .newlink fails, bareudp_newlink() must undo what bareudp_configure() has done if bareudp_link_config() fails. v2: call bareudp_dellink(), like bareudp_dev_create() does Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Link: https://lore.kernel.org/r/20210105190725.1736246-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-06net: mvneta: fix error message when MTU too large for XDPMarek Behún1-1/+1
The error message says that "Jumbo frames are not supported on XDP", but the code checks for mtu > MVNETA_MAX_RX_BUF_SIZE, not mtu > 1500. Fix this error message. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 0db51da7a8e9 ("net: mvneta: add basic XDP support") Cc: Lorenzo Bianconi <lorenzo@kernel.org> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Link: https://lore.kernel.org/r/20210105172333.21613-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-06Revert "drm/amd/display: Fix memory leaks in S3 resume"Alex Deucher1-2/+1
This reverts commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362. This leads to blank screens on some boards after replugging a display. Revert until we understand the root cause and can fix both the leak and the blank screen after replug. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211033 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1427 Cc: Stylon Wang <stylon.wang@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Andre Tomt <andre@tomt.net> Cc: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-01-06drm/amdgpu/display: drop DCN support for aarch64Alex Deucher13-73/+1
From Ard: "Simply disabling -mgeneral-regs-only left and right is risky, given that the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, and GCC is known to use SIMD registers for spilling, and may invent other uses of the FP/SIMD register file that have nothing to do with the floating point code in question. Note that putting kernel_neon_begin() and kernel_neon_end() around the code that does use FP is not sufficient here, the problem is in all the other code that may be emitted with references to SIMD registers in it. So the only way to do this properly is to put all floating point code in a separate compilation unit, and only compile that unit with -mgeneral-regs-only." Disable support until the code can be properly refactored to support this properly on aarch64. Acked-by: Will Deacon <will@kernel.org> Reported-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-06drm/amdgpu: enable ras eeprom support for sienna cichlidJohn Clements1-1/+7
added I2C address and asic support flag Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-06drm/amdgpu: fix no bad_pages issue after umc ue injectionDennis Li1-4/+4
old code wrongly used the bad page status as the function return value, which cause amdgpu_ras_badpages_read always return failed. Signed-off-by: Dennis Li <Dennis.Li@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-06drm/amdgpu: fix potential memory leak during navi12 deinitializationJiawei Gu1-4/+14
Navi12 HDCP & DTM deinitialization needs continue to free bo if already created though initialized flag is not set. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jiawei Gu <Jiawei.Gu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-06drm/amd/display: Fix unused variable warningArnd Bergmann2-4/+2
Some of the newly added code is hidden inside of #ifdef blocks, but one variable is unused when debugfs is disabled: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8370:8: error: unused variable 'configure_crc' [-Werror,-Wunused-variable] Change the #ifdef to an if(IS_ENABLED()) check to fix the warning and avoid adding more #ifdefs. Fixes: c920888c604d ("drm/amd/display: Expose new CRC window property") Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-29 18:22:34 +0000