commit ce615a08404c821bcb3c6f358b8f34307bfe30c9 Author: Greg Kroah-Hartman Date: Thu Mar 11 14:06:51 2021 +0100 Linux 5.4.105 Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Ross Schmidt Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Hulk Robot Link: https://lore.kernel.org/r/20210310132320.550932445@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit d17cf4cb1928898fae7e8bd11c0dc0af6c93812e Author: Pascal Terjan Date: Tue Feb 23 22:10:46 2021 +0000 nvme-pci: add quirks for Lexar 256GB SSD [ Upstream commit 6e6a6828c517fb6819479bf5187df5f39084eb9e ] Add the NVME_QUIRK_NO_NS_DESC_LIST and NVME_QUIRK_IGNORE_DEV_SUBNQN quirks for this buggy device. Reported and tested in https://bugs.mageia.org/show_bug.cgi?id=28417 Signed-off-by: Pascal Terjan Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1d08ff8464849be7b2054650b027d7eafc9bad93 Author: Julian Einwag Date: Tue Feb 16 13:25:43 2021 +0100 nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST. [ Upstream commit 5e112d3fb89703a4981ded60561b5647db3693bf ] The kernel fails to fully detect these SSDs, only the character devices are present: [ 10.785605] nvme nvme0: pci function 0000:04:00.0 [ 10.876787] nvme nvme1: pci function 0000:81:00.0 [ 13.198614] nvme nvme0: missing or invalid SUBNQN field. [ 13.198658] nvme nvme1: missing or invalid SUBNQN field. [ 13.206896] nvme nvme0: Shutdown timeout set to 20 seconds [ 13.215035] nvme nvme1: Shutdown timeout set to 20 seconds [ 13.225407] nvme nvme0: 16/0/0 default/read/poll queues [ 13.233602] nvme nvme1: 16/0/0 default/read/poll queues [ 13.239627] nvme nvme0: Identify Descriptors failed (8194) [ 13.246315] nvme nvme1: Identify Descriptors failed (8194) Adding the NVME_QUIRK_NO_NS_DESC_LIST fixes this problem. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205679 Signed-off-by: Julian Einwag Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Signed-off-by: Sasha Levin commit 9106a7844efb5dc32f6569ae83160500837a088e Author: Hans de Goede Date: Sat Jan 30 21:33:23 2021 +0100 HID: i2c-hid: Add I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for ITE8568 EC on Voyo Winpad A15 [ Upstream commit fc6a31b00739356809dd566e16f2c4325a63285d ] The ITE8568 EC on the Voyo Winpad A15 presents itself as an I2C-HID attached keyboard and mouse (which seems to never send any events). This needs the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirk, otherwise we get the following errors: [ 3688.770850] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3694.915865] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3701.059717] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3707.205944] i2c_hid i2c-ITE8568:00: failed to reset device. [ 3708.227940] i2c_hid i2c-ITE8568:00: can't add hid device: -61 [ 3708.236518] i2c_hid: probe of i2c-ITE8568:00 failed with error -61 Which leads to a significant boot delay. Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b5e10e9b30471679ee1612d34209a2aea669c6fd Author: Jisheng Zhang Date: Thu Dec 10 16:55:10 2020 +0800 mmc: sdhci-of-dwcmshc: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN [ Upstream commit 5f7dfda4f2cec580c135fd81d96a05006651c128 ] The SDHCI_PRESET_FOR_* registers are not set(all read as zeros), so set the quirk. Signed-off-by: Jisheng Zhang Link: https://lore.kernel.org/r/20201210165510.76b917e5@xhacker.debian Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 21f3fb36b5a213328d6000e73f9da357c6632d70 Author: AngeloGioacchino Del Regno Date: Wed Jan 13 19:33:33 2021 +0100 drm/msm/a5xx: Remove overwriting A5XX_PC_DBG_ECO_CNTL register [ Upstream commit 8f03c30cb814213e36032084a01f49a9e604a3e3 ] The PC_DBG_ECO_CNTL register on the Adreno A5xx family gets programmed to some different values on a per-model basis. At least, this is what we intend to do here; Unfortunately, though, this register is being overwritten with a static magic number, right after applying the GPU-specific configuration (including the GPU-specific quirks) and that is effectively nullifying the efforts. Let's remove the redundant and wrong write to the PC_DBG_ECO_CNTL register in order to retain the wanted configuration for the target GPU. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 1d113893ff9d1215b88e6ad4be43c5a4c428afa7 Author: Aswath Govindraju Date: Tue Jan 5 16:28:12 2021 +0530 misc: eeprom_93xx46: Add quirk to support Microchip 93LC46B eeprom [ Upstream commit f6f1f8e6e3eea25f539105d48166e91f0ab46dd1 ] A dummy zero bit is sent preceding the data during a read transfer by the Microchip 93LC46B eeprom (section 2.7 of[1]). This results in right shift of data during a read. In order to ignore this bit a quirk can be added to send an extra zero bit after the read address. Add a quirk to ignore the zero bit sent before data by adding a zero bit after the read address. [1] - https://www.mouser.com/datasheet/2/268/20001749K-277859.pdf Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210105105817.17644-3-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9f1f09887551e876693a6341b97aadd4f7d4e769 Author: Bjorn Helgaas Date: Tue Nov 10 16:00:57 2020 -0600 PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller [ Upstream commit 059983790a4c963d92943e55a61fca55be427d55 ] Add function 1 DMA alias quirk for Marvell 88SS9215 PCIe SSD Controller. Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679#c135 Link: https://lore.kernel.org/r/20201110220516.697934-1-helgaas@kernel.org Reported-by: John Smith Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit f40fdcb7ca294946fa58f5fe9b8f8ac9acf14997 Author: Chris Chiu Date: Tue Dec 8 14:04:14 2020 +0800 ASoC: Intel: bytcr_rt5640: Add quirk for ARCHOS Cesium 140 [ Upstream commit 1bea2256aa96a2d7b1b576eb74e29d79edc9bea8 ] Tha ARCHOS Cesium 140 tablet has problem with the jack-sensing, thus the heaset functions are not working. Add quirk for this model to select the correct input map, jack-detect options and channel map to enable jack sensing and headset microphone. This device uses IN1 for its internal MIC and JD2 for jack-detect. Signed-off-by: Chris Chiu Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20201208060414.27646-1-chiu@endlessos.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 242be7cddd258cec518f9d2ff790b2bf75713a1e Author: Jasper St. Pierre Date: Wed Dec 2 14:39:42 2020 +0800 ACPI: video: Add DMI quirk for GIGABYTE GB-BXBT-2807 [ Upstream commit 25417185e9b5ff90746d50769d2a3fcd1629e254 ] The GIGABYTE GB-BXBT-2807 is a mini-PC which uses off the shelf components, like an Intel GPU which is meant for mobile systems. As such, it, by default, has a backlight controller exposed. Unfortunately, the backlight controller only confuses userspace, which sees the existence of a backlight device node and has the unrealistic belief that there is actually a backlight there! Add a DMI quirk to force the backlight off on this system. Signed-off-by: Jasper St. Pierre Reviewed-by: Chris Chiu Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 86c8848d680adfc9877d022f2cfb10a65718c67a Author: Daniel Lee Kruse Date: Wed Sep 30 05:36:35 2020 +0200 media: cx23885: add more quirks for reset DMA on some AMD IOMMU [ Upstream commit dbf0b3a7b719eb3f72cb53c2ce7d34a012a9c261 ] On AMD Family 15h (Models 30h-3fh), I/O Memory Management Unit RiSC engine sometimes stalls, requiring a reset. As result, MythTV and w-scan won't scan channels on the AMD Kaveri APU with the Hauppauge QuadHD TV tuner card. For the solution I added the Input/Output Memory Management Unit's PCI Identity of 0x1423 to the broken_dev_id[] array, which is used by a quirks logic meant to fix similar problems with other AMD chipsets. Signed-off-by: Daniel Lee Kruse Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fd476c6d4e1a6988920def9cbbebb92ea9e2273f Author: Ethan Warth Date: Tue Nov 17 09:48:00 2020 +0100 HID: mf: add support for 0079:1846 Mayflash/Dragonrise USB Gamecube Adapter [ Upstream commit 1008230f2abeb624f6d71b2e1c424fa4eeebbf84 ] Mayflash/Dragonrise seems to have yet another device ID for one of their Gamecube controller adapters. Previous to this commit, the adapter registered only one /dev/input/js* device, and all controller inputs (from any controller) were mapped to this device. This patch defines the 1846 USB device ID and enables the HID_QUIRK_MULTI_INPUT quirk for it, which fixes that (with the patch, four /dev/input/js* devices are created, one for each of the four controller ports). Signed-off-by: Ethan Warth Tested-by: Wladimir J. van der Laan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ef9fa6bb858221a426a099b8965444ee7ff65703 Author: Hans de Goede Date: Mon Nov 23 16:16:25 2020 +0100 platform/x86: acer-wmi: Add ACER_CAP_KBD_DOCK quirk for the Aspire Switch 10E SW3-016 [ Upstream commit bf753400280d1384abb783efc0b42c491d6deec3 ] Add the Acer Aspire Switch 10E SW3-016 to the list of models which use the Acer Switch WMI interface for reporting SW_TABLET_MODE. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201123151625.5530-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 3a8eb20cb87b609dce6853bb5fd7324dac9cb718 Author: Hans de Goede Date: Mon Oct 19 20:56:28 2020 +0200 platform/x86: acer-wmi: Add support for SW_TABLET_MODE on Switch devices [ Upstream commit 5c54cb6c627e8f50f490e6b5656051a5ac29eab4 ] Add support for SW_TABLET_MODE on the Acer Switch 10 (SW5-012) and the acer Switch 10 (S1003) models. There is no way to detect if this is supported, so this uses DMI based quirks setting force_caps to ACER_CAP_KBD_DOCK (these devices have no other acer-wmi based functionality). The new SW_TABLET_MODE functionality can be tested on devices which are not in the DMI table by passing acer_wmi.force_caps=0x40 on the kernel commandline. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-6-hdegoede@redhat.com Signed-off-by: Sasha Levin commit e3a3a69da1778dcd4c9144b836329bd6b41430f1 Author: Hans de Goede Date: Mon Oct 19 20:56:27 2020 +0200 platform/x86: acer-wmi: Add ACER_CAP_SET_FUNCTION_MODE capability flag [ Upstream commit 82cb8a5c395ea5be20e0fe31a8fe84380a502ca5 ] Not all devices supporting WMID_GUID3 support the wmid3_set_function_mode() call, leading to errors like these: [ 60.138358] acer_wmi: Enabling RF Button failed: 0x1 - 0xff [ 60.140036] acer_wmi: Enabling Launch Manager failed: 0x1 - 0xff Add an ACER_CAP_SET_FUNCTION_MODE capability flag, so that these calls can be disabled through the new force_caps mechanism. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-5-hdegoede@redhat.com Signed-off-by: Sasha Levin commit b734af305c781c8bfde3ef8b5789937bd7a797d4 Author: Hans de Goede Date: Mon Oct 19 20:56:26 2020 +0200 platform/x86: acer-wmi: Add new force_caps module parameter [ Upstream commit 39aa009bb66f9d5fbd1e58ca4aa03d6e6f2c9915 ] Add a new force_caps module parameter to allow overriding the drivers builtin capability detection mechanism. This can be used to for example: -Disable rfkill functionality on devices where there is an AA OEM DMI record advertising non functional rfkill switches -Force loading of the driver on devices with a missing AA OEM DMI record Note that force_caps is -1 when unset, this allows forcing the capability field to 0, which results in acer-wmi only providing WMI hotkey handling while disabling all other (led, rfkill, backlight) functionality. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-4-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 02518024425190aecdae9356a6b6a52b0109fde5 Author: Hans de Goede Date: Mon Oct 19 20:56:25 2020 +0200 platform/x86: acer-wmi: Cleanup accelerometer device handling [ Upstream commit 9feb0763e4985ccfae632de3bb2f029cc8389842 ] Cleanup accelerometer device handling: -Drop acer_wmi_accel_destroy instead directly call input_unregister_device. -The information tracked by the CAP_ACCEL flag mirrors acer_wmi_accel_dev being NULL. Drop the CAP flag, this is a preparation change for allowing users to override the capability flags. Dropping the flag stops users from causing a NULL pointer dereference by forcing the capability. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-3-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 37b4324cb78e3766be8ee5c98c41ac7d8bade7fe Author: Hans de Goede Date: Mon Oct 19 20:56:24 2020 +0200 platform/x86: acer-wmi: Cleanup ACER_CAP_FOO defines [ Upstream commit 7c936d8d26afbc74deac0651d613dead2f76e81c ] Cleanup the ACER_CAP_FOO defines: -Switch to using BIT() macro. -The ACER_CAP_RFBTN flag is set, but it is never checked anywhere, drop it. -Drop the unused ACER_CAP_ANY define. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201019185628.264473-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 200e14759da5fed9e4b89390cecab4f428e17b12 Author: Tsuchiya Yuto Date: Wed Oct 28 23:23:46 2020 +0900 mwifiex: pcie: skip cancel_work_sync() on reset failure path [ Upstream commit 4add4d988f95f47493500a7a19c623827061589b ] If a reset is performed, but even the reset fails for some reasons (e.g., on Surface devices, the fw reset requires another quirks), cancel_work_sync() hangs in mwifiex_cleanup_pcie(). # firmware went into a bad state [...] [ 1608.281690] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex... [ 1608.282724] mwifiex_pcie 0000:03:00.0: rx_pending=0, tx_pending=1, cmd_pending=0 [ 1608.292400] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed [ 1608.292405] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed # reset performed after firmware went into a bad state [ 1609.394320] mwifiex_pcie 0000:03:00.0: WLAN FW already running! Skip FW dnld [ 1609.394335] mwifiex_pcie 0000:03:00.0: WLAN FW is active # but even the reset failed [ 1619.499049] mwifiex_pcie 0000:03:00.0: mwifiex_cmd_timeout_func: Timeout cmd id = 0xfa, act = 0xe000 [ 1619.499094] mwifiex_pcie 0000:03:00.0: num_data_h2c_failure = 0 [ 1619.499103] mwifiex_pcie 0000:03:00.0: num_cmd_h2c_failure = 0 [ 1619.499110] mwifiex_pcie 0000:03:00.0: is_cmd_timedout = 1 [ 1619.499117] mwifiex_pcie 0000:03:00.0: num_tx_timeout = 0 [ 1619.499124] mwifiex_pcie 0000:03:00.0: last_cmd_index = 0 [ 1619.499133] mwifiex_pcie 0000:03:00.0: last_cmd_id: fa 00 07 01 07 01 07 01 07 01 [ 1619.499140] mwifiex_pcie 0000:03:00.0: last_cmd_act: 00 e0 00 00 00 00 00 00 00 00 [ 1619.499147] mwifiex_pcie 0000:03:00.0: last_cmd_resp_index = 3 [ 1619.499155] mwifiex_pcie 0000:03:00.0: last_cmd_resp_id: 07 81 07 81 07 81 07 81 07 81 [ 1619.499162] mwifiex_pcie 0000:03:00.0: last_event_index = 2 [ 1619.499169] mwifiex_pcie 0000:03:00.0: last_event: 58 00 58 00 58 00 58 00 58 00 [ 1619.499177] mwifiex_pcie 0000:03:00.0: data_sent=0 cmd_sent=1 [ 1619.499185] mwifiex_pcie 0000:03:00.0: ps_mode=0 ps_state=0 [ 1619.499215] mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device # mwifiex_pcie_work hang happening [ 1823.233923] INFO: task kworker/3:1:44 blocked for more than 122 seconds. [ 1823.233932] Tainted: G WC OE 5.10.0-rc1-1-mainline #1 [ 1823.233935] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1823.233940] task:kworker/3:1 state:D stack: 0 pid: 44 ppid: 2 flags:0x00004000 [ 1823.233960] Workqueue: events mwifiex_pcie_work [mwifiex_pcie] [ 1823.233965] Call Trace: [ 1823.233981] __schedule+0x292/0x820 [ 1823.233990] schedule+0x45/0xe0 [ 1823.233995] schedule_timeout+0x11c/0x160 [ 1823.234003] wait_for_completion+0x9e/0x100 [ 1823.234012] __flush_work.isra.0+0x156/0x210 [ 1823.234018] ? flush_workqueue_prep_pwqs+0x130/0x130 [ 1823.234026] __cancel_work_timer+0x11e/0x1a0 [ 1823.234035] mwifiex_cleanup_pcie+0x28/0xd0 [mwifiex_pcie] [ 1823.234049] mwifiex_free_adapter+0x24/0xe0 [mwifiex] [ 1823.234060] _mwifiex_fw_dpc+0x294/0x560 [mwifiex] [ 1823.234074] mwifiex_reinit_sw+0x15d/0x300 [mwifiex] [ 1823.234080] mwifiex_pcie_reset_done+0x50/0x80 [mwifiex_pcie] [ 1823.234087] pci_try_reset_function+0x5c/0x90 [ 1823.234094] process_one_work+0x1d6/0x3a0 [ 1823.234100] worker_thread+0x4d/0x3d0 [ 1823.234107] ? rescuer_thread+0x410/0x410 [ 1823.234112] kthread+0x142/0x160 [ 1823.234117] ? __kthread_bind_mask+0x60/0x60 [ 1823.234124] ret_from_fork+0x22/0x30 [...] This is a deadlock caused by calling cancel_work_sync() in mwifiex_cleanup_pcie(): - Device resets are done via mwifiex_pcie_card_reset() - which schedules card->work to call mwifiex_pcie_card_reset_work() - which calls pci_try_reset_function(). - This leads to mwifiex_pcie_reset_done() be called on the same workqueue, which in turn calls - mwifiex_reinit_sw() and that calls - _mwifiex_fw_dpc(). The problem is now that _mwifiex_fw_dpc() calls mwifiex_free_adapter() in case firmware initialization fails. That ends up calling mwifiex_cleanup_pcie(). Note that all those calls are still running on the workqueue. So when mwifiex_cleanup_pcie() now calls cancel_work_sync(), it's really waiting on itself to complete, causing a deadlock. This commit fixes the deadlock by skipping cancel_work_sync() on a reset failure path. After this commit, when reset fails, the following output is expected to be shown: kernel: mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device kernel: mwifiex: Failed to bring up adapter: -5 kernel: mwifiex_pcie 0000:03:00.0: reinit failed: -5 To reproduce this issue, for example, try putting the root port of wifi into D3 (replace "00:1d.3" with your setup). # put into D3 (root port) sudo setpci -v -s 00:1d.3 CAP_PM+4.b=0b Cc: Maximilian Luz Signed-off-by: Tsuchiya Yuto Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201028142346.18355-1-kitakar@gmail.com Signed-off-by: Sasha Levin commit c699a89d385ca0119135182073d4f224c027a1e3 Author: Andrey Ryabinin Date: Wed Feb 17 17:30:04 2021 +0300 iommu/amd: Fix sleeping in atomic in increase_address_space() commit 140456f994195b568ecd7fc2287a34eadffef3ca upstream. increase_address_space() calls get_zeroed_page(gfp) under spin_lock with disabled interrupts. gfp flags passed to increase_address_space() may allow sleeping, so it comes to this: BUG: sleeping function called from invalid context at mm/page_alloc.c:4342 in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8 Call Trace: dump_stack+0x66/0x8b ___might_sleep+0xec/0x110 __alloc_pages_nodemask+0x104/0x300 get_zeroed_page+0x15/0x40 iommu_map_page+0xdd/0x3e0 amd_iommu_map+0x50/0x70 iommu_map+0x106/0x220 vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1] do_vfs_ioctl+0xa3/0x6f0 ksys_ioctl+0x66/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4e/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by moving get_zeroed_page() out of spin_lock/unlock section. Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()") Signed-off-by: Andrey Ryabinin Acked-by: Will Deacon Cc: Link: https://lore.kernel.org/r/20210217143004.19165-1-arbn@yandex-team.com Signed-off-by: Joerg Roedel Signed-off-by: Andrey Ryabinin Signed-off-by: Greg Kroah-Hartman commit fa56bf637eac0c77e3a41f66113270340cabc419 Author: Hans de Goede Date: Thu Feb 18 15:17:07 2021 -0800 ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter handling commit c27f3d011b08540e68233cf56274fdc34bebb9b5 upstream. ACPICA commit c9e0116952363b0fa815143dca7e9a2eb4fefa61 The handling of the generic_serial_bus (I2C) and GPIO op_regions in acpi_ev_address_space_dispatch() passes a number of extra parameters to the address-space handler through the address-space Context pointer (instead of using more function parameters). The Context is shared between threads, so if multiple threads try to call the handler for the same address-space at the same time, then a second thread could change the parameters of a first thread while the handler is running for the first thread. An example of this race hitting is the Lenovo Yoga Tablet2 1015L, where there are both attrib_bytes accesses and attrib_byte accesses to the same address-space. The attrib_bytes access stores the number of bytes to transfer in Context->access_length. Where as for the attrib_byte access the number of bytes to transfer is always 1 and field_obj->Field.access_length is unused (so 0). Both types of accesses racing from different threads leads to the following problem: 1. Thread a. starts an attrib_bytes access, stores a non 0 value from field_obj->Field.access_length in Context->access_length 2. Thread b. starts an attrib_byte access, stores 0 in Context->access_length 3. Thread a. calls i2c_acpi_space_handler() (under Linux). Which sees that the access-type is ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE and calls acpi_gsb_i2c_read_bytes(..., Context->access_length) 4. At this point Context->access_length is 0 (set by thread b.) rather then the field_obj->Field.access_length value from thread a. This 0 length reads leads to the following errors being logged: i2c i2c-0: adapter quirk: no zero length (addr 0x0078, size 0, read) i2c i2c-0: i2c read 0 bytes from client@0x78 starting at reg 0x0 failed, error: -95 Note this is just an example of the problems which this race can cause. There are likely many more (sporadic) problems caused by this race. This commit adds a new context_mutex to struct acpi_object_addr_handler and makes acpi_ev_address_space_dispatch() take that mutex when using the shared Context to pass extra parameters to an address-space handler, fixing this race. Note the new mutex must be taken *after* exiting the interpreter, therefor the existing acpi_ex_exit_interpreter() call is moved to above the code which stores the extra parameters in the Context. Link: https://github.com/acpica/acpica/commit/c9e01169 Signed-off-by: Hans de Goede Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f27765adb3f67ba2542f3dfe147257be5a5549e5 Author: Jeffle Xu Date: Mon Feb 8 22:46:38 2021 -0500 dm table: fix zoned iterate_devices based device capability checks commit 24f6b6036c9eec21191646930ad42808e6180510 upstream. Fix dm_table_supports_zoned_model() and invert logic of both iterate_devices_callout_fn so that all devices' zoned capabilities are properly checked. Add one more parameter to dm_table_any_dev_attr(), which is actually used as the @data parameter of iterate_devices_callout_fn, so that dm_table_matches_zone_sectors() can be replaced by dm_table_any_dev_attr(). Fixes: dd88d313bef02 ("dm table: add zoned block devices validation") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer [jeffle: also convert partial completion check] Signed-off-by: Greg Kroah-Hartman commit 06ef17b886762e4f921d755453f349d84f51ca60 Author: Jeffle Xu Date: Mon Feb 8 22:34:36 2021 -0500 dm table: fix DAX iterate_devices based device capability checks commit 5b0fab508992c2e120971da658ce80027acbc405 upstream. Fix dm_table_supports_dax() and invert logic of both iterate_devices_callout_fn so that all devices' DAX capabilities are properly checked. Fixes: 545ed20e6df6 ("dm: add infrastructure for DAX support") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit b8aedc65db40cdb2393a9ae1b6193c6c297ae5c8 Author: Jeffle Xu Date: Tue Feb 2 11:35:28 2021 +0800 dm table: fix iterate_devices based device capability checks commit a4c8dd9c2d0987cf542a2a0c42684c9c6d78a04e upstream. According to the definition of dm_iterate_devices_fn: * This function must iterate through each section of device used by the * target until it encounters a non-zero return code, which it then returns. * Returns zero if no callout returned non-zero. For some target type (e.g. dm-stripe), one call of iterate_devices() may iterate multiple underlying devices internally, in which case a non-zero return code returned by iterate_devices_callout_fn will stop the iteration in advance. No iterate_devices_callout_fn should return non-zero unless device iteration should stop. Rename dm_table_requires_stable_pages() to dm_table_any_dev_attr() and elevate it for reuse to stop iterating (and return non-zero) on the first device that causes iterate_devices_callout_fn to return non-zero. Use dm_table_any_dev_attr() to properly iterate through devices. Rename device_is_nonrot() to device_is_rotational() and invert logic accordingly to fix improper disposition. Fixes: c3c4555edd10 ("dm table: clear add_random unless all devices have it set") Fixes: 4693c9668fdc ("dm table: propagate non rotational flag") Cc: stable@vger.kernel.org Signed-off-by: Jeffle Xu Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit c1f5fc082beb8653f814711b838b51186cc696e2 Author: Alexander Lobakin Date: Tue Apr 21 16:41:08 2020 +0300 net: dsa: add GRO support via gro_cells commit e131a5634830047923c694b4ce0c3b31745ff01b upstream. gro_cells lib is used by different encapsulating netdevices, such as geneve, macsec, vxlan etc. to speed up decapsulated traffic processing. CPU tag is a sort of "encapsulation", and we can use the same mechs to greatly improve overall DSA performance. skbs are passed to the GRO layer after removing CPU tags, so we don't need any new packet offload types as it was firstly proposed by me in the first GRO-over-DSA variant [1]. The size of struct gro_cells is sizeof(void *), so hot struct dsa_slave_priv becomes only 4/8 bytes bigger, and all critical fields remain in one 32-byte cacheline. The other positive side effect is that drivers for network devices that can be shipped as CPU ports of DSA-driven switches can now use napi_gro_frags() to pass skbs to kernel. Packets built that way are completely non-linear and are likely being dropped without GRO. This was tested on to-be-mainlined-soon Ethernet driver that uses napi_gro_frags(), and the overall performance was on par with the variant from [1], sometimes even better due to minimal overhead. net.core.gro_normal_batch tuning may help to push it to the limit on particular setups and platforms. iperf3 IPoE VLAN NAT TCP forwarding (port1.218 -> port0) setup on 1.2 GHz MIPS board: 5.7-rc2 baseline: [ID] Interval Transfer Bitrate Retr [ 5] 0.00-120.01 sec 9.00 GBytes 644 Mbits/sec 413 sender [ 5] 0.00-120.00 sec 8.99 GBytes 644 Mbits/sec receiver Iface RX packets TX packets eth0 7097731 7097702 port0 426050 6671829 port1 6671681 425862 port1.218 6671677 425851 With this patch: [ID] Interval Transfer Bitrate Retr [ 5] 0.00-120.01 sec 12.2 GBytes 870 Mbits/sec 122 sender [ 5] 0.00-120.00 sec 12.2 GBytes 870 Mbits/sec receiver Iface RX packets TX packets eth0 9474792 9474777 port0 455200 353288 port1 9019592 455035 port1.218 353144 455024 v2: - Add some performance examples in the commit message; - No functional changes. [1] https://lore.kernel.org/netdev/20191230143028.27313-1-alobakin@dlink.ru/ Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Cc: Pali Rohár Signed-off-by: Greg Kroah-Hartman