commit f259ee2f037925eaf3d0c53f7d7aa2d3fae4ea13 Author: Greg Kroah-Hartman Date: Sun Aug 8 09:06:57 2021 +0200 Linux 5.13.9 Link: https://lore.kernel.org/r/20210806081113.718626745@linuxfoundation.org Tested-by: Fox Chen Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Aakash Hemadri Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 4288f43d9e0ebe8d1c0ca2cf88b0e4ea13f7dfa8 Author: Guenter Roeck Date: Sun Aug 1 20:00:23 2021 -0700 spi: mediatek: Fix fifo transfer commit 0d5c3954b35eddff0da0436c31e8d721eceb7dc2 upstream. Commit 3a70dd2d0503 ("spi: mediatek: fix fifo rx mode") claims that fifo RX mode was never handled, and adds the presumably missing code to the FIFO transfer function. However, the claim that receive data was not handled is incorrect. It was handled as part of interrupt handling after the transfer was complete. The code added with the above mentioned commit reads data from the receive FIFO before the transfer is started, which is wrong. This results in an actual transfer error on a Hayato Chromebook. Remove the code trying to handle receive data before the transfer is started to fix the problem. Fixes: 3a70dd2d0503 ("spi: mediatek: fix fifo rx mode") Cc: Peter Hess Cc: Frank Wunderlich Cc: Tzung-Bi Shih Cc: Hsin-Yi Wang Signed-off-by: Guenter Roeck Tested-by: Hsin-Yi Wang Tested-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20210802030023.1748777-1-linux@roeck-us.net Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit fad0494f626f1a6b2ea76cd7c6d137d1b4961636 Author: Stylon Wang Date: Wed Jul 21 12:25:24 2021 +0800 drm/amd/display: Fix ASSR regression on embedded panels commit 6be50f5d83adc9541de3d5be26e968182b5ac150 upstream. [Why] Regression found in some embedded panels traces back to the earliest upstreamed ASSR patch. The changed code flow are causing problems with some panels. [How] - Change ASSR enabling code while preserving original code flow as much as possible - Simplify the code on guarding with internal display flag Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213779 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1620 Reviewed-by: Alex Deucher Signed-off-by: Stylon Wang Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 02db470b866fd06d8951f599e986166892aa2cbe Author: Greg Kroah-Hartman Date: Fri Aug 6 08:28:48 2021 +0200 Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout" This reverts commit 5e65819a006ec8a8df2f8639dc26ef0cfaa95ae7 which is commit cb011044e34c293e139570ce5c01aed66a34345c upstream. It is reported to cause problems with systems and probably should not have been backported in the first place :( Link: https://lore.kernel.org/r/20210803165108.4154cd52@endymion Reported-by: Jean Delvare Cc: Jan Kiszka Cc: Guenter Roeck Cc: Guenter Roeck Cc: Wim Van Sebroeck Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c268b30ff4e096ecf4a1e8f407f9bac444ef38a2 Author: Greg Kroah-Hartman Date: Thu Aug 5 20:58:57 2021 +0200 Revert "Bluetooth: Shutdown controller after workqueues are flushed or cancelled" This reverts commit c19a2820df32b94d1d4fb65e96ae36f97dddda56 which is commit 0ea9fd001a14ebc294f112b0361a4e601551d508 upstream. It has been reported to have problems: https://lore.kernel.org/linux-bluetooth/8735ryk0o7.fsf@baylibre.com/ Reported-by: Guenter Roeck Cc: Kai-Heng Feng Cc: Marcel Holtmann Cc: Sasha Levin Link: https://lore.kernel.org/r/efee3a58-a4d2-af22-0931-e81b877ab539@roeck-us.net Signed-off-by: Greg Kroah-Hartman commit 989b27104a97642f6a1ed563ee32bec95a2552e2 Author: Jens Axboe Date: Fri Jul 23 11:53:54 2021 -0600 io_uring: explicitly catch any illegal async queue attempt [ Upstream commit 991468dcf198bb87f24da330676724a704912b47 ] Catch an illegal case to queue async from an unrelated task that got the ring fd passed to it. This should not be possible to hit, but better be proactive and catch it explicitly. io-wq is extended to check for early IO_WQ_WORK_CANCEL being set on a work item as well, so it can run the request through the normal cancelation path. Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f7be9c72d1de9307a7fbc0c394996268d4fdc4e9 Author: Jens Axboe Date: Fri Jul 23 11:49:29 2021 -0600 io_uring: never attempt iopoll reissue from release path [ Upstream commit 3c30ef0f78cfb36fdb13753794b0384cf7e37cc9 ] There are two reasons why this shouldn't be done: 1) Ring is exiting, and we're canceling requests anyway. Any request should be canceled anyway. In theory, this could iterate for a number of times if someone else is also driving the target block queue into request starvation, however the likelihood of this happening is miniscule. 2) If the original task decided to pass the ring to another task, then we don't want to be reissuing from this context as it may be an unrelated task or context. No assumptions should be made about the context in which ->release() is run. This can only happen for pure read/write, and we'll get -EFAULT on them anyway. Link: https://lore.kernel.org/io-uring/YPr4OaHv0iv0KTOc@zeniv-ca.linux.org.uk/ Reported-by: Al Viro Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit eb9b9c610f25f4b4e526d7ebe0303f5aef1cde84 Author: Nicholas Kazlauskas Date: Wed Jul 7 13:19:14 2021 -0400 drm/amd/display: Fix max vstartup calculation for modes with borders [ Upstream commit d7940911fc0754d99b208f0e3098762d39f403a0 ] [Why] Vertical and horizontal borders in timings are treated as increasing the active area - vblank and hblank actually shrink. Our input into DML does not include these borders so it incorrectly assumes it has more time than available for vstartup and tmdl calculations for some modes with borders. An example of such a timing would be 640x480@72Hz: h_total: 832 h_border_left: 8 h_addressable: 640 h_border_right: 8 h_front_porch: 16 h_sync_width: 40 v_total: 520 v_border_top: 8 v_addressable: 480 v_border_bottom: 8 v_front_porch: 1 v_sync_width: 3 pix_clk_100hz: 315000 [How] Include borders as part of destination vactive/hactive. This change DCN20+ so it has wide impact, but the destination vactive and hactive are only really used for vstartup calculation anyway. Most modes do not have vertical or horizontal borders. Reviewed-by: Dmytro Laktyushkin Acked-by: Rodrigo Siqueira Signed-off-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9cc57c6cdd24c54c9ac9231097906196b20c48dd Author: Victor Lu Date: Thu Jun 24 11:05:42 2021 -0400 drm/amd/display: Fix comparison error in dcn21 DML [ Upstream commit ec3102dc6b36c692104c4a0546d4119de59a3bc1 ] [why] A comparison error made it possible to not iterate through all the specified prefetch modes. [how] Correct "<" to "<=" Reviewed-by: Dmytro Laktyushkin Reviewed-by: Yongqiang Sun Acked-by: Rodrigo Siqueira Signed-off-by: Victor Lu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b3b7be42461057a1b78bf30afb7301ceb9a44d41 Author: Keith Busch Date: Mon Jul 19 09:44:39 2021 -0700 nvme: fix nvme_setup_command metadata trace event [ Upstream commit 234211b8dd161fa25f192c78d5a8d2dd6bf920a0 ] The metadata address is set after the trace event, so the trace is not capturing anything useful. Rather than logging the memory address, it's useful to know if the command carries a metadata payload, so change the trace event to log that true/false state instead. Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d26ac2d83b026ec21b4fd7dd15211c9a635ea668 Author: Borislav Petkov Date: Tue Jul 20 09:28:09 2021 +0200 efi/mokvar: Reserve the table only if it is in boot services data [ Upstream commit 47e1e233e9d822dfda068383fb9a616451bda703 ] One of the SUSE QA tests triggered: localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000 which comes from x86's version of efi_arch_mem_reserve() trying to reserve a memory region. Usually, that function expects EFI_BOOT_SERVICES_DATA memory descriptors but the above case is for the MOKvar table which is allocated in the EFI shim as runtime services. That lead to a fix changing the allocation of that table to boot services. However, that fix broke booting SEV guests with that shim leading to this kernel fix 8d651ee9c71b ("x86/ioremap: Map EFI-reserved memory as encrypted for SEV") which extended the ioremap hint to map reserved EFI boot services as decrypted too. However, all that wasn't needed, IMO, because that error message in efi_arch_mem_reserve() was innocuous in this case - if the MOKvar table is not in boot services, then it doesn't need to be reserved in the first place because it is, well, in runtime services which *should* be reserved anyway. So do that reservation for the MOKvar table only if it is allocated in boot services data. I couldn't find any requirement about where that table should be allocated in, unlike the ESRT which allocation is mandated to be done in boot services data by the UEFI spec. Signed-off-by: Borislav Petkov Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit dbdf7e3d5684cabd8b33128e4545ad0688df5c16 Author: Peter Ujfalusi Date: Sat Jul 17 15:28:19 2021 +0300 ASoC: ti: j721e-evm: Check for not initialized parent_clk_id [ Upstream commit 82d28b67f780910f816fe1cfb0f676fc38c4cbb3 ] During probe the parent_clk_id is set to -1 which should not be used to array index within hsdiv_rates[]. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210717122820.1467-3-peter.ujfalusi@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f248077aef20b992d143a3af535b6eef9ca83e7f Author: Peter Ujfalusi Date: Sat Jul 17 15:28:18 2021 +0300 ASoC: ti: j721e-evm: Fix unbalanced domain activity tracking during startup [ Upstream commit 78d2a05ef22e7b5863b01e073dd6a06b3979bb00 ] In case of an error within j721e_audio_startup() the domain->active must be decremented to avoid unbalanced counter. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210717122820.1467-2-peter.ujfalusi@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a35d559db687aef53edd58482d58d450a250f7c6 Author: Pravin B Shelar Date: Thu Jul 15 16:59:00 2021 -0700 net: Fix zero-copy head len calculation. [ Upstream commit a17ad0961706244dce48ec941f7e476a38c0e727 ] In some cases skb head could be locked and entire header data is pulled from skb. When skb_zerocopy() called in such cases, following BUG is triggered. This patch fixes it by copying entire skb in such cases. This could be optimized incase this is performance bottleneck. ---8<--- kernel BUG at net/core/skbuff.c:2961! invalid opcode: 0000 [#1] SMP PTI CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE 5.4.0-77-generic #86-Ubuntu Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:skb_zerocopy+0x37a/0x3a0 RSP: 0018:ffffbcc70013ca38 EFLAGS: 00010246 Call Trace: queue_userspace_packet+0x2af/0x5e0 [openvswitch] ovs_dp_upcall+0x3d/0x60 [openvswitch] ovs_dp_process_packet+0x125/0x150 [openvswitch] ovs_vport_receive+0x77/0xd0 [openvswitch] netdev_port_receive+0x87/0x130 [openvswitch] netdev_frame_hook+0x4b/0x60 [openvswitch] __netif_receive_skb_core+0x2b4/0xc90 __netif_receive_skb_one_core+0x3f/0xa0 __netif_receive_skb+0x18/0x60 process_backlog+0xa9/0x160 net_rx_action+0x142/0x390 __do_softirq+0xe1/0x2d6 irq_exit+0xae/0xb0 do_IRQ+0x5a/0xf0 common_interrupt+0xf/0xf Code that triggered BUG: int skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) { int i, j = 0; int plen = 0; /* length of skb->head fragment */ int ret; struct page *page; unsigned int offset; BUG_ON(!from->head_frag && !hlen); Signed-off-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4bf6168d0b6ad6d81a76a325a2ef4610bccc116b Author: Oder Chiou Date: Fri Jul 16 16:58:53 2021 +0800 ASoC: rt5682: Fix the issue of garbled recording after powerd_dbus_suspend [ Upstream commit 6a503e1c455316fd0bfd8188c0a62cce7c5525ca ] While using the DMIC recording, the garbled data will be captured by the DMIC. It is caused by the critical power of PLL closed in the jack detect function. Signed-off-by: Oder Chiou Link: https://lore.kernel.org/r/20210716085853.20170-1-oder_chiou@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3cadaeae64dc4d9ab3cc09cecd2a5153111b2426 Author: Jia He Date: Thu Jul 15 16:08:21 2021 +0800 qed: fix possible unpaired spin_{un}lock_bh in _qed_mcp_cmd_and_union() [ Upstream commit 6206b7981a36476f4695d661ae139f7db36a802d ] Liajian reported a bug_on hit on a ThunderX2 arm64 server with FastLinQ QL41000 ethernet controller: BUG: scheduling while atomic: kworker/0:4/531/0x00000200 [qed_probe:488()]hw prepare failed kernel BUG at mm/vmalloc.c:2355! Internal error: Oops - BUG: 0 [#1] SMP CPU: 0 PID: 531 Comm: kworker/0:4 Tainted: G W 5.4.0-77-generic #86-Ubuntu pstate: 00400009 (nzcv daif +PAN -UAO) Call trace: vunmap+0x4c/0x50 iounmap+0x48/0x58 qed_free_pci+0x60/0x80 [qed] qed_probe+0x35c/0x688 [qed] __qede_probe+0x88/0x5c8 [qede] qede_probe+0x60/0xe0 [qede] local_pci_probe+0x48/0xa0 work_for_cpu_fn+0x24/0x38 process_one_work+0x1d0/0x468 worker_thread+0x238/0x4e0 kthread+0xf0/0x118 ret_from_fork+0x10/0x18 In this case, qed_hw_prepare() returns error due to hw/fw error, but in theory work queue should be in process context instead of interrupt. The root cause might be the unpaired spin_{un}lock_bh() in _qed_mcp_cmd_and_union(), which causes botton half is disabled incorrectly. Reported-by: Lijian Zhang Signed-off-by: Jia He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a6b2ef5b5ffbad5bc6697fc1cf51fe92bdc3aaea Author: Takashi Iwai Date: Wed Jul 14 19:00:22 2021 +0200 r8152: Fix a deadlock by doubly PM resume [ Upstream commit 776ac63a986d211286230c4fd70f85390eabedcd ] r8152 driver sets up the MAC address at reset-resume, while rtl8152_set_mac_address() has the temporary autopm get/put. This may lead to a deadlock as the PM lock has been already taken for the execution of the runtime PM callback. This patch adds the workaround to avoid the superfluous autpm when called from rtl8152_reset_resume(). Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194 Signed-off-by: Takashi Iwai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5feeb2da23e5985aaf49724558d6350093528f33 Author: Takashi Iwai Date: Wed Jul 14 19:00:21 2021 +0200 r8152: Fix potential PM refcount imbalance [ Upstream commit 9c23aa51477a37f8b56c3c40192248db0663c196 ] rtl8152_close() takes the refcount via usb_autopm_get_interface() but it doesn't release when RTL8152_UNPLUG test hits. This may lead to the imbalance of PM refcount. This patch addresses it. Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194 Signed-off-by: Takashi Iwai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bf7dd85e9e02beb577ba2f7fb2408b8f6e8deb47 Author: Axel Lin Date: Fri Jul 2 22:21:40 2021 +0800 regulator: mtk-dvfsrc: Fix wrong dev pointer for devm_regulator_register [ Upstream commit ea986908ccfcc53204a03bb0841227e1b26578c4 ] If use dev->parent, the regulator_unregister will not be called when this driver is unloaded. Fix it by using dev instead. Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210702142140.2678130-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ee37879e24c4480ab05aa0eb601efbfd91ea9acc Author: Kyle Russell Date: Mon Jun 21 21:09:41 2021 -0400 ASoC: tlv320aic31xx: fix reversed bclk/wclk master bits [ Upstream commit 9cf76a72af6ab81030dea6481b1d7bdd814fbdaf ] These are backwards from Table 7-71 of the TLV320AIC3100 spec [1]. This was broken in 12eb4d66ba2e when BCLK_MASTER and WCLK_MASTER were converted from 0x08 and 0x04 to BIT(2) and BIT(3), respectively. -#define AIC31XX_BCLK_MASTER 0x08 -#define AIC31XX_WCLK_MASTER 0x04 +#define AIC31XX_BCLK_MASTER BIT(2) +#define AIC31XX_WCLK_MASTER BIT(3) Probably just a typo since the defines were not listed in bit order. [1] https://www.ti.com/lit/gpn/tlv320aic3100 Signed-off-by: Kyle Russell Link: https://lore.kernel.org/r/20210622010941.241386-1-bkylerussell@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c2fdcb148e332d2c9f666fad3592fa462485d320 Author: Alain Volmat Date: Wed Jun 30 10:45:19 2021 +0200 spi: stm32h7: fix full duplex irq handler handling [ Upstream commit e4a5c19888a5f8a9390860ca493e643be58c8791 ] In case of Full-Duplex mode, DXP flag is set when RXP and TXP flags are set. But to avoid 2 different handlings, just add TXP and RXP flag in the mask instead of DXP, and then keep the initial handling of TXP and RXP events. Also rephrase comment about EOTIE which is one of the interrupt enable bits. It is not triggered by any event. Signed-off-by: Amelie Delaunay Signed-off-by: Alain Volmat Reviewed-by: Amelie Delaunay Link: https://lore.kernel.org/r/1625042723-661-3-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 64d62c4e4ccb4a30c35f4cfff155648bb5ca16d1 Author: Axel Lin Date: Sun Jun 27 16:04:18 2021 +0800 regulator: rt5033: Fix n_voltages settings for BUCK and LDO [ Upstream commit 6549c46af8551b346bcc0b9043f93848319acd5c ] For linear regulators, the n_voltages should be (max - min) / step + 1. Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f. If value is from 20 to 31, the voltage will all be fixed to 3V. And LDO also, just vout range is different from 1.2v to 3v, step is the same. If value is from 18 to 31, the voltage will also be fixed to 3v. Signed-off-by: Axel Lin Reviewed-by: ChiYuan Huang Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2e4e8df287c1854b84851f8c93f4788b59e38a72 Author: ChiYuan Huang Date: Sat Jun 26 23:58:32 2021 +0800 regulator: rtmv20: Fix wrong mask for strobe-polarity-high [ Upstream commit 2b6a761be079f9fa8abf3157b5679a6f38885db4 ] Fix wrong mask for strobe-polarity-high. Signed-off-by: ChiYuan Huang In-reply-to: Reviewed-by: Axel Lin Link: https://lore.kernel.org/r/1624723112-26653-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1c5b8c4e4cb532b2055200d3f512b761d485a5af Author: Rander Wang Date: Fri Jun 25 15:50:39 2021 -0500 ASoC: Intel: boards: fix xrun issue on platform with max98373 [ Upstream commit 33c8516841ea4fa12fdb8961711bf95095c607ee ] On TGL platform with max98373 codec the trigger start sequence is fe first, then codec component and sdw link is the last. Recently a delay was introduced in max98373 codec driver and this resulted to the start of sdw stream transmission was delayed and the data transmitted by fw can't be consumed by sdw controller, so xrun happened. Adding delay in trigger function is a bad idea. This patch enable spk pin in prepare function and disable it in hw_free to avoid xrun issue caused by delay in trigger. Fixes: 3a27875e91fb ("ASoC: max98373: Added 30ms turn on/off time delay") BugLink: https://github.com/thesofproject/sof/issues/4066 Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Signed-off-by: Rander Wang Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210625205042.65181-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 497a0258df141d9db8f4fe32c82c29d687d8e04f Author: Pierre-Louis Bossart Date: Wed May 5 11:36:58 2021 -0500 ASoC: Intel: boards: create sof-maxim-common module [ Upstream commit 9c5046e4b3e736eec5b9a8f1d59c07bb0ed78a7a ] sof_maxim_common.o is linked twice, move to a dedicated module. Also clean-up interfaces to use a consistent 'max_98373' prefix for all symbols. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20210505163705.305616-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 301f2270d3ac06ab43c672809db5b3da03013bc4 Author: Pierre-Louis Bossart Date: Wed May 5 11:36:57 2021 -0500 ASoC: Intel: boards: handle hda-dsp-common as a module hda-dsp-common.o is linked multiple times due to copy/paste and inertia. Move to a dedicated module with a namespace. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20210505163705.305616-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown commit c348419f365b8efcb7651e83a0bb8b02cc6f17fb Author: Vladimir Oltean Date: Tue Jul 13 12:37:19 2021 +0300 net: dsa: sja1105: fix address learning getting disabled on the CPU port [ Upstream commit b0b33b048dcfbd7da82c3cde4fab02751dfab4d6 ] In May 2019 when commit 640f763f98c2 ("net: dsa: sja1105: Add support for Spanning Tree Protocol") was introduced, the comment that "STP does not get called for the CPU port" was true. This changed after commit 0394a63acfe2 ("net: dsa: enable and disable all ports") in August 2019 and went largely unnoticed, because the sja1105_bridge_stp_state_set() method did nothing different compared to the static setup done by sja1105_init_mac_settings(). With the ability to turn address learning off introduced by the blamed commit, there is a new priv->learn_ena port mask in the driver. When sja1105_bridge_stp_state_set() gets called and we are in BR_STATE_LEARNING or later, address learning is enabled or not depending on priv->learn_ena & BIT(port). So what happens is that priv->learn_ena is not being set from anywhere for the CPU port, and the static configuration done by sja1105_init_mac_settings() is being overwritten. To solve this, acknowledge that the static configuration of STP state is no longer necessary because the STP state is being set by the DSA core now, but what is necessary is to set priv->learn_ena for the CPU port. Fixes: 4d9423549501 ("net: dsa: sja1105: offload bridge port flags to device") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ee064ade19a60fa07832c93f6037412ea30755b Author: Vladimir Oltean Date: Mon May 24 16:14:13 2021 +0300 net: dsa: sja1105: parameterize the number of ports [ Upstream commit 542043e91df452ed09f382d8c41cdf3788f31b5e ] The sja1105 driver will gain support for the next-gen SJA1110 switch, which is very similar except for the fact it has more than 5 ports. So we need to replace the hardcoded SJA1105_NUM_PORTS in this driver with ds->num_ports. This patch is as mechanical as possible (save for the fact that ds->num_ports is not an integer constant expression). Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1ce09f0ae45586c7917cd80bea5817a546d6d936 Author: Ronnie Sahlberg Date: Wed Jul 28 16:38:29 2021 +1000 cifs: add missing parsing of backupuid [ Upstream commit b946dbcfa4df80ec81b442964e07ad37000cc059 ] We lost parsing of backupuid in the switch to new mount API. Add it back. Signed-off-by: Ronnie Sahlberg Reviewed-by: Shyam Prasad N Cc: # v5.11+ Reported-by: Xiaoli Feng Signed-off-by: Steve French Signed-off-by: Sasha Levin commit cf5663d06bc367c433a6b32badc1a372163afbcf Author: Ronnie Sahlberg Date: Thu Jul 8 09:24:16 2021 +1000 cifs: use helpers when parsing uid/gid mount options and validate them [ Upstream commit e0a3cbcd5cef00cace01546cc6eaaa3b31940da9 ] Use the nice helpers to initialize and the uid/gid/cred_uid when passed as mount arguments. Signed-off-by: Ronnie Sahlberg Acked-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2abe7e0f1983aed1a3c62ddab0d222befc162ad8 Author: John Fastabend Date: Tue Jul 27 09:04:59 2021 -0700 bpf, sockmap: On cleanup we additionally need to remove cached skb [ Upstream commit 476d98018f32e68e7c5d4e8456940cf2b6d66f10 ] Its possible if a socket is closed and the receive thread is under memory pressure it may have cached a skb. We need to ensure these skbs are free'd along with the normal ingress_skb queue. Before 799aa7f98d53 ("skmsg: Avoid lock_sock() in sk_psock_backlog()") tear down and backlog processing both had sock_lock for the common case of socket close or unhash. So it was not possible to have both running in parrallel so all we would need is the kfree in those kernels. But, latest kernels include the commit 799aa7f98d5e and this requires a bit more work. Without the ingress_lock guarding reading/writing the state->skb case its possible the tear down could run before the state update causing it to leak memory or worse when the backlog reads the state it could potentially run interleaved with the tear down and we might end up free'ing the state->skb from tear down side but already have the reference from backlog side. To resolve such races we wrap accesses in ingress_lock on both sides serializing tear down and backlog case. In both cases this only happens after an EAGAIN error case so having an extra lock in place is likely fine. The normal path will skip the locks. Note, we check state->skb before grabbing lock. This works because we can only enqueue with the mutex we hold already. Avoiding a race on adding state->skb after the check. And if tear down path is running that is also fine if the tear down path then removes state->skb we will simply set skb=NULL and the subsequent goto is skipped. This slight complication avoids locking in normal case. With this fix we no longer see this warning splat from tcp side on socket close when we hit the above case with redirect to ingress self. [224913.935822] WARNING: CPU: 3 PID: 32100 at net/core/stream.c:208 sk_stream_kill_queues+0x212/0x220 [224913.935841] Modules linked in: fuse overlay bpf_preload x86_pkg_temp_thermal intel_uncore wmi_bmof squashfs sch_fq_codel efivarfs ip_tables x_tables uas xhci_pci ixgbe mdio xfrm_algo xhci_hcd wmi [224913.935897] CPU: 3 PID: 32100 Comm: fgs-bench Tainted: G I 5.14.0-rc1alu+ #181 [224913.935908] Hardware name: Dell Inc. Precision 5820 Tower/002KVM, BIOS 1.9.2 01/24/2019 [224913.935914] RIP: 0010:sk_stream_kill_queues+0x212/0x220 [224913.935923] Code: 8b 83 20 02 00 00 85 c0 75 20 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 df e8 2b 11 fe ff eb c3 0f 0b e9 7c ff ff ff 0f 0b eb ce <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 0f 1f 44 00 00 41 57 41 [224913.935932] RSP: 0018:ffff88816271fd38 EFLAGS: 00010206 [224913.935941] RAX: 0000000000000ae8 RBX: ffff88815acd5240 RCX: dffffc0000000000 [224913.935948] RDX: 0000000000000003 RSI: 0000000000000ae8 RDI: ffff88815acd5460 [224913.935954] RBP: ffff88815acd5460 R08: ffffffff955c0ae8 R09: fffffbfff2e6f543 [224913.935961] R10: ffffffff9737aa17 R11: fffffbfff2e6f542 R12: ffff88815acd5390 [224913.935967] R13: ffff88815acd5480 R14: ffffffff98d0c080 R15: ffffffff96267500 [224913.935974] FS: 00007f86e6bd1700(0000) GS:ffff888451cc0000(0000) knlGS:0000000000000000 [224913.935981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [224913.935988] CR2: 000000c0008eb000 CR3: 00000001020e0005 CR4: 00000000003706e0 [224913.935994] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [224913.936000] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [224913.936007] Call Trace: [224913.936016] inet_csk_destroy_sock+0xba/0x1f0 [224913.936033] __tcp_close+0x620/0x790 [224913.936047] tcp_close+0x20/0x80 [224913.936056] inet_release+0x8f/0xf0 [224913.936070] __sock_release+0x72/0x120 [224913.936083] sock_close+0x14/0x20 Fixes: a136678c0bdbb ("bpf: sk_msg, zap ingress queue on psock down") Signed-off-by: John Fastabend Signed-off-by: Andrii Nakryiko Acked-by: Jakub Sitnicki Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20210727160500.1713554-3-john.fastabend@gmail.com Signed-off-by: Sasha Levin commit 96b1d399a4f2ae73e0cc51ba4624c405fe4165c4 Author: Cong Wang Date: Mon Jun 14 19:13:41 2021 -0700 skmsg: Pass source psock to sk_psock_skb_redirect() [ Upstream commit 42830571f1fd9751b3fbf38084bbb253320e185f ] sk_psock_skb_redirect() only takes skb as a parameter, we will need to know where this skb is from, so just pass the source psock to this function as a new parameter. This patch prepares for the next one. Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20210615021342.7416-8-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit b82ffbf5597703737fe5ce3b7e1264844f75ad4b Author: Cong Wang Date: Mon Jun 14 19:13:42 2021 -0700 skmsg: Increase sk->sk_drops when dropping packets [ Upstream commit 781dd0431eb549f9cb1fdddf91a50d985febe884 ] It is hard to observe packet drops without increasing relevant drop counters, here we should increase sk->sk_drops which is a protocol-independent counter. Fortunately psock is always associated with a struct sock, we can just use psock->sk. Suggested-by: John Fastabend Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20210615021342.7416-9-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit af888405578074879f733443f2dd55b99727168b Author: Linus Walleij Date: Sun May 23 00:50:40 2021 +0200 power: supply: ab8500: Call battery population once [ Upstream commit 7e2bb83c617f8fccc04db7d03f105a06b9d491a9 ] The code was calling ab8500_bm_of_probe() in four different spots effectively overwriting the same configuration three times. This was done because probe order was uncertain. Since we now used componentized probe, call it only once while probing the main charging component. Signed-off-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 5a40048e60b2eda85cfad7ac5af2020d13a57b1f Author: Jason Ekstrand Date: Mon Aug 2 13:48:19 2021 -0500 Revert "drm/i915: Propagate errors on awaiting already signaled fences" commit 3761baae908a7b5012be08d70fa553cc2eb82305 upstream. 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/20210602164149.391653-2-jason@jlekstrand.net/ 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 Reported-by: Marcin Slusarz Cc: # v5.6+ Cc: Jason Ekstrand Cc: Marcin Slusarz Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Acked-by: Daniel Vetter Reviewed-by: Jon Bloomfield Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-3-jason@jlekstrand.net (cherry picked from commit 93a2711cddd5760e2f0f901817d71c93183c3b87) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 15c8463df133973f8e05309c98c6df172d518604 Author: Jason Ekstrand Date: Mon Aug 2 13:48:18 2021 -0500 drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser" commit c9d9fdbc108af8915d3f497bbdf3898bf8f321b8 upstream. 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 Cc: # v5.6+ Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Cc: Maarten Lankhorst Reviewed-by: Jon Bloomfield Acked-by: Daniel Vetter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-2-jason@jlekstrand.net Signed-off-by: Sasha Levin