aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-07powerpc/bpf ppc32: Fix JMP32_JSET_KNaveen N. Rao1-1/+1
'andi' only takes an unsigned 16-bit value. Correct the imm range used when emitting andi. Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32") Signed-off-by: Naveen N. Rao <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/b94489f52831305ec15aca4dd04a3527236be7e8.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07powerpc/bpf ppc32: Fix ALU32 BPF_ARSH operationNaveen N. Rao1-1/+1
Correct the destination register used for ALU32 BPF_ARSH operation. Fixes: 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32") Signed-off-by: Naveen N. Rao <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/6d24c1f9e79b6f61f5135eaf2ea1e8bcd4dac87b.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPECNaveen N. Rao2-8/+55
Emit similar instruction sequences to commit a048a07d7f4535 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit") when encountering BPF_NOSPEC. Mitigations are enabled depending on what the firmware advertises. In particular, we do not gate these mitigations based on current settings, just like in x86. Due to this, we don't need to take any action if mitigations are enabled or disabled at runtime. Signed-off-by: Naveen N. Rao <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/956570cbc191cd41f8274bed48ee757a86dac62a.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07powerpc/security: Add a helper to query stf_barrier typeNaveen N. Rao2-0/+10
Add a helper to return the stf_barrier type for the current processor. Signed-off-by: Naveen N. Rao <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/3bd5d7f96ea1547991ac2ce3137dc2b220bae285.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07powerpc/bpf: Fix BPF_SUB when imm == 0x80000000Naveen N. Rao1-10/+17
We aren't handling subtraction involving an immediate value of 0x80000000 properly. Fix the same. Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF") Signed-off-by: Naveen N. Rao <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> [mpe: Fold in fix from Naveen to use imm <= 32768] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/fc4b1276eb10761fd7ce0814c8dd089da2815251.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07powerpc/bpf: Fix BPF_MOD when imm == 1Naveen N. Rao1-2/+8
Only ignore the operation if dividing by 1. Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF") Signed-off-by: Naveen N. Rao <[email protected]> Tested-by: Johan Almbladh <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Acked-by: Song Liu <[email protected]> Acked-by: Johan Almbladh <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/c674ca18c3046885602caebb326213731c675d06.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07powerpc/bpf: Validate branch rangesNaveen N. Rao4-11/+37
Add checks to ensure that we never emit branch instructions with truncated branch offsets. Suggested-by: Michael Ellerman <[email protected]> Signed-off-by: Naveen N. Rao <[email protected]> Tested-by: Johan Almbladh <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Acked-by: Song Liu <[email protected]> Acked-by: Johan Almbladh <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/71d33a6b7603ec1013c9734dd8bdd4ff5e929142.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07powerpc/lib: Add helper to check if offset is within conditional branch rangeNaveen N. Rao3-7/+8
Add a helper to check if a given offset is within the branch range for a powerpc conditional branch instruction, and update some sites to use the new helper. Signed-off-by: Naveen N. Rao <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Acked-by: Song Liu <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/442b69a34ced32ca346a0d9a855f3f6cfdbbbd41.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
2021-10-07ALSA: hda: intel: Allow repeatedly probing on codec configuration errorsTakashi Iwai7-25/+56
It seems that a few recent AMD systems show the codec configuration errors at the early boot, while loading the driver at a later stage works magically. Although the root cause of the error isn't clear, it's certainly not bad to allow retrying the codec probe in such a case if that helps. This patch adds the capability for retrying the probe upon codec probe errors on the certain AMD platforms. The probe_work is changed to a delayed work, and at the secondary call, it'll jump to the codec probing. Note that, not only adding the re-probing, this includes the behavior changes in the codec configuration function. Namely, snd_hda_codec_configure() won't unregister the codec at errors any longer. Instead, its caller, azx_codec_configure() unregisters the codecs with the probe failures *if* any codec has been successfully configured. If all codec probe failed, it doesn't unregister but let it re-probed -- which is the most case we're seeing and this patch tries to improve. Even if the driver doesn't re-probe or give up, it will go to the "free-all" error path, hence the leftover codecs shall be disabled / deleted in anyway. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-10-06Merge tag 'devicetree-fixes-for-5.15-3' of ↵Linus Torvalds9-12/+6
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - Add another allowed address for TI sn65dsi86 - Drop more redundant minItems/maxItems - Fix more graph 'unevaluatedProperties' warnings in media bindings * tag 'devicetree-fixes-for-5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: drm/bridge: ti-sn65dsi86: Fix reg value dt-bindings: Drop more redundant 'maxItems/minItems' dt-bindings: media: Fix more graph 'unevaluatedProperties' related warnings
2021-10-06kunit: fix kernel-doc warnings due to mismatched arg namesDaniel Latypov1-3/+3
Commit 7122debb4367 ("kunit: introduce kunit_kmalloc_array/kunit_kcalloc() helpers") added new functions but called last arg `flags`, unlike the existing code that used `gfp`. This only is an issue in test.h, test.c still used `gfp`. But the documentation was copy-pasted with the old names, leading to kernel-doc warnings. Do s/flags/gfp to make the names consistent and fix the warnings. Fixes: 7122debb4367 ("kunit: introduce kunit_kmalloc_array/kunit_kcalloc() helpers") Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Daniel Latypov <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Reviewed-by: Brendan Higgins <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2021-10-06bitfield: build kunit tests without structleak pluginArnd Bergmann1-1/+1
The structleak plugin causes the stack frame size to grow immensely: lib/bitfield_kunit.c: In function 'test_bitfields_constants': lib/bitfield_kunit.c:93:1: error: the frame size of 7440 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Turn it off in this file. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Brendan Higgins <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2021-10-06thunderbolt: build kunit tests without structleak pluginBrendan Higgins1-0/+1
The structleak plugin causes the stack frame size to grow immensely when used with KUnit: drivers/thunderbolt/test.c:1529:1: error: the frame size of 1176 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Turn it off in this file. Linus already split up tests in this file, so this change *should* be redundant now. Signed-off-by: Brendan Higgins <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Acked-by: Mika Westerberg <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2021-10-06device property: build kunit tests without structleak pluginBrendan Higgins1-1/+1
The structleak plugin causes the stack frame size to grow immensely when used with KUnit: ../drivers/base/test/property-entry-test.c:492:1: warning: the frame size of 2832 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/base/test/property-entry-test.c:322:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/base/test/property-entry-test.c:250:1: warning: the frame size of 4976 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/base/test/property-entry-test.c:115:1: warning: the frame size of 3280 bytes is larger than 2048 bytes [-Wframe-larger-than=] Turn it off in this file. Signed-off-by: Brendan Higgins <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2021-10-06iio/test-format: build kunit tests without structleak pluginBrendan Higgins1-0/+1
The structleak plugin causes the stack frame size to grow immensely when used with KUnit: ../drivers/iio/test/iio-test-format.c: In function ‘iio_test_iio_format_value_fixedpoint’: ../drivers/iio/test/iio-test-format.c:98:1: warning: the frame size of 2336 bytes is larger than 2048 bytes [-Wframe-larger-than=] Turn it off in this file. Signed-off-by: Brendan Higgins <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Reviewed-by: Kees Cook <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2021-10-06gcc-plugins/structleak: add makefile var for disabling structleakBrendan Higgins1-0/+4
KUnit and structleak don't play nice, so add a makefile variable for enabling structleak when it complains. Co-developed-by: Kees Cook <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Brendan Higgins <[email protected]> Reviewed-by: David Gow <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2021-10-06drm/amd/display: Fix detection of 4 lane for DPALTHansen2-1/+35
[Why] DPALT detection for B0 PHY has its own set of RDPCSPIPE registers [How] Use RDPCSPIPE registers to detect if DPALT lane is 4 lane Reviewed-by: Charlene Liu <[email protected]> Acked-by: Solomon Chiu <[email protected]> Signed-off-by: Hansen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-10-06drm/amd/display: Limit display scaling to up to 4k for DCN 3.1Nikola Cornij1-1/+1
[why] The existing limit was mistakenly bigger than 4k for DCN 3.1 Reviewed-by: Zhan Liu <[email protected]> Acked-by: Solomon Chiu <[email protected]> Signed-off-by: Nikola Cornij <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-10-06drm/amd/display: Skip override for preferred link settings during link trainingGeorge Shen1-6/+0
[Why] Overriding link setting inside override_training_settings result in fallback link settings being ignored. This can potentially cause link training to always fail and consequently result in an infinite loop of link training to occur in dp_verify_link_cap during detection. [How] Since preferred link settings are already considered inside decide_link_settings, skip the check in override_training_settings to avoid infinite link training loops. Reviewed-by: Wenjing Liu <[email protected]> Acked-by: Solomon Chiu <[email protected]> Signed-off-by: George Shen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-10-06NFSD: Keep existing listeners on portlist errorBenjamin Coddington1-1/+4
If nfsd has existing listening sockets without any processes, then an error returned from svc_create_xprt() for an additional transport will remove those existing listeners. We're seeing this in practice when userspace attempts to create rpcrdma transports without having the rpcrdma modules present before creating nfsd kernel processes. Fix this by checking for existing sockets before calling nfsd_destroy(). Signed-off-by: Benjamin Coddington <[email protected]> Signed-off-by: Chuck Lever <[email protected]>
2021-10-06iavf: fix double unlock of crit_lockStefan Assmann1-1/+0
The crit_lock mutex could be unlocked twice as reported here https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20210823/025525.html Remove the superfluous unlock. Technically the problem was already present before 5ac49f3c2702 as that commit only replaced the locking primitive, but no functional change. Reported-by: Dan Carpenter <[email protected]> Fixes: 5ac49f3c2702 ("iavf: use mutexes for locking of critical sections") Fixes: bac8486116b0 ("iavf: Refactor the watchdog state machine") Signed-off-by: Stefan Assmann <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2021-10-06i40e: Fix freeing of uninitialized misc IRQ vectorSylwester Dziedziuch1-1/+2
When VSI set up failed in i40e_probe() as part of PF switch set up driver was trying to free misc IRQ vectors in i40e_clear_interrupt_scheme and produced a kernel Oops: Trying to free already-free IRQ 266 WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300 Workqueue: events work_for_cpu_fn RIP: 0010:__free_irq+0x9a/0x300 Call Trace: ? synchronize_irq+0x3a/0xa0 free_irq+0x2e/0x60 i40e_clear_interrupt_scheme+0x53/0x190 [i40e] i40e_probe.part.108+0x134b/0x1a40 [i40e] ? kmem_cache_alloc+0x158/0x1c0 ? acpi_ut_update_ref_count.part.1+0x8e/0x345 ? acpi_ut_update_object_reference+0x15e/0x1e2 ? strstr+0x21/0x70 ? irq_get_irq_data+0xa/0x20 ? mp_check_pin_attr+0x13/0xc0 ? irq_get_irq_data+0xa/0x20 ? mp_map_pin_to_irq+0xd3/0x2f0 ? acpi_register_gsi_ioapic+0x93/0x170 ? pci_conf1_read+0xa4/0x100 ? pci_bus_read_config_word+0x49/0x70 ? do_pci_enable_device+0xcc/0x100 local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40 The problem is that at that point misc IRQ vectors were not allocated yet and we get a call trace that driver is trying to free already free IRQ vectors. Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED PF state before calling i40e_free_misc_vector. This state is set only if misc IRQ vectors were properly initialized. Fixes: c17401a1dd21 ("i40e: use separate state bit for miscellaneous IRQ setup") Reported-by: PJ Waskiewicz <[email protected]> Signed-off-by: Sylwester Dziedziuch <[email protected]> Signed-off-by: Mateusz Palczewski <[email protected]> Tested-by: Dave Switzer <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2021-10-06i40e: fix endless loop under rtnlJiri Benc1-1/+1
The loop in i40e_get_capabilities can never end. The problem is that although i40e_aq_discover_capabilities returns with an error if there's a firmware problem, the returned error is not checked. There is a check for pf->hw.aq.asq_last_status but that value is set to I40E_AQ_RC_OK on most firmware problems. When i40e_aq_discover_capabilities encounters a firmware problem, it will encounter the same problem on its next invocation. As the result, the loop becomes endless. We hit this with I40E_ERR_ADMIN_QUEUE_TIMEOUT but looking at the code, it can happen with a range of other firmware errors. I don't know what the correct behavior should be: whether the firmware should be retried a few times, or whether pf->hw.aq.asq_last_status should be always set to the encountered firmware error (but then it would be pointless and can be just replaced by the i40e_aq_discover_capabilities return value). However, the current behavior with an endless loop under the rtnl mutex(!) is unacceptable and Intel has not submitted a fix, although we explained the bug to them 7 months ago. This may not be the best possible fix but it's better than hanging the whole system on a firmware bug. Fixes: 56a62fc86895 ("i40e: init code and hardware support") Tested-by: Stefan Assmann <[email protected]> Signed-off-by: Jiri Benc <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Tested-by: Dave Switzer <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2021-10-06x86/Kconfig: Correct reference to MWINCHIP3DLukas Bulwahn1-1/+1
Commit in Fixes intended to exclude the Winchip series and referred to CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D. Hence, scripts/checkkconfigsymbols.py warns: WINCHIP3D Referencing files: arch/x86/Kconfig Correct the reference to the intended config symbol. Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group") Suggested-by: Randy Dunlap <[email protected]> Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-10-06x86/platform/olpc: Correct ifdef symbol to intended CONFIG_OLPC_XO15_SCILukas Bulwahn1-1/+1
The refactoring in the commit in Fixes introduced an ifdef CONFIG_OLPC_XO1_5_SCI, however the config symbol is actually called "CONFIG_OLPC_XO15_SCI". Fortunately, ./scripts/checkkconfigsymbols.py warns: OLPC_XO1_5_SCI Referencing files: arch/x86/platform/olpc/olpc.c Correct this ifdef condition to the intended config symbol. Fixes: ec9964b48033 ("Platform: OLPC: Move EC-specific functionality out from x86") Suggested-by: Randy Dunlap <[email protected]> Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-10-06x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=nVegard Nossum1-0/+1
Commit 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks") added a warning if AC is set when in the kernel. Commit 662a0221893a3d ("x86/entry: Fix AC assertion") changed the warning to only fire if the CPU supports SMAP. However, the warning can still trigger on a machine that supports SMAP but where it's disabled in the kernel config and when running the syscall_nt selftest, for example: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode CPU: 0 PID: 49 Comm: init Tainted: G T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:irqentry_enter_from_user_mode ... Call Trace: ? irqentry_enter ? exc_general_protection ? asm_exc_general_protection ? asm_exc_general_protectio IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but even this would not be enough in case SMAP is disabled at boot time with the "nosmap" parameter. To be consistent with "nosmap" behaviour, clear X86_FEATURE_SMAP when !CONFIG_X86_SMAP. Found using entry-fuzz + satrandconfig. [ bp: Massage commit message. ] Fixes: 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks") Fixes: 662a0221893a ("x86/entry: Fix AC assertion") Signed-off-by: Vegard Nossum <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2021-10-06x86/entry: Correct reference to intended CONFIG_64_BITLukas Bulwahn1-1/+1
Commit in Fixes adds a condition with IS_ENABLED(CONFIG_64_BIT), but the intended config item is called CONFIG_64BIT, as defined in arch/x86/Kconfig. Fortunately, scripts/checkkconfigsymbols.py warns: 64_BIT Referencing files: arch/x86/include/asm/entry-common.h Correct the reference to the intended config symbol. Fixes: 662a0221893a ("x86/entry: Fix AC assertion") Suggested-by: Randy Dunlap <[email protected]> Signed-off-by: Lukas Bulwahn <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-10-06x86/resctrl: Fix kfree() of the wrong type in domain_add_cpu()James Morse1-2/+2
Commit in Fixes separated the architecture specific and filesystem parts of the resctrl domain structures. This left the error paths in domain_add_cpu() kfree()ing the memory with the wrong type. This will cause a problem if someone adds a new member to struct rdt_hw_domain meaning d_resctrl is no longer the first member. Fixes: 792e0f6f789b ("x86/resctrl: Split struct rdt_domain") Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Acked-by: Reinette Chatre <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-10-06x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() failsJames Morse1-0/+2
domain_add_cpu() is called whenever a CPU is brought online. The earlier call to domain_setup_ctrlval() allocates the control value arrays. If domain_setup_mon_state() fails, the control value arrays are not freed. Add the missing kfree() calls. Fixes: 1bd2a63b4f0de ("x86/intel_rdt/mba_sc: Add initialization support") Fixes: edf6fa1c4a951 ("x86/intel_rdt/cqm: Add RMID (Resource monitoring ID) management") Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Acked-by: Reinette Chatre <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2021-10-06x86/hyperv: Avoid erroneously sending IPI to 'self'Vitaly Kuznetsov1-5/+15
__send_ipi_mask_ex() uses an optimization: when the target CPU mask is equal to 'cpu_present_mask' it uses 'HV_GENERIC_SET_ALL' format to avoid converting the specified cpumask to VP_SET. This case was overlooked when 'exclude_self' parameter was added. As the result, a spurious IPI to 'self' can be send. Reported-by: Thomas Gleixner <[email protected]> Fixes: dfb5c1e12c28 ("x86/hyperv: remove on-stack cpumask from hv_send_ipi_mask_allbutself") Signed-off-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2021-10-06Merge tag 'imx-fixes-5.15-2' of ↵Arnd Bergmann13-12/+17
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.15, round 2: - A couple of fixes from Haibo Chen to update SPI NOR TX bus width for i.MX6 and i.MX8 boards. This becomes necessary because spi-nor driver starts using the setting in DT. - Mark buck2 always-on for i.MX8MM Kontron-n801x-som board to avoid the core supply being turned off unexpectedly. - Fix eSDHC2 device tree settings for LS1028A SoC. - Disable GIC CPU interface before calling stby-poweroff sequence to fix power-off failure on i.MX6. - Fix M2_RST# GPIO pinmux on i.MX8M venice-gw7902 boards. * tag 'imx-fixes-5.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: dts: imx8m*-venice-gw7902: fix M2_RST# gpio ARM: imx6: disable the GIC CPU interface before calling stby-poweroff sequence arm64: dts: ls1028a: fix eSDHC2 node arm64: dts: imx8mm-kontron-n801x-som: do not allow to switch off buck2 arm64: dts: imx8: change the spi-nor tx ARM: dts: imx: change the spi-nor tx Link: https://lore.kernel.org/r/20211006125734.GA10197@dragon Signed-off-by: Arnd Bergmann <[email protected]>
2021-10-06mmc: meson-gx: do not use memcpy_to/fromio for dram-access-quirkNeil Armstrong1-14/+59
The memory at the end of the controller only accepts 32bit read/write accesses, but the arm64 memcpy_to/fromio implementation only uses 64bit (which will be split into two 32bit access) and 8bit leading to incomplete copies to/from this memory when the buffer is not multiple of 8bytes. Add a local copy using writel/readl accesses to make sure we use the right memory access width. The switch to memcpy_to/fromio was done because of 285133040e6c ("arm64: Import latest memcpy()/memmove() implementation"), but using memcpy worked before since it mainly used 32bit memory acceses. Fixes: 103a5348c22c ("mmc: meson-gx: use memcpy_to/fromio for dram-access-quirk") Reported-by: Christian Hewitt <[email protected]> Suggested-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Martin Blumenstingl <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-06mmc: sdhci-of-at91: replace while loop with read_poll_timeoutClaudiu Beznea1-11/+5
Replace while loop with read_poll_timeout(). Signed-off-by: Claudiu Beznea <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-06mmc: sdhci-of-at91: wait for calibration done before proceedClaudiu Beznea1-0/+6
Datasheet specifies that at the end of calibration the SDMMC_CALCR_EN bit will be cleared. No commands should be send before calibration is done. Fixes: dbdea70f71d67 ("mmc: sdhci-of-at91: fix CALCR register being rewritten") Fixes: 727d836a375ad ("mmc: sdhci-of-at91: add DT property to enable calibration on full reset") Signed-off-by: Claudiu Beznea <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2021-10-06dt-bindings: net: dsa: marvell: fix compatible in exampleMarcel Ziswiler1-1/+1
While the MV88E6390 switch chip exists, one is supposed to use a compatible of "marvell,mv88e6190" for it. Fix this in the given example. Signed-off-by: Marcel Ziswiler <[email protected]> Fixes: a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06ionic: move filter sync_needed bit setShannon Nelson2-4/+3
Move the setting of the filter-sync-needed bit to the error case in the filter add routine to be sure we're checking the live filter status rather than a copy of the pre-sync status. Fixes: 969f84394604 ("ionic: sync the filters in the work task") Signed-off-by: Shannon Nelson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06gve: report 64bit tx_bytes counter from gve_handle_report_stats()Eric Dumazet1-2/+3
Each tx queue maintains a 64bit counter for bytes, there is no reason to truncate this to 32bit (or this has not been documented) Fixes: 24aeb56f2d38 ("gve: Add Gvnic stats AQ command and ethtool show/set-priv-flags.") Signed-off-by: Eric Dumazet <[email protected]> Cc: Yangchun Fu <[email protected]> Cc: Kuo Zhao <[email protected]> Cc: David Awogbemila <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06gve: fix gve_get_stats()Eric Dumazet1-4/+9
gve_get_stats() can report wrong numbers if/when u64_stats_fetch_retry() returns true. What is needed here is to sample values in temporary variables, and only use them after each loop is ended. Fixes: f5cedc84a30d ("gve: Add transmit and receive support") Signed-off-by: Eric Dumazet <[email protected]> Cc: Catherine Sullivan <[email protected]> Cc: Sagi Shahar <[email protected]> Cc: Jon Olson <[email protected]> Cc: Willem de Bruijn <[email protected]> Cc: Luigi Rizzo <[email protected]> Cc: Jeroen de Borst <[email protected]> Cc: Tao Liu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06rtnetlink: fix if_nlmsg_stats_size() under estimationEric Dumazet1-1/+1
rtnl_fill_statsinfo() is filling skb with one mandatory if_stats_msg structure. nlmsg_put(skb, pid, seq, type, sizeof(struct if_stats_msg), flags); But if_nlmsg_stats_size() never considered the needed storage. This bug did not show up because alloc_skb(X) allocates skb with extra tailroom, because of added alignments. This could very well be changed in the future to have deterministic behavior. Fixes: 10c9ead9f3c6 ("rtnetlink: add new RTM_GETSTATS message to dump link stats") Signed-off-by: Eric Dumazet <[email protected]> Cc: Roopa Prabhu <[email protected]> Acked-by: Roopa Prabhu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06gve: Properly handle errors in gve_assign_qplCatherine Sullivan1-1/+7
Ignored errors would result in crash. Fixes: ede3fcf5ec67f ("gve: Add support for raw addressing to the rx path") Signed-off-by: Catherine Sullivan <[email protected]> Signed-off-by: Jeroen de Borst <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06gve: Avoid freeing NULL pointerTao Liu1-10/+17
Prevent possible crashes when cleaning up after unsuccessful initializations. Fixes: 893ce44df5658 ("gve: Add basic driver framework for Compute Engine Virtual NIC") Signed-off-by: Tao Liu <[email protected]> Signed-off-by: Catherine Sully <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06gve: Correct available tx qpl checkCatherine Sullivan1-1/+1
The qpl_map_size is rounded up to a multiple of sizeof(long), but the number of qpls doesn't have to be. Fixes: f5cedc84a30d2 ("gve: Add transmit and receive support") Signed-off-by: Catherine Sullivan <[email protected]> Signed-off-by: Jeroen de Borst <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06ALSA: hda/realtek: Add quirk for TongFang PHxTxX1Werner Sembach1-1/+25
This applies a SND_PCI_QUIRK(...) to the TongFang PHxTxX1 barebone. This fixes the issue of the internal Microphone not working after booting another OS. When booting a certain another OS this barebone keeps some coeff settings even after a cold shutdown. These coeffs prevent the microphone detection from working in Linux, making the Laptop think that there is always an external microphone plugged-in and therefore preventing the use of the internal one. The relevant indexes and values where gathered by naively diff-ing and reading a working and a non-working coeff dump. Signed-off-by: Werner Sembach <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-10-06unix: Fix an issue in unix_shutdown causing the other end read/write failuresJiang Wang1-4/+5
Commit 94531cfcbe79 ("af_unix: Add unix_stream_proto for sockmap") sets unix domain socket peer state to TCP_CLOSE in unix_shutdown. This could happen when the local end is shutdown but the other end is not. Then, the other end will get read or write failures which is not expected. Fix the issue by setting the local state to shutdown. Fixes: 94531cfcbe79 ("af_unix: Add unix_stream_proto for sockmap") Reported-by: Casey Schaufler <[email protected]> Suggested-by: Cong Wang <[email protected]> Signed-off-by: Jiang Wang <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Casey Schaufler <[email protected]> Reviewed-by: Casey Schaufler <[email protected]> Acked-by: Song Liu <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-10-06hyper-v: Replace uuid.h with types.hAndy Shevchenko1-1/+1
There is no user of anything in uuid.h in the hyperv.h. Replace it with more appropriate types.h. Fixes: f081bbb3fd03 ("hyper-v: Remove internal types from UAPI header") Reported-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Haiyang Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2021-10-06Merge branch 'stmmac-eee-fix'David S. Miller2-5/+14
Wong Vee Khee says: ==================== net: stmmac: Turn off EEE on MAC link down This patch series ensure PCS EEE is turned off on the event of MAC link down. Tested on Intel AlderLake-S (STMMAC + MaxLinear GPY211 PHY). ==================== Signed-off-by: David S. Miller <[email protected]>
2021-10-06net: stmmac: trigger PCS EEE to turn off on link downWong Vee Khee1-1/+5
The current implementation enable PCS EEE feature in the event of link up, but PCS EEE feature is not disabled on link down. This patch makes sure PCE EEE feature is disabled on link down. Fixes: 656ed8b015f1 ("net: stmmac: fix EEE init issue when paired with EEE capable PHYs") Signed-off-by: Wong Vee Khee <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06net: pcs: xpcs: fix incorrect steps on disable EEEWong Vee Khee1-4/+9
When Energy-Efficient Ethernet(EEE) is disable from the MAC side, we need to clear the DW_VR_MII_EEE_TRN_LPI bit of DW_VR_MII_EEE_MCTRL1 register. Fixes: 7617af3d1a5e ("net: pcs: Introducing support for DWC xpcs Energy Efficient Ethernet") Cc: Michael Sit Wei Hong <[email protected]> Signed-off-by: Wong Vee Khee <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-10-06firmware: arm_scmi: Add proper barriers to scmi virtio deviceCristian Marussi1-4/+9
Only one single SCMI Virtio device is currently supported by this driver and it is referenced using a static global variable which is initialized once for all during probing and nullified at virtio device removal. Add proper SMP barriers to protect accesses to such device reference to ensure that the initialzation state of such device is correctly observed by all PEs at any time. Return -EBUSY, instead of -EINVAL, and a descriptive error message if more than one SCMI Virtio device is ever found and probed. Link: https://lore.kernel.org/r/[email protected] Cc: "Michael S. Tsirkin" <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2021-10-06firmware: arm_scmi: Simplify spinlocks in virtio transportCristian Marussi1-8/+21
Remove unneeded nested irqsave/irqrestore spinlocks. Add also a few descriptive comments to explain better the system behaviour at shutdown time. Link: https://lore.kernel.org/r/[email protected] Cc: "Michael S. Tsirkin" <[email protected]> Cc: Sudeep Holla <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.