summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-10-17blkcg: Update MAINTAINERS entryTejun Heo
Josef wrote iolatency and iocost is missing from the files list. Let's add Josef as a maintainer and add blk-iocost.c to the files list. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Jens Axboe <axboe@kernel.dk>
2022-10-17x86/topology: Fix duplicated core ID within a packageZhang Rui
Today, core ID is assumed to be unique within each package. But an AlderLake-N platform adds a Module level between core and package, Linux excludes the unknown modules bits from the core ID, resulting in duplicate core ID's. To keep core ID unique within a package, Linux must include all APIC-ID bits for known or unknown levels above the core and below the package in the core ID. It is important to understand that core ID's have always come directly from the APIC-ID encoding, which comes from the BIOS. Thus there is no guarantee that they start at 0, or that they are contiguous. As such, naively using them for array indexes can be problematic. [ dhansen: un-known -> unknown ] Fixes: 7745f03eb395 ("x86/topology: Add CPUID.1F multi-die/package support") Suggested-by: Len Brown <len.brown@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Len Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221014090147.1836-5-rui.zhang@intel.com
2022-10-17x86/topology: Fix multiple packages shown on a single-package systemZhang Rui
CPUID.1F/B does not enumerate Package level explicitly, instead, all the APIC-ID bits above the enumerated levels are assumed to be package ID bits. Current code gets package ID by shifting out all the APIC-ID bits that Linux supports, rather than shifting out all the APIC-ID bits that CPUID.1F enumerates. This introduces problems when CPUID.1F enumerates a level that Linux does not support. For example, on a single package AlderLake-N, there are 2 Ecore Modules with 4 atom cores in each module. Linux does not support the Module level and interprets the Module ID bits as package ID and erroneously reports a multi module system as a multi-package system. Fix this by using APIC-ID bits above all the CPUID.1F enumerated levels as package ID. [ dhansen: spelling fix ] Fixes: 7745f03eb395 ("x86/topology: Add CPUID.1F multi-die/package support") Suggested-by: Len Brown <len.brown@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Len Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221014090147.1836-4-rui.zhang@intel.com
2022-10-17hwmon/coretemp: Handle large core ID valueZhang Rui
The coretemp driver supports up to a hard-coded limit of 128 cores. Today, the driver can not support a core with an ID above that limit. Yet, the encoding of core ID's is arbitrary (BIOS APIC-ID) and so they may be sparse and they may be large. Update the driver to map arbitrary core ID numbers into appropriate array indexes so that 128 cores can be supported, no matter the encoding of core ID's. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Len Brown <len.brown@intel.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221014090147.1836-3-rui.zhang@intel.com
2022-10-17bpf: prevent decl_tag from being referenced in func_protoStanislav Fomichev
Syzkaller was able to hit the following issue: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3609 at kernel/bpf/btf.c:1946 btf_type_id_size+0x2d5/0x9d0 kernel/bpf/btf.c:1946 Modules linked in: CPU: 0 PID: 3609 Comm: syz-executor361 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 RIP: 0010:btf_type_id_size+0x2d5/0x9d0 kernel/bpf/btf.c:1946 Code: ef e8 7f 8e e4 ff 41 83 ff 0b 77 28 f6 44 24 10 18 75 3f e8 6d 91 e4 ff 44 89 fe bf 0e 00 00 00 e8 20 8e e4 ff e8 5b 91 e4 ff <0f> 0b 45 31 f6 e9 98 02 00 00 41 83 ff 12 74 18 e8 46 91 e4 ff 44 RSP: 0018:ffffc90003cefb40 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: ffff8880259c0000 RSI: ffffffff81968415 RDI: 0000000000000005 RBP: ffff88801270ca00 R08: 0000000000000005 R09: 000000000000000e R10: 0000000000000011 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000011 R14: ffff888026ee6424 R15: 0000000000000011 FS: 000055555641b300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000f2e258 CR3: 000000007110e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> btf_func_proto_check kernel/bpf/btf.c:4447 [inline] btf_check_all_types kernel/bpf/btf.c:4723 [inline] btf_parse_type_sec kernel/bpf/btf.c:4752 [inline] btf_parse kernel/bpf/btf.c:5026 [inline] btf_new_fd+0x1926/0x1e70 kernel/bpf/btf.c:6892 bpf_btf_load kernel/bpf/syscall.c:4324 [inline] __sys_bpf+0xb7d/0x4cf0 kernel/bpf/syscall.c:5010 __do_sys_bpf kernel/bpf/syscall.c:5069 [inline] __se_sys_bpf kernel/bpf/syscall.c:5067 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:5067 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f0fbae41c69 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc8aeb6228 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0fbae41c69 RDX: 0000000000000020 RSI: 0000000020000140 RDI: 0000000000000012 RBP: 00007f0fbae05e10 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000ffffffff R11: 0000000000000246 R12: 00007f0fbae05ea0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Looks like it tries to create a func_proto which return type is decl_tag. For the details, see Martin's spot on analysis in [0]. 0: https://lore.kernel.org/bpf/CAKH8qBuQDLva_hHxxBuZzyAcYNO4ejhovz6TQeVSk8HY-2SO6g@mail.gmail.com/T/#mea6524b3fcd6298347432226e81b1e6155efc62c Cc: Yonghong Song <yhs@fb.com> Cc: Martin KaFai Lau <martin.lau@kernel.org> Fixes: bd16dee66ae4 ("bpf: Add BTF_KIND_DECL_TAG typedef support") Reported-by: syzbot+d8bd751aef7c6b39a344@syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev <sdf@google.com> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221015002444.2680969-2-sdf@google.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2022-10-17selftests/bpf: Add reproducer for decl_tag in func_proto return typeStanislav Fomichev
It should trigger a WARN_ON_ONCE in btf_type_id_size. btf_func_proto_check kernel/bpf/btf.c:4447 [inline] btf_check_all_types kernel/bpf/btf.c:4723 [inline] btf_parse_type_sec kernel/bpf/btf.c:4752 [inline] btf_parse kernel/bpf/btf.c:5026 [inline] btf_new_fd+0x1926/0x1e70 kernel/bpf/btf.c:6892 bpf_btf_load kernel/bpf/syscall.c:4324 [inline] __sys_bpf+0xb7d/0x4cf0 kernel/bpf/syscall.c:5010 __do_sys_bpf kernel/bpf/syscall.c:5069 [inline] __se_sys_bpf kernel/bpf/syscall.c:5067 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:5067 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Cc: Yonghong Song <yhs@fb.com> Cc: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Stanislav Fomichev <sdf@google.com> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20221015002444.2680969-1-sdf@google.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2022-10-17MAINTAINERS: git://github -> https://github.com for broadcomPalmer Dabbelt
Github deprecated the git:// links about a year ago, so let's move to the https:// URLs instead. Acked-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reported-by: Conor Dooley <conor.dooley@microchip.com> Link: https://github.blog/2021-09-01-improving-git-protocol-security-github/ Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2022-10-17Merge tag 'v6.1-p2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "This fixes an issue exposed by the recent change to feed untrusted sources into /dev/random" * tag 'v6.1-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: hwrng: bcm2835 - use hwrng_msleep() instead of cpu_relax()
2022-10-17x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUBNathan Chancellor
A recent change in LLVM made CONFIG_EFI_STUB unselectable because it no longer pretends to support -mabi=ms, breaking the dependency in Kconfig. Lack of CONFIG_EFI_STUB can prevent kernels from booting via EFI in certain circumstances. This check was added by 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi") to ensure that __attribute__((ms_abi)) was available, as -mabi=ms is not actually used in any cflags. According to the GCC documentation, this attribute has been supported since GCC 4.4.7. The kernel currently requires GCC 5.1 so this check is not necessary; even when that change landed in 5.6, the kernel required GCC 4.9 so it was unnecessary then as well. Clang supports __attribute__((ms_abi)) for all versions that are supported for building the kernel so no additional check is needed. Remove the 'depends on' line altogether to allow CONFIG_EFI_STUB to be selected when CONFIG_EFI is enabled, regardless of compiler. Fixes: 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/d1ad006a8f64bdc17f618deffa9e7c91d82c444d
2022-10-17Revert "PCI: tegra: Use PCI_CONF1_EXT_ADDRESS() macro"Jon Hunter
This reverts commit 8bb7ff12a91429eb76e093b517ae810b146448fe. Commit 8bb7ff12a914 ("PCI: tegra: Use PCI_CONF1_EXT_ADDRESS() macro") updated the Tegra PCI driver to use the macro PCI_CONF1_EXT_ADDRESS() instead of a local function in the Tegra PCI driver. This broke PCI for some Tegra platforms because, when calculating the offset value, the mask applied to the lower 8-bits changed from 0xff to 0xfc. For now, fix this by reverting this commit. Fixes: 8bb7ff12a914 ("PCI: tegra: Use PCI_CONF1_EXT_ADDRESS() macro") Link: https://lore.kernel.org/r/20221017084006.11770-1-jonathanh@nvidia.com Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
2022-10-17sched: Introduce struct balance_callback to avoid CFI mismatchesKees Cook
Introduce distinct struct balance_callback instead of performing function pointer casting which will trip CFI. Avoids warnings as found by Clang's future -Wcast-function-type-strict option: In file included from kernel/sched/core.c:84: kernel/sched/sched.h:1755:15: warning: cast from 'void (*)(struct rq *)' to 'void (*)(struct callback_head *)' converts to incompatible function type [-Wcast-function-type-strict] head->func = (void (*)(struct callback_head *))func; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No binary differences result from this change. This patch is a cleanup based on Brad Spengler/PaX Team's modifications to sched code in their last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. Reported-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://github.com/ClangBuiltLinux/linux/issues/1724 Link: https://lkml.kernel.org/r/20221008000758.2957718-1-keescook@chromium.org
2022-10-17sched/core: Fix comparison in sched_group_cookie_match()Lin Shengwang
In commit 97886d9dcd86 ("sched: Migration changes for core scheduling"), sched_group_cookie_match() was added to help determine if a cookie matches the core state. However, while it iterates the SMT group, it fails to actually use the RQ for each of the CPUs iterated, use cpu_rq(cpu) instead of rq to fix things. Fixes: 97886d9dcd86 ("sched: Migration changes for core scheduling") Signed-off-by: Lin Shengwang <linshengwang1@huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20221008022709.642-1-linshengwang1@huawei.com
2022-10-17bpf: Fix sample_flags for bpf_perf_event_outputSumanth Korikkar
* Raw data is also filled by bpf_perf_event_output. * Add sample_flags to indicate raw data. * This eliminates the segfaults as shown below: Run ./samples/bpf/trace_output BUG pid 9 cookie 1001000000004 sized 4 BUG pid 9 cookie 1001000000004 sized 4 BUG pid 9 cookie 1001000000004 sized 4 Segmentation fault (core dumped) Fixes: 838d9bb62d13 ("perf: Use sample_flags for raw_data") Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lkml.kernel.org/r/20221007081327.1047552-1-sumanthk@linux.ibm.com
2022-10-17selftests/perf_events: Add a SIGTRAP stress test with disablesMarco Elver
Add a SIGTRAP stress test that exercises repeatedly enabling/disabling an event while it concurrently keeps firing. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/Y0E3uG7jOywn7vy3@elver.google.com/
2022-10-17perf: Fix missing SIGTRAPsPeter Zijlstra
Marco reported: Due to the implementation of how SIGTRAP are delivered if perf_event_attr::sigtrap is set, we've noticed 3 issues: 1. Missing SIGTRAP due to a race with event_sched_out() (more details below). 2. Hardware PMU events being disabled due to returning 1 from perf_event_overflow(). The only way to re-enable the event is for user space to first "properly" disable the event and then re-enable it. 3. The inability to automatically disable an event after a specified number of overflows via PERF_EVENT_IOC_REFRESH. The worst of the 3 issues is problem (1), which occurs when a pending_disable is "consumed" by a racing event_sched_out(), observed as follows: CPU0 | CPU1 --------------------------------+--------------------------- __perf_event_overflow() | perf_event_disable_inatomic() | pending_disable = CPU0 | ... | _perf_event_enable() | event_function_call() | task_function_call() | /* sends IPI to CPU0 */ <IPI> | ... __perf_event_enable() +--------------------------- ctx_resched() task_ctx_sched_out() ctx_sched_out() group_sched_out() event_sched_out() pending_disable = -1 </IPI> <IRQ-work> perf_pending_event() perf_pending_event_disable() /* Fails to send SIGTRAP because no pending_disable! */ </IRQ-work> In the above case, not only is that particular SIGTRAP missed, but also all future SIGTRAPs because 'event_limit' is not reset back to 1. To fix, rework pending delivery of SIGTRAP via IRQ-work by introduction of a separate 'pending_sigtrap', no longer using 'event_limit' and 'pending_disable' for its delivery. Additionally; and different to Marco's proposed patch: - recognise that pending_disable effectively duplicates oncpu for the case where it is set. As such, change the irq_work handler to use ->oncpu to target the event and use pending_* as boolean toggles. - observe that SIGTRAP targets the ctx->task, so the context switch optimization that carries contexts between tasks is invalid. If the irq_work were delayed enough to hit after a context switch the SIGTRAP would be delivered to the wrong task. - observe that if the event gets scheduled out (rotation/migration/context-switch/...) the irq-work would be insufficient to deliver the SIGTRAP when the event gets scheduled back in (the irq-work might still be pending on the old CPU). Therefore have event_sched_out() convert the pending sigtrap into a task_work which will deliver the signal at return_to_user. Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Reported-by: Dmitry Vyukov <dvyukov@google.com> Debugged-by: Dmitry Vyukov <dvyukov@google.com> Reported-by: Marco Elver <elver@google.com> Debugged-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Marco Elver <elver@google.com> Tested-by: Marco Elver <elver@google.com>
2022-10-17counter: ti-ecap-capture: fix IS_ERR() vs NULL checkDan Carpenter
The devm_counter_alloc() function returns NULL on error. It doesn't return error pointers. Fixes: 4e2f42aa00b6 ("counter: ti-ecap-capture: capture driver support for ECAP") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Julien Panis <jpanis@baylibre.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/Y0bUbZvfDJHBG9C6@kili/ Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
2022-10-17counter: Reduce DEFINE_COUNTER_ARRAY_POLARITY() to defining counter_arrayWilliam Breathitt Gray
A spare warning was reported for drivers/counter/ti-ecap-capture.c:: sparse warnings: (new ones prefixed by >>) >> drivers/counter/ti-ecap-capture.c:380:8: sparse: sparse: symbol 'ecap_cnt_pol_array' was not declared. Should it be static? vim +/ecap_cnt_pol_array +380 drivers/counter/ti-ecap-capture.c 379 > 380 static DEFINE_COUNTER_ARRAY_POLARITY(ecap_cnt_pol_array, ecap_cnt_pol_avail, ECAP_NB_CEVT); 381 The first argument to the DEFINE_COUNTER_ARRAY_POLARITY() macro is a token serving as the symbol name in the definition of a new struct counter_array structure. However, this macro actually expands to two statements:: #define DEFINE_COUNTER_ARRAY_POLARITY(_name, _enums, _length) \ DEFINE_COUNTER_AVAILABLE(_name##_available, _enums); \ struct counter_array _name = { \ .type = COUNTER_COMP_SIGNAL_POLARITY, \ .avail = &(_name##_available), \ .length = (_length), \ } Because of this, the "static" on line 380 only applies to the first statement. This patch splits out the DEFINE_COUNTER_AVAILABLE() line and leaves DEFINE_COUNTER_ARRAY_POLARITY() as a simple structure definition to avoid issues like this. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/all/202210020619.NQbyomII-lkp@intel.com/ Cc: Julien Panis <jpanis@baylibre.com> Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
2022-10-17x86/fpu: Exclude dynamic states from init_fpstateChang S. Bae
== Background == The XSTATE init code initializes all enabled and supported components. Then, the init states are saved in the init_fpstate buffer that is statically allocated in about one page. The AMX TILE_DATA state is large (8KB) but its init state is zero. And the feature comes only with the compacted format with these established dependencies: AMX->XFD->XSAVES. So this state is excludable from init_fpstate. == Problem == But the buffer is formatted to include that large state. Then, this can be the cause of a noisy splat like the below. This came from XRSTORS for the task with init_fpstate in its XSAVE buffer. It is reproducible on AMX systems when the running kernel is built with CONFIG_DEBUG_PAGEALLOC=y and CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y: Bad FPU state detected at restore_fpregs_from_fpstate+0x57/0xd0, reinitializing FPU registers. ... RIP: 0010:restore_fpregs_from_fpstate+0x57/0xd0 ? restore_fpregs_from_fpstate+0x45/0xd0 switch_fpu_return+0x4e/0xe0 exit_to_user_mode_prepare+0x17b/0x1b0 syscall_exit_to_user_mode+0x29/0x40 do_syscall_64+0x67/0x80 ? do_syscall_64+0x67/0x80 ? exc_page_fault+0x86/0x180 entry_SYSCALL_64_after_hwframe+0x63/0xcd == Solution == Adjust init_fpstate to exclude dynamic states. XRSTORS from init_fpstate still initializes those states when their bits are set in the requested-feature bitmap. Fixes: 2308ee57d93d ("x86/fpu/amx: Enable the AMX feature in 64-bit mode") Reported-by: Lin X Wang <lin.x.wang@intel.com> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Lin X Wang <lin.x.wang@intel.com> Link: https://lore.kernel.org/r/20220824191223.1248-4-chang.seok.bae@intel.com
2022-10-17x86/fpu: Fix the init_fpstate size check with the actual sizeChang S. Bae
The init_fpstate buffer is statically allocated. Thus, the sanity test was established to check whether the pre-allocated buffer is enough for the calculated size or not. The currently measured size is not strictly relevant. Fix to validate the calculated init_fpstate size with the pre-allocated area. Also, replace the sanity check function with open code for clarity. The abstraction itself and the function naming do not tend to represent simply what it does. Fixes: 2ae996e0c1a3 ("x86/fpu: Calculate the default sizes independently") Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220824191223.1248-3-chang.seok.bae@intel.com
2022-10-17x86/fpu: Configure init_fpstate attributes orderlyChang S. Bae
The init_fpstate setup code is spread out and out of order. The init image is recorded before its scoped features and the buffer size are determined. Determine the scope of init_fpstate components and its size before recording the init state. Also move the relevant code together. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: neelnatu@google.com Link: https://lore.kernel.org/r/20220824191223.1248-2-chang.seok.bae@intel.com
2022-10-17ata: ahci_st: Fix compilation warningDamien Le Moal
If CONFIG_OF is disabled and the ahci_st driver is builtin (or CONFIG_MODULES is disabled), then using the macro of_match_ptr() results in the st_ahci_match variable being unused, which generates a compilation warning and a compilation error if CONFIG_WERROR is enabled. Fix this by directly assigning st_ahci_match to .of_match_table in the st_ahci_driver platform driver definition. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2022-10-17ASoC: codecs: jz4725b: add missed microphone widgetsSiarhei Volkau
Microphone input can be single ended or differential, although known SoCs with that codec expose MIC1P only. Also there is 20dB mic boost in the Mic1 path. Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Link: https://lore.kernel.org/r/20221016132648.3011729-8-lis8215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: jz4725b: add missed Mixer inputsSiarhei Volkau
The Mixer couples analog input from 4 sources (DAC, Line In, Mic 1, Mic 2) each input has its own gain & mute controls. At the moment only DAC is implemented fully and Line In path can be switched on/off. The patch implements Mic 1 and Mic 2 paths and fully implements Line In path. Manual states that these controls (16.6.3.3 Programmable attenuation: GOi) gain varies from -22.5dB to +6.0dB with 1.5dB step. Also there's extra values below the minimum, but they behave the same as the minimum value. Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Link: https://lore.kernel.org/r/20221016132648.3011729-7-lis8215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: jz4725b: use right control for Master PlaybackSiarhei Volkau
At the moment DAC control is used as Master Playback control, this is incorrect as DAC's output goes to a Mixer. The Mixer couples analog input from 4 sources (DAC, Line In, Mic 1, Mic 2) each input has its own gain & mute controls. Output of the Mixer goes to Output Stage control which is the best suite for the new Playback Master. However, it doesn't have mute capability. The patch implements Output Stage control as a new master and renames old Master to DAC. Rest of mixer inputs will be implemented in the next patch in the series. Manual states that Output stage control (16.6.3.5 Programmable output amplifier: PGAT) gain varies from -33.5dB to +4.5dB, gain step isn't fixed and has 3 opts. Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Link: https://lore.kernel.org/r/20221016132648.3011729-6-lis8215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: jz4725b: fix capture selector namingSiarhei Volkau
At the moment Capture source selector appears on Playback tab in the alsamixer and has a senseless name. Let's fix that. Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Link: https://lore.kernel.org/r/20221016132648.3011729-5-lis8215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: jz4725b: use right control for Capture VolumeSiarhei Volkau
Line In Bypass control is used as Master Capture at the moment this is completely incorrect. Current control routed to Mixer instead of ADC, thus can't affect Capture path. ADC control shall be used instead. ADC volume control parameters are different, so the patch fixes that as well. Manual says (16.6.3.2 Programmable input attenuation amplifier: PGATM) that gain varies in range 0dB..22.5dB with 1.5dB step. Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Link: https://lore.kernel.org/r/20221016132648.3011729-4-lis8215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: jz4725b: fix reported volume for Master ctlSiarhei Volkau
DAC volume control is the Master Playback Volume at the moment and it reports wrong levels in alsamixer and other alsa apps. The patch fixes that, as stated in manual on the jz4725b SoC (16.6.3.4 Programmable attenuation: GOD) the ctl range varies from -22.5dB to 0dB with 1.5dB step. Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Link: https://lore.kernel.org/r/20221016132648.3011729-3-lis8215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: jz4725b: add missed Line In power control bitSiarhei Volkau
Line In path stayed powered off during capturing or bypass to mixer. Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Link: https://lore.kernel.org/r/20221016132648.3011729-2-lis8215@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: hda: Fix spelling error in log messageCezary Rojewski
To improve readability. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-16-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Simplify log control for SKLCezary Rojewski
Loop only till the actual number of AudioDSP cores, not the value of mask made from said number. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-15-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Simplify ignore_fw_version descriptionCezary Rojewski
Reword the parameter description to drop any confusion regarding its purpose. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-14-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Do not print IPC error message twiceCezary Rojewski
ENABLE_LOGS and SYSTEM_TIME IPCs call LARGE_CONFIG_SET internally which dumps an error message in case of an error. There is no need to repeat the process in the top level handler. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-13-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Do not treat unsupported IPCs as invalidCezary Rojewski
Utilize NOT_SUPPORTED status code to differentiate between unsupported and invalid requests. Skip over error paths if it is the former that is communicated by the base firmware. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-12-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Do not reuse msg between different IPC handlersCezary Rojewski
While LOG_BUFFER_STATUS is a simple notification with only one meaningful field, same message ptr shall not be reused for two different handlers. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-11-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Add missing include to HDA boardAmadeusz Sławiński
In some configurations board fails to compile due to missing header. Add it to fix build. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-10-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Simplify d0ix disabling routineCezary Rojewski
No need to atomic_add_return(1) when there is atomic_inc_return() available. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-9-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Add missing SKL-based device IDsCezary Rojewski
Enable additional SKL-based configurations by filling device ID table with new entries. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-8-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Support da7219 on both KBL and APLAmadeusz Sławiński
KBL and APL devices use same codec but have different clock, so it must be set appropriately depending on device. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Support AML with rt286 configurationCezary Rojewski
ACPI ID of INT343A signals rt286 device for SKL, KBL and AML platforms. Add the missing AML entry. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Add quirk for KBL-R RVP platformAmadeusz Sławiński
KBL-R RVPs contain built-in rt298 codec which requires different PLL clock and .dai_fmt configuration than seen on other boards. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: codecs: rt298: Add quirk for KBL-R RVP platformAmadeusz Sławiński
KBL-R RVP platforms also use combojack, so we need to enable that configuration for them. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Fix potential RX buffer overflowCezary Rojewski
If an event caused firmware to return invalid RX size for LARGE_CONFIG_GET, memcpy_fromio() could end up copying too many bytes. Fix by utilizing min_t(). Reported-by: CoolStar <coolstarorganization@gmail.com> Fixes: f14a1c5a9f83 ("ASoC: Intel: avs: Add module management requests") Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: Intel: avs: Fix DMA mask assignmentCezary Rojewski
Spelling error leads to incorrect behavior when setting up DMA mask. Fixes: a5bbbde2b81e ("ASoC: Intel: avs: Use helper function to set up DMA") Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20221010121955.718168-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17fbdev: MIPS supports iomem addressesKees Cook
Add MIPS to fb_* helpers list for iomem addresses. This silences Sparse warnings about lacking __iomem address space casts: drivers/video/fbdev/pvr2fb.c:800:9: sparse: sparse: incorrect type in argument 1 (different address spaces) drivers/video/fbdev/pvr2fb.c:800:9: sparse: expected void const * drivers/video/fbdev/pvr2fb.c:800:9: sparse: got char [noderef] __iomem *screen_base Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/202210100209.tR2Iqbqk-lkp@intel.com/ Cc: Helge Deller <deller@gmx.de> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Helge Deller <deller@gmx.de>
2022-10-17ASoC: amd: Update Pink Sardine platform ACP register headerVijendar Mukunda
Update Pink Sardine platform ACP register header with Soundwire Controller specific registers and other ACP registers. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20221010093941.2354783-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: kirkwood: enable Kirkwood driver for Armada 38x platformsMarcin Wojtas
The audio unit of Marvell Armada38x SoC is similar to the ones comprised by other Marvell SoCs (Kirkwood, Dove and Armada 370). Therefore KW audio driver can be used to support it and this commit adds new compatible string to identify Armada 38x variant. Two new memory regions are added: first one for PLL configuration and the second one for choosing one of audio I/O modes (I2S or S/PDIF). For the latter purpose a new optional DT property is added ('spdif-mode'). kirkwood-i2s driver is extended by adding a new init function for Armada 38x flavor and also a routine that enables PLL output (i.e. MCLK) configuration. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Tested-by: Star_Automation <star@marvell.com> Reviewed-by: Nadav Haklai <nadavh@marvell.com> Reviewed-by: Lior Amsalem <alior@marvell.com> Tested-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Hezi Shahmoon <hezi@marvell.com> Reviewed-by: Neta Zur Hershkovits <neta@marvell.com> [pali: Fix support for pre-38x SoCs] Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220926110533.13475-1-pali@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: cs42l83: change cs42l83_regmap to staticYang Yingliang
cs42l83_regmap is only used in cs42l83-i2c.c now, change it to static. Fixes: 94d5f62a91aa ("ASoC: cs42l83: Extend CS42L42 support to new part") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220921153123.1508144-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: ak4458: add optional reset control to instead of gpioViorel Suman
Add optional reset control instead of GPIO to manage codec PDN pin. As there is reference counter for reset control, so need to remove one ak4458_reset in runtime resume to make the reference counter balance. Signed-off-by: Viorel Suman <viorel.suman@nxp.com> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1665664611-21350-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: fsl_micfil: Add Hardware Voice Activity Detector supportShengjiu Wang
The Hardware Voice Activity Detector (HWVAD) is a block responsible for detect voice activity in a channel selected by the user. It can be configured in Envelope-based or Energy-based mode. There are additional two interrupts for HWVAD, one is event interrupt, another is error interrupt. Enable hwvad in parallel with recording. when voice activity detected, HWVAD will be disabled and alsa control notification is triggerred. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1663925494-9941-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-10-17ASoC: ti: davinci-mcasp: Use DIV_ROUND_UP() instead of open-coding itShang XiaoJing
Use DIV_ROUND_UP() instead of open-coding it, which intents and makes it more clear what is going on for the casual reviewer. The Coccinelle references Commit e4d8aef21403 ("ALSA: usb: Use DIV_ROUND_UP() instead of open-coding it"). Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/r/20220927140948.17696-5-shangxiaojing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-19 15:47:23 +0000