summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-10-01iwlwifi: mvm: add PROTECTED_TWT firmware APIShaul Triebitz
Add the PROTECTED_TWT bit to the MAC context data_policy enum. Define the PROTECTED_TWT TLV. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200911204056.c80b994d6bf0.Ifd45dfd5066283886f969313c20ff81edde428ff@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01iwlwifi: mvm: rs-fw: handle VHT extended NSS capabilityJohannes Berg
If extended NSS capability is used, the NSS for 160 may be lower than for 80. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200911204056.523f5eca82ce.Ic0cd9cc86a91b1f23a5a54921736332be9abac29@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2020-10-01Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "A previous commit to prevent AML memory opregions from accessing the kernel memory turned out to be too restrictive. Relax the permission check to permit the ACPI core to map kernel memory used for table overrides" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: permit ACPI core to map kernel memory used for table overrides
2020-10-01Merge tag 'drm-fixes-2020-10-01-1' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "AMD and vmwgfx fixes. Just dequeuing these a bit early as the AMD ones are bit larger than I'd prefer, but Alex missed last week so it's a double set of fixes. The larger ones are just register header fixes for the new chips that were just introduced in rc1 along with some new PCI IDs for new hw. Otherwise it is usual fixes. The vmwgfx fix was due to some testing I was doing and found we weren't booting properly, vmware had the fix internally so hurried it vmwgfx: - fix a regression due to TTM refactor amdgpu: - Fix potential double free in userptr handling - Sienna Cichlid and Navy Flounder udpates - Add Sienna Cichlid PCI IDs - Drop experimental flag for navi12 - Raven fixes - Renoir fixes - HDCP fix - DCN3 fix for clang and older versions of gcc - Fix a runtime pm refcount issue" * tag 'drm-fixes-2020-10-01-1' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: disable gfxoff temporarily for navy_flounder drm/amd/pm: setup APU dpm clock table in SMU HW initialization drm/vmwgfx: Fix error handling in get_node drm/amd/display: remove duplicate call to rn_vbios_smu_get_smu_version() drm/amdgpu/swsmu/smu12: fix force clock handling for mclk drm/amdgpu: restore proper ref count in amdgpu_display_crtc_set_config drm/amdgpu/display: fix CFLAGS setup for DCN30 drm/amd/display: fix return value check for hdcp_work drm/amdgpu: remove gpu_info fw support for sienna_cichlid etc. drm/amd/pm: Removed fixed clock in auto mode DPM drm/amdgpu: remove experimental flag from navi12 drm/amdgpu: add device ID for sienna_cichlid (v2) drm/amdgpu: use the AV1 defines for VCN 3.0 drm/amdgpu: add VCN 3.0 AV1 registers drm/amdgpu: add the GC 10.3 VRS registers drm/amdgpu: prevent double kfree ttm->sg
2020-10-01Merge tag 'trace-v5.9-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "Two tracing fixes: - Fix temp buffer accounting that caused a WARNING for ftrace_dump_on_opps() - Move the recursion check in one of the function callback helpers to the beginning of the function, as if the rcu_is_watching() gets traced, it will cause a recursive loop that will crash the kernel" * tag 'trace-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace: Move RCU is watching check after recursion check tracing: Fix trace_find_next_entry() accounting of temp buffer size
2020-10-01bpf: Fix "unresolved symbol" build error with resolve_btfidsYonghong Song
Michal reported a build failure likes below: BTFIDS vmlinux FAILED unresolved symbol tcp_timewait_sock make[1]: *** [/.../linux-5.9-rc7/Makefile:1176: vmlinux] Error 255 This error can be triggered when config has CONFIG_NET enabled but CONFIG_INET disabled. In this case, there is no user of istructs inet_timewait_sock and tcp_timewait_sock and hence vmlinux BTF types are not generated for these two structures. To fix the problem, let us force BTF generation for these two structures with BTF_TYPE_EMIT. Fixes: fce557bcef11 ("bpf: Make btf_sock_ids global") Reported-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20201001051339.2549085-1-yhs@fb.com
2020-10-01rtw88: pci: Power cycle device during shutdownKai-Heng Feng
There are reports that 8822CE fails to work rtw88 with "failed to read DBI register" error. Also I have a system with 8723DE which freezes the whole system when the rtw88 is probing the device. According to [1], platform firmware may not properly power manage the device during shutdown. I did some expirements and putting the device to D3 can workaround the issue. So let's power cycle the device by putting the device to D3 at shutdown to prevent the issue from happening. [1] https://bugzilla.kernel.org/show_bug.cgi?id=206411#c9 BugLink: https://bugs.launchpad.net/bugs/1872984 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928165508.20775-1-kai.heng.feng@canonical.com
2020-10-01brcmfmac: Fix warning message after dongle setup failedWright Feng
Brcmfmac showed warning message in fweh.c when checking the size of event queue which is not initialized. Therefore, we only cancel the worker and reset event handler only when it is initialized. [ 145.505899] brcmfmac 0000:02:00.0: brcmf_pcie_setup: Dongle setup [ 145.929970] ------------[ cut here ]------------ [ 145.929994] WARNING: CPU: 0 PID: 288 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c:312 brcmf_fweh_detach+0xbc/0xd0 [brcmfmac] ... [ 145.930029] Call Trace: [ 145.930036] brcmf_detach+0x77/0x100 [brcmfmac] [ 145.930043] brcmf_pcie_remove+0x79/0x130 [brcmfmac] [ 145.930046] pci_device_remove+0x39/0xc0 [ 145.930048] device_release_driver_internal+0x141/0x200 [ 145.930049] device_release_driver+0x12/0x20 [ 145.930054] brcmf_pcie_setup+0x101/0x3c0 [brcmfmac] [ 145.930060] brcmf_fw_request_done+0x11d/0x1f0 [brcmfmac] [ 145.930062] ? lock_timer_base+0x7d/0xa0 [ 145.930063] ? internal_add_timer+0x1f/0xa0 [ 145.930064] ? add_timer+0x11a/0x1d0 [ 145.930066] ? __kmalloc_track_caller+0x18c/0x230 [ 145.930068] ? kstrdup_const+0x23/0x30 [ 145.930069] ? add_dr+0x46/0x80 [ 145.930070] ? devres_add+0x3f/0x50 [ 145.930072] ? usermodehelper_read_unlock+0x15/0x20 [ 145.930073] ? _request_firmware+0x288/0xa20 [ 145.930075] request_firmware_work_func+0x36/0x60 [ 145.930077] process_one_work+0x144/0x360 [ 145.930078] worker_thread+0x4d/0x3c0 [ 145.930079] kthread+0x112/0x150 [ 145.930080] ? rescuer_thread+0x340/0x340 [ 145.930081] ? kthread_park+0x60/0x60 [ 145.930083] ret_from_fork+0x25/0x30 Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928054922.44580-3-wright.feng@cypress.com
2020-10-01brcmfmac: Fix warning when hitting FW crash with flow control featureWright Feng
Brcmfmac got warning message when hitting FW crash in TX throughput test with fcmode=2. It's caused by FMAC flushed TXQ in brcmf_sdio_bus_stop but without doing hanger slot cleanup. Therefore, we move brcmf_remove_interface before brcmf_bus_stop to make sure the hanger slot is clean when flushing TXQ. [ 1891.512234] WARNING: CPU: 1 PID: 2765 at drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c:49 brcmu_pkt_buf_free_skb+0x21/0x30 [brcmutil] [ 1891.512234] Modules linked in: brcmfmac(OE-) brcmutil(OE) cfg80211(OE) compat(OE) rfkill mmc_block(OE) sdhci_pci(OE) sdhci(OE) mmc_core(OE) ip6table_filter ip6_tables ebtable_nat ebtables dns_resolver fscache e1000e ppdev iTCO_wdt iTCO_vendor_support tpm_tis tpm_tis_core tpm mei_me mei pcspkr lpc_ich i2c_i801 mfd_core ptp pps_core parport_pc parport wmi tcp_bic uinput i915 iosf_mbi i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: brcmfmac] [ 1891.512247] CPU: 1 PID: 2765 Comm: rmmod Tainted: G W OE 4.12.0 #1 [ 1891.512247] Hardware name: /DH77EB, BIOS EBH7710H.86A.0100.2013.0312.1351 03/12/2013 [ 1891.512248] task: ffff880118f08000 task.stack: ffffc90001180000 [ 1891.512249] RIP: 0010:brcmu_pkt_buf_free_skb+0x21/0x30 [brcmutil] [ 1891.512249] RSP: 0018:ffffc90001183cc0 EFLAGS: 00010086 [ 1891.512250] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 [ 1891.512251] RDX: 0000000000000000 RSI: 0000000000000086 RDI: ffff880118e3ab00 [ 1891.512251] RBP: ffffc90001183cc0 R08: 0000000000000000 R09: 000000000000a050 [ 1891.512252] R10: 0000000000000001 R11: 0000000000aaaaaa R12: 00000000000000bc [ 1891.512253] R13: ffff880118b40c78 R14: 0000000000000002 R15: ffff880118e3ab00 [ 1891.512253] FS: 00007f2a49760740(0000) GS:ffff88011f280000(0000) knlGS:0000000000000000 [ 1891.512254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1891.512254] CR2: 00000000012994a8 CR3: 000000011a3c4000 CR4: 00000000001406e0 [ 1891.512255] Call Trace: [ 1891.512259] brcmf_fws_cleanup+0x1ea/0x240 [brcmfmac] [ 1891.512264] brcmf_fws_detach+0x42/0x60 [brcmfmac] [ 1891.512268] brcmf_proto_bcdc_detach+0x26/0x40 [brcmfmac] [ 1891.512273] brcmf_proto_detach+0x57/0x70 [brcmfmac] [ 1891.512277] brcmf_detach+0x89/0x100 [brcmfmac] [ 1891.512282] brcmf_sdio_remove+0x76/0x180 [brcmfmac] [ 1891.512286] brcmf_sdiod_remove+0x25/0xb0 [brcmfmac] [ 1891.512291] brcmf_ops_sdio_remove+0xbd/0x120 [brcmfmac] [ 1891.512294] sdio_bus_remove+0x33/0x100 [mmc_core] [ 1891.512295] device_release_driver_internal+0x141/0x200 [ 1891.512297] driver_detach+0x38/0x70 [ 1891.512298] bus_remove_driver+0x55/0xd0 [ 1891.512299] driver_unregister+0x2c/0x50 [ 1891.512303] sdio_unregister_driver+0x1a/0x20 [mmc_core] [ 1891.512307] brcmf_sdio_exit+0x2f/0x40 [brcmfmac] [ 1891.512312] brcmf_core_exit+0x15/0xd7 [brcmfmac] [ 1891.512316] __exit_compat+0x9/0x2b [brcmfmac] [ 1891.512318] SyS_delete_module+0x155/0x230 [ 1891.512319] ? exit_to_usermode_loop+0x70/0x99 [ 1891.512321] do_syscall_64+0x54/0xc0 [ 1891.512322] entry_SYSCALL64_slow_path+0x25/0x25 Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200928054922.44580-2-wright.feng@cypress.com
2020-10-01bcma: use semicolons rather than commas to separate statementsJulia Lawall
Replace commas with semicolons. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601233948-11629-6-git-send-email-Julia.Lawall@inria.fr
2020-10-01iommu/vt-d: Fix lockdep splat in iommu_flush_dev_iotlb()Lu Baolu
Lock(&iommu->lock) without disabling irq causes lockdep warnings. [ 12.703950] ======================================================== [ 12.703962] WARNING: possible irq lock inversion dependency detected [ 12.703975] 5.9.0-rc6+ #659 Not tainted [ 12.703983] -------------------------------------------------------- [ 12.703995] systemd-udevd/284 just changed the state of lock: [ 12.704007] ffffffffbd6ff4d8 (device_domain_lock){..-.}-{2:2}, at: iommu_flush_dev_iotlb.part.57+0x2e/0x90 [ 12.704031] but this lock took another, SOFTIRQ-unsafe lock in the past: [ 12.704043] (&iommu->lock){+.+.}-{2:2} [ 12.704045] and interrupts could create inverse lock ordering between them. [ 12.704073] other info that might help us debug this: [ 12.704085] Possible interrupt unsafe locking scenario: [ 12.704097] CPU0 CPU1 [ 12.704106] ---- ---- [ 12.704115] lock(&iommu->lock); [ 12.704123] local_irq_disable(); [ 12.704134] lock(device_domain_lock); [ 12.704146] lock(&iommu->lock); [ 12.704158] <Interrupt> [ 12.704164] lock(device_domain_lock); [ 12.704174] *** DEADLOCK *** Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20200927062428.13713-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-10-01xen/events: don't use chip_data for legacy IRQsJuergen Gross
Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.") Xen is using the chip_data pointer for storing IRQ specific data. When running as a HVM domain this can result in problems for legacy IRQs, as those might use chip_data for their own purposes. Use a local array for this purpose in case of legacy IRQs, avoiding the double use. Cc: stable@vger.kernel.org Fixes: c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.") Signed-off-by: Juergen Gross <jgross@suse.com> Tested-by: Stefan Bader <stefan.bader@canonical.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20200930091614.13660-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2020-10-01iommu/amd: Fix the overwritten field in IVMD headerAdrian Huang
Commit 387caf0b759a ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions") accidentally overwrites the 'flags' field in IVMD (struct ivmd_header) when the I/O virtualization memory definition is associated with the exclusion range entry. This leads to the corrupted IVMD table (incorrect checksum). The kdump kernel reports the invalid checksum: ACPI BIOS Warning (bug): Incorrect checksum in table [IVRS] - 0x5C, should be 0x60 (20200717/tbprint-177) AMD-Vi: [Firmware Bug]: IVRS invalid checksum Fix the above-mentioned issue by modifying the 'struct unity_map_entry' member instead of the IVMD header. Cleanup: The *exclusion_range* functions are not used anymore, so get rid of them. Fixes: 387caf0b759a ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions") Reported-and-tested-by: Baoquan He <bhe@redhat.com> Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Cc: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20200926102602.19177-1-adrianhuang0701@gmail.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-10-01KVM: arm64: Restore missing ISB on nVHE __tlb_switch_to_guestMarc Zyngier
Commit a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct kvm") dropped the ISB after __load_guest_stage2(), only leaving the one that is required when the speculative AT workaround is in effect. As Andrew points it: "This alternative is 'backwards' to avoid a double ISB as there is one in __load_guest_stage2 when the workaround is active." Restore the missing ISB, conditionned on the AT workaround not being active. Fixes: a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct kvm") Reported-by: Andrew Scull <ascull@google.com> Reported-by: Thomas Tai <thomas.tai@oracle.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-10-01gpio: pca953x: Correctly initialize registers 6 and 7 for PCA957xAndy Shevchenko
When driver has been converted to the bitmap API the non-bitmap functions started behaving differently on 32-bit BE architectures since the bytes in two consequent unsigned longs are in different order in comparison to byte array. Hence if the chip had had more than 32 lines the memset() call over it would have not set up upper lines correctly. Although it's currently a theoretical case (no supported chips of this type has 32+ lines), it's better to provide a clean code to avoid people thinking this is okay and potentially producing not fully working things. Fixes: 35d13d94893f ("gpio: pca953x: convert to use bitmap API") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200930142013.59247-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-01gpio: pca953x: Use bitmap API over implicit GCC extensionAndy Shevchenko
In IRQ handler we have to clear bitmap before use. Currently the GCC extension has been used for that. For sake of the consistency switch to bitmap API. As expected bloat-o-meter shows no difference in the object size. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200930142013.59247-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-01pinctrl: mediatek: check mtk_is_virt_gpio input parameterHanks Chen
check mtk_is_virt_gpio input parameter, virtual gpio need to support eint mode. add error handler for the ko case to fix this boot fail: pc : mtk_is_virt_gpio+0x20/0x38 [pinctrl_mtk_common_v2] lr : mtk_gpio_get_direction+0x44/0xb0 [pinctrl_paris] Fixes: edd546465002 ("pinctrl: mediatek: avoid virtual gpio trying to set reg") Signed-off-by: Hanks Chen <hanks.chen@mediatek.com> Acked-by: Sean Wang <sean.wang@kernel.org> Singed-off-by: Jie Yang <sin_jieyang@mediatek.com> Link: https://lore.kernel.org/r/1597922546-29633-1-git-send-email-hanks.chen@mediatek.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-10-01pinctrl: qcom: sm8250: correct sdc2_clkDmitry Baryshkov
Correct sdc2_clk pin definition (register offset is wrong, verified by the msm-4.19 driver). Fixes: 4e3ec9e407ad ("pinctrl: qcom: Add sm8250 pinctrl driver.") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20200914091846.55204-1-dmitry.baryshkov@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-09-30Merge branch 'introduce BPF_F_PRESERVE_ELEMS'Alexei Starovoitov
Song Liu says: ==================== This set introduces BPF_F_PRESERVE_ELEMS to perf event array for better sharing of perf event. By default, perf event array removes the perf event when the map fd used to add the event is closed. With BPF_F_PRESERVE_ELEMS set, however, the perf event will stay in the array until it is removed, or the map is closed. --- Changes v3 => v5: 1. Clean up in selftest. (Alexei) Changes v2 => v3: 1. Move perf_event_fd_array_map_free() to avoid unnecessary forward declaration. (Daniel) Changes v1 => v2: 1. Rename the flag as BPF_F_PRESERVE_ELEMS. (Alexei, Daniel) 2. Simplify the code and selftest. (Daniel, Alexei) ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-09-30selftests/bpf: Add tests for BPF_F_PRESERVE_ELEMSSong Liu
Add tests for perf event array with and without BPF_F_PRESERVE_ELEMS. Add a perf event to array via fd mfd. Without BPF_F_PRESERVE_ELEMS, the perf event is removed when mfd is closed. With BPF_F_PRESERVE_ELEMS, the perf event is removed when the map is freed. Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200930224927.1936644-3-songliubraving@fb.com
2020-09-30bpf: Introduce BPF_F_PRESERVE_ELEMS for perf event arraySong Liu
Currently, perf event in perf event array is removed from the array when the map fd used to add the event is closed. This behavior makes it difficult to the share perf events with perf event array. Introduce perf event map that keeps the perf event open with a new flag BPF_F_PRESERVE_ELEMS. With this flag set, perf events in the array are not removed when the original map fd is closed. Instead, the perf event will stay in the map until 1) it is explicitly removed from the array; or 2) the array is freed. Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200930224927.1936644-2-songliubraving@fb.com
2020-10-01Merge tag 'amd-drm-fixes-5.9-2020-09-30' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.9-2020-09-30: amdgpu: - Fix potential double free in userptr handling - Sienna Cichlid and Navy Flounder udpates - Add Sienna Cichlid PCI IDs - Drop experimental flag for navi12 - Raven fixes - Renoir fixes - HDCP fix - DCN3 fix for clang and older versions of gcc - Fix a runtime pm refcount issue Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200930161326.4243-1-alexander.deucher@amd.com
2020-09-30net/mlx5e: Fix potential null pointer dereferenceGustavo A. R. Silva
Calls to kzalloc() and kvzalloc() should be null-checked in order to avoid any potential failures. In this case, a potential null pointer dereference. Fix this by adding null checks for _parse_attr_ and _flow_ right after allocation. Addresses-Coverity-ID: 1497154 ("Dereference before null check") Fixes: c620b772152b ("net/mlx5: Refactor tc flow attributes structure") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5e: Fix a use after free on error in mlx5_tc_ct_shared_counter_get()Dan Carpenter
This code frees "shared_counter" and then dereferences on the next line to get the error code. Fixes: 1edae2335adf ("net/mlx5e: CT: Use the same counter for both directions") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: Fix dereference on pointer attr after null checkAriel Levkovich
When removing a flow from the slow path fdb, a flow attr struct is allocated for the rule removal process. If the allocation fails the code prints a warning message but continues with the removal flow which include dereferencing a pointer which could be null. Fix this by exiting the function in case the attr allocation failed. Fixes: c620b772152b ("net/mlx5: Refactor tc flow attributes structure") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: Use dma device access helperParav Pandit
Use the PCI device directly for dma accesses as non PCI device unlikely support IOMMU and dma mappings. Introduce and use helper routine to access DMA device. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-Switch, Support flow source for local vportHamdan Igbaria
Set flow source as hint for local vport. Signed-off-by: Hamdan Igbaria <hamdani@mellanox.com> Reviewed-by: Oz Shlomo <ozsh@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Move devlink eswitch ports closer to eswitchParav Pandit
Currently devlink eswitch ports are registered and unregistered by the representor layer. However it is better to register them at eswitch layer so that in future user initiated command port add and delete commands can also register/unregister devlink ports without depending on representor layer. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Use helper function to load unload representorParav Pandit
To register and unregister devlink ports when loading/unload representors, refactor the code to helper functions. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Add helper to check egress ACL needParav Pandit
Currently only VF vports need egress ACL table. Add a generic helper to check whether a vport need egress ACL table or not. Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: E-switch, Use PF num in metadata reg c0sunils
Currently only 256 vports can be supported as only 8 bits are reserved for them and 8 bits are reserved for vhca_ids in metadata reg c0. To support more than 256 vports, replace vhca_id with a unique shorter 4-bit PF number which covers upto 16 PF's. Use remaining 12 bits for vports ranging 1-4095. This will continue to generate unique metadata even if multiple PCI devices have same switch_id. Signed-off-by: sunils <sunils@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Add support for rule creation with flow source hintHamdan Igbaria
Skip the rule according to flow arrival source, in case of RX and the source is local port skip and in case of TX and the source is uplink skip, we get this info according to the flow source hint we get from upper layers when creating the rule. This is needed because for example in case of FDB table which has a TX and RX tables and we are inserting a rule with an encap action which is only a TX action, in this case rule will fail on RX, so we can rely on the flow source hint and skip RX in such case. Until now we relied on metadata regc_0 that upper layer mapped the port in the regc_0, but the problem is that upper layer did not always use regc_0 for port mapping, so now we added support to flow source hint which upper layers will pass to SW steering when creating a rule. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Hamdan Igbaria <hamdani@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Call ste_builder directly with tag pointerYevgeny Kliteynik
Instead of getting the tag in each function, call the builder directly with the tag. This will allow to use the same function for building the tag and the bitmask. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Remove unneeded local variableYevgeny Kliteynik
The misc3 variable is used only once and can be dropped. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Remove unneeded vlan check from L2 builderYevgeny Kliteynik
When we create a matcher we check that all fields are consumed. There is no need for this specific check. This keeps the STE builder functions simple and clean. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Remove unneeded check from source port builderYevgeny Kliteynik
Mask validity for ste builders is checked by mlx5dr_ste_build_pre_check during matcher creation. It already checks the mask value of source_vport, so removing this duplicated check. Also, moving there the check of source_eswitch_owner_vhca_id mask. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30net/mlx5: DR, Replace the check for valid STE entryYevgeny Kliteynik
Validity check is done by reading the next lu_type from the STE, this check can be replaced by checking the refcount. This will make the check independent on internal STE structure. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-09-30selftests/bpf: Fix alignment of .BTF_idsJean-Philippe Brucker
Fix a build failure on arm64, due to missing alignment information for the .BTF_ids section: resolve_btfids.test.o: in function `test_resolve_btfids': tools/testing/selftests/bpf/prog_tests/resolve_btfids.c:140:(.text+0x29c): relocation truncated to fit: R_AARCH64_LDST32_ABS_LO12_NC against `.BTF_ids' ld: tools/testing/selftests/bpf/prog_tests/resolve_btfids.c:140: warning: one possible cause of this error is that the symbol is being referenced in the indicated code as if it had a larger alignment than was declared where it was defined In vmlinux, the .BTF_ids section is aligned to 4 bytes by vmlinux.lds.h. In test_progs however, .BTF_ids doesn't have alignment constraints. The arm64 linker expects the btf_id_set.cnt symbol, a u32, to be naturally aligned but finds it misaligned and cannot apply the relocation. Enforce alignment of .BTF_ids to 4 bytes. Fixes: cd04b04de119 ("selftests/bpf: Add set test to resolve_btfids") Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Link: https://lore.kernel.org/bpf/20200930093559.2120126-1-jean-philippe@linaro.org
2020-09-30Merge branch 'drop_monitor-Convert-to-use-devlink-tracepoint'David S. Miller
Ido Schimmel says: ==================== drop_monitor: Convert to use devlink tracepoint Drop monitor is able to monitor both software and hardware originated drops. Software drops are monitored by having drop monitor register its probe on the 'kfree_skb' tracepoint. Hardware originated drops are monitored by having devlink call into drop monitor whenever it receives a dropped packet from the underlying hardware. This patch set converts drop monitor to monitor both software and hardware originated drops in the same way - by registering its probe on the relevant tracepoint. In addition to drop monitor being more consistent, it is now also possible to build drop monitor as module instead of as a builtin and still monitor hardware originated drops. Initially, CONFIG_NET_DEVLINK implied CONFIG_NET_DROP_MONITOR, but after commit def2fbffe62c ("kconfig: allow symbols implied by y to become m") we can have CONFIG_NET_DEVLINK=y and CONFIG_NET_DROP_MONITOR=m and hardware originated drops will not be monitored. Patch set overview: Patch #1 adds a tracepoint in devlink for trap reports. Patch #2 prepares probe functions in drop monitor for the new tracepoint. Patch #3 converts drop monitor to use the new tracepoint. Patches #4-#6 perform cleanups after the conversion. Patch #7 adds a test case for drop monitor. Both software originated drops and hardware originated drops (using netdevsim) are tested. Tested: | CONFIG_NET_DEVLINK | CONFIG_NET_DROP_MONITOR | Build | SW drops | HW drops | | -------------------|-------------------------|-------|----------|----------| | y | y | v | v | v | | y | m | v | v | v | | y | n | v | x | x | | n | y | v | v | x | | n | m | v | v | x | | n | n | v | x | x | ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30selftests: net: Add drop monitor testIdo Schimmel
Test that drop monitor correctly captures both software and hardware originated packet drops. # ./drop_monitor_tests.sh Software drops test TEST: Capturing active software drops [ OK ] TEST: Capturing inactive software drops [ OK ] Hardware drops test TEST: Capturing active hardware drops [ OK ] TEST: Capturing inactive hardware drops [ OK ] Tests passed: 4 Tests failed: 0 Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30drop_monitor: Filter control packets in drop monitorIdo Schimmel
Previously, devlink called into drop monitor in order to report hardware originated drops / exceptions. devlink intentionally filtered control packets and did not pass them to drop monitor as they were not dropped by the underlying hardware. Now drop monitor registers its probe on a generic 'devlink_trap_report' tracepoint and should therefore perform this filtering itself instead of having devlink do that. Add the trap type as metadata and have drop monitor ignore control packets. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30drop_monitor: Remove duplicate structIdo Schimmel
'struct net_dm_hw_metadata' is a duplicate of 'struct devlink_trap_metadata'. Remove the former and simplify the code. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30drop_monitor: Remove no longer used functionsIdo Schimmel
The old probe functions that were invoked by drop monitor code are no longer called and can thus be removed. They were replaced by actual probe functions that are registered on the recently introduced 'devlink_trap_report' tracepoint. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30drop_monitor: Convert to using devlink tracepointIdo Schimmel
Convert drop monitor to use the recently introduced 'devlink_trap_report' tracepoint instead of having devlink call into drop monitor. This is both consistent with software originated drops ('kfree_skb' tracepoint) and also allows drop monitor to be built as a module and still report hardware originated drops. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30drop_monitor: Prepare probe functions for devlink tracepointIdo Schimmel
Drop monitor supports two alerting modes: Summary and packet. Prepare a probe function for each, so that they could be later registered on the devlink tracepoint by calling register_trace_devlink_trap_report(), based on the configured alerting mode. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30devlink: Add a tracepoint for trap reportsIdo Schimmel
Add a tracepoint for trap reports so that drop monitor could register its probe on it. Use trace_devlink_trap_report_enabled() to avoid wasting cycles setting the trap metadata if the tracepoint is not enabled. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30Merge tag 'linux-can-next-for-5.10-20200930' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2020-09-30 this is a pull request of 13 patches for net-next. The first 10 target the mcp25xxfd driver (which is renamed to mcp251xfd during this series). The first two patches are by Thomas Kopp, which adds reference to the just related errata and updates the documentation and log messages. Dan Carpenter's patch fixes a resource leak during ifdown. A patch by me adds the missing initialization of a variable. Oleksij Rempel updates the DT binding documentation as requested by Rob Herring. The next 5 patches are by Thomas Kopp and me. During review Geert Uytterhoeven suggested to use "microchip,mcp251xfd" instead of "microchip,mcp25xxfd" as the DT autodetection compatible to avoid clashes with future but incompatible devices. We decided not only to rename the compatible but the whole driver from "mcp25xxfd" to "mcp251xfd". This is done in several patches. Joakim Zhang contributes three patches for the flexcan driver. The first one adds support for the ECC feature, which is implemented on some modern IP cores, by initializing the controller's memory during ifup. The next patch adds support for the i.MX8MP (which supports ECC) and the last patch properly disables the runtime PM if device registration fails. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30Merge branch 'ionic-watchdog-training'David S. Miller
Shannon Nelson says: ==================== ionic watchdog training Our link watchdog displayed a couple of unfriendly behaviors in some recent stress testing. These patches change the startup and stop timing in order to be sure that expected structures are ready to be used by the watchdog. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30ionic: prevent early watchdog checkShannon Nelson
In one corner case scenario, the driver device lif setup can get delayed such that the ionic_watchdog_cb() timer goes off before the ionic->lif is set, thus causing a NULL pointer panic. We catch the problem by checking for a NULL lif just a little earlier in the callback. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-09-30ionic: stop watchdog timer earlier on removeShannon Nelson
We need to be better at making sure we don't have a link check watchdog go off while we're shutting things down, so let's stop the timer as soon as we start the remove. Meanwhile, since that was the only thing in ionic_dev_teardown(), simplify and remove that function. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-12 22:55:26 +0000