Merge pull request #1 from torvalds/master #114

e-mailky · 2014-08-18T02:10:22Z

Merge pull request #1 from torvalds/master

pull from torvalds

pull from torvalds/linux

frankcash · 2014-08-18T02:23:23Z

Linus doesn't accept pull requests on GitHub.

pull from torvalds

Patrick-Edouard · 2014-08-18T07:33:49Z

You should take a look at https://www.kernel.org/doc/Documentation/SubmittingPatches

Replace __get_cpu_var safely with get_cpu_var to avoid the following call trace: [ 7253.637591] BUG: using smp_processor_id() in preemptible [00000000 00000000] code: hugemmap01/9048 [ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8 [ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ torvalds#114 [ 7253.637606] Call Trace: [ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable) [ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134 [ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8 [ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168 [ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150 [ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c [ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc [ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c [ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c [ 7253.637686] --- Exception: c01 at 0xff16004 Signed-off-by: Tiejun Chen<tiejun.chen@windriver.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: huawei.libin@huawei.com Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>

When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ #114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18 [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>

commit fd1d0dd upstream. When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ #114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit fd1d0dd ] When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ torvalds#114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18 [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

arm64: add system suspend support

…e tx interrut Doing tx_clean() inside poll() may scramble the tx ring buffer if tx() is running. This will cause tx to stop working, which can be reproduced by simultaneously downloading two large files at high speed. Moving tx_clean() into tx() will prevent this. And tx interrupt is no longer needed now. Picked the Shuyu's patch up, the patch is sent on https://patchwork.kernel.org/patch/8356821/, since that make sense for rockchip platform. Note: Many people feedback the cransh problems with rk3036/rk3188 emac when download the heavy loading and this patch is indeed can fix the crash. The crash log as the followings: ... [ 2191.996127 ] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc6 torvalds#114 [ 2192.002475 ] Hardware name: Rockchip (Device Tree) [ 2192.007174 ] Backtrace: [ 2192.009658 ] [<c00134d4>] (dump_backtrace) from [<c0013680>] (show_stack+0x18/0x1c) [ 2192.017220 ] r7:c051c4f8 r6:ef463180 r5:c05b7000 r4:00000000 [ 2192.022948 ] [<c0013668>] (show_stack) from [<c0219d90>] (dump_stack+0x90/0xa0) [ 2192.030176 ] [<c0219d00>] (dump_stack) from [<c00b2cd4>] (bad_page+0xdc/0x12c) [ 2192.037302 ] r5:c059a100 r4:c05f430c [ 2192.040913 ] [<c00b2bf8>] (bad_page) from [<c00b606c>] (get_page_from_freelist+0x388/0x95c) [ 2192.049166 ] r9:00000008 r8:ef463180 r7:c051c4d0 r6:00000000 r5:00000000 r4:c051c4e4 [ 2192.056982 ] [<c00b5ce4>] (get_page_from_freelist) from [<c00b6880>] (__alloc_pages_nodemask+0xd8/0x8e8) [ 2192.066362 ] r10:c001b068 r9:00000000 r8:ee0b02b0 r7:60000113 r6:00000003 r5:02095220 [ 2192.074254 ] r4:c05ca1c0 [ 2192.076809 ] [<c00b67a8>] (__alloc_pages_nodemask) from [<c00b7140>] (__alloc_page_frag+0xb0/0x160) [ 2192.085757 ] r10:c001b068 r9:00000000 r8:ee0b02b0 r7:60000113 r6:02080020 r5:00000740 [ 2192.093650 ] r4:eedbc884 [ 2192.096207 ] [<c00b7090>] (__alloc_page_frag) from [<c03273b4>] (__netdev_alloc_skb+0xa0/0x104) [ 2192.104806 ] r7:60000113 r6:eedbc884 r5:ee0b0000 r4:00000740 [ 2192.110525 ] [<c0327314>] (__netdev_alloc_skb) from [<c02aac00>] (arc_emac_poll+0x318/0x57c) [ 2192.118865 ] r9:00000000 r8:ee0b02b0 r7:0000019c r6:ee163780 r5:00000670 r4:ee0b0000 [ 2192.126683 ] [<c02aa8e8>] (arc_emac_poll) from [<c0339ed8>] (net_rx_action+0x1f0/0x2ec) [ 2192.134590 ] r10:c0599df8 r9:c059a100 r8:00073760 r7:0000012c r6:00000028 r5:c02aa8e8 [ 2192.142483 ] r4:ee0b04e0 [ 2192.145040 ] [<c0339ce8>] (net_rx_action) from [<c0026f5c>] (__do_softirq+0x134/0x258) [ 2192.152860 ] r10:c059a080 r9:40000003 r8:00000003 r7:00000100 r6:c0598000 r5:c059a08c [ 2192.160751 ] r4:00000000 ... Signed-off-by: Shuyu Wei <sy.w@outlook.com> Tested-by: Michael Niewoehner <linux@mniewoehner.de> Tested-by: Xing Zheng <zhengxing@rock-chips.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexander Kochetkov <al.kochet@gmail.com> Cc: netdev@vger.kernel.org Signed-off-by: Caesar Wang <wxt@rock-chips.com>

WARNING: 'minumum' may be misspelled - perhaps 'minimum'? torvalds#114: FILE: fs/namespace.c:1367: + * to the tree at mnt is one greater than the minumum WARNING: function definition argument 'struct mount *' should also have an identifier name torvalds#168: FILE: fs/pnode.h:41: +struct mount *propagation_next(struct mount *, struct mount *); WARNING: function definition argument 'struct mount *' should also have an identifier name torvalds#168: FILE: fs/pnode.h:41: +struct mount *propagation_next(struct mount *, struct mount *); total: 0 errors, 3 warnings, 125 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/vfs-make-may_umount_tree-mount-propogation-aware.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Ian Kent <ikent@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

lkl: Replace threads_counter_lock with atomic ops

commit fd1d0dd upstream. When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ torvalds#114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…rval to 1ms Prevent the host from being set to poll every frame as this causes excessive polling resulting in excessive EMC emissions Fixes torvalds#114

Currently a crash can be seen if we reach the "err" label in dmi_add_platform_ipmi(), calling platform_device_put(), like here: [ 7.270584] (null): ipmi:dmi: Unable to add resources: -16 [ 7.330229] ------------[ cut here ]------------ [ 7.334889] kernel BUG at mm/slub.c:3894! [ 7.338936] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 7.344475] Modules linked in: [ 7.347556] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00004-gbe9cb7b-dirty torvalds#114 [ 7.355907] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 11/29/2017 [ 7.365137] task: 00000000c211f6d3 task.stack: 00000000f276e9af [ 7.371116] pstate: 60000005 (nZCv daif -PAN -UAO) [ 7.375957] pc : kfree+0x194/0x1b4 [ 7.379389] lr : platform_device_release+0xcc/0xd8 [ 7.384225] sp : ffff0000092dba90 [ 7.387567] x29: ffff0000092dba90 x28: ffff000008a83000 [ 7.392933] x27: ffff0000092dbc10 x26: 00000000000000e6 [ 7.398297] x25: 0000000000000003 x24: ffff0000085b51e8 [ 7.403662] x23: 0000000000000100 x22: ffff7e0000234cc0 [ 7.409027] x21: ffff000008af3660 x20: ffff8017d21acc10 [ 7.414392] x19: ffff8017d21acc00 x18: 0000000000000002 [ 7.419757] x17: 0000000000000001 x16: 0000000000000008 [ 7.425121] x15: 0000000000000001 x14: 6666666678303d65 [ 7.430486] x13: 6469727265766f5f x12: 7265766972642e76 [ 7.435850] x11: 6564703e2d617020 x10: 6530326435373638 [ 7.441215] x9 : 3030303030303030 x8 : 3d76656420657361 [ 7.446580] x7 : ffff000008f59df8 x6 : ffff8017fbe0ea50 [ 7.451945] x5 : 0000000000000000 x4 : 0000000000000000 [ 7.457309] x3 : ffffffffffffffff x2 : 0000000000000000 [ 7.462674] x1 : 0fffc00000000800 x0 : ffff7e0000234ce0 [ 7.468039] Process swapper/0 (pid: 1, stack limit = 0x00000000f276e9af) [ 7.474809] Call trace: [ 7.477272] kfree+0x194/0x1b4 [ 7.480351] platform_device_release+0xcc/0xd8 [ 7.484837] device_release+0x34/0x90 [ 7.488531] kobject_put+0x70/0xcc [ 7.491961] put_device+0x14/0x1c [ 7.495304] platform_device_put+0x14/0x1c [ 7.499439] dmi_add_platform_ipmi+0x348/0x3ac [ 7.503923] scan_for_dmi_ipmi+0xfc/0x10c [ 7.507970] do_one_initcall+0x38/0x124 [ 7.511840] kernel_init_freeable+0x188/0x228 [ 7.516238] kernel_init+0x10/0x100 [ 7.519756] ret_from_fork+0x10/0x18 [ 7.523362] Code: f94002c0 37780080 f94012c0 37000040 (d4210000) [ 7.529552] ---[ end trace 11750e4787deef9e ]--- [ 7.534228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 7.534228] This is because when the device is released in platform_device_release(), we try to free pdev.driver_override. This is a const string, hence the crash. Fix by using dynamic memory for pdev->driver_override. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Cc: <stable@vger.kernel.org> # 4.14.x

Currently a crash can be seen if we reach the "err" label in dmi_add_platform_ipmi(), calling platform_device_put(), like here: [ 7.270584] (null): ipmi:dmi: Unable to add resources: -16 [ 7.330229] ------------[ cut here ]------------ [ 7.334889] kernel BUG at mm/slub.c:3894! [ 7.338936] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 7.344475] Modules linked in: [ 7.347556] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-00004-gbe9cb7b-dirty torvalds#114 [ 7.355907] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 11/29/2017 [ 7.365137] task: 00000000c211f6d3 task.stack: 00000000f276e9af [ 7.371116] pstate: 60000005 (nZCv daif -PAN -UAO) [ 7.375957] pc : kfree+0x194/0x1b4 [ 7.379389] lr : platform_device_release+0xcc/0xd8 [ 7.384225] sp : ffff0000092dba90 [ 7.387567] x29: ffff0000092dba90 x28: ffff000008a83000 [ 7.392933] x27: ffff0000092dbc10 x26: 00000000000000e6 [ 7.398297] x25: 0000000000000003 x24: ffff0000085b51e8 [ 7.403662] x23: 0000000000000100 x22: ffff7e0000234cc0 [ 7.409027] x21: ffff000008af3660 x20: ffff8017d21acc10 [ 7.414392] x19: ffff8017d21acc00 x18: 0000000000000002 [ 7.419757] x17: 0000000000000001 x16: 0000000000000008 [ 7.425121] x15: 0000000000000001 x14: 6666666678303d65 [ 7.430486] x13: 6469727265766f5f x12: 7265766972642e76 [ 7.435850] x11: 6564703e2d617020 x10: 6530326435373638 [ 7.441215] x9 : 3030303030303030 x8 : 3d76656420657361 [ 7.446580] x7 : ffff000008f59df8 x6 : ffff8017fbe0ea50 [ 7.451945] x5 : 0000000000000000 x4 : 0000000000000000 [ 7.457309] x3 : ffffffffffffffff x2 : 0000000000000000 [ 7.462674] x1 : 0fffc00000000800 x0 : ffff7e0000234ce0 [ 7.468039] Process swapper/0 (pid: 1, stack limit = 0x00000000f276e9af) [ 7.474809] Call trace: [ 7.477272] kfree+0x194/0x1b4 [ 7.480351] platform_device_release+0xcc/0xd8 [ 7.484837] device_release+0x34/0x90 [ 7.488531] kobject_put+0x70/0xcc [ 7.491961] put_device+0x14/0x1c [ 7.495304] platform_device_put+0x14/0x1c [ 7.499439] dmi_add_platform_ipmi+0x348/0x3ac [ 7.503923] scan_for_dmi_ipmi+0xfc/0x10c [ 7.507970] do_one_initcall+0x38/0x124 [ 7.511840] kernel_init_freeable+0x188/0x228 [ 7.516238] kernel_init+0x10/0x100 [ 7.519756] ret_from_fork+0x10/0x18 [ 7.523362] Code: f94002c0 37780080 f94012c0 37000040 (d4210000) [ 7.529552] ---[ end trace 11750e4787deef9e ]--- [ 7.534228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 7.534228] This is because when the device is released in platform_device_release(), we try to free pdev.driver_override. This is a const string, hence the crash. Fix by using dynamic memory for pdev->driver_override. Signed-off-by: John Garry <john.garry@huawei.com> [Removed the free of driver_override from ipmi_si_remove_by_dev(). The free is done in platform_device_release(), and would result in a double free, and ipmi_si_remove_by_dev() is called by non-platform devices.] Signed-off-by: Corey Minyard <cminyard@mvista.com> Cc: <stable@vger.kernel.org> # 4.14+

Fix CVE-2017-1000405 and mptsas hotplug in 4.13

WARNING: line over 80 characters torvalds#34: FILE: fs/ocfs2/alloc.c:1484: + status = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#35: FILE: fs/ocfs2/alloc.c:1485: +^I^I^I^I "Owner %llu has empty extent list (next_free_rec == 0)\n",$ WARNING: line over 80 characters torvalds#36: FILE: fs/ocfs2/alloc.c:1486: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci)); ERROR: code indent should use tabs where possible torvalds#36: FILE: fs/ocfs2/alloc.c:1486: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci));$ WARNING: line over 80 characters torvalds#46: FILE: fs/ocfs2/alloc.c:1492: + status = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#47: FILE: fs/ocfs2/alloc.c:1493: +^I^I^I^I "Owner %llu has extent list where extent # %d has no physical block start\n",$ WARNING: line over 80 characters torvalds#48: FILE: fs/ocfs2/alloc.c:1494: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), i); ERROR: code indent should use tabs where possible torvalds#48: FILE: fs/ocfs2/alloc.c:1494: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), i);$ WARNING: line over 80 characters torvalds#61: FILE: fs/ocfs2/alloc.c:3215: + ret = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#62: FILE: fs/ocfs2/alloc.c:3216: +^I^I^I^I "Owner %llu has empty extent block at %llu\n",$ WARNING: line over 80 characters torvalds#63: FILE: fs/ocfs2/alloc.c:3217: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), ERROR: code indent should use tabs where possible torvalds#63: FILE: fs/ocfs2/alloc.c:3217: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci),$ WARNING: line over 80 characters torvalds#64: FILE: fs/ocfs2/alloc.c:3218: + (unsigned long long)le64_to_cpu(eb->h_blkno)); ERROR: code indent should use tabs where possible torvalds#64: FILE: fs/ocfs2/alloc.c:3218: +^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno));$ ERROR: code indent should use tabs where possible torvalds#79: FILE: fs/ocfs2/alloc.c:4412: +^I^I^I^I^I "Extent block #%llu has an invalid l_next_free_rec of %d. It should have matched the l_count of %d\n",$ WARNING: line over 80 characters torvalds#80: FILE: fs/ocfs2/alloc.c:4413: + (unsigned long long)le64_to_cpu(eb->h_blkno), ERROR: code indent should use tabs where possible torvalds#80: FILE: fs/ocfs2/alloc.c:4413: +^I^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno),$ WARNING: line over 80 characters torvalds#81: FILE: fs/ocfs2/alloc.c:4414: + le16_to_cpu(new_el->l_next_free_rec), ERROR: code indent should use tabs where possible torvalds#81: FILE: fs/ocfs2/alloc.c:4414: +^I^I^I^I^I le16_to_cpu(new_el->l_next_free_rec),$ WARNING: line over 80 characters torvalds#82: FILE: fs/ocfs2/alloc.c:4415: + le16_to_cpu(new_el->l_count)); ERROR: code indent should use tabs where possible torvalds#82: FILE: fs/ocfs2/alloc.c:4415: +^I^I^I^I^I le16_to_cpu(new_el->l_count));$ ERROR: code indent should use tabs where possible torvalds#96: FILE: fs/ocfs2/alloc.c:4466: +^I^I^I^I^I "Extent block #%llu has an invalid l_next_free_rec of %d\n",$ WARNING: line over 80 characters torvalds#97: FILE: fs/ocfs2/alloc.c:4467: + (unsigned long long)le64_to_cpu(eb->h_blkno), ERROR: code indent should use tabs where possible torvalds#97: FILE: fs/ocfs2/alloc.c:4467: +^I^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno),$ WARNING: line over 80 characters torvalds#98: FILE: fs/ocfs2/alloc.c:4468: + le16_to_cpu(new_el->l_next_free_rec)); ERROR: code indent should use tabs where possible torvalds#98: FILE: fs/ocfs2/alloc.c:4468: +^I^I^I^I^I le16_to_cpu(new_el->l_next_free_rec));$ WARNING: line over 80 characters torvalds#114: FILE: fs/ocfs2/localalloc.c:666: + status = ocfs2_error(osb->sb, "local alloc inode %llu says it has %u used bits, but a count shows %u\n", WARNING: line over 80 characters torvalds#115: FILE: fs/ocfs2/localalloc.c:667: + (unsigned long long)le64_to_cpu(alloc->i_blkno), ERROR: code indent should use tabs where possible torvalds#115: FILE: fs/ocfs2/localalloc.c:667: +^I^I^I (unsigned long long)le64_to_cpu(alloc->i_blkno),$ ERROR: code indent should use tabs where possible torvalds#116: FILE: fs/ocfs2/localalloc.c:668: +^I^I^I le32_to_cpu(alloc->id1.bitmap1.i_used),$ ERROR: code indent should use tabs where possible torvalds#117: FILE: fs/ocfs2/localalloc.c:669: +^I^I^I ocfs2_local_alloc_count_bits(alloc));$ ERROR: code indent should use tabs where possible torvalds#138: FILE: fs/ocfs2/quota_local.c:142: +^I^I^I "Quota file %llu is probably corrupted! Requested to read block %Lu but file has size only %Lu\n",$ WARNING: %Lu is non-standard C, use %llu torvalds#138: FILE: fs/ocfs2/quota_local.c:142: + "Quota file %llu is probably corrupted! Requested to read block %Lu but file has size only %Lu\n", ERROR: code indent should use tabs where possible torvalds#139: FILE: fs/ocfs2/quota_local.c:143: +^I^I^I (unsigned long long)OCFS2_I(inode)->ip_blkno,$ ERROR: code indent should use tabs where possible torvalds#140: FILE: fs/ocfs2/quota_local.c:144: +^I^I^I (unsigned long long)v_block,$ ERROR: code indent should use tabs where possible torvalds#141: FILE: fs/ocfs2/quota_local.c:145: +^I^I^I (unsigned long long)i_size_read(inode));$ total: 21 errors, 15 warnings, 108 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/ocfs2-return-erofs-when-filesystem-becomes-read-only.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

WARNING: line over 80 characters torvalds#34: FILE: fs/ocfs2/alloc.c:1484: + status = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#35: FILE: fs/ocfs2/alloc.c:1485: +^I^I^I^I "Owner %llu has empty extent list (next_free_rec == 0)\n",$ WARNING: line over 80 characters torvalds#36: FILE: fs/ocfs2/alloc.c:1486: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci)); ERROR: code indent should use tabs where possible torvalds#36: FILE: fs/ocfs2/alloc.c:1486: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci));$ WARNING: line over 80 characters torvalds#46: FILE: fs/ocfs2/alloc.c:1492: + status = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#47: FILE: fs/ocfs2/alloc.c:1493: +^I^I^I^I "Owner %llu has extent list where extent # %d has no physical block start\n",$ WARNING: line over 80 characters torvalds#48: FILE: fs/ocfs2/alloc.c:1494: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), i); ERROR: code indent should use tabs where possible torvalds#48: FILE: fs/ocfs2/alloc.c:1494: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), i);$ WARNING: line over 80 characters torvalds#61: FILE: fs/ocfs2/alloc.c:3215: + ret = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#62: FILE: fs/ocfs2/alloc.c:3216: +^I^I^I^I "Owner %llu has empty extent block at %llu\n",$ WARNING: line over 80 characters torvalds#63: FILE: fs/ocfs2/alloc.c:3217: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), ERROR: code indent should use tabs where possible torvalds#63: FILE: fs/ocfs2/alloc.c:3217: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci),$ WARNING: line over 80 characters torvalds#64: FILE: fs/ocfs2/alloc.c:3218: + (unsigned long long)le64_to_cpu(eb->h_blkno)); ERROR: code indent should use tabs where possible torvalds#64: FILE: fs/ocfs2/alloc.c:3218: +^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno));$ ERROR: code indent should use tabs where possible torvalds#79: FILE: fs/ocfs2/alloc.c:4412: +^I^I^I^I^I "Extent block #%llu has an invalid l_next_free_rec of %d. It should have matched the l_count of %d\n",$ WARNING: line over 80 characters torvalds#80: FILE: fs/ocfs2/alloc.c:4413: + (unsigned long long)le64_to_cpu(eb->h_blkno), ERROR: code indent should use tabs where possible torvalds#80: FILE: fs/ocfs2/alloc.c:4413: +^I^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno),$ WARNING: line over 80 characters torvalds#81: FILE: fs/ocfs2/alloc.c:4414: + le16_to_cpu(new_el->l_next_free_rec), ERROR: code indent should use tabs where possible torvalds#81: FILE: fs/ocfs2/alloc.c:4414: +^I^I^I^I^I le16_to_cpu(new_el->l_next_free_rec),$ WARNING: line over 80 characters torvalds#82: FILE: fs/ocfs2/alloc.c:4415: + le16_to_cpu(new_el->l_count)); ERROR: code indent should use tabs where possible torvalds#82: FILE: fs/ocfs2/alloc.c:4415: +^I^I^I^I^I le16_to_cpu(new_el->l_count));$ ERROR: code indent should use tabs where possible torvalds#96: FILE: fs/ocfs2/alloc.c:4466: +^I^I^I^I^I "Extent block #%llu has an invalid l_next_free_rec of %d\n",$ WARNING: line over 80 characters torvalds#97: FILE: fs/ocfs2/alloc.c:4467: + (unsigned long long)le64_to_cpu(eb->h_blkno), ERROR: code indent should use tabs where possible torvalds#97: FILE: fs/ocfs2/alloc.c:4467: +^I^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno),$ WARNING: line over 80 characters torvalds#98: FILE: fs/ocfs2/alloc.c:4468: + le16_to_cpu(new_el->l_next_free_rec)); ERROR: code indent should use tabs where possible torvalds#98: FILE: fs/ocfs2/alloc.c:4468: +^I^I^I^I^I le16_to_cpu(new_el->l_next_free_rec));$ WARNING: line over 80 characters torvalds#114: FILE: fs/ocfs2/localalloc.c:666: + status = ocfs2_error(osb->sb, "local alloc inode %llu says it has %u used bits, but a count shows %u\n", WARNING: line over 80 characters torvalds#115: FILE: fs/ocfs2/localalloc.c:667: + (unsigned long long)le64_to_cpu(alloc->i_blkno), ERROR: code indent should use tabs where possible torvalds#115: FILE: fs/ocfs2/localalloc.c:667: +^I^I^I (unsigned long long)le64_to_cpu(alloc->i_blkno),$ ERROR: code indent should use tabs where possible torvalds#116: FILE: fs/ocfs2/localalloc.c:668: +^I^I^I le32_to_cpu(alloc->id1.bitmap1.i_used),$ ERROR: code indent should use tabs where possible torvalds#117: FILE: fs/ocfs2/localalloc.c:669: +^I^I^I ocfs2_local_alloc_count_bits(alloc));$ ERROR: code indent should use tabs where possible torvalds#138: FILE: fs/ocfs2/quota_local.c:142: +^I^I^I "Quota file %llu is probably corrupted! Requested to read block %Lu but file has size only %Lu\n",$ WARNING: %Lu is non-standard C, use %llu torvalds#138: FILE: fs/ocfs2/quota_local.c:142: + "Quota file %llu is probably corrupted! Requested to read block %Lu but file has size only %Lu\n", ERROR: code indent should use tabs where possible torvalds#139: FILE: fs/ocfs2/quota_local.c:143: +^I^I^I (unsigned long long)OCFS2_I(inode)->ip_blkno,$ ERROR: code indent should use tabs where possible torvalds#140: FILE: fs/ocfs2/quota_local.c:144: +^I^I^I (unsigned long long)v_block,$ ERROR: code indent should use tabs where possible torvalds#141: FILE: fs/ocfs2/quota_local.c:145: +^I^I^I (unsigned long long)i_size_read(inode));$ total: 21 errors, 15 warnings, 108 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/ocfs2-return-erofs-when-filesystem-becomes-read-only.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

WARNING: line over 80 characters torvalds#34: FILE: fs/ocfs2/alloc.c:1484: + status = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#35: FILE: fs/ocfs2/alloc.c:1485: +^I^I^I^I "Owner %llu has empty extent list (next_free_rec == 0)\n",$ WARNING: line over 80 characters torvalds#36: FILE: fs/ocfs2/alloc.c:1486: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci)); ERROR: code indent should use tabs where possible torvalds#36: FILE: fs/ocfs2/alloc.c:1486: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci));$ WARNING: line over 80 characters torvalds#46: FILE: fs/ocfs2/alloc.c:1492: + status = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#47: FILE: fs/ocfs2/alloc.c:1493: +^I^I^I^I "Owner %llu has extent list where extent # %d has no physical block start\n",$ WARNING: line over 80 characters torvalds#48: FILE: fs/ocfs2/alloc.c:1494: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), i); ERROR: code indent should use tabs where possible torvalds#48: FILE: fs/ocfs2/alloc.c:1494: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), i);$ WARNING: line over 80 characters torvalds#61: FILE: fs/ocfs2/alloc.c:3215: + ret = ocfs2_error(ocfs2_metadata_cache_get_super(et->et_ci), ERROR: code indent should use tabs where possible torvalds#62: FILE: fs/ocfs2/alloc.c:3216: +^I^I^I^I "Owner %llu has empty extent block at %llu\n",$ WARNING: line over 80 characters torvalds#63: FILE: fs/ocfs2/alloc.c:3217: + (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci), ERROR: code indent should use tabs where possible torvalds#63: FILE: fs/ocfs2/alloc.c:3217: +^I^I^I^I (unsigned long long)ocfs2_metadata_cache_owner(et->et_ci),$ WARNING: line over 80 characters torvalds#64: FILE: fs/ocfs2/alloc.c:3218: + (unsigned long long)le64_to_cpu(eb->h_blkno)); ERROR: code indent should use tabs where possible torvalds#64: FILE: fs/ocfs2/alloc.c:3218: +^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno));$ ERROR: code indent should use tabs where possible torvalds#79: FILE: fs/ocfs2/alloc.c:4412: +^I^I^I^I^I "Extent block #%llu has an invalid l_next_free_rec of %d. It should have matched the l_count of %d\n",$ WARNING: line over 80 characters torvalds#80: FILE: fs/ocfs2/alloc.c:4413: + (unsigned long long)le64_to_cpu(eb->h_blkno), ERROR: code indent should use tabs where possible torvalds#80: FILE: fs/ocfs2/alloc.c:4413: +^I^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno),$ WARNING: line over 80 characters torvalds#81: FILE: fs/ocfs2/alloc.c:4414: + le16_to_cpu(new_el->l_next_free_rec), ERROR: code indent should use tabs where possible torvalds#81: FILE: fs/ocfs2/alloc.c:4414: +^I^I^I^I^I le16_to_cpu(new_el->l_next_free_rec),$ WARNING: line over 80 characters torvalds#82: FILE: fs/ocfs2/alloc.c:4415: + le16_to_cpu(new_el->l_count)); ERROR: code indent should use tabs where possible torvalds#82: FILE: fs/ocfs2/alloc.c:4415: +^I^I^I^I^I le16_to_cpu(new_el->l_count));$ ERROR: code indent should use tabs where possible torvalds#96: FILE: fs/ocfs2/alloc.c:4466: +^I^I^I^I^I "Extent block #%llu has an invalid l_next_free_rec of %d\n",$ WARNING: line over 80 characters torvalds#97: FILE: fs/ocfs2/alloc.c:4467: + (unsigned long long)le64_to_cpu(eb->h_blkno), ERROR: code indent should use tabs where possible torvalds#97: FILE: fs/ocfs2/alloc.c:4467: +^I^I^I^I^I (unsigned long long)le64_to_cpu(eb->h_blkno),$ WARNING: line over 80 characters torvalds#98: FILE: fs/ocfs2/alloc.c:4468: + le16_to_cpu(new_el->l_next_free_rec)); ERROR: code indent should use tabs where possible torvalds#98: FILE: fs/ocfs2/alloc.c:4468: +^I^I^I^I^I le16_to_cpu(new_el->l_next_free_rec));$ WARNING: line over 80 characters torvalds#114: FILE: fs/ocfs2/localalloc.c:666: + status = ocfs2_error(osb->sb, "local alloc inode %llu says it has %u used bits, but a count shows %u\n", WARNING: line over 80 characters torvalds#115: FILE: fs/ocfs2/localalloc.c:667: + (unsigned long long)le64_to_cpu(alloc->i_blkno), ERROR: code indent should use tabs where possible torvalds#115: FILE: fs/ocfs2/localalloc.c:667: +^I^I^I (unsigned long long)le64_to_cpu(alloc->i_blkno),$ ERROR: code indent should use tabs where possible torvalds#116: FILE: fs/ocfs2/localalloc.c:668: +^I^I^I le32_to_cpu(alloc->id1.bitmap1.i_used),$ ERROR: code indent should use tabs where possible torvalds#117: FILE: fs/ocfs2/localalloc.c:669: +^I^I^I ocfs2_local_alloc_count_bits(alloc));$ ERROR: code indent should use tabs where possible torvalds#138: FILE: fs/ocfs2/quota_local.c:142: +^I^I^I "Quota file %llu is probably corrupted! Requested to read block %Lu but file has size only %Lu\n",$ WARNING: %Lu is non-standard C, use %llu torvalds#138: FILE: fs/ocfs2/quota_local.c:142: + "Quota file %llu is probably corrupted! Requested to read block %Lu but file has size only %Lu\n", ERROR: code indent should use tabs where possible torvalds#139: FILE: fs/ocfs2/quota_local.c:143: +^I^I^I (unsigned long long)OCFS2_I(inode)->ip_blkno,$ ERROR: code indent should use tabs where possible torvalds#140: FILE: fs/ocfs2/quota_local.c:144: +^I^I^I (unsigned long long)v_block,$ ERROR: code indent should use tabs where possible torvalds#141: FILE: fs/ocfs2/quota_local.c:145: +^I^I^I (unsigned long long)i_size_read(inode));$ total: 21 errors, 15 warnings, 108 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/ocfs2-return-erofs-when-filesystem-becomes-read-only.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

When enabling the CRTC after waking up from a power-saving mode, the primary plane's framebuffer might be NULL, which leads to a stack trace as shown below. [ 632.624608] BUG: kernel NULL pointer dereference, address: 0000000000000048 [ 632.624631] #PF: supervisor read access in kernel mode [ 632.624639] #PF: error_code(0x0000) - not-present page [ 632.624647] PGD 0 P4D 0 [ 632.624654] Oops: 0000 [rib#1] SMP PTI [ 632.624662] CPU: 0 PID: 2082 Comm: gnome-shell Tainted: G E 5.4.0-rc7-1-default+ torvalds#114 [ 632.624673] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN FIRE X2270 M2, BIOS 2.05 07/01/2010 [ 632.624689] RIP: 0010:ast_crtc_helper_atomic_enable+0x7d/0x680 [ast] [ 632.624698] Code: 48 8b 80 e0 02 00 00 4c 8b 60 10 31 c0 f3 48 ab 48 8b 83 78 04 00 00 4c 89 ef 48 8d 70 18 e8 9a e9 55 ce 48 8b 83 78 04 00 00 <49> 8b 7c 24 48 4c 89 ea 4c 8d 44 24 28 48 8d 4c 24 20 48 8d 70 18 [ 632.624718] RSP: 0018:ffffbe9ec123fa40 EFLAGS: 00010246 [ 632.624726] RAX: ffff95a13cfd3400 RBX: ffff95a13cf32000 RCX: 0000000000000000 [ 632.624735] RDX: 0000000000000000 RSI: ffff95a13cfd34e8 RDI: ffffbe9ec123fb40 [ 632.624744] RBP: ffffbe9ec123fb80 R08: 0000000000000000 R09: 0000000000000003 [ 632.624753] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 632.624762] R13: ffffbe9ec123fa70 R14: ffff95a13beb7000 R15: ffff95a13cf32800 [ 632.624772] FS: 00007f6d2763e140(0000) GS:ffff95a134000000(0000) knlGS:0000000000000000 [ 632.624782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 632.624790] CR2: 0000000000000048 CR3: 00000001192f8004 CR4: 00000000000206f0 [ 632.624800] Call Trace: [ 632.624811] ? __lock_acquire+0x409/0x7c0 [ 632.624830] drm_atomic_helper_commit_modeset_enables+0x1af/0x200 [ 632.624840] drm_atomic_helper_commit_tail+0x32/0x70 [ 632.624849] commit_tail+0xc7/0x110 [ 632.624857] drm_atomic_helper_commit+0x121/0x130 [ 632.624867] drm_atomic_connector_commit_dpms+0xd7/0x100 [ 632.624878] set_property_atomic+0xaf/0x110 [ 632.624890] drm_mode_obj_set_property_ioctl+0xbb/0x190 [ 632.624899] ? drm_mode_obj_find_prop_id+0x40/0x40 [ 632.624909] drm_ioctl_kernel+0x86/0xd0 [ 632.624918] drm_ioctl+0x1e4/0x36b [ 632.624925] ? drm_mode_obj_find_prop_id+0x40/0x40 [ 632.624939] do_vfs_ioctl+0x4bd/0x6e0 [ 632.624949] ksys_ioctl+0x5e/0x90 [ 632.624957] __x64_sys_ioctl+0x16/0x20 [ 632.624966] do_syscall_64+0x5a/0x220 [ 632.624976] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 632.624984] RIP: 0033:0x7f6d2b0de387 [ 632.624991] Code: 00 00 90 48 8b 05 f9 9a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c9 9a 0c 00 f7 d8 64 89 01 48 [ 632.625011] RSP: 002b:00007fffb49def38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 632.625021] RAX: ffffffffffffffda RBX: 00007fffb49def70 RCX: 00007f6d2b0de387 [ 632.625030] RDX: 00007fffb49def70 RSI: 00000000c01864ba RDI: 0000000000000009 [ 632.625040] RBP: 00000000c01864ba R08: 0000000000000000 R09: 00000000c0c0c0c0 [ 632.625049] R10: 0000000000000030 R11: 0000000000000246 R12: 000055bc367eb920 [ 632.625058] R13: 0000000000000009 R14: 0000000000000002 R15: 0000000000000000 [ 632.625071] Modules linked in: ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) ip_tables(E) x_tables(E) af_packet(E) scsi_transport_iscsi(E) dmi_sysfs(E) msr(E) xfs(E) intel_powerclamp(E) coretemp(E) k) [ 632.625185] CR2: 0000000000000048 The STR is * start gdm and wait for it to switch off the display * wake up the display by pressing a key CRTC modesetting depends on the new state of the CRTC and the primary plane's framebuffer. The bugfix moves the modesetting code into the CRTC's atomic_flush() function, where it is protected from the plane's framebuffer being NULL. The CRTC's atomic-enable function, which is the modesetting's original location, still contains DPMS state handling. It's exactly the inverse of the atomic-disable function. v3: * protect modesetting from from fb == NULL v2: * do an atomic check for plane * reject invisible primary planes Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Fixes: b48e1b6 ("drm/ast: Add CRTC helpers for atomic modesetting") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Y.C. Chen" <yc_chen@aspeedtech.com> Cc: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191202111557.15176-2-tzimmermann@suse.de

[ 23.419442] BUG: KASAN: null-ptr-deref in intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.419527] Read of size 4 at addr 00000000000000f8 by task insmod/735 [ 23.419578] [ 23.419644] CPU: 2 PID: 735 Comm: insmod Not tainted 5.5.0+ torvalds#114 [ 23.419716] Hardware name: �� /��, BIOS RYBDWi35.86A.0246.2 [ 23.419793] Call Trace: [ 23.419864] dump_stack+0xef/0x16e [ 23.419927] __kasan_report.cold+0x60/0x90 [ 23.420157] ? intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420397] intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420630] intel_atomic_check+0x455f/0x65a0 [i915] [ 23.420708] ? mark_held_locks+0x90/0x90 [ 23.420929] ? intel_crtc_duplicate_state+0x2e/0x1b0 [i915] [ 23.421172] ? intel_plane_duplicate_state+0x2d/0xc0 [i915] [ 23.421239] ? __drm_dbg+0xa4/0x120 [ 23.421303] ? __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 23.421355] ? __kmalloc_track_caller+0x23a/0x320 [ 23.421602] ? intel_calc_active_pipes+0x1c0/0x1c0 [i915] [ 23.421852] sanitize_watermarks+0x220/0x510 [i915] [ 23.422092] ? intel_atomic_check+0x65a0/0x65a0 [i915] [ 23.422164] ? drm_modeset_unlock_all+0x88/0x130 [ 23.422402] intel_modeset_init+0x1b76/0x3c90 [i915] [ 23.422647] ? intel_finish_reset+0x2d0/0x2d0 [i915] [ 23.422851] ? intel_irq_install+0x12c/0x210 [i915] [ 23.423076] i915_driver_probe+0x13e7/0x2930 [i915] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>

[ 23.419442] BUG: KASAN: null-ptr-deref in intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.419527] Read of size 4 at addr 00000000000000f8 by task insmod/735 [ 23.419578] [ 23.419644] CPU: 2 PID: 735 Comm: insmod Not tainted 5.5.0+ torvalds#114 [ 23.419716] Hardware name: �� /��, BIOS RYBDWi35.86A.0246.2 [ 23.419793] Call Trace: [ 23.419864] dump_stack+0xef/0x16e [ 23.419927] __kasan_report.cold+0x60/0x90 [ 23.420157] ? intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420397] intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420630] intel_atomic_check+0x455f/0x65a0 [i915] [ 23.420708] ? mark_held_locks+0x90/0x90 [ 23.420929] ? intel_crtc_duplicate_state+0x2e/0x1b0 [i915] [ 23.421172] ? intel_plane_duplicate_state+0x2d/0xc0 [i915] [ 23.421239] ? __drm_dbg+0xa4/0x120 [ 23.421303] ? __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 23.421355] ? __kmalloc_track_caller+0x23a/0x320 [ 23.421602] ? intel_calc_active_pipes+0x1c0/0x1c0 [i915] [ 23.421852] sanitize_watermarks+0x220/0x510 [i915] [ 23.422092] ? intel_atomic_check+0x65a0/0x65a0 [i915] [ 23.422164] ? drm_modeset_unlock_all+0x88/0x130 [ 23.422402] intel_modeset_init+0x1b76/0x3c90 [i915] [ 23.422647] ? intel_finish_reset+0x2d0/0x2d0 [i915] [ 23.422851] ? intel_irq_install+0x12c/0x210 [i915] [ 23.423076] i915_driver_probe+0x13e7/0x2930 [i915] v2: No crtc is implied by an invisible plane, so the extra !crtc check is redundant. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

[ 23.419442] BUG: KASAN: null-ptr-deref in intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.419527] Read of size 4 at addr 00000000000000f8 by task insmod/735 [ 23.419578] [ 23.419644] CPU: 2 PID: 735 Comm: insmod Not tainted 5.5.0+ torvalds#114 [ 23.419716] Hardware name: �� /��, BIOS RYBDWi35.86A.0246.2 [ 23.419793] Call Trace: [ 23.419864] dump_stack+0xef/0x16e [ 23.419927] __kasan_report.cold+0x60/0x90 [ 23.420157] ? intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420397] intel_plane_calc_min_cdclk+0x82/0x440 [i915] [ 23.420630] intel_atomic_check+0x455f/0x65a0 [i915] [ 23.420708] ? mark_held_locks+0x90/0x90 [ 23.420929] ? intel_crtc_duplicate_state+0x2e/0x1b0 [i915] [ 23.421172] ? intel_plane_duplicate_state+0x2d/0xc0 [i915] [ 23.421239] ? __drm_dbg+0xa4/0x120 [ 23.421303] ? __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 23.421355] ? __kmalloc_track_caller+0x23a/0x320 [ 23.421602] ? intel_calc_active_pipes+0x1c0/0x1c0 [i915] [ 23.421852] sanitize_watermarks+0x220/0x510 [i915] [ 23.422092] ? intel_atomic_check+0x65a0/0x65a0 [i915] [ 23.422164] ? drm_modeset_unlock_all+0x88/0x130 [ 23.422402] intel_modeset_init+0x1b76/0x3c90 [i915] [ 23.422647] ? intel_finish_reset+0x2d0/0x2d0 [i915] [ 23.422851] ? intel_irq_install+0x12c/0x210 [i915] [ 23.423076] i915_driver_probe+0x13e7/0x2930 [i915] v2: No crtc is implied by an invisible plane, so the extra !crtc check is redundant. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203133824.198872-1-chris@chris-wilson.co.uk

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#12: FILE: ./hal/HalHWImg8723B_MAC.c:12: + struct DM_ODM_T * pDM_Odm, const u32 Condition1, const u32 Condition2 ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#114: FILE: ./hal/HalHWImg8723B_MAC.c:114: + struct DM_ODM_T * pDM_Odm, const u32 Condition1, const u32 Condition2 ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#231: FILE: ./hal/HalHWImg8723B_MAC.c:231: +void ODM_ReadAndConfig_MP_8723B_MAC_REG(struct DM_ODM_T * pDM_Odm) Signed-off-by: Marco Cesati <marcocesati@gmail.com>

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#12: FILE: ./hal/HalHWImg8723B_MAC.c:12: + struct DM_ODM_T * pDM_Odm, const u32 Condition1, const u32 Condition2 ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#114: FILE: ./hal/HalHWImg8723B_MAC.c:114: + struct DM_ODM_T * pDM_Odm, const u32 Condition1, const u32 Condition2 ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#231: FILE: ./hal/HalHWImg8723B_MAC.c:231: +void ODM_ReadAndConfig_MP_8723B_MAC_REG(struct DM_ODM_T * pDM_Odm) Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marco Cesati <marcocesati@gmail.com> Link: https://lore.kernel.org/r/20210315170618.2566-10-marcocesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Simplify how clients define file operations.

kvm->arch.arm_pmu is set when userspace attempts to set the first PMU attribute. As certain attributes are mandatory, arm_pmu ends up always being set to a valid arm_pmu, otherwise KVM will refuse to run the VCPU. However, this only happens if the VCPU has the PMU feature. If the VCPU doesn't have the feature bit set, kvm->arch.arm_pmu will be left uninitialized and equal to NULL. KVM doesn't do ID register emulation for 32-bit guests and accesses to the PMU registers aren't gated by the pmu_visibility() function. This is done to prevent injecting unexpected undefined exceptions in guests which have detected the presence of a hardware PMU. But even though the VCPU feature is missing, KVM still attempts to emulate certain aspects of the PMU when PMU registers are accessed. This leads to a NULL pointer dereference like this one, which happens on an odroid-c4 board when running the kvm-unit-tests pmu-cycle-counter test with kvmtool and without the PMU feature being set: [ 454.402699] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000150 [ 454.405865] Mem abort info: [ 454.408596] ESR = 0x96000004 [ 454.411638] EC = 0x25: DABT (current EL), IL = 32 bits [ 454.416901] SET = 0, FnV = 0 [ 454.419909] EA = 0, S1PTW = 0 [ 454.423010] FSC = 0x04: level 0 translation fault [ 454.427841] Data abort info: [ 454.430687] ISV = 0, ISS = 0x00000004 [ 454.434484] CM = 0, WnR = 0 [ 454.437404] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000c924000 [ 454.443800] [0000000000000150] pgd=0000000000000000, p4d=0000000000000000 [ 454.450528] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 454.456036] Modules linked in: [ 454.459053] CPU: 1 PID: 267 Comm: kvm-vcpu-0 Not tainted 5.18.0-rc4 torvalds#113 [ 454.465697] Hardware name: Hardkernel ODROID-C4 (DT) [ 454.470612] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 454.477512] pc : kvm_pmu_event_mask.isra.0+0x14/0x74 [ 454.482427] lr : kvm_pmu_set_counter_event_type+0x2c/0x80 [ 454.487775] sp : ffff80000a9839c0 [ 454.491050] x29: ffff80000a9839c0 x28: ffff000000a83a00 x27: 0000000000000000 [ 454.498127] x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000a510000 [ 454.505198] x23: ffff000000a83a00 x22: ffff000003b01000 x21: 0000000000000000 [ 454.512271] x20: 000000000000001f x19: 00000000000003ff x18: 0000000000000000 [ 454.519343] x17: 000000008003fe98 x16: 0000000000000000 x15: 0000000000000000 [ 454.526416] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 454.533489] x11: 000000008003fdbc x10: 0000000000009d20 x9 : 000000000000001b [ 454.540561] x8 : 0000000000000000 x7 : 0000000000000d00 x6 : 0000000000009d00 [ 454.547633] x5 : 0000000000000037 x4 : 0000000000009d00 x3 : 0d09000000000000 [ 454.554705] x2 : 000000000000001f x1 : 0000000000000000 x0 : 0000000000000000 [ 454.561779] Call trace: [ 454.564191] kvm_pmu_event_mask.isra.0+0x14/0x74 [ 454.568764] kvm_pmu_set_counter_event_type+0x2c/0x80 [ 454.573766] access_pmu_evtyper+0x128/0x170 [ 454.577905] perform_access+0x34/0x80 [ 454.581527] kvm_handle_cp_32+0x13c/0x160 [ 454.585495] kvm_handle_cp15_32+0x1c/0x30 [ 454.589462] handle_exit+0x70/0x180 [ 454.592912] kvm_arch_vcpu_ioctl_run+0x1c4/0x5e0 [ 454.597485] kvm_vcpu_ioctl+0x23c/0x940 [ 454.601280] __arm64_sys_ioctl+0xa8/0xf0 [ 454.605160] invoke_syscall+0x48/0x114 [ 454.608869] el0_svc_common.constprop.0+0xd4/0xfc [ 454.613527] do_el0_svc+0x28/0x90 [ 454.616803] el0_svc+0x34/0xb0 [ 454.619822] el0t_64_sync_handler+0xa4/0x130 [ 454.624049] el0t_64_sync+0x18c/0x190 [ 454.627675] Code: a9be7bfd 910003fd f9000bf3 52807ff3 (b9415001) [ 454.633714] ---[ end trace 0000000000000000 ]--- In this particular case, Linux hasn't detected the presence of a hardware PMU because the PMU node is missing from the DTB, so userspace would have been unable to set the VCPU PMU feature even if it attempted it. What happens is that the 32-bit guest reads ID_DFR0, which advertises the presence of the PMU, and when it tries to program a counter, it triggers the NULL pointer dereference because kvm->arch.arm_pmu is NULL. kvm-arch.arm_pmu was introduced by commit 46b1878 ("KVM: arm64: Keep a per-VM pointer to the default PMU"). Until that commit, this error would be triggered instead: [ 73.388140] ------------[ cut here ]------------ [ 73.388189] Unknown PMU version 0 [ 73.390420] WARNING: CPU: 1 PID: 264 at arch/arm64/kvm/pmu-emul.c:36 kvm_pmu_event_mask.isra.0+0x6c/0x74 [ 73.399821] Modules linked in: [ 73.402835] CPU: 1 PID: 264 Comm: kvm-vcpu-0 Not tainted 5.17.0 torvalds#114 [ 73.409132] Hardware name: Hardkernel ODROID-C4 (DT) [ 73.414048] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 73.420948] pc : kvm_pmu_event_mask.isra.0+0x6c/0x74 [ 73.425863] lr : kvm_pmu_event_mask.isra.0+0x6c/0x74 [ 73.430779] sp : ffff80000a8db9b0 [ 73.434055] x29: ffff80000a8db9b0 x28: ffff000000dbaac0 x27: 0000000000000000 [ 73.441131] x26: ffff000000dbaac0 x25: 00000000c600000d x24: 0000000000180720 [ 73.448203] x23: ffff800009ffbe10 x22: ffff00000b612000 x21: 0000000000000000 [ 73.455276] x20: 000000000000001f x19: 0000000000000000 x18: ffffffffffffffff [ 73.462348] x17: 000000008003fe98 x16: 0000000000000000 x15: 0720072007200720 [ 73.469420] x14: 0720072007200720 x13: ffff800009d32488 x12: 00000000000004e6 [ 73.476493] x11: 00000000000001a2 x10: ffff800009d32488 x9 : ffff800009d32488 [ 73.483565] x8 : 00000000ffffefff x7 : ffff800009d8a488 x6 : ffff800009d8a488 [ 73.490638] x5 : ffff0000f461a9d8 x4 : 0000000000000000 x3 : 0000000000000001 [ 73.497710] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000000dbaac0 [ 73.504784] Call trace: [ 73.507195] kvm_pmu_event_mask.isra.0+0x6c/0x74 [ 73.511768] kvm_pmu_set_counter_event_type+0x2c/0x80 [ 73.516770] access_pmu_evtyper+0x128/0x16c [ 73.520910] perform_access+0x34/0x80 [ 73.524532] kvm_handle_cp_32+0x13c/0x160 [ 73.528500] kvm_handle_cp15_32+0x1c/0x30 [ 73.532467] handle_exit+0x70/0x180 [ 73.535917] kvm_arch_vcpu_ioctl_run+0x20c/0x6e0 [ 73.540489] kvm_vcpu_ioctl+0x2b8/0x9e0 [ 73.544283] __arm64_sys_ioctl+0xa8/0xf0 [ 73.548165] invoke_syscall+0x48/0x114 [ 73.551874] el0_svc_common.constprop.0+0xd4/0xfc [ 73.556531] do_el0_svc+0x28/0x90 [ 73.559808] el0_svc+0x28/0x80 [ 73.562826] el0t_64_sync_handler+0xa4/0x130 [ 73.567054] el0t_64_sync+0x1a0/0x1a4 [ 73.570676] ---[ end trace 0000000000000000 ]--- [ 73.575382] kvm: pmu event creation failed -2 The root cause remains the same: kvm->arch.pmuver was never set to something sensible because the VCPU feature itself was never set. The odroid-c4 is somewhat of a special case, because Linux doesn't probe the PMU. But the above errors can easily be reproduced on any hardware, with or without a PMU driver, as long as userspace doesn't set the PMU feature. Work around the fact that KVM advertises a PMU even when the VCPU feature is not set by gating all PMU emulation on the feature. The guest can still access the registers without KVM injecting an undefined exception. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220425145530.723858-1-alexandru.elisei@arm.com

There are two issues in rockchip_usb2phy_otg_port_init(): (1) even if devm_extcon_register_notifier() returns error, the code proceeds to the next if statement and (2) if no extcon is defined in of_node, the return value of property_enabled() is reused as the return value of the whole function. If the return value of property_enable() is nonzero, (2) results in an unexpected probe failure and kernel panic in delayed work: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000019dc000 [0000000000000000] pgd=080000000131a003, p4d=080000000131a003, pud=080000000 Internal error: Oops: 86000006 [#1] PREEMPT SMP Modules linked in: ipv6 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc5 torvalds#114 Hardware name: FriendlyElec NanoPi M4 (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : call_timer_fn.constprop.0+0x24/0x80 sp : ffff80000a40ba40 x29: ffff80000a40ba40 x28: 0000000000000000 x27: ffff80000a40baf0 x26: ffff800009e779c0 x25: ffff00007fb28070 x24: ffff00007fb28028 x23: ffff80000a40baf0 x22: 0000000000000000 x21: 0000000000000101 x20: ffff0000006ad880 x19: 0000000000000000 x18: 0000000000000006 x17: ffff8000761af000 x16: ffff80000800c000 x15: 0000000000004000 x14: ffff0000006ad880 x13: 000000000000030a x12: 0000000000000000 x11: ffff8000761af000 x10: ffff80000800bf40 x9 : ffff00007fb2d038 x8 : 0000000000000001 x7 : 0000000000000009 x6 : 0000000000000240 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000200 x2 : 000000003fffffff x1 : 0000000000000000 x0 : ffff0000016c9710 Call trace: 0x0 __run_timers+0x220/0x264 run_timer_softirq+0x20/0x40 __do_softirq+0x10c/0x298 __irq_exit_rcu+0xec/0xf4 irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x70 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 cpuidle_enter_state+0x130/0x2fc cpuidle_enter+0x38/0x50 do_idle+0x22c/0x2c0 cpu_startup_entry+0x24/0x30 secondary_start_kernel+0x130/0x14c __secondary_switched+0xb0/0xb4 Code: bad PC value ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x4000,0820b021,00001086 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Refactor the control flow to avoid both issues. Since the code below out: label does no cleanup, return error codes immediately instead of using gotos and return success at the end of the function. Cc: stable@vger.kernel.org Fixes: 8dc60f8 ("phy: rockchip-inno-usb2: Sync initial otg state") Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com>

After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e torvalds#114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point). Signed-off-by: Remi Pommarel <repk@triplefau.lt>

Not-signed-off-by: "Jens Glathe <jens.glathe@oldschoolsolutions.biz>" wifi: mac80211: Update skb's NULL key in ieee80211_tx_h_select_key() The ieee80211 skb control block key (set when skb was queued) could have been removed before ieee80211_tx_dequeue() call. ieee80211_tx_dequeue() already called ieee80211_tx_h_select_key() to get the current key, but the latter do not update the key in skb control block in case it is NULL. Because some drivers actually use this key in their TX callbacks (e.g. ath1{1,2}k_mac_op_tx()) this could lead to the use after free below: BUG: KASAN: slab-use-after-free in ath11k_mac_op_tx+0x590/0x61c Read of size 4 at addr ffffff803083c248 by task kworker/u16:4/1440 CPU: 3 UID: 0 PID: 1440 Comm: kworker/u16:4 Not tainted 6.13.0-ge128f627f404 #2 Hardware name: HW (DT) Workqueue: bat_events batadv_send_outstanding_bcast_packet Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x58/0x74 print_report+0x164/0x4c0 kasan_report+0xac/0xe8 __asan_report_load4_noabort+0x1c/0x24 ath11k_mac_op_tx+0x590/0x61c ieee80211_handle_wake_tx_queue+0x12c/0x1c8 ieee80211_queue_skb+0xdcc/0x1b4c ieee80211_tx+0x1ec/0x2bc ieee80211_xmit+0x224/0x324 __ieee80211_subif_start_xmit+0x85c/0xcf8 ieee80211_subif_start_xmit+0xc0/0xec4 dev_hard_start_xmit+0xf4/0x28c __dev_queue_xmit+0x6ac/0x318c batadv_send_skb_packet+0x38c/0x4b0 batadv_send_outstanding_bcast_packet+0x110/0x328 process_one_work+0x578/0xc10 worker_thread+0x4bc/0xc7c kthread+0x2f8/0x380 ret_from_fork+0x10/0x20 Allocated by task 1906: kasan_save_stack+0x28/0x4c kasan_save_track+0x1c/0x40 kasan_save_alloc_info+0x3c/0x4c __kasan_kmalloc+0xac/0xb0 __kmalloc_noprof+0x1b4/0x380 ieee80211_key_alloc+0x3c/0xb64 ieee80211_add_key+0x1b4/0x71c nl80211_new_key+0x2b4/0x5d8 genl_family_rcv_msg_doit+0x198/0x240 <...> Freed by task 1494: kasan_save_stack+0x28/0x4c kasan_save_track+0x1c/0x40 kasan_save_free_info+0x48/0x94 __kasan_slab_free+0x48/0x60 kfree+0xc8/0x31c kfree_sensitive+0x70/0x80 ieee80211_key_free_common+0x10c/0x174 ieee80211_free_keys+0x188/0x46c ieee80211_stop_mesh+0x70/0x2cc ieee80211_leave_mesh+0x1c/0x60 cfg80211_leave_mesh+0xe0/0x280 cfg80211_leave+0x1e0/0x244 <...> Update SKB control block key even when key is NULL to avoid that. Signed-off-by: Remi Pommarel <repk@triplefau.lt> wifi: mac80211: Purge vif txq in ieee80211_do_stop() After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state. Because vif.drv_priv is now cleared in this function, this could lead to driver crash. For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158 To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point). Signed-off-by: Remi Pommarel <repk@triplefau.lt> wifi: ath9k: cleanup struct ath_tx_control and ath_tx_prepare() After switching to mac80211 software queues, pointer to 'struct ath_node' in 'struct ath_tx_control' is still assigned but not actually used. So drop it and cleanup related things in 'ath_tx_prepare()'. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250115171750.259917-1-dmantipov@yandex.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath9k: use unsigned long for activity check timestamp Since 'rx_active_check_time' of 'struct ath_softc' is in jiffies, prefer 'unsigned long' over 'u32' to avoid possible truncation in 'ath_hw_rx_inactive_check()'. Found with clang's -Wshorten-64-to-32, compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250115171750.259917-2-dmantipov@yandex.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Refactor the monitor Rx parser handler argument Currently, the monitor Rx parser handlers ath12k_dp_mon_rx_parse_status_tlv() and ath12k_dp_mon_parse_rx_dest() take the device handle from the caller. However, these handlers functionality is technically pdev specific. Additionally, the device handle can be retrieved from the pdev handle. Therefore, for better code understanding, change the monitor Rx parser handlers argument from the device handle to the pdev handle. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241224143613.164921-2-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Refactor the monitor Tx/RX handler procedure arguments Currently, the pdev handle is given along with the mac id to all the monitor Tx/Rx handler procedure arguments. The mac id information is derived from the pdev handle itself. Therefore, remove the unnecessary mac id argument from the handler. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241224143613.164921-3-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Refactor Rx status TLV parsing procedure argument Currently, ath12k_dp_mon_rx_parse_status_tlv() takes the TLV tag, TLV data and TLV userid as separate arguments from the caller. In the future, the TLV length will be needed for parsing the EHT TLV tag. Therefore, instead of increasing the number of arguments, pass the TLV header and retrieve the necessary fields from the TLV header itself. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241224143613.164921-4-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath11k: Fix DMA buffer allocation to resolve SWIOTLB issues Currently, the driver allocates cacheable DMA buffers for rings like HAL_REO_DST and HAL_WBM2SW_RELEASE. The buffers for HAL_WBM2SW_RELEASE are large (1024 KiB), exceeding the SWIOTLB slot size of 256 KiB. This leads to "swiotlb buffer is full" error messages on systems without an IOMMU that use SWIOTLB, causing driver initialization failures. The driver calls dma_map_single() with these large buffers obtained from kzalloc(), resulting in ring initialization errors on systems without an IOMMU that use SWIOTLB. To address these issues, replace the flawed buffer allocation mechanism with the appropriate DMA API. Specifically, use dma_alloc_noncoherent() for cacheable DMA buffers, ensuring proper freeing of buffers with dma_free_noncoherent(). Error log: [ 10.194343] ath11k_pci 0000:04:00.0: swiotlb buffer is full (sz:1048583 bytes), total 32768 (slots), used 2529 (slots) [ 10.194406] ath11k_pci 0000:04:00.0: failed to set up tcl_comp ring (0) :-12 [ 10.194781] ath11k_pci 0000:04:00.0: failed to init DP: -12 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Reported-by: Tim Harvey <tharvey@gateworks.com> Closes: https://lore.kernel.org/all/20241210041133.GA17116@lst.de/ Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Tested-by: Tim Harvey <tharvey@gateworks.com> Link: https://patch.msgid.link/20250119164219.647059-2-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath11k: Use dma_alloc_noncoherent for rx_tid buffer allocation Currently, the driver allocates cacheable DMA buffers for the rx_tid structure using kzalloc() and dma_map_single(). These buffers are long-lived and can persist for the lifetime of the peer, which is not advisable. Instead of using kzalloc() and dma_map_single() for allocating cacheable DMA buffers, utilize the dma_alloc_noncoherent() helper for the allocation of long-lived cacheable DMA buffers, such as the peer's rx_tid. Since dma_alloc_noncoherent() returns unaligned physical and virtual addresses, align them internally before use within the driver. This ensures proper allocation of non-coherent memory through the kernel helper. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Tested-by: Tim Harvey <tharvey@gateworks.com> Link: https://patch.msgid.link/20250119164219.647059-3-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath: create common testmode_i.h file for ath drivers User space application requires that the testmode interface is exactly same between ath drivers. Move testmode_i.h file in ath directory to ensure that all ath driver uses same testmode interface instead of duplicating testmode_i.h for each ath drivers. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Reviewed-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250119083657.1937557-2-quic_aarasahu@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: export ath12k_wmi_tlv_hdr for testmode Export ath12k_wmi_tlv_hdr() to further use in the testmode command processing. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Reviewed-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250119083657.1937557-3-quic_aarasahu@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: add factory test mode support Add support to process factory test mode commands(FTM) for calibration. By default firmware start with MISSION mode and to process the FTM commands firmware needs to be restarted in FTM mode using module parameter ftm_mode. The pre-request is all the radios should be down before starting the test. All ath12k test mode interface related commands specified in enum ath_tm_cmd. When start command ATH_TM_CMD_TESTMODE_START is received, ar state is set to test Mode and FTM daemon sends test mode command to wifi driver via cfg80211. Wifi driver sends these command to firmware as wmi events. If it is segmented commands it will be broken down into multiple segments and encoded with TLV header else it is sent to firmware as it is. Firmware response via UTF events, wifi driver creates skb and send to cfg80211, cfg80211 sends firmware response to FTM daemon via netlink message. Command to boot in ftm mode insmod ath12k ftm_mode=1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Reviewed-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250119083657.1937557-4-quic_aarasahu@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Disable MLO in Factory Test Mode Factory test mode(FTM) is supported only in non-MLO(multi-link operation) mode. Therefore, disable MLO when driver boots in FTM mode. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Reviewed-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250119083657.1937557-5-quic_aarasahu@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: fix skb_ext_desc leak in ath12k_dp_tx() error path When vlan support was added, we missed that when ath12k_dp_prepare_htt_metadata() returns an error we also need to free the skb holding the metadata before going on with the cleanup process. Compile tested only. Fixes: 26dd8ccdba4d ("wifi: ath12k: dynamic VLAN support") Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250122160112.3234558-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: report station mode transmit rate Currently, the transmit rate of "iw dev xxx station dump" command always show an invalid value. To address this issue, ath12k parse the info of transmit complete report from firmware and indicate the transmit rate to mac80211. This patch affects the station mode of WCN7850 and QCN9274. After that, "iw dev xxx station dump" show the correct transmit rate. Such as: Station 00:03:7f:12:03:03 (on wlo1) inactive time: 872 ms rx bytes: 219111 rx packets: 1133 tx bytes: 53767 tx packets: 462 tx retries: 51 tx failed: 0 beacon loss: 0 beacon rx: 403 rx drop misc: 74 signal: -95 dBm beacon signal avg: -18 dBm tx bitrate: 1441.1 MBit/s 80MHz EHT-MCS 13 EHT-NSS 2 EHT-GI 0 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219715 Link: https://patch.msgid.link/20250115063537.35797-2-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: report station mode receive rate for IEEE 802.11be Currently, the receive rate of EHT of "iw dev xxx station dump" command always show an invalid value. This is because ath12k does not pass information about the rx_status of EHT to mac80211. So, mac80211 not calculate the receive rate. To address this issue, add logic for handling rx_status of EHT to the ath12k_dp_rx_h_rate() function. After that, "iw dev xxx station dump" show the correct receive rate. Such as: Station 00:03:7f:12:03:03 (on wlo1) inactive time: 48 ms rx bytes: 59226 rx packets: 320 tx bytes: 26556 tx packets: 191 tx retries: 99 tx failed: 0 beacon loss: 0 beacon rx: 79 rx drop misc: 68 signal: -95 dBm beacon signal avg: -20 dBm tx bitrate: 688.2 MBit/s 40MHz EHT-MCS 13 EHT-NSS 2 EHT-GI 0 tx duration: 0 us rx bitrate: 619.5 MBit/s 40MHz EHT-MCS 8 EHT-NSS 3 EHT-GI 0 This patch affects the station mode of WCN7850 and QCN9274. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219715 Link: https://patch.msgid.link/20250115063537.35797-3-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: report station mode signal strength Currently, the signal strength of "iw dev xxx station dump" always show an invalid value. This is because signal strength is only set in ath12k_mgmt_rx_event() function, and not set for received data packet. So, change to get signal from firmware and report to mac80211. After that, "iw dev xxx station dump" show the correct signal strength. Such as: Station 00:03:7f:12:03:03 (on wlo1) inactive time: 36 ms rx bytes: 61571 rx packets: 336 tx bytes: 28204 tx packets: 205 tx retries: 49 tx failed: 0 beacon loss: 0 beacon rx: 83 rx drop misc: 66 signal: -24 dBm beacon signal avg: -22 dBm For WCN7850, the firmware supports db2dbm, so not need to add noise floor. For QCN9274, the firmware not support db2dbm, so need to add noise floor. This patch affects the station mode of WCN7850 and QCN9274. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Link: https://patch.msgid.link/20250115063537.35797-4-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath11k: fix memory leak in ath11k_xxx_remove() The firmware memory was allocated in ath11k_pci_probe() or ath11k_ahb_probe(), but not freed in ath11k_xxx_remove() in case ATH11K_FLAG_QMI_FAIL bit is set. So call ath11k_fw_destroy() to free the memory. Found while fixing the same problem in ath12k: https://lore.kernel.org/linux-wireless/20240314012746.2729101-1-quic_miaoqing@quicinc.com Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04546-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250123084948.1124357-1-quic_miaoqing@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: encode max Tx power in scan channel list command Currently, when sending the scan channel list command to the firmware, the maximum Tx power is not encoded in the reg2 member. This omission causes the firmware to be unaware of the host's maximum Tx power, leading to incorrect Tx power derivation at firmware level. To resolve this issue, encode the maximum Tx power in the scan channel list command before sending it to firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sathishkumar Muruganandam <quic_murugana@quicinc.com> Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Tested-by: Nicolas Escande <nico.escande@gmail.com> Link: https://patch.msgid.link/20250107-add_max_reg_pwr_in_scan_ch_list_cmd-v1-1-70d9963a21e4@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: fix memory leak in ath12k_pci_remove() Kmemleak reported this error: unreferenced object 0xffff1c165cec3060 (size 32): comm "insmod", pid 560, jiffies 4296964570 (age 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 The firmware memory was allocated in ath12k_pci_probe(), but not freed in ath12k_pci_remove() in case ATH12K_FLAG_QMI_FAIL bit is set. So call ath12k_fw_unmap() to free the memory. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Signed-off-by: Miaoqing Pan <quic_miaoqing@quicinc.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250123080226.1116479-1-quic_miaoqing@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Request vdev stats from firmware Add support to request and print vdev stats from firmware through WMI. Sample output: ------------- cat /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/fw_stats/vdev_stats ath12k VDEV stats ================= VDEV ID 0 VDEV MAC address 00:03:7f:6c:9c:1a beacon snr 96 data snr 255 num rx frames 0 num rts fail 0 num rts success 0 num rx err 0 num rx discard 0 num tx not acked 0 num tx frames [00] 0 num tx frames [01] 0 num tx frames [02] 0 num tx frames [03] 2 num tx frames retries [00] 0 num tx frames retries [01] 0 num tx frames retries [02] 0 num tx frames retries [03] 0 num tx frames failures [00] 0 num tx frames failures [01] 0 num tx frames failures [02] 0 num tx frames failures [03] 0 tx rate history [00] 0x00000000 tx rate history [01] 0x00000000 tx rate history [02] 0x00000000 tx rate history [03] 0x00000000 tx rate history [04] 0x00000000 tx rate history [05] 0x00000000 tx rate history [06] 0x00000000 tx rate history [07] 0x00000000 tx rate history [08] 0x00000000 tx rate history [09] 0x00000000 beacon rssi history [00] 0 beacon rssi history [01] 0 beacon rssi history [02] 0 beacon rssi history [03] 0 beacon rssi history [04] 0 beacon rssi history [05] 0 beacon rssi history [06] 0 beacon rssi history [07] 0 beacon rssi history [08] 0 beacon rssi history [09] 0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250124185330.1244585-2-ramya.gnanasekar@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Request beacon stats from firmware Add support to request and dump beacon statistics from firmware Sample output: ------------- cat /sys/kernel/debug/ath12k/pci-0000:06:00.0/mac0/fw_stats/beacon_stats ath12k Beacon stats (1) =================== VDEV ID 0 VDEV MAC address 00:03:7f:04:37:58 ================ Num of beacon tx success 20 Num of beacon tx failures 0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250124185330.1244585-3-ramya.gnanasekar@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Request pdev stats from firmware Add support to request pdev stats from firmware through WMI and print the information Sample Output: ------------- cat /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/fw_stats/pdev_stats ath12k PDEV stats ================= Channel noise floor -85 Channel TX power 126 TX frame count 0 RX frame count 8637 RX clear count 37424 Cycle count 4372024 PHY error count 0 soc drop count 0 ath12k PDEV TX stats ==================== HTT cookies queued 0 HTT cookies disp. 0 MSDU queued 0 MPDU queued 0 MSDUs dropped 0 Local enqued 0 Local freed 0 HW queued 0 PPDUs reaped 0 Num underruns 0 PPDUs cleaned 0 MPDUs requeued 0 Excessive retries 0 HW rate 0 Sched self triggers 0 Dropped due to SW retries 0 Illegal rate phy errors 0 PDEV continuous xretry 0 TX timeout 9 PDEV resets 0 Stateless TIDs alloc failures 0 PHY underrun 0 MPDU is more than txop limit 0 ath12k PDEV RX stats ==================== Mid PPDU route change 0 Tot. number of statuses 0 Extra frags on rings 0 0 Extra frags on rings 1 0 Extra frags on rings 2 0 Extra frags on rings 3 0 MSDUs delivered to HTT 0 MPDUs delivered to HTT 0 MSDUs delivered to stack 0 MPDUs delivered to stack 0 Oversized AMSUs 0 PHY errors 0 PHY errors drops 0 MPDU errors (FCS, MIC, ENC) 0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250124185330.1244585-4-ramya.gnanasekar@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Fix pdev lookup in WBM error processing Currently in ath12k_dp_rx_process_wbm_err(), when processing packets received on the WBM error ring, pdev validation is done based upon the hw_link_id. But hw_link_id corresponds to link id of a given partner pdev in a MLO hardware group, and is not the correct index to use to lookup a pdev in an SoC(ab). As a result, pdev validation fails, and the reaped packets are dropped instead of being processed. The correct index to use is the pdev_id, which is already derived in the function. So update the logic to validate the pdev based upon the pdev_id instead of the hw_link_id. This matches the logic used in other Rx ring processing functions. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 1a73acb5fba4 ("wifi: ath12k: move to HW link id based receive handling") Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Link: https://patch.msgid.link/20250102043048.2596791-1-quic_ramess@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Add HTT source ring ID for monitor rings Add source buffer ring and destination buffer ring ID for monitor rings. These IDs are used for ring configuration during initial ring setup. Since monitor rings are enabled based on the rxdma1_enable flag, enable it in the hardware param for the QCN9274 version 2 hardware and increase the destination ring size to handle MSDU data buffers. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-2-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Enable filter config for monitor destination ring Add provision to configure monitor filter for the destination ring. These filters are used for requesting statistics or monitor mode through the monitor destination ring. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-3-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Avoid multiple times configuring monitor filter ath12k_mac_op_configure_filter() gets called multiple times during interface bringup. Applying filter configuration from this function leads to writing same filter configurations multiple times. Resolve this issue by relocating the filter configuration to ath12k_mac_config_mon_status_default(), which is invoked by both ath12k_mac_op_start() and ath12k_mac_op_stop(). Additionally, set the rxmon_disable flag to true when called from ath12k_mac_op_stop() to disable the monitor destination ring. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-4-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Avoid code duplication in monitor ring processing The current implementation processes the monitor destination ring using two separate functions, ath12k_dp_mon_srng_process() for standalone monitor mode and ath12k_dp_mon_rx_process_stats() for statistics. However, both functions contain same code which performs monitor ring reaping and skb data processing. To eliminate redundancy, remove the duplicate code and use a single function to handle both the cases. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-5-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Restructure the code for monitor ring processing Currently, monitor ring reaping and processing occur in the same loop, which requires holding ring locks until skb processing is complete. However, only the ring reaping part requires the ring lock; the skb processing part does not need it. This approach is problematic because it unnecessarily extends the duration for which the ring locks are held, leading to increased contention and potential backpressure issues. Fix it by holding ring locks only during the reaping phase, as skb processing does not require them. First, reap the monitor destination ring with the ring lock and queue the skbs into an skb list. Then, process the skbs in this list in a separate loop without holding the ring lock. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-6-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry to fetch the next entry from the destination ring. This is incorrect because ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management. To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-7-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Fix end offset bit definition in monitor ring descriptor End offset for the monitor destination ring descriptor is defined as 16 bits, while the firmware definition specifies only 12 bits. The remaining bits (bit 12 to bit 15) are reserved and may contain junk values, leading to invalid information retrieval. Fix this issue by updating the correct genmask values. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-8-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Add drop descriptor handling for monitor ring When monitor block in Hardware experiences internal backpressure, a ring entry with the EMPTY_DESC reason is received in the monitor destination ring descriptor. The cookie field for this corresponding entry is invalid. Currently driver attempts to process this cookie resulting in invalid buf_id warning logs flooding the console. To fix this, skip processing the destination descriptor when the EMPTY_DESCRIPTOR bit is set to true in ring descriptor, thereby avoiding the processing of junk cookies. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-9-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Handle end reason for the monitor destination ring Currently, the monitor destination ring's descriptor includes a 2-bit field for the end reason. Out of all the end reason values, hardware uses HAL_MON_FLUSH_DETECTED and HAL_MON_PPDU_TRUNCATED to indicate buffers that should not be processed due to system level errors. Driver should not process entries with these end reasons, as they contain junk values. However, the current code lacks end reason-specific checks for the monitor destination ring, leading to the processing of invalid buffers. Fix this by adding checks for these two end reasons during the reaping phase. Free the skb if either HAL_MON_FLUSH_DETECTED or HAL_MON_PPDU_TRUNCATED is detected, preventing the driver from processing invalid entries. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-10-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Optimize NAPI budget by adjusting PPDU processing In the current implementation, when PPDU spans multiple ring descriptors, leading to inefficient use of the NAPI budget. The budget counter is decremented for each ring descriptor, causing rapid depletion of the budget even though the processing of a single PPDU might not be complete. To address this issue, modify the code to decrement the budget counter only when the driver receives HAL_MON_END_OF_PPDU as the end reason. This change ensures that the budget is decremented only once per PPDU, resulting in more efficient utilization of the NAPI budget and better handling of monitor destination ring. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-11-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Handle PPDU spread across multiple buffers Each PPDU contains numerous TLV tags. HAL_RX_PPDU_START marks the start of the PPDU, and HAL_RX_PPDU_END_STATUS_DONE marks the end. From the monitor destination rings, the driver retrieves skb containing these TLV tags and their corresponding data. Sometimes, one PPDU’s information spreads across multiple skbs. The current parsing logic uses memset on struct hal_rx_mon_ppdu_info after parsing each skb, leading to information loss if a PPDU spans multiple skbs. Fix this by setting the ppdu_continuation flag when the driver fails to get HAL_RX_PPDU_END_STATUS_DONE, and do memset on struct hal_rx_mon_ppdu_info only when the ppdu_continuation flag is not set. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-12-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Avoid memory leak while enabling statistics Driver uses monitor destination rings for extended statistics mode and standalone monitor mode. In extended statistics mode, TLVs are parsed from the buffer received from the monitor destination ring and assigned to the ppdu_info structure to update per-packet statistics. In standalone monitor mode, along with per-packet statistics, the packet data (payload) is captured, and the driver updates per MSDU to mac80211. When the AP interface is enabled, only extended statistics mode is activated. As part of enabling monitor rings for collecting statistics, the driver subscribes to HAL_RX_MPDU_START TLV in the filter configuration. This TLV is received from the monitor destination ring, and kzalloc for the mon_mpdu object occurs, which is not freed, leading to a memory leak. The kzalloc for the mon_mpdu object is only required while enabling the standalone monitor interface. This causes a memory leak while enabling extended statistics mode in the driver. Fix this memory leak by removing the kzalloc for the mon_mpdu object in the HAL_RX_MPDU_START TLV handling. Additionally, remove the standalone monitor mode handlings in the HAL_MON_BUF_ADDR and HAL_RX_MSDU_END TLVs. These TLV tags will be handled properly when enabling standalone monitor mode in the future. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-13-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Handle monitor drop TLVs scenario During monitor destination ring back-pressure, hardware failed to send HAL_RX_PPDU_END_STATUS_DONE TLV. But driver uses this TLV as a delimiter to complete one PPDU worth of data parsing. This causes driver to overwrite the existing PPDU information with the new PPDU information. Fix it by recording the end reason which is provided under each buffer's descriptor in skb->cb and uses it while parsing TLV tags to mark the PPDU end delimiter. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-14-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Enable monitor ring mask for QCN9274 QCN9274's monitor related rings are initialized properly. Hence enabling the corresponding ring mask in the hardware params. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Link: https://patch.msgid.link/20241223060132.3506372-15-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Fetch regdb.bin file from board-2.bin Currently, ath12k_core_fetch_regdb() finds regdb.bin file through board id's but in board-2.bin file regdb.bin file is present with default board id because of which regdb.bin is not fetched. Add support to fetch regdb.bin file from board-2.bin through default board id. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Reviewed-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250116032835.118397-1-quic_aarasahu@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath9k: return by of_get_mac_address When using nvmem, ath9k could potentially be loaded before nvmem, which loads after mtd. This is an issue if DT contains an nvmem mac address. If nvmem is not ready in time for ath9k, -EPROBE_DEFER is returned. Pass it to _probe so that ath9k can properly grab a potentially present MAC address. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20241105222326.194417-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath9k: do not submit zero bytes to the entropy pool In 'ath_cmn_process_fft()', it doesn't make too much sense to add zero bytes in attempt to improve randomness. So swap calls to 'memset()' and 'add_device_randomness()' to feed the pool with actual FFT results rather than zeroes. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Fixes: 2aa56cca3571 ("ath9k: Mix the received FFT bins to the random pool") Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250123141058.1696502-1-dmantipov@yandex.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath11k: remove peer extra rssi update Commit b205ce4c266c ("ath11k: support avg signal in station dump") added an extra assignment of arsta->rssi_comb in ath11k_dp_rx_update_peer_stats() when it added the average rssi support. So let's keep only one by removing the legacy assignment so the two statements about rssi stay next to each other. Compile tested only. Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com> Link: https://patch.msgid.link/20250117181953.3375273-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: fix ath12k_hal_tx_cmd_ext_desc_setup() info1 override Since inception there is an obvious typo laying around in ath12k_hal_tx_cmd_ext_desc_setup(). Instead of initializing + adding flags to tcl_ext_cmd->info1, we initialize + override. This will be needed in the future to make broadcast frames work with ethernet encapsulation. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250127071306.1454699-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: remove return for empty tx bitrate in mac_op_sta_statistics Currently in ath12k_mac_op_sta_statistics() there is the following logic: if (!arsta->txrate.legacy && !arsta->txrate.nss) return; Because ath12k_sta_statistics is used to report many info to iw wlan0 link, if it return for empty legacy and nss of arsta->txrate, then the other stats after it will not be set. To address this issue remove the return and instead invert the logic to set the txrate logic if (arsta->txrate.legacy || arsta->txrate.nss). The same was done also in both ath10k with commit 1cd6ba8ae33e ("ath10k: remove return for NL80211_STA_INFO_TX_BITRATE") and ath11k as well with commit 1d795645e1ee ("ath11k: remove return for empty tx bitrate in mac_op_sta_statistics"). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Remi Pommarel <repk@triplefau.lt> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/38c2a7c4f7eaf57b9306bb95a9e6c42b7d987e05.1738169458.git.repk@triplefau.lt Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: update beacon template function to use arvif structure The current code has ath12k_wmi_bcn_tmpl() accepting separate ar and vdev_id parameters. However, ath12k_link_vif structure can be used to derive both of these. Hence, simplify the function signature. Later change needs arvif pointer access within the function hence it is better if arvif is directly passed now. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250124-ath12k_mlo_csa-v2-1-420c42fcfecf@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: fix handling of CSA offsets in beacon template command The driver is informed of the counter offsets in the beacon during CSA through the ieee80211_mutable_offsets structure. According to the documentation for the cntdwn_counter_offs member, "This array can contain zero values which should be ignored." However, the current implementation uses these values unconditionally, without checking for zeros. Whenever CSA is active, these offsets are guaranteed to be set. Therefore, add a check for CSA active status before setting the CSA switch count offsets. This ensures that the offsets are only set when CSA is active, preventing incorrect configurations. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250124-ath12k_mlo_csa-v2-2-420c42fcfecf@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: update the latest CSA counter At present, the driver configures the firmware to send the Channel Switch (CS) count event only when the count reaches zero during a Channel Switch Announcement (CSA). For frames managed by the upper layer, where the driver does not update the counter, the CS count in these frames remains unchanged throughout the entire CSA period. This is because the upper layer is not aware of the latest ongoing count. Indicating same count value throughout the CSA time is wrong and could lead to connection instabilities. Fix this by configuring firmware to send CS count event for every count and then accordingly decrementing the count in mac80211. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250124-ath12k_mlo_csa-v2-3-420c42fcfecf@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: prevent CSA counter to reach 0 and hit WARN_ON_ONCE Currently, when the driver receives a channel switch count WMI event from the firmware with a count greater than 1, it calls ieee80211_beacon_update_cntdwn(). If the beacon transmission fails, the event will be received again with the previous count value. In this scenario, the host decrements the mac80211 counter again, causing it to move ahead of the firmware counter. Ultimately, when the firmware count reaches 1, the mac80211 counter will reach zero, triggering a WARN_ON_ONCE(). Therefore, there is a need to check the count value in the event. Hence to fix this, maintain the current ongoing counter in arvif. If the count in the event does not match the expected value, silently discard the event. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20250124-ath12k_mlo_csa-v2-4-420c42fcfecf@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Avoid napi_sync() before napi_enable() In case of MHI error a reset work will be queued which will try napi_disable() after napi_synchronize(). As the napi will be only enabled after qmi_firmware_ready event, trying napi_synchronize() before napi_enable() will result in indefinite sleep in case of a firmware crash in QMI init sequence. To avoid this, introduce napi_enabled flag to check if napi is enabled or not before calling napi_synchronize(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Avula Sri Charan <quic_asrichar@quicinc.com> Signed-off-by: Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250124090058.3194299-1-quic_tamizhr@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: relocate ath12k_mac_ieee80211_sta_bw_to_wmi() An upcoming change will invoke ath12k_mac_ieee80211_sta_bw_to_wmi() from a line located above its current definition. Hence, relocate it to above so that it can be invoked later on. No functionality changes. Compile tested only. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Link: https://patch.msgid.link/20250110-fix_link_sta_bandwidth_update-v1-1-61b6f3ef2ea3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: handle ath12k_mac_ieee80211_sta_bw_to_wmi() for link sta Currently ath12k_mac_ieee80211_sta_bw_to_wmi() handles the bandwidth from sta's deflink member. This works only for non-ML station. Now that MLO support is there, extend this function to use link sta instead of deflink. Additionally, in ath12k_mac_handle_link_sta_state(), the link sta structure is not accessible, making it difficult to fetch the bandwidth there. However, ath12k_mac_station_assoc() does reference the link sta structure. Therefore, move the initial assignment of the arsta bandwidth member to ath12k_mac_station_assoc(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Link: https://patch.msgid.link/20250110-fix_link_sta_bandwidth_update-v1-2-61b6f3ef2ea3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Add support for obtaining the buffer type ACPI function bitmap Currently, ath12k does not support obtaining the buffer type ACPI function bitmap. To solve this issue, change the code to support obtaining the buffer type ACPI function bitmap. This patch will not affect QCN9274, because only WCN7850 supports ACPI. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20250113074810.29729-2-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Add Support for enabling or disabling specific features based on ACPI bitflag Currently, ath12k does not support enable or disable specific features by ACPI bitflag. To address this issue, obtain the ACPI bitflag value and use it to selectively enable or disable specific features. This patch will not affect QCN9274, because only WCN7850 supports ACPI. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20250113074810.29729-3-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Adjust the timing to access ACPI table Currently, the timing for accessing the ACPI table is inappropriate. Due to special ACPI requirements, the ACPI table must be obtained before downloading the board data file. Therefore, adjust the timing for accessing the ACPI table accordingly. This patch will not affect QCN9274, because only WCN7850 supports ACPI. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20250113074810.29729-4-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Add support for reading variant from ACPI to download board data file Currently, ath12k does not support reading variant from ACPI board data filename extension for downloading board data file. To address this issue, obtain the string of the ACPI data filename extension and use it as part of the string to search for the board data file from board-2.bin. This patch will not affect QCN9274, because only WCN7850 supports ACPI. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20250113074810.29729-5-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath11k: add support for MU EDCA The current code does not have the MU EDCA feature, so it cannot support the use of EDCA by STA in specific UL MU HE TB PPDU transmissions. Refer to IEEE Std 802.11ax-2021 "9.4.2.251 MU EDCA Parameter Set element", "26.2.7 EDCA operation using MU EDCA parameters". Add ath11k_mac_op_conf_tx_mu_edca() to construct the MU EDCA parameters received from mac80211 into WMI WMM parameters，and send to the firmware according to the different WMM type flags. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04523-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Yu Zhang (Yuriy) <quic_yuzha@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250124061343.2263467-1-quic_yuzha@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath11k: fix wrong overriding for VHT Beamformee STS Capability Current code in ath11k_mac_set_txbf_conf overrides nsts, which is incorrect as it confuses nss and nsts. nss is Number of Spatial Streams，nsts is Number of Space-Time Streams. As mentioned in Fixes: 55b5ee3357d7, the nss used when acting as a beamformee in VHT mode should be reported by the firmware and should not be greater than the number of receiving antennas - 1. The num_rx_chains related nss rather than nsts. If STBC is enabled, nsts is greater than nss. About nss are mapped to nsts, refer to IEEE Std 802.11-2020: 19.3.11.9.2 Space-time block coding (STBC), Table 19-18—Constellation mapper output to spatial mapper input for STBC. Remove wrong overriding for nsts of VHT Beamformee STS Capability, acting DL MU-MIMO in VHT mode is working properly. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04479-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: 55b5ee3357d7 ("wifi: ath11k: fix number of VHT beamformee spatial streams") Signed-off-by: Yu Zhang (Yuriy) <quic_yuzha@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250124075953.2282354-1-quic_yuzha@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Dump PDEV transmit rate HTT stats Support to dump PDEV transmit rate stats through HTT debugfs stats type 9. Sample output: ------------------------- echo 9 > /sys/kernel/debug/ath12k/pci-0000\:03\:00.0/mac0/htt_stats_type cat /sys/kernel/debug/ath12k/pci-0000\:03\:00.0/mac0/htt_stats HTT_TX_PDEV_RATE_STATS_TLV: mac_id = 0 tx_ldpc = 1088 ac_mu_mimo_tx_ldpc = 0 ax_mu_mimo_tx_ldpc = 0 ofdma_tx_ldpc = 0 rts_cnt = 941 rts_success = 180 ack_rssi = 4294967168 Legacy CCK Rates: 1 Mbps: 830, 2 Mbps: 0, 5.5 Mbps: 0, 12 Mbps: 0 Legacy OFDM Rates: 6 Mbps: 942, 9 Mbps: 0, 12 Mbps: 0, 18 Mbps: 0 24 Mbps: 0, 36 Mbps: 0, 48 Mbps: 0, 54 Mbps: 0 HE LTF: 1x: 0, 2x: 957, 4x: 132 tx_mcs = 0:342, 1:260, 2:171, 3:148, 4:31, 5:34, 6:93, 7:10, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 ax_mu_mimo_tx_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ofdma_tx_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 tx_nss = 1:754, 2:335, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0 ac_mu_mimo_tx_nss = 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0 ax_mu_mimo_tx_nss = 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0 ofdma_tx_nss = 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0 tx_bw = 0:1089, 1:0, 2:0, 3:0, 4:0 tx_stbc = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 tx_gi[0] = 0:210, 1:260, 2:171, 3:148, 4:31, 5:34, 6:93, 7:10, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 tx_gi[1] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 tx_gi[2] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 tx_gi[3] = 0:132, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ac_mu_mimo_tx_gi[0] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 ac_mu_mimo_tx_gi[1] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 ac_mu_mimo_tx_gi[2] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 ac_mu_mimo_tx_gi[3] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 ax_mu_mimo_tx_gi[0] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ax_mu_mimo_tx_gi[1] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ax_mu_mimo_tx_gi[2] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ax_mu_mimo_tx_gi[3] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ofdma_tx_gi[0] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ofdma_tx_gi[1] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ofdma_tx_gi[2] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 ofdma_tx_gi[3] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0 tx_su_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 tx_mu_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 ac_mu_mimo_tx_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 ac_mu_mimo_tx_bw = 0:0, 1:0, 2:0, 3:0 ax_mu_mimo_tx_bw = 0:0, 1:0, 2:0, 3:0 ofdma_tx_bw = 0:0, 1:0, 2:0, 3:0 tx_pream = 0:942, 1:830, 2:0, 3:0, 4:1850, 5:0, 6:0 tx_dcm = 0:131, 1:0, 2:0, 3:0, 4:0 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250113071758.19589-2-quic_lingbok@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> wifi: ath12k: Dump PDEV receive rate HTT stats Support to dump PDEV receive rate stats through HTT debugfs stats type 10. Sample output: ----------------- echo 10 > /sys/kernel/debug/ath12k/pci-0000\:03\:00.0/mac0/htt_stats_type cat /sys/kernel/debug/ath12k/pci-0000\:03\:00.0/mac0/htt_stats HTT_RX_PDEV_RATE_STATS_TLV: mac_id = 0 nsts = 0 rx_ldpc = 96 rts_cnt = 0 rssi_mgmt = 4294967240 rssi_data = 4294967250 rssi_comb = 4294967239 rssi_in_dbm = -46 rx_evm_nss_count = 0 rx_evm_pilot_count = 0 rx_11ax_su_ext = 0 rx_11ac_mumimo = 0 rx_11ax_mumimo = 0 rx_11ax_ofdma = 0 txbf = 0 rx_su_ndpa = 0 rx_mu_ndpa = 0 rx_br_poll = 0 rx_active_dur_us_low = 1000106 rx_active_dur_us_high = 0 rx_11ax_ul_ofdma = 0 ul_ofdma_rx_stbc = 0 ul_ofdma_rx_ldpc = 0 per_chain_rssi_pkt_type = 0x88 rx_nss = 0:40, 1:56, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_dcm = 0:0, 1:0, 2:0, 3:0, 4:0 rx_stbc = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 rx_bw = 0:1175, 1:0, 2:0, 3:0 rx_pream = 0:435, 1:644, 2:0, 3:0, 4:96, 5:0, 6:0 rx_11ax_su_txbf_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 rx_11ax_mu_txbf_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 rx_legacy_cck_rate = 0:641, 1:0, 2:3, 3:0 rx_legacy_ofdm_rate = 0:267, 1:0, 2:72, 3:0, 4:96, 5:0, 6:0, 7:0 ul_ofdma_rx_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 ul_ofdma_rx_nss = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 ul_ofdma_rx_bw = 0:0, 1:0, 2:0, 3:0 rx_ulofdma_non_data_ppdu = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulofdma_data_ppdu = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulofdma_mpdu_ok = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulofdma_mpdu_fail = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulofdma_non_data_nusers = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulofdma_data_nusers = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_11ax_dl_ofdma_mcs = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0 rx_11ax_dl_ofdma_ru = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0 rx_ulmumimo_non_data_ppdu = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulmumimo_data_ppdu = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulmumimo_mpdu_ok = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_ulmumimo_mpdu_fail = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0 rx_mcs = 0:0, 1:0, 2:0, 3:0, 4:28, 5:8, 6:37, 7:21, 8:2, 9:0, 10:0, 11:0, 12:0, 13:0 pilot_evm_db[0] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db[1] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db[2] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db[3] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db[4] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db[5] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db[6] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db[7] = 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0, 7:0, 8:0, 9:0, 10:0, 11:0, 12:0, 13:0, 14:0, 15:0 pilot_evm_db_mean = …

e-mailky added 2 commits January 20, 2014 23:57

Merge pull request #1 from torvalds/master

e28d69f

pull from torvalds

Merge pull request #2 from torvalds/master

5eee762

pull from torvalds/linux

Merge pull request #3 from torvalds/master

bba6068

pull from torvalds

e-mailky closed this Aug 20, 2014

xin3liang pushed a commit to xin3liang/linux that referenced this pull request Oct 16, 2015

Merge pull request torvalds#114 from Leo-Yan/enable_suspend_0820

5f7b98b

arm64: add system suspend support

causten mentioned this pull request Dec 3, 2015

ftgmac crashing openbmc/linux#26

Closed

laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017

Merge pull request torvalds#114 from pscollins/atomic-thread-counter

b43930b

lkl: Replace threads_counter_lock with atomic ops

iaguis pushed a commit to kinvolk/linux that referenced this pull request Feb 6, 2018

Merge pull request torvalds#114 from bgilbert/v4.13.16-coreos

1327d7d

Fix CVE-2017-1000405 and mptsas hotplug in 4.13

ojeda added a commit to ojeda/linux that referenced this pull request Mar 18, 2021

Merge pull request torvalds#114 from Rust-for-Linux/file_operations

e134ae0

Simplify how clients define file operations.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge pull request #1 from torvalds/master #114

Merge pull request #1 from torvalds/master #114

e-mailky commented Aug 18, 2014

frankcash commented Aug 18, 2014

Patrick-Edouard commented Aug 18, 2014

Merge pull request #1 from torvalds/master #114

Merge pull request #1 from torvalds/master #114

Conversation

e-mailky commented Aug 18, 2014

frankcash commented Aug 18, 2014

Patrick-Edouard commented Aug 18, 2014