aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-07-19bnxt_en: Add missing check for BNXT_STATE_ABORT_ERR in bnxt_fw_rset_task()Michael Chan1-0/+4
In the BNXT_FW_RESET_STATE_POLL_VF state in bnxt_fw_reset_task() after all VFs have unregistered, we need to check for BNXT_STATE_ABORT_ERR after we acquire the rtnl_lock. If the flag is set, we need to abort. Fixes: 230d1f0de754 ("bnxt_en: Handle firmware reset.") Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-07-19bnxt_en: Refresh RoCE capabilities in bnxt_ulp_probe()Michael Chan1-4/+5
The capabilities can change after firmware upgrade/downgrade, so we should get the up-to-date RoCE capabilities everytime bnxt_ulp_probe() is called. Fixes: 2151fe0830fd ("bnxt_en: Handle RESET_NOTIFY async event from firmware.") Reviewed-by: Somnath Kotur <[email protected]> Reviewed-by: Edwin Peer <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-07-19bnxt_en: reject ETS settings that will starve a TCEdwin Peer1-1/+9
ETS proportions are presented to HWRM_QUEUE_COS2BW_CFG as minimum bandwidth constraints. Thus, zero is a legal value for a given TC. However, if all the other TCs sum up to 100%, then at least one hardware queue will starve, resulting in guaranteed TX timeouts. Reject such nonsensical configurations. Reviewed-by: Pavan Chebbi <[email protected]> Signed-off-by: Edwin Peer <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-07-19bnxt_en: don't disable an already disabled PCI deviceKalesh AP1-1/+2
If device is already disabled in reset path and PCI io error is detected before the device could be enabled, driver could call pci_disable_device() for already disabled device. Fix this problem by calling pci_disable_device() only if the device is already enabled. Fixes: 6316ea6db93d ("bnxt_en: Enable AER support.") Signed-off-by: Kalesh AP <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-07-19ACPI: utils: Fix reference counting in for_each_acpi_dev_match()Andy Shevchenko3-9/+5
Currently it's possible to iterate over the dangling pointer in case the device suddenly disappears. This may happen becase callers put it at the end of a loop. Instead, let's move that call inside acpi_dev_get_next_match_dev(). Fixes: 803abec64ef9 ("media: ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver") Fixes: bf263f64e804 ("media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macro") Fixes: edbd1bc4951e ("efi/dev-path-parser: Switch to use for_each_acpi_dev_match()") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-07-19ACPI: Kconfig: Fix table override from built-in initrdRobert Richter1-1/+1
During a rework of initramfs code the INITRAMFS_COMPRESSION config option was removed in commit 65e00e04e5ae. A leftover as a dependency broke the config option ACPI_TABLE_OVERRIDE_VIA_ BUILTIN_INITRD that is used to enable the overriding of ACPI tables from built-in initrd. Fixing the dependency. Fixes: 65e00e04e5ae ("initramfs: refactor the initramfs build rules") Signed-off-by: Robert Richter <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-07-19Revert "drm/i915: Propagate errors on awaiting already signaled fences"Jason Ekstrand1-6/+2
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Error propagation along fences sound like a good idea, but as your bug shows, surprising consequences, since propagating errors across security boundaries is not a good thing. What we do have is track the hangs on the ctx, and report information to userspace using RESET_STATS. That's how arb_robustness works. Also, if my understanding is still correct, the EIO from execbuf is when your context is banned (because not recoverable or too many hangs). And in all these cases it's up to userspace to figure out what is all impacted and should be reported to the application, that's not on the kernel to guess and automatically propagate. What's more, we're also building more features on top of ctx error reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the userspace fence wait also relies on that mechanism. So it is the path going forward for reporting gpu hangs and resets to userspace. So all together that's why I think we should just bury this idea again as not quite the direction we want to go to, hence why I think the revert is the right option here. For backporters: Please note that you _must_ have a backport of https://lore.kernel.org/dri-devel/[email protected]/ for otherwise backporting just this patch opens up a security bug. v2: Augment commit message. Also restore Jason's sob that I accidentally lost. v3: Add a note for backporters Signed-off-by: Jason Ekstrand <[email protected]> Reported-by: Marcin Slusarz <[email protected]> Cc: <[email protected]> # v5.6+ Cc: Jason Ekstrand <[email protected]> Cc: Marcin Slusarz <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Jon Bloomfield <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 93a2711cddd5760e2f0f901817d71c93183c3b87) Signed-off-by: Rodrigo Vivi <[email protected]>
2021-07-19drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"Jason Ekstrand4-279/+91
This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser"). The justification for this commit in the git history was a vague comment about getting it out from under the struct_mutex. While this may improve perf for some workloads on Gen7 platforms where we rely on the command parser for features such as indirect rendering, no numbers were provided to prove such an improvement. It claims to closed two gitlab/bugzilla issues but with no explanation whatsoever as to why or what bug it's fixing. Meanwhile, by moving command parsing off to an async callback, it leaves us with a problem of what to do on error. When things were synchronous, EXECBUFFER2 would fail with an error code if parsing failed. When moving it to async, we needed another way to handle that error and the solution employed was to set an error on the dma_fence and then trust that said error gets propagated to the client eventually. Moving back to synchronous will help us untangle the fence error propagation mess. This also reverts most of 0edbb9ba1bfe ("drm/i915: Move cmd parser pinning to execbuffer") which is a refactor of some of our allocation paths for asynchronous parsing. Now that everything is synchronous, we don't need it. v2 (Daniel Vetter): - Add stabel Cc and Fixes tag Signed-off-by: Jason Ekstrand <[email protected]> Cc: <[email protected]> # v5.6+ Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Cc: Maarten Lankhorst <[email protected]> Reviewed-by: Jon Bloomfield <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 93b713304188844b8514074dc13ffd56d12235d3) Signed-off-by: Rodrigo Vivi <[email protected]>
2021-07-19Merge tag 'gvt-fixes-2021-07-15' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi1-0/+15
drm-intel-fixes gvt-fixes-2021-07-15 - Fix shadow ppgtt invalidation with proper D3 state tracking (Colin) Signed-off-by: Rodrigo Vivi <[email protected]> From: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-19spi: cadence: Correct initialisation of runtime PM againMarek Vasut1-5/+9
The original implementation of RPM handling in probe() was mostly correct, except it failed to call pm_runtime_get_*() to activate the hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM"), breaks the implementation further, to the point where the system using this hard IP on ZynqMP hangs on boot, because it accesses hardware which is gated off. Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM") and instead add missing pm_runtime_get_noresume() and move the RPM disabling all the way to the end of probe(). That makes ZynqMP not hang on boot yet again. Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM") Signed-off-by: Marek Vasut <[email protected]> Cc: Charles Keepax <[email protected]> Cc: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-07-19Drivers: hv: vmbus: Fix duplicate CPU assignments within a deviceHaiyang Zhang1-32/+64
The vmbus module uses a rotational algorithm to assign target CPUs to a device's channels. Depending on the timing of different device's channel offers, different channels of a device may be assigned to the same CPU. For example on a VM with 2 CPUs, if NIC A and B's channels are offered in the following order, NIC A will have both channels on CPU0, and NIC B will have both channels on CPU1 -- see below. This kind of assignment causes RSS load that is spreading across different channels to end up on the same CPU. Timing of channel offers: NIC A channel 0 NIC B channel 0 NIC A channel 1 NIC B channel 1 VMBUS ID 14: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter Device_ID = {cab064cd-1f31-47d5-a8b4-9d57e320cccd} Sysfs path: /sys/bus/vmbus/devices/cab064cd-1f31-47d5-a8b4-9d57e320cccd Rel_ID=14, target_cpu=0 Rel_ID=17, target_cpu=0 VMBUS ID 16: Class_ID = {f8615163-df3e-46c5-913f-f2d2f965ed0e} - Synthetic network adapter Device_ID = {244225ca-743e-4020-a17d-d7baa13d6cea} Sysfs path: /sys/bus/vmbus/devices/244225ca-743e-4020-a17d-d7baa13d6cea Rel_ID=16, target_cpu=1 Rel_ID=18, target_cpu=1 Update the vmbus CPU assignment algorithm to avoid duplicate CPU assignments within a device. The new algorithm iterates num_online_cpus + 1 times. The existing rotational algorithm to find "next NUMA & CPU" is still here. But if the resulting CPU is already used by the same device, it will try the next CPU. In the last iteration, it assigns the channel to the next available CPU like the existing algorithm. This is not normally expected, because during device probe, we limit the number of channels of a device to be <= number of online CPUs. Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Tested-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2021-07-19drm/nouveau: init the base GEM fields for internal BOsChristian König1-0/+6
TTMs buffer objects are based on GEM objects for quite a while and rely on initializing those fields before initializing the TTM BO. Nouveau now doesn't init the GEM object for internally allocated BOs, so make sure that we at least initialize some necessary fields. Signed-off-by: Christian König <[email protected]> Tested-by: Mikko Perttunen <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Huang Rui <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-18scsi: target: Fix protect handling in WRITE SAME(32)Dmitry Bogdanov1-18/+17
WRITE SAME(32) command handling reads WRPROTECT at the wrong offset in 1st byte instead of 10th byte. Link: https://lore.kernel.org/r/[email protected] Fixes: afd73f1b60fc ("target: Perform PROTECT sanity checks for WRITE_SAME") Signed-off-by: Dmitry Bogdanov <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2021-07-18scsi: iscsi: Fix iface sysfs attr detectionMike Christie1-56/+34
A ISCSI_IFACE_PARAM can have the same value as a ISCSI_NET_PARAM so when iscsi_iface_attr_is_visible tries to figure out the type by just checking the value, we can collide and return the wrong type. When we call into the driver we might not match and return that we don't want attr visible in sysfs. The patch fixes this by setting the type when we figure out what the param is. Link: https://lore.kernel.org/r/[email protected] Fixes: 3e0f65b34cc9 ("[SCSI] iscsi_transport: Additional parameters for network settings") Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2021-07-18Revert "gpio: mpc8xxx: change the gpio interrupt flags."Rasmus Villemoes1-1/+1
This reverts commit 3d5bfbd9716318b1ca5c38488aa69f64d38a9aa5. When booting with threadirqs, it causes a splat WARNING: CPU: 0 PID: 29 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1ec/0x27c irq 66 handler irq_default_primary_handler+0x0/0x1c enabled interrupts That splat later went away with commit 81e2073c175b ("genirq: Disable interrupts for force threaded handlers"), which got backported to -stable. However, when running an -rt kernel, the splat still exists. Moreover, quoting Thomas Gleixner [1] But 3d5bfbd97163 ("gpio: mpc8xxx: change the gpio interrupt flags.") has nothing to do with that: "Delete the interrupt IRQF_NO_THREAD flags in order to gpio interrupts can be threaded to allow high-priority processes to preempt." This changelog is blatantly wrong. In mainline forced irq threads have always been invoked with softirqs disabled, which obviously makes them non-preemptible. So the patch didn't even do what its commit log said. [1] https://lore.kernel.org/lkml/[email protected]/ Cc: [email protected] # v5.9+ Signed-off-by: Rasmus Villemoes <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2021-07-17Merge tag 'soc-fixes-5.14-1' of ↵Linus Torvalds9-110/+162
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Here are the patches for this week that came as the fallout of the merge window: - Two fixes for the NVidia memory controller driver - multiple defconfig files get patched to turn CONFIG_FB back on after that is no longer selected by CONFIG_DRM - ffa and scmpi firmware drivers fixes, mostly addressing compiler and documentation warnings - Platform specific fixes for device tree files on ASpeed, Renesas and NVidia SoC, mostly for recent regressions. - A workaround for a regression on the USB PHY with devlink when the usb-nop-xceiv driver is not available until the rootfs is mounted. - Device tree compiler warnings in Arm Versatile-AB" * tag 'soc-fixes-5.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (35 commits) ARM: dts: versatile: Fix up interrupt controller node names ARM: multi_v7_defconfig: Make NOP_USB_XCEIV driver built-in ARM: configs: Update u8500_defconfig ARM: configs: Update Vexpress defconfig ARM: configs: Update Versatile defconfig ARM: configs: Update RealView defconfig ARM: configs: Update Integrator defconfig arm: Typo s/PCI_IXP4XX_LEGACY/IXP4XX_PCI_LEGACY/ firmware: arm_scmi: Fix range check for the maximum number of pending messages firmware: arm_scmi: Avoid padding in sensor message structure firmware: arm_scmi: Fix kernel doc warnings about return values firmware: arm_scpi: Fix kernel doc warnings firmware: arm_scmi: Fix kernel doc warnings ARM: shmobile: defconfig: Restore graphical consoles firmware: arm_ffa: Fix a possible ffa_linux_errmap buffer overflow firmware: arm_ffa: Fix the comment style firmware: arm_ffa: Simplify probe function firmware: arm_ffa: Ensure drivers provide a probe function firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow firmware: arm_scmi: Ensure drivers provide a probe function ...
2021-07-17Merge tag 'scsi-fixes' of ↵Linus Torvalds11-101/+115
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "One core fix for an oops which can occur if the error handling thread fails to start for some reason and the driver is removed. The other fixes are all minor ones in drivers" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Add missing host_lock in ufshcd_vops_setup_xfer_req() scsi: mpi3mr: Fix W=1 compilation warnings scsi: pm8001: Clean up kernel-doc and comments scsi: zfcp: Report port fc_security as unknown early during remote cable pull scsi: core: Fix bad pointer dereference when ehandler kthread is invalid scsi: fas216: Fix a build error scsi: core: Fix the documentation of the scsi_execute() time parameter
2021-07-17iio: adis: set GPIO reset pin directionAntti Keränen1-2/+1
Set reset pin direction to output as the reset pin needs to be an active low output pin. Co-developed-by: Hannu Hartikainen <[email protected]> Signed-off-by: Hannu Hartikainen <[email protected]> Signed-off-by: Antti Keränen <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Fixes: ecb010d44108 ("iio: imu: adis: Refactor adis_initial_startup") Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2021-07-17iio: adc: ti-ads7950: Ensure CS is deasserted after reading channelsUwe Kleine-König1-1/+0
The ADS7950 requires that CS is deasserted after each SPI word. Before commit e2540da86ef8 ("iio: adc: ti-ads7950: use SPI_CS_WORD to reduce CPU usage") the driver used a message with one spi transfer per channel where each but the last one had .cs_change set to enforce a CS toggle. This was wrongly translated into a message with a single transfer and .cs_change set which results in a CS toggle after each word but the last which corrupts the first adc conversion of all readouts after the first readout. Fixes: e2540da86ef8 ("iio: adc: ti-ads7950: use SPI_CS_WORD to reduce CPU usage") Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: David Lechner <[email protected]> Tested-by: David Lechner <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2021-07-17platform/x86: think-lmi: Fix possible mem-leaks on tlmi_analyze() error-exitHans de Goede1-3/+9
Fix 2 possible memleaks on error-exits from tlmi_analyze(): 1. If the kzalloc of pwd_power fails, then not only free the atributes, but also the allocated pwd_admin struct. 2. Freeing the attributes should also free the possible_values strings. Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-07-17platform/x86: think-lmi: Split kobject_init() and kobject_add() callsHans de Goede1-6/+9
tlmi_sysfs_init() calls tlmi_release_attr() on errors which calls kobject_put() for attributes created by tlmi_analyze(), but if we bail early because of an error, then this means that some of the kobjects will not have been initialized yet; and we should thus not call kobject_put() on them. Switch from using kobject_init_and_add() inside tlmi_sysfs_init() to initializing all the created kobjects directly in tlmi_analyze() and only adding them from tlmi_sysfs_init(). This way all kobjects will always be initialized when tlmi_release_attr() gets called. Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-07-17platform/x86: think-lmi: Move pending_reboot_attr to the attributes sysfs dirMark Pearson1-6/+5
Move the pending_reboot node under attributes dir where it should live, as documented in: Documentation/ABI/testing/sysfs-class-firmware-attributes. Also move the create / remove code to be together with the other code populating / cleaning the attributes sysfs dir. In the removal path this is necessary so that the remove is done before the kset_unregister(tlmi_priv.attribute_kset) call. Signed-off-by: Mark Pearson <[email protected]> Co-developed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-07-17platform/x86: amd-pmc: Fix undefined reference to __udivdi3Shyam Sundar S K1-1/+2
It was reported that on i386 config ------ on i386: ld: drivers/platform/x86/amd-pmc.o: in function `s0ix_stats_show': amd-pmc.c:(.text+0x100): undefined reference to `__udivdi3' ------- The reason for this is that 64-bit integer division is not supported on 32-bit architecture. Use do_div macro to fix this. Fixes: b9a4fa6978be ("platform/x86: amd-pmc: Add support for logging s0ix counters") Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> # and build-tested Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-07-16bonding: fix build issueMahesh Bandewar1-0/+2
The commit 9a5605505d9c (" bonding: Add struct bond_ipesc to manage SA") is causing following build error when XFRM is not selected in kernel config. lld: error: undefined symbol: xfrm_dev_state_flush >>> referenced by bond_main.c:3453 (drivers/net/bonding/bond_main.c:3453) >>> net/bonding/bond_main.o:(bond_netdev_event) in archive drivers/built-in.a Fixes: 9a5605505d9c (" bonding: Add struct bond_ipesc to manage SA") Signed-off-by: Mahesh Bandewar <[email protected]> CC: Taehee Yoo <[email protected]> CC: Jay Vosburgh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-07-16Merge tag 'scmi-fixes-5.14' of ↵Arnd Bergmann4-12/+20
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes ARM SCMI fixes for v5.14 A small set of fixes: - adding check for presence of probe while registering the driver to prevent NULL pointer access - dropping the duplicate check as the driver core already takes care of it - fix for possible scmi_linux_errmap buffer overflow - fix to avoid sensor message structure padding - fix the range check for the maximum number of pending SCMI messages - fix for various kernel-doc warnings * tag 'scmi-fixes-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fix range check for the maximum number of pending messages firmware: arm_scmi: Avoid padding in sensor message structure firmware: arm_scmi: Fix kernel doc warnings about return values firmware: arm_scpi: Fix kernel doc warnings firmware: arm_scmi: Fix kernel doc warnings firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow firmware: arm_scmi: Ensure drivers provide a probe function firmware: arm_scmi: Simplify device probe function on the bus Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-07-16Merge tag 'arm-ffa-fixes-5.14' of ↵Arnd Bergmann2-6/+8
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm FF-A fixes for v5.14 A small set of fixes: - adding check for presence of probe while registering the driver to prevent NULL pointer access - dropping the duplicate check as the driver core already takes care of it - fixing possible ffa_linux_errmap buffer overflow and - fixing kernel-doc warning for comment style * tag 'arm-ffa-fixes-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Fix a possible ffa_linux_errmap buffer overflow firmware: arm_ffa: Fix the comment style firmware: arm_ffa: Simplify probe function firmware: arm_ffa: Ensure drivers provide a probe function Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-07-16mt7530 fix mt7530_fdb_write vid missing ivl bitEric Woudstra2-0/+2
According to reference guides mt7530 (mt7620) and mt7531: NOTE: When IVL is reset, MAC[47:0] and FID[2:0] will be used to read/write the address table. When IVL is set, MAC[47:0] and CVID[11:0] will be used to read/write the address table. Since the function only fills in CVID and no FID, we need to set the IVL bit. The existing code does not set it. This is a fix for the issue I dropped here earlier: http://lists.infradead.org/pipermail/linux-mediatek/2021-June/025697.html With this patch, it is now possible to delete the 'self' fdb entry manually. However, wifi roaming still has the same issue, the entry does not get deleted automatically. Wifi roaming also needs a fix somewhere else to function correctly in combination with vlan. Signed-off-by: Eric Woudstra <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-07-16Merge tag 'block-5.14-2021-07-16' of git://git.kernel.dk/linux-blockLinus Torvalds5-212/+87
Pull block fixes from Jens Axboe: - NVMe fixes via Christoph: - fix various races in nvme-pci when shutting down just after probing (Casey Chen) - fix a net_device leak in nvme-tcp (Prabhakar Kushwaha) - Fix regression in xen-blkfront by cleaning up the removal state machine (Christoph) - Fix tag_set and queue cleanup ordering regression in nbd (Wang) - Fix tag_set and queue cleanup ordering regression in pd (Guoqing) * tag 'block-5.14-2021-07-16' of git://git.kernel.dk/linux-block: xen-blkfront: sanitize the removal state machine nbd: fix order of cleaning up the queue and freeing the tagset pd: fix order of cleaning up the queue and freeing the tagset nvme-pci: do not call nvme_dev_remove_admin from nvme_remove nvme-pci: fix multiple races in nvme_setup_io_queues nvme-tcp: use __dev_get_by_name instead dev_get_by_name for OPT_HOST_IFACE
2021-07-16drm/amd/display: Fix 10bit 4K display on CIK GPUsLiviu Dudau1-1/+1
Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken image that looks like it has an effective resolution of 1920x1080 but scaled up in an irregular way. Reverting the commit or applying this patch fixes the problem on v5.14-rc1. Fixes: 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at 30bpp for DCE-11.0.") Acked-by: Mario Kleiner <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Liviu Dudau <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-16drm/amd/pm: update DRIVER_IF_VERSION for beige_gobyTao Zhou1-1/+1
Update the version to 0xD for beige_goby. Signed-off-by: Tao Zhou <[email protected]> Reviewed-by: Jack Gui <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-16drm/amdgpu: update gc golden setting for dimgrey_cavefishTao Zhou1-0/+1
Update gc_10_3_4 golden setting. Signed-off-by: Tao Zhou <[email protected]> Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-07-16drm/amdgpu: update golden setting for sienna_cichlidLikun Gao1-0/+1
Update GFX golden setting for sienna_cichlid. Signed-off-by: Likun Gao <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-07-16drm/amdgpu: update the golden setting for vangoghXiaojian Du1-0/+1
This patch is to update the golden setting for vangogh. Signed-off-by: Xiaojian Du <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-07-16amdgpu/nv.c - Optimize code for video codec support structureVeerabadhran Gopalakrishnan3-350/+56
Optimized the code for codec info structure initialization Signed-off-by: Veerabadhran Gopalakrishnan <[email protected]> Reviewed-by: James Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-16amdgpu/nv.c - Added video codec support for Yellow CarpVeerabadhran Gopalakrishnan1-1/+19
Added the supported codecs in the video capabilities query. Signed-off-by: Veerabadhran Gopalakrishnan <[email protected]> Reviewed-by: James Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-07-16Merge tag 'drm-fixes-2021-07-16' of git://anongit.freedesktop.org/drm/drmLinus Torvalds38-1395/+202
Pull drm fixes from Dave Airlie: "Regular rc2 fixes though a bit more than usual at rc2 stage, people must have been testing early or else some fixes from last week got a bit laggy. There is one larger change in the amd fixes to amalgamate some power management code on the newer chips with the code from the older chips, it should only affects chips where support was introduced in rc1 and it should make future fixes easier to maintain probably a good idea to merge it now. Otherwise it's mostly fixes across the board. dma-buf: - Fix fence leak in sync_file_merge() error code drm/panel: - nt35510: Don't fail on DSI reads fbdev: - Avoid use-after-free by not deleting current video mode ttm: - Avoid NULL-ptr deref in ttm_range_man_fini() vmwgfx: - Fix a merge commit qxl: - fix a TTM regression amdgpu: - SR-IOV fixes - RAS fixes - eDP fixes - SMU13 code unification to facilitate fixes in the future - Add new renoir DID - Yellow Carp fixes - Beige Goby fixes - Revert a bunch of TLB fixes that caused regressions - Revert an LTTPR display regression amdkfd - Fix VRAM access regression - SVM fixes i915: - Fix -EDEADLK handling regression - Drop the page table optimisation" * tag 'drm-fixes-2021-07-16' of git://anongit.freedesktop.org/drm/drm: (29 commits) drm/amdgpu: add another Renoir DID drm/ttm: add a check against null pointer dereference drm/i915/gtt: drop the page table optimisation drm/i915/gt: Fix -EDEADLK handling regression drm/amd/pm: Add waiting for response of mode-reset message for yellow carp Revert "drm/amdkfd: Add heavy-weight TLB flush after unmapping" Revert "drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update" Revert "drm/amdkfd: Make TLB flush conditional on mapping" Revert "drm/amdgpu: Fix warning of Function parameter or member not described" Revert "drm/amdkfd: Add memory sync before TLB flush on unmap" drm/amd/pm: Fix BACO state setting for Beige_Goby drm/amdgpu: Restore msix after FLR drm/amdkfd: Allow CPU access for all VRAM BOs drm/amdgpu/display - only update eDP's backlight level when necessary drm/amdkfd: handle fault counters on invalid address drm/amdgpu: Correct the irq numbers for virtual crtc drm/amd/display: update header file name drm/amd/pm: drop smu_v13_0_1.c|h files for yellow carp drm/amd/display: remove faulty assert Revert "drm/amd/display: Always write repeater mode regardless of LTTPR" ...
2021-07-16spi: cadence-quadspi: Disable Auto-HW pollingApurva Nandan1-13/+14
cadence-quadspi has a builtin Auto-HW polling funtionality using which it keep tracks of completion of write operations. When Auto-HW polling is enabled, it automatically initiates status register read operation, until the flash clears its busy bit. cadence-quadspi controller doesn't allow an address phase when auto-polling the busy bit on the status register. Unlike SPI NOR flashes, SPI NAND flashes do require the address of status register when polling the busy bit using the read register operation. As Auto-HW polling is enabled by default, cadence-quadspi returns a timeout for every write operation after an indefinite amount of polling on SPI NAND flashes. Disable Auto-HW polling completely as the spi-nor core, spinand core, etc. take care of polling the busy bit on their own. Signed-off-by: Apurva Nandan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-07-16efi/libstub: Fix the efi_load_initrd function descriptionAtish Patra1-2/+2
The soft_limit and hard_limit in the function efi_load_initrd describes the preferred and max address of initrd loading location respectively. However, the description wrongly describes it as the size of the allocated memory. Fix the function description. Signed-off-by: Atish Patra <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2021-07-16firmware/efi: Tell memblock about EFI iomem reservationsMarc Zyngier1-1/+12
kexec_load_file() relies on the memblock infrastructure to avoid stamping over regions of memory that are essential to the survival of the system. However, nobody seems to agree how to flag these regions as reserved, and (for example) EFI only publishes its reservations in /proc/iomem for the benefit of the traditional, userspace based kexec tool. On arm64 platforms with GICv3, this can result in the payload being placed at the location of the LPI tables. Shock, horror! Let's augment the EFI reservation code with a memblock_reserve() call, protecting our dear tables from the secondary kernel invasion. Reported-by: Moritz Fischer <[email protected]> Tested-by: Moritz Fischer <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Cc: [email protected] Cc: Ard Biesheuvel <[email protected]> Cc: James Morse <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2021-07-16efi/tpm: Differentiate missing and invalid final event log table.Michal Suchanek1-3/+5
Missing TPM final event log table is not a firmware bug. Clearly if providing event log in the old format makes the final event log invalid it should not be provided at least in that case. Fixes: b4f1874c6216 ("tpm: check event log version before reading final events") Signed-off-by: Michal Suchanek <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2021-07-16spi: spi-cadence-quadspi: Fix division by zero warningYoshitaka Ikeda1-0/+3
Fix below division by zero warning: - The reason for dividing by zero is because the dummy bus width is zero, but if the dummy n bytes is zero, it indicates that there is no data transfer, so we can just return zero without doing any calculations. [ 0.795337] Division by zero in kernel. : [ 0.834051] [<807fd40c>] (__div0) from [<804e1acc>] (Ldiv0+0x8/0x10) [ 0.839097] [<805f0710>] (cqspi_exec_mem_op) from [<805edb4c>] (spi_mem_exec_op+0x3b0/0x3f8) Fixes: 7512eaf54190 ("spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1") Signed-off-by: Yoshitaka Ikeda <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-07-16spi: spi-cadence-quadspi: Revert "Fix division by zero warning"Yoshitaka Ikeda1-6/+4
Revert to change to a better code. This reverts commit 55cef88bbf12f3bfbe5c2379a8868a034707e755. Signed-off-by: Yoshitaka Ikeda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2021-07-16drm/amdgpu: workaround failed COW checks for Thunk VMAsFelix Kuehling1-0/+9
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE. is_cow_mapping returns true for these mappings, which causes mmap to fail in ttm_bo_mmap_obj. As a workaround, clear VM_MAYWRITE for PROT_NONE-COW mappings. This should prevent the mapping from ever becoming writable and makes is_cow_mapping(vm_flags) false. Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3") Suggested-by: Daniel Vetter <[email protected]> Tested-by: Felix Kuehling <[email protected]> Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Christian König <[email protected]>
2021-07-16Merge tag 'drm-intel-fixes-2021-07-15' of ↵Dave Airlie2-5/+2
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Two regression fixes targeting stable: - Fix -EDEADLK handling regression (Ville) - Drop the page table optimisation (Matt) Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-07-16Merge tag 'drm-misc-fixes-2021-07-15' of ↵Dave Airlie5-9/+10
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull (less than what git shortlog provides): * fbdev: Avoid use-after-free by not deleting current video mode * ttm: Avoid NULL-ptr deref in ttm_range_man_fini() * vmwgfx: Fix a merge commit Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/YO/yoFO+iSEqnIH0@linux-uq9g
2021-07-15Merge tag 'pwm/for-5.14-rc2' of ↵Linus Torvalds5-73/+56
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm fixes from Thierry Reding: "A couple of fixes from Uwe that I missed for v5.14-rc1" * tag 'pwm/for-5.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: ep93xx: Ensure configuring period and duty_cycle isn't wrongly skipped pwm: berlin: Ensure configuring period and duty_cycle isn't wrongly skipped pwm: tiecap: Ensure configuring period and duty_cycle isn't wrongly skipped pwm: spear: Ensure configuring period and duty_cycle isn't wrongly skipped pwm: sprd: Ensure configuring period and duty_cycle isn't wrongly skipped
2021-07-16mtd: cfi_cmdset_0002: fix crash when erasing/writing AMD cardsAndreas Persson1-1/+1
Erasing an AMD linear flash card (AM29F016D) crashes after the first sector has been erased. Likewise, writing to it crashes after two bytes have been written. The reason is a missing check for a null pointer - the cmdset_priv field is not set for this type of card. Fixes: 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling status register") Signed-off-by: Andreas Persson <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/DB6P189MB05830B3530B8087476C5CFE4C1159@DB6P189MB0583.EURP189.PROD.OUTLOOK.COM
2021-07-16mtd: core: handle flashes without OTP gracefullyMichael Walle1-1/+3
There are flash drivers which registers the OTP callbacks although the flash doesn't support OTP regions and return -ENODATA for these callbacks if there is no OTP. If this happens, the probe of the whole flash will fail. Fix it by handling the ENODATA return code and skip the OTP region nvmem setup. Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Michael Walle <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2021-07-16mtd: mchp48l640: silence some uninitialized variable warningsDan Carpenter1-2/+2
Smatch complains that zero length read/writes will lead to an uninitalized return value. I don't know if that's possible, but it's nicer to return a zero literal anyway so let's do that. Fixes: 88d125026753 ("mtd: devices: add support for microchip 48l640 EERAM") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Reviewed-by: Heiko Schocher <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/YMyir961W28TX5dT@mwanda
2021-07-16mtd: break circular locks in register_mtd_blktransDesmond Cheong Zhi Xi1-6/+2
Syzbot reported a circular locking dependency: https://syzkaller.appspot.com/bug?id=7bd106c28e846d1023d4ca915718b1a0905444cb This happens because of the following lock dependencies: 1. loop_ctl_mutex -> bdev->bd_mutex (when loop_control_ioctl calls loop_remove, which then calls del_gendisk; this also happens in loop_exit which eventually calls loop_remove) 2. bdev->bd_mutex -> mtd_table_mutex (when blkdev_get_by_dev calls __blkdev_get, which then calls blktrans_open) 3. mtd_table_mutex -> major_names_lock (when register_mtd_blktrans calls __register_blkdev) 4. major_names_lock -> loop_ctl_mutex (when blk_request_module calls loop_probe) Hence there's an overall dependency of: loop_ctl_mutex ----------> bdev->bd_mutex ^ | | | | v major_names_lock <--------- mtd_table_mutex We can break this circular dependency by holding mtd_table_mutex only for the required critical section in register_mtd_blktrans. This avoids the mtd_table_mutex -> major_names_lock dependency. Reported-and-tested-by: [email protected] Co-developed-by: Christoph Hellwig <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Desmond Cheong Zhi Xi <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.