Repository navigation
Conversation
…/kernel/git/wireless/wireless Johannes Berg says: ==================== Valentine's day edition, with just few fixes because that's how we love it ;-) iwlwifi: - correct A3 in A-MSDUs - fix crash when operating as AP and running out of station slots to use - clear link ID to correct some later checks against it - fix error codes in SAR table loading - fix error path in PPAG table read mac80211: - reload a pointer after SKB may have changed (only in certain monitor inject mode scenarios) * tag 'wireless-2024-02-14' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: iwlwifi: mvm: fix a crash when we run out of stations wifi: iwlwifi: uninitialized variable in iwl_acpi_get_ppag_table() wifi: iwlwifi: Fix some error codes wifi: iwlwifi: clear link_id in time_event wifi: iwlwifi: mvm: use correct address 3 in A-MSDU wifi: mac80211: reload info pointer in ieee80211_tx_dequeue() ==================== Link: https://lore.kernel.org/r/20240214184326.132813-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
To fully support initializing the LAG support code, a DDP package that extracts the logical port from the metadata is required. If such a package is not present, there could be difficulties in supporting some bond types. Add a check into the initialization flow that will bypass the new paths if any of the support pieces are missing. Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Fixes: df006dd ("ice: Add initial support framework for LAG") Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20240213183957.1483857-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test runners on debug kernels occasionally fail with: # # RUN tls_err.13_aes_gcm.poll_partial_rec_async ... # # tls.c:1883:poll_partial_rec_async:Expected poll(&pfd, 1, 5) (0) == 1 (1) # # tls.c:1870:poll_partial_rec_async:Expected status (256) == 0 (0) # # poll_partial_rec_async: Test failed at step #17 # # FAIL tls_err.13_aes_gcm.poll_partial_rec_async # not ok 699 tls_err.13_aes_gcm.poll_partial_rec_async # # FAILED: 698 / 699 tests passed. This points to the second poll() in the test which is expected to wait for the sender to send the rest of the data. Apparently under some conditions that doesn't happen within 5ms, bump the timeout to 20ms. Fixes: 23fcb62 ("selftests: tls: add tests for poll behavior") Link: https://lore.kernel.org/r/20240213142055.395564-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The function xe_vm_prepare_vma was blindly accepting zero as the number of fences and forwarded that to drm_exec_prepare_obj. However, that leads to an out-of-bounds shift in the dma_resv_reserve_fences() and while one could argue that the dma_resv code should be robust against that, avoid attempting to reserve zero fences. Relevant stack trace: [773.183188] ------------[ cut here ]------------ [773.183199] UBSAN: shift-out-of-bounds in ../include/linux/log2.h:57:13 [773.183241] shift exponent 64 is too large for 64-bit type 'long unsigned int' [773.183254] CPU: 2 PID: 1816 Comm: xe_evict Tainted: G U 6.8.0-rc3-xe #1 [773.183256] Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 2014 10/14/2022 [773.183257] Call Trace: [773.183258] <TASK> [773.183260] dump_stack_lvl+0xaf/0xd0 [773.183266] dump_stack+0x10/0x20 [773.183283] ubsan_epilogue+0x9/0x40 [773.183286] __ubsan_handle_shift_out_of_bounds+0x10f/0x170 [773.183293] dma_resv_reserve_fences.cold+0x2b/0x48 [773.183295] ? ww_mutex_lock+0x3c/0x110 [773.183301] drm_exec_prepare_obj+0x45/0x60 [drm_exec] [773.183313] xe_vm_prepare_vma+0x33/0x70 [xe] [773.183375] xe_vma_destroy_unlocked+0x55/0xa0 [xe] [773.183427] xe_vm_close_and_put+0x526/0x940 [xe] Fixes: 2714d50 ("drm/xe: Convert pagefaulting code to use drm_exec") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208132115.3132-1-thomas.hellstrom@linux.intel.com (cherry picked from commit eb538b5) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
shmem ensures the memory is cleared on allocation, however here we are using TTM, which doesn't natively support shmem (other than for swap), but instead just allocates normal system memory. And we only zero such memory for userspace allocations. In the case of intel_fbdev we are missing the memset_io() since display path incorrectly thinks object is shmem based. Fixes: 44e6949 ("drm/xe/display: Implement display support") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205153110.38340-2-matthew.auld@intel.com (cherry picked from commit 63fb531) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Distinguish between xe_pt and the xe_pt_dir subclass when allocating and freeing. Also use a fixed-size array for the xe_pt_dir page entries to make life easier for dynamic range- checkers. Finally rename the page-directory child pointer array to "children". While no functional change, this fixes ubsan splats similar to: [ 51.463021] ------------[ cut here ]------------ [ 51.463022] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/xe/xe_pt.c:47:9 [ 51.463023] index 0 is out of range for type 'xe_ptw *[*]' [ 51.463024] CPU: 5 PID: 2778 Comm: xe_vm Tainted: G U 6.8.0-rc1+ #218 [ 51.463026] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 51.463027] Call Trace: [ 51.463028] <TASK> [ 51.463029] dump_stack_lvl+0x47/0x60 [ 51.463030] __ubsan_handle_out_of_bounds+0x95/0xd0 [ 51.463032] xe_pt_destroy+0xa5/0x150 [xe] [ 51.463088] __xe_pt_unbind_vma+0x36c/0x9b0 [xe] [ 51.463144] xe_vm_unbind+0xd8/0x580 [xe] [ 51.463204] ? drm_exec_prepare_obj+0x3f/0x60 [drm_exec] [ 51.463208] __xe_vma_op_execute+0x5da/0x910 [xe] [ 51.463268] ? __drm_gpuvm_sm_unmap+0x1cb/0x220 [drm_gpuvm] [ 51.463272] ? radix_tree_node_alloc.constprop.0+0x89/0xc0 [ 51.463275] ? drm_gpuva_it_remove+0x1f3/0x2a0 [drm_gpuvm] [ 51.463279] ? drm_gpuva_remove+0x2f/0xc0 [drm_gpuvm] [ 51.463283] xe_vm_bind_ioctl+0x1a55/0x20b0 [xe] [ 51.463344] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] [ 51.463414] drm_ioctl_kernel+0xb6/0x120 [ 51.463416] drm_ioctl+0x287/0x4e0 [ 51.463418] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] [ 51.463481] __x64_sys_ioctl+0x94/0xd0 [ 51.463484] do_syscall_64+0x86/0x170 [ 51.463486] ? syscall_exit_to_user_mode+0x7d/0x200 [ 51.463488] ? do_syscall_64+0x96/0x170 [ 51.463490] ? do_syscall_64+0x96/0x170 [ 51.463492] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 51.463494] RIP: 0033:0x7f246bfe817d [ 51.463498] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 [ 51.463501] RSP: 002b:00007ffc1bd19ad0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 51.463502] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f246bfe817d [ 51.463504] RDX: 00007ffc1bd19b60 RSI: 0000000040886445 RDI: 0000000000000003 [ 51.463505] RBP: 00007ffc1bd19b20 R08: 0000000000000000 R09: 0000000000000000 [ 51.463506] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc1bd19b60 [ 51.463508] R13: 0000000040886445 R14: 0000000000000003 R15: 0000000000010000 [ 51.463510] </TASK> [ 51.463517] ---[ end trace ]--- v2 - Fix kerneldoc warning (Matthew Brost) Fixes: dd08ebf ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240209112655.4872-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 157261c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
clang-16 warns about a cast between incompatible function types:
drivers/gpu/drm/xe/xe_range_fence.c:155:10: error: cast from 'void (*)(const void *)' to 'void (*)(struct xe_range_fence *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
155 | .free = (void (*)(struct xe_range_fence *rfence)) kfree,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avoid this with a trivial helper function that calls kfree() here.
v2:
- s/* rfence/*rfence/ (Thomas)
Fixes: 845f64b ("drm/xe: Introduce a range-fence utility")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240213095719.454865-1-arnd@kernel.org
(cherry picked from commit f2c9364)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
When SOF_TIMESTAMPING_OPT_ID is used to ambiguate timestamped datagrams, the sk_tskey can become unpredictable in case of any error happened during sendmsg(). Move increment later in the code and make decrement of sk_tskey in error path. This solution is still racy in case of multiple threads doing snedmsg() over the very same socket in parallel, but still makes error path much more predictable. Fixes: 09c2d25 ("net-timestamp: add key to disambiguate concurrent datagrams") Reported-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Vadim Fedorenko <vadfed@meta.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20240213110428.1681540-1-vadfed@meta.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
…pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2024-02-14 this is a pull request of 3 patches for net/master. the first patch is by Ziqi Zhao and targets the CAN J1939 protocol, it fixes a potential deadlock by replacing the spinlock by an rwlock. Oleksij Rempel's patch adds a missing spin_lock_bh() to prevent a potential Use-After-Free in the CAN J1939's setsockopt(SO_J1939_FILTER). Maxime Jayat contributes a patch to fix the transceiver delay compensation (TDCO) calculation, which is needed for higher CAN-FD bit rates (usually 2Mbit/s). * tag 'linux-can-fixes-for-6.8-20240214' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: netlink: Fix TDCO calculation using the old data bittiming can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock ==================== Link: https://lore.kernel.org/r/20240214140348.2412776-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add the MIDR value of Microsoft Azure Cobalt 100, which is a Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore suffers from all the same errata. CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240214175522.2457857-1-eahariha@linux.microsoft.com Signed-off-by: Will Deacon <will@kernel.org>
Doug Anderson observed that ChromeOS crashes are being reported which
include failing allocations of order 7 during core dumps due to ptrace
allocating storage for regsets:
chrome: page allocation failure: order:7,
mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
nodemask=(null),cpuset=urgent,mems_allowed=0
...
regset_get_alloc+0x1c/0x28
elf_core_dump+0x3d8/0xd8c
do_coredump+0xeb8/0x1378
with further investigation showing that this is:
[ 66.957385] DOUG: Allocating 279584 bytes
which is the maximum size of the SVE regset. As Doug observes it is not
entirely surprising that such a large allocation of contiguous memory might
fail on a long running system.
The SVE regset is currently sized to hold SVE registers with a VQ of
SVE_VQ_MAX which is 512, substantially more than the architectural maximum
of 16 which we might see even in a system emulating the limits of the
architecture. Since we don't expose the size we tell the regset core
externally let's define ARCH_SVE_VQ_MAX with the actual architectural
maximum and use that for the regset, we'll still overallocate most of the
time but much less so which will be helpful even if the core is fixed to
not require contiguous allocations.
Specify ARCH_SVE_VQ_MAX in terms of the maximum value that can be written
into ZCR_ELx.LEN (where this is set in the hardware). For consistency
update the maximum SME vector length to be specified in the same style
while we are at it.
We could also teach the ptrace core about runtime discoverable regset sizes
but that would be a more invasive change and this is being observed in
practical systems.
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
…git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following batch contains Netfilter fixes for net: 1) Missing : in kdoc field in nft_set_pipapo. 2) Restore default DNAT behavior When a DNAT rule is configured via iptables with different port ranges, from Kyle Swenson. 3) Restore flowtable hardware offload for bidirectional flows by setting NF_FLOW_HW_BIDIRECTIONAL flag, from Felix Fietkau. netfilter pull request 24-02-15 * tag 'nf-24-02-15' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_tables: fix bidirectional offload regression netfilter: nat: restore default DNAT behavior netfilter: nft_set_pipapo: fix missing : in kdoc ==================== Link: https://lore.kernel.org/r/20240214233818.7946-1-pablo@netfilter.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The buffer_pg variable needs to hold an order-5 allocation (32 x PAGE_SIZE) which, under memory pressure may fail to be allocated. Deal with that error condition properly to avoid doing a NULL pointer de-reference in the subsequent call to dma_map_page(). In addition, the err_reclaim_tx error label in bcmasp_netif_init() needs to ensure that the TX NAPI object is properly deleted, otherwise unregister_netdev() will spin forever attempting to test and clear the NAPI_STATE_HASHED bit. Fixes: 490cb41 ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Justin Chen <justin.chen@broadcom.com> Link: https://lore.kernel.org/r/20240213173339.3438713-1-florian.fainelli@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Since commit d492cc2 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the soundbus_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240214-bus_cleanup-alsa-v1-1-8fedbb4afa94@marliere.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since commit d492cc2 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the snd_seq_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240214-bus_cleanup-alsa-v1-2-8fedbb4afa94@marliere.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
The type 'tristate' is already specified three lines above. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://msgid.link/r/20240215132854.1907630-1-masahiroy@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
lld is now able to build ARMv4 and ARMv4T kernels, which means it can generate thunks for those (__ARMv4PILongThunk_*, __ARMv4PILongBXThunk_*) that can interfere with kallsyms table generation since they do not get ignore like the corresponding ARMv5+ ones are: Inconsistent kallsyms data Try "make KALLSYMS_EXTRA_PASS=1" as a workaround Replace the hardcoded list of thunk symbols with a more general regex that covers this one along with future symbols that follow the same pattern. Fixes: 5eb6e28 ("ARM: 9289/1: Allow pre-ARMv5 builds with ld.lld 16.0.0 and newer") Fixes: efe6e30 ("kallsyms: fix nonconverging kallsyms table with lld") Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
…/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.8 A relatively large set of fixes and quirk additions here but they're all driver specific, people seem to be back into the swing of things after the holidays. This is all driver specific and much of it fairly minor.
'def_tristate' is a shorthand for 'default' + 'tristate'. Another 'tristate' is redundant. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20240215135304.1909431-1-masahiroy@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
In case of GSO, 'chunk->skb' pointer may point to an entry from fraglist created in 'sctp_packet_gso_append()'. To avoid freeing random fraglist entry (and so undefined behavior and/or memory leak), introduce 'sctp_inq_chunk_free()' helper to ensure that 'chunk->skb' is set to 'chunk->head_skb' (i.e. fraglist head) before calling 'sctp_chunk_free()', and use the aforementioned helper in 'sctp_inq_pop()' as well. Reported-by: syzbot+8bb053b5d63595ab47db@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=0d8351bbe54fd04a492c2daab0164138db008042 Fixes: 90017ac ("sctp: Add GSO support") Suggested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/20240214082224.10168-1-dmantipov@yandex.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
syzbot reports a memory leak in pppoe_sendmsg [1].
The problem is in the pppoe_recvmsg() function that handles errors
in the wrong order. For the skb_recv_datagram() function, check
the pointer to skb for NULL first, and then check the 'error' variable,
because the skb_recv_datagram() function can set 'error'
to -EAGAIN in a loop but return a correct pointer to socket buffer
after a number of attempts, though 'error' remains set to -EAGAIN.
skb_recv_datagram
__skb_recv_datagram // Loop. if (err == -EAGAIN) then
// go to the next loop iteration
__skb_try_recv_datagram // if (skb != NULL) then return 'skb'
// else if a signal is received then
// return -EAGAIN
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller.
Link: https://syzkaller.appspot.com/bug?extid=6bdfd184eac7709e5cc9 [1]
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+6bdfd184eac7709e5cc9@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6bdfd184eac7709e5cc9
Signed-off-by: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Reviewed-by: Guillaume Nault <gnault@redhat.com>
Link: https://lore.kernel.org/r/20240214085814.3894917-1-Ilia.Gavrilov@infotecs.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The units of "work done" in the RX path should be packets instead of descriptors, as large packets can be spread over multiple descriptors. Fixes: 1c59eb6 ("ravb: Fillup ravb_rx_gbeth() stub") Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/20240214151204.2976-1-paul.barker.ct@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The HP mt645 G7 Thin Client uses an ALC236 codec and needs the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make the mute and micmute LEDs work. There are two variants of the USB-C PD chip on this device. Each uses a different BIOS and board ID, hence the two entries. Signed-off-by: Eniac Zhang <eniac-xw.zhang@hp.com> Signed-off-by: Alexandru Gagniuc <alexandru.gagniuc@hp.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240215154922.778394-1-alexandru.gagniuc@hp.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
The USB audio driver tries to retrieve MIDI jack name strings that can be used for rawmidi substream names and sequencer port names, but its checking is too strict: often the firmware provides the jack info for unexpected directions, and then we miss the info although it's present. In this patch, the code to extract the jack info is changed to allow both in and out directions in a single loop. That is, the former two functions to obtain the descriptor pointers for jack in and out are changed to a single function that returns iJack of the corresponding jack ID, no matter which direction is used. It's a code simplification at the same time as well as the fix. Fixes: eb596e0 ("ALSA: usb-audio: generate midi streaming substream names from jack names") Link: https://lore.kernel.org/r/20240215153144.26047-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull the latest 6.8 stuff into devel branch for further development. Fixed the trivial merge conflict for HD-audio Realtek stuff. Signed-off-by: Takashi Iwai <tiwai@suse.de>
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the Xen backend network module. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Paul Durrant <paul@xen.org> Link: https://lore.kernel.org/r/20240214152741.670178-2-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the IEEE 802.15.4 loopback driver. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240214152741.670178-3-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the PLIP (parallel port) network module Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240214152741.670178-4-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the SysKonnect FDDI PCI module. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240214152741.670178-5-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
W=1 builds now warn if module is built without a MODULE_DESCRIPTION(). Add descriptions to the PPP modules. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20240214152741.670178-6-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert the RT1015 Mono Class D Audio Amplifier to DT schema. Signed-off-by: Javier García <javier.gar.tab@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://msgid.link/r/20240304142315.14522-1-javier.gar.tab@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
The snd_soc_bias_level_start and snd_soc_bias_level_done trace events
currently look like:
aplay-229 [000] 1250.140778: snd_soc_bias_level_start: card=vscn-2046 val=1
aplay-229 [000] 1250.140784: snd_soc_bias_level_done: card=vscn-2046 val=1
aplay-229 [000] 1250.140786: snd_soc_bias_level_start: card=vscn-2046 val=2
aplay-229 [000] 1250.140788: snd_soc_bias_level_done: card=vscn-2046 val=2
kworker/u8:1-21 [000] 1250.140871: snd_soc_bias_level_start: card=vscn-2046 val=1
kworker/u8:0-11 [000] 1250.140951: snd_soc_bias_level_start: card=vscn-2046 val=1
kworker/u8:0-11 [000] 1250.140956: snd_soc_bias_level_done: card=vscn-2046 val=1
kworker/u8:0-11 [000] 1250.140959: snd_soc_bias_level_start: card=vscn-2046 val=2
kworker/u8:0-11 [000] 1250.140961: snd_soc_bias_level_done: card=vscn-2046 val=2
kworker/u8:1-21 [000] 1250.167219: snd_soc_bias_level_done: card=vscn-2046 val=1
kworker/u8:1-21 [000] 1250.167222: snd_soc_bias_level_start: card=vscn-2046 val=2
kworker/u8:1-21 [000] 1250.167232: snd_soc_bias_level_done: card=vscn-2046 val=2
kworker/u8:0-11 [000] 1250.167440: snd_soc_bias_level_start: card=vscn-2046 val=3
kworker/u8:0-11 [000] 1250.167444: snd_soc_bias_level_done: card=vscn-2046 val=3
kworker/u8:1-21 [000] 1250.167497: snd_soc_bias_level_start: card=vscn-2046 val=3
kworker/u8:1-21 [000] 1250.167506: snd_soc_bias_level_done: card=vscn-2046 val=3
There are clearly multiple calls, one per component, but they cannot be
discriminated from each other.
Change the ftrace events to also print the component name, to make it clear
which part of the code is involved. This requires changing the passed value
from a struct snd_soc_card, where the DAPM context is not kwown, to a
struct snd_soc_dapm_context where it is obviously known but the a card
pointer is also available.
With this change, the resulting trace becomes:
aplay-247 [000] 1436.357332: snd_soc_bias_level_start: card=vscn-2046 component=(none) val=1
aplay-247 [000] 1436.357338: snd_soc_bias_level_done: card=vscn-2046 component=(none) val=1
aplay-247 [000] 1436.357340: snd_soc_bias_level_start: card=vscn-2046 component=(none) val=2
aplay-247 [000] 1436.357343: snd_soc_bias_level_done: card=vscn-2046 component=(none) val=2
kworker/u8:4-215 [000] 1436.357437: snd_soc_bias_level_start: card=vscn-2046 component=ff560000.codec val=1
kworker/u8:5-231 [000] 1436.357518: snd_soc_bias_level_start: card=vscn-2046 component=ff320000.i2s val=1
kworker/u8:5-231 [000] 1436.357523: snd_soc_bias_level_done: card=vscn-2046 component=ff320000.i2s val=1
kworker/u8:5-231 [000] 1436.357526: snd_soc_bias_level_start: card=vscn-2046 component=ff320000.i2s val=2
kworker/u8:5-231 [000] 1436.357528: snd_soc_bias_level_done: card=vscn-2046 component=ff320000.i2s val=2
kworker/u8:4-215 [000] 1436.383217: snd_soc_bias_level_done: card=vscn-2046 component=ff560000.codec val=1
kworker/u8:4-215 [000] 1436.383221: snd_soc_bias_level_start: card=vscn-2046 component=ff560000.codec val=2
kworker/u8:4-215 [000] 1436.383231: snd_soc_bias_level_done: card=vscn-2046 component=ff560000.codec val=2
kworker/u8:5-231 [000] 1436.383468: snd_soc_bias_level_start: card=vscn-2046 component=ff320000.i2s val=3
kworker/u8:5-231 [000] 1436.383472: snd_soc_bias_level_done: card=vscn-2046 component=ff320000.i2s val=3
kworker/u8:4-215 [000] 1436.383503: snd_soc_bias_level_start: card=vscn-2046 component=ff560000.codec val=3
kworker/u8:4-215 [000] 1436.383513: snd_soc_bias_level_done: card=vscn-2046 component=ff560000.codec val=3
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://msgid.link/r/20240306-improve-asoc-trace-events-v1-1-edb252bbeb10@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the event value to the snd_soc_dapm_start and snd_soc_dapm_done trace
events to make them more informative.
Trace before:
aplay-229 [000] 250.140309: snd_soc_dapm_start: card=vscn-2046
aplay-229 [000] 250.167531: snd_soc_dapm_done: card=vscn-2046
aplay-229 [000] 251.169588: snd_soc_dapm_start: card=vscn-2046
aplay-229 [000] 251.195245: snd_soc_dapm_done: card=vscn-2046
Trace after:
aplay-214 [000] 693.290612: snd_soc_dapm_start: card=vscn-2046 event=1
aplay-214 [000] 693.315508: snd_soc_dapm_done: card=vscn-2046 event=1
aplay-214 [000] 694.537349: snd_soc_dapm_start: card=vscn-2046 event=2
aplay-214 [000] 694.563241: snd_soc_dapm_done: card=vscn-2046 event=2
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://msgid.link/r/20240306-improve-asoc-trace-events-v1-2-edb252bbeb10@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Stuart Henderson <stuarth@opensource.cirrus.com> Link: https://msgid.link/r/20240306161439.1385643-1-stuarth@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Stuart Henderson <stuarth@opensource.cirrus.com> Link: https://msgid.link/r/20240306161439.1385643-2-stuarth@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Use source instead of ret, which seems to be unrelated and will always be zero. Signed-off-by: Stuart Henderson <stuarth@opensource.cirrus.com> Link: https://msgid.link/r/20240306161439.1385643-5-stuarth@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Member
Author
|
one pretty bad ipc timeout issue It's worth redoing the checks.... |
Member
Author
|
SOFCI TEST |
Member
Author
plbossart
marked this pull request as ready for review
March 7, 2024 14:50
plbossart
requested review from
bardliao,
dbaluta,
kv2019i,
lgirdwood,
ranj063 and
ujfalusi
as code owners
March 7, 2024 14:50
Member
Author
|
SOFCI TEST |
Member
Author
|
Oh, this is going to be very painful... https://sof-ci.01.org/linuxpr/PR4853/build1738/devicetest/index.html does not show the same regressions as this PR, so it's a kernel side regression due to the upstream merge. |
Member
Author
|
SOFCI TEST |
Member
Author
|
Still systematic failure for MTLP_RVP_NOCODEC but on different tests... The SET_MOD_DX IPC timeout reeks of a firmware problem, but we don't see it without the upstream merge, so not sure what to think... |
Collaborator
I think the error is similar to the PR test failure of #4849 |
Member
Author
|
Merging since we have at least 3 PRs with the same SET_MOD_DX IPC timeout. Clearly a firmware issue @kv2019i |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.