summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2026-03-16net/mlx5: LAG, replace mlx5_get_dev_index with LAG sequence numberShay Drory1-0/+11
Introduce mlx5_lag_get_dev_seq() which returns a device's sequence number within the LAG: master is always 0, remaining devices numbered sequentially. This provides a stable index for peer flow tracking and vport ordering without depending on native_port_num. Replace mlx5_get_dev_index() usage in en_tc.c (peer flow array indexing) and ib_rep.c (vport index ordering) with the new API. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260309093435.1850724-7-tariqt@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-03-16net/mlx5: Add silent mode set/query and VHCA RX IFC bitsShay Drory1-5/+14
Update the mlx5 IFC headers with newly defined capability and command-layout bits: - Add silent_mode_query and rename silent_mode to silent_mode_set cap fields. - Add forward_vhca_rx and MLX5_IFC_FLOW_DESTINATION_TYPE_VHCA_RX. - Expose silent mode fields in the L2 table query command structures. Update the SD support check to use the new capability name (silent_mode_set) to match the updated IFC definition. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260309093435.1850724-3-tariqt@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-03-16net/mlx5: Add IFC bits for shared headroom pool PBMC supportAlexei Lazar1-2/+5
Add hardware interface definitions for shared headroom pool (SHP) in port buffer management: - shp_pbmc_pbsr_support: capability bit in PCAM enhanced features indicating device support for shared headroom pool in PBMC/PBSR. - shared_headroom_pool: buffer entry in PBMC register (pbmc_reg_bits) for the shared headroom pool configuration, reusing the bufferx layout; reduce trailing reserved region accordingly. Signed-off-by: Alexei Lazar <alazar@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260309093435.1850724-2-tariqt@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-03-16Merge tag 'mm-hotfixes-stable-2026-03-16-12-15' of ↵Linus Torvalds1-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "6 hotfixes. 4 are cc:stable. 3 are for MM. All are singletons - please see the changelogs for details" * tag 'mm-hotfixes-stable-2026-03-16-12-15' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: MAINTAINERS: update email address for Ignat Korchagin mm/huge_memory: fix early failure try_to_migrate() when split huge pmd for shared THP mm/rmap: fix incorrect pte restoration for lazyfree folios mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd() build_bug.h: correct function parameters names in kernel-doc crash_dump: don't log dm-crypt key bytes in read_key_from_user_keying
2026-03-16ASoC: Handle edge case on SDCA jack control namingMark Brown1-0/+1
Charles Keepax <ckeepax@opensource.cirrus.com> says: Normally the SDCA jack detection controls will be named after the GE widget that represents the grouping of everything in the topology controlled by the jack selection. However, in the case that the jack selection only controls a single widget the control will be named after the SU widget that implements that. It is rather confusing to have the jack detection controls change naming scheme between devices. Add a new widget type, similar to mixer widgets, to force use of the control name rather than falling back to the widget names.
2026-03-16ASoC: dapm: Add a named controls variant of a mux widgetCharles Keepax1-0/+1
There is already a version of the mixer widget that forces use of the specified control name, rather than factoring in the widget name. Add the same feature for mux widgets. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260303155308.138989-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16spi: controller registration fixesMark Brown52-195/+411
Johan Hovold <johan@kernel.org> says: This series fixes a few issues related to controller registration found through inspection.
2026-03-16Merge tag 'device_lock_cond_guard-7.1-rc1' into for-7.1/cxl-consolidate-endpointDave Jiang1-0/+1
DEFINE_GUARD_COND() for device_lock_interruptible() Introduce conditional guard version of device_lock() for scenarios that require conditional device lock holding. This is a stable tag for other trees to merge.
2026-03-16ALSA: pcm: oss: use proper stream lock for runtime->state accessCen Zhang1-0/+4
__snd_pcm_set_state() writes runtime->state under the PCM stream lock. However, the OSS I/O functions snd_pcm_oss_write3(), snd_pcm_oss_read3(), snd_pcm_oss_writev3() and snd_pcm_oss_readv3() read runtime->state without holding the stream lock, only holding oss.params_lock (a different mutex that does not synchronize with the stream lock). Since __snd_pcm_set_state() is called from IRQ context (e.g., snd_pcm_period_elapsed -> snd_pcm_update_state -> __snd_pcm_xrun -> snd_pcm_stop -> snd_pcm_post_stop) while the OSS read/write paths run in process context, these are concurrent accesses that constitute a data race. Rather than using READ_ONCE()/WRITE_ONCE() barriers, introduce a snd_pcm_get_state() helper that reads runtime->state under the stream lock, matching the locking discipline used elsewhere in the PCM layer. Also export snd_pcm_set_state() for completeness. Use snd_pcm_get_state() in all four OSS I/O functions, caching the result in a local variable where the same snapshot is used for multiple comparisons to avoid taking the lock repeatedly. Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/20260316085047.2876451-1-zzzccc427@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-16ASoC: soc-component: re-add pcm_new()/pcm_free()Mark Brown1-4/+4
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says: Because old pcm_new()/pcm_free() didn't care about parameter component, to avoid name collisions, we have added pcm_construct()/pcm_destruct() by commit c64bfc9066007 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") Because all driver switch to new pcm_construct()/pcm_destruct(), old pcm_new()/pcm_free() were remoted by commit e9067bb502787 ("ASoC: soc-component: remove snd_pcm_ops from component driver") But naming of pcm_construct()/pcm_destruct() are not goot. re-add pcm_new()/pcm_free(), and switch to use it, again. Because it has no functional significance, 1 patch is for 1 vender.
2026-03-16ASoC: soc-component: remove pcm_construct()/pcm_destruct()Kuninori Morimoto1-4/+0
All driver have switched to use pcm_new()/pcm_free(), let's remove pcm_construct()/pcm_destruct(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/875x6wjyoa.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16ASoC: soc-component: re-add pcm_new()/pcm_free()Kuninori Morimoto1-0/+4
Because old pcm_new()/pcm_free() didn't care about parameter component, to avoid name collisions, we have added pcm_construct()/pcm_destruct() by commit c64bfc9066007 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") Because all driver switch to new pcm_construct()/pcm_destruct(), old pcm_new()/pcm_free() were remoted by commit e9067bb502787 ("ASoC: soc-component: remove snd_pcm_ops from component driver") But naming of pcm_construct()/pcm_destruct() are not goot. re-add pcm_new()/pcm_free(), and switch to use it, again. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87a4w8lde4.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16ASoC: codec: arizona: Convert to use GPIO descriptorsLinus Walleij1-10/+0
This converts the Arizona driver to use GPIO descriptors exclusively, deletes the legacy code path an updates the in-tree user of legacy GPIO. The GPIO lines for mic detect polarity and headphone ID detection are made exclusively descriptor-oriented. The headphone ID detection could actually only be used by the legacy GPIO code, but I converted it to use a descriptor if someone would actually need it so we don't just drop useful code. The compatible "wlf,hpdet-id-gpio" is not in the device tree bindings and only intended to be used by software nodes if any. If someone insists I can try to add a binding for it, but I doubt there is any real user so it seems pointless. Signed-off-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260314-asoc-arizona-v1-1-ecc9a165307c@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16locking: Add lock context support in do_raw_{read,write}_trylock()Bart Van Assche1-2/+12
Convert do_raw_{read,write}_trylock() from macros into inline functions and annotate these inline functions with __cond_acquires_shared() or __cond_acquires() as appropriate. This change is necessary to build kernel drivers or subsystems that use rwlock synchronization objects with lock context analysis enabled. The return type 'int' matches the return type for CONFIG_DEBUG_SPINLOCK=y. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260313171510.230998-3-bvanassche@acm.org
2026-03-16locking: Fix rwlock support in <linux/spinlock_up.h>Bart Van Assche1-10/+10
Architecture support for rwlocks must be available whether or not CONFIG_DEBUG_SPINLOCK has been defined. Move the definitions of the arch_{read,write}_{lock,trylock,unlock}() macros such that these become visbile if CONFIG_DEBUG_SPINLOCK=n. This patch prepares for converting do_raw_{read,write}_trylock() into inline functions. Without this patch that conversion triggers a build failure for UP architectures, e.g. arm-ep93xx. I used the following kernel configuration to build the kernel for that architecture: CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=n CONFIG_ATAGS=y CONFIG_MMU=y CONFIG_ARCH_MULTI_V4T=y CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_ARCH_EP93XX=y Fixes: fb1c8f93d869 ("[PATCH] spinlock consolidation") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260313171510.230998-2-bvanassche@acm.org
2026-03-16cleanup: Optimize guardsPeter Zijlstra1-8/+11
Andrew reported that a guard() conversion of zone_lock increased the code size unnecessarily. It turns out the unconditional __GUARD_IS_ERR() is to blame. As explored earlier [1], __GUARD_IS_ERR(), similar to IS_ERR_OR_NULL(), generates somewhat sub-optimal code. However, looking at things again, it is possible to avoid doing the __GUARD_IS_ERR() unconditionally. Revert the normal destructors to a simple NULL test and only add the IS_ERR bit to COND guards. This cures the reported overhead; as compiled by GCC-16: page_alloc.o: pre: Total: Before=45299, After=45371, chg +0.16% post: Total: Before=45299, After=45026, chg -0.60% [1] https://lkml.kernel.org/r/20250513085001.GC25891@noisy.programming.kicks-ass.net Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Dan Williams <dan.j.williams@intel.com> Link: https://patch.msgid.link/20260309164516.GE606826@noisy.programming.kicks-ass.net
2026-03-16jump_label: remove workaround for old compilers in initializationsThomas Weißschuh1-9/+2
The extra braces for the initialization of the anonymous union members were added in commit cd8d860dcce9 ("jump_label: Fix anonymous union initialization") to compensate for limitations in gcc < 4.6. Versions of gcc this old are not supported anymore, so drop the workaround. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260313-jump_label-cleanup-v2-2-35d3c0bde549@linutronix.de
2026-03-16jump_label: use ATOMIC_INIT() for initialization of .enabledThomas Weißschuh1-9/+2
Currently ATOMIC_INIT() is not used because in the past that macro was provided by linux/atomic.h which is not usable from linux/jump_label.h. However since commit 7ca8cf5347f7 ("locking/atomic: Move ATOMIC_INIT into linux/types.h") the macro only requires linux/types.h. Remove the now unnecessary workaround and the associated assertions. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260313-jump_label-cleanup-v2-1-35d3c0bde549@linutronix.de
2026-03-16Merge 7.0-rc4 into usb-nextGreg Kroah-Hartman78-285/+569
We need the USB fixes in this branch as well to build on top of Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-16gpio: kempld: Implement the interrupt controllerAlban Bedel1-0/+1
Add a GPIO IRQ chip implementation for the kempld GPIO controller. Of note is only how the parent IRQ is obtained. The IRQ for the GPIO controller can be configured in the BIOS, along with the IRQ for the I2C controller. These IRQ are returned by ACPI but this information is only usable if both IRQ are configured. When only one is configured, only one is returned making it impossible to know which one it is. Luckily the BIOS will set the configured IRQ in the PLD registers, so it can be read from there instead, and that also work on platforms without ACPI. The vendor driver allowed to override the IRQ using a module parameters, so there are boards in field which used this parameter instead of properly configuring the BIOS. This implementation provides this as well for compatibility. Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de> Link: https://patch.msgid.link/20260311143120.2179347-5-alban.bedel@lht.dlh.de Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-03-16drm/{i915,xe}: move framebuffer bo to parent interfaceJani Nikula1-0/+6
Add .framebuffer_init, .framebuffer_fini and .framebuffer_lookup to the bo parent interface. While they're about framebuffers, they're specifically about framebuffer objects, so the bo interface is a good enough fit, and there's no need to add another interface struct. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/848d32a44bf844cba3d66e44ba9f20bea4a8352d.1773238670.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-16drm/{i915, xe}/bo: move display bo calls to parent interfaceJani Nikula1-0/+16
Continue i915 and xe separation from display by moving the bo calls to the display parent interface. Instead of adding all these functions to intel_parent.[ch], reuse the now vacated intel_bo.[ch], and avoid mass renames to calls of these functions. This is similar to intel_display_rpm.[ch]. Make many of the hooks optional to avoid having to implement dummy functions in xe. Indeed now we can remove many of the existing dummy functions. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/7899eef2ccf0cd603df69099df065226a0df917b.1773238670.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-16gpio: remove machine hogsBartosz Golaszewski1-33/+0
With no more users, remove legacy machine hog API from the kernel. Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260309-gpio-hog-fwnode-v2-5-4e61f3dbf06a@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-03-16Merge tag 'amd-drm-next-7.1-2026-03-12' of ↵Dave Airlie1-0/+2
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.1-2026-03-12: amdgpu: - SMU13 fix - SMU14 fix - Fixes for bring up hw testing - Kerneldoc fix - GC12 idle power fix for compute workloads - DCCG fixes - UserQ fixes - Move test for fbdev object to a generic helper - GC 12.1 updates - Use struct drm_edid in non-DC code - Include IP discovery data in devcoredump - SMU 13.x updates - Misc cleanups - DML 2.1 fixes - Enable NV12/P010 support on primary planes - Enable color encoding and color range on overlay planes - DC underflow fixes - HWSS fast path fixes - Replay fixes - DCN 4.2 updates - Support newer IP discovery tables - LSDMA 7.1 support - IH 7.1 fixes - SoC v1 updates - GC12.1 updates - PSP 15 updates - XGMI fixes - GPUVM locking fix amdkfd: - Fix missing BO unreserve in an error path radeon: - Move test for fbdev object to a generic helper From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260312184425.3875669-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-03-16dt-bindings: arm: qcom,ids: add SOC IDs for IPQ5210 familyKathiravan Thirumoorthy1-0/+5
SoCs based on IPQ5210 is shipped under two different naming schemes namely IPQ52xx and QCF2xxx/QCF3xxx. In the later variants Passive Optical Network (PON) interface acts as the backhaul where as in the former it is ethernet backhaul. Document the same. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260313-b4-ipq5210_soc_ids-v1-1-97faae3fef95@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16Merge tag 'drm-xe-next-2026-03-12' of ↵Dave Airlie5-0/+278
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next UAPI Changes: - add VM_BIND DECOMPRESS support and on-demand decompression (Nitin) - Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13 (Lionel) Cross-subsystem Changes: - Introduce the DRM RAS infrastructure over generic netlink (Riana, Rodrigo) Core Changes: - Two-pass MMU interval notifiers (Thomas) Driver Changes: - Merge drm/drm-next into drm-xe-next (Brost) - Fix overflow in guc_ct_snapshot_capture (Mika, Fixes) - Extract gt_pta_entry (Gustavo) - Extra enabling patches for NVL-P (Gustavo) - Add Wa_14026578760 (Varun) - Add type-specific GT loop iterator (Roper) - Refactor xe_migrate_prepare_vm (Raag) - Don't disable GuCRC in suspend path (Vinay, Fixes) - Add missing kernel docs in xe_exec_queue.c (Niranjana) - Change TEST_VRAM to work with 32-bit resource_size_t (Wajdeczko) - Fix memory leak in xe_vm_madvise_ioctl (Varun, Fixes) - Skip access counter queue init for unsupported platforms (Himal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/abLUVfSHu8EHRF9q@lstrano-desk.jf.intel.com
2026-03-16Merge branch '20260309230346.3584252-2-daniel.lezcano@oss.qualcomm.com' into ↵Bjorn Andersson1-0/+12
drivers-for-7.1 Merge the relocated constants through a topic branch, to allow this change being shared with other trees.
2026-03-16soc: qcom: qmi: Enumerate the service IDs of QMIDaniel Lezcano1-0/+12
The QMI framework proposes a set of services which are defined by an integer identifier. The different QMI client lookup for the services via this identifier. Moreover, the function qmi_add_lookup() and qmi_add_server() must match the service ID but the code in different places set the same value but with a different macro name. These macros are spreaded across the different subsystems implementing the protocols associated with a service. It would make more sense to define them in the QMI header for the sake of consistency and clarity. This change use an unified naming for the services and enumerate the ones implemented in the Linux kernel. More services can come later and put the service ID in this same header. Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260309230346.3584252-2-daniel.lezcano@oss.qualcomm.com [bjorn: Lower case hex constants] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_eiMukesh Ojha1-0/+1
It looks element length declared in servreg_loc_pfr_req_ei for reason not matching servreg_loc_pfr_req's reason field due which we could observe decoding error on PD crash. qmi_decode_string_elem: String len 81 >= Max Len 65 Fix this by matching with servreg_loc_pfr_req's reason field. Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation") Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20260129152320.3658053-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16soc: qcom: llcc: Add per-slice counter and common llcc slice descriptorUnnathi Chalicheemala1-4/+4
Fix incorrect slice activation/deactivation accounting by replacing the bitmap-based activation tracking with per-slice atomic reference counters. This resolves mismatches that occur when multiple client drivers vote for the same slice or when llcc_slice_getd() is called multiple times. As part of this fix, simplify slice descriptor handling by eliminating dynamic allocation. llcc_slice_getd() now returns a pointer to a preallocated descriptor, removing the need for repeated allocation/free cycles and ensuring consistent reference tracking across all users. Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> Signed-off-by: Francisco Munoz Ruiz <francisco.ruiz@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-external_llcc_changes1set-v1-1-6347e52e648e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16dt-bindings: arm: qcom,ids: Add SoC IDs for SM7450 and SM7450PAelin Reidel1-0/+2
SM7450 and SM7450P are two SoCs of the 'fillmore' family. Signed-off-by: Aelin Reidel <aelin@mainlining.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260302-fillmore-socids-v2-1-e6c5ad167ec4@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-16ASoC: basic support for configuring bus keepersMark Brown1-0/+22
James Calligeros <jcalligeros99@gmail.com> says: This series introduces some infrastructure to allow platform drivers to specify what a DAI should be doing when it is not active on the bus. The primary use case for this is configuring bus keepers which may be integrated into various codecs. The instigating use case for this functionality is an interesting bus topology on Apple Silicon laptops with multiple codecs. Most Apple Silicon laptops have six codecs split into groups of three, driving a pair of dual opposed woofers and a tweeter for L/R stereo sound. These codecs report the voltage and current across their connected voice coils back to the SoC via the SDOUT pin, represented as PCM data sent via configurable TDM slots. This data is used in conjunction with the connected speaker's Thiele/Small Parameters to ensure that the speaker is not being driven to levels that would permanently damage them. This is integrated into CoreAudio on macOS. speakersafetyd[1] handles this for Linux. All of the codec SDOUT pins are attached to a single receiver port on the SoC's I2S peripheral, however are split across two physical data lines (one each for the left and right codec groups). The receiver has an OR gate in front of it, which is used to sum the two lines. If at any point a codec is trying to transmit data, and the "opposite" line ends up floating high, the transmitting codec's data will be corrupted. We need to guarantee that the idle line stays idle. In the downstream Asahi Linux kernel[2], we set up one codec in each group to zero-fill or pull down its line while a codec on the opposite line is actively transmitting. This is done entirely in the codec driver, however this approach is over-fit for this one use case. This sort of functionality may also be of use for other hardware, so following previous mailing list discussions[3], I have tried to expose the functionality in a more configurable and generic way. I have integrated this approach into our downstream platform driver and select Devicetrees as an example of how this mechanism is intended to be used[4]. [1] https://github.com/AsahiLinux/speakersafetyd [2] https://github.com/AsahiLinux/linux/tree/bits/070-audio [3] https://lore.kernel.org/asahi/20250227-apple-codec-changes-v3-17-cbb130030acf@gmail.com/ [4] https://github.com/chadmed/tree/tdm-revised2 Link: https://patch.msgid.link/20260301-tdm-idle-slots-v3-0-c6ac5351489a@gmail.com
2026-03-16ASoC: soc-dai: add common operation to set TDM idle modeJames Calligeros1-0/+7
Some audio devices, like certain Texas Instruments codecs, integrate configurable bus keepers that dictate the codec's behaviour during idle TDM slots. Now that we have definitions for various idle modes, add a snd_soc_dai_set_tdm_idle() operation to control this in a standardised way. This is useful on Apple Silicon laptops, where a single I2S bus is comprised of two physical lines which are ORed just before the receiving port. When a codec on one line is transmitting, we must guarantee that the other line is low. We can achieve this by configuring one codec on each line to use its bus keeper to fill its line with zeroes during the active slots of the other line. Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Link: https://patch.msgid.link/20260301-tdm-idle-slots-v3-5-c6ac5351489a@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16ASoC: soc-dai: define possible idle TDM slot modesJames Calligeros1-0/+15
Some audio devices, such as certain Texas Instruments codecs, include configurable bus keepers. We currently don't have a standardised way to configure such hardware, and instead rely on the hardware initialising setting itself up into a sane state. There are situations where this is insufficient, however, and some platforms require more concrete guarantees as to the state of the bus, and being able to explicitly configure bus keepers enables this. For example, some Apple Silicon machines have an odd bus topology where the SDOUT pins of all codecs are split across two data lines, which are summed via an OR gate in front of the receiving port on the SoC's I2S peripheral. Each line must transmit 0 while a codec on the other line is actively transmitting data, or the SoC will receive garbage data. To do this, one codec on each line must be configured to transmit zeroes during the other line's active TDM slots. Thus, we define seven possible bus-keeping modes that a device can be in: NONE (UB/as initialised), OFF (explicitly disabled), ZERO (actively transmit a 0), PULLDOWN, HIZ (floating), PULLUP, and DRIVE_HIGH. These will be consumed by CODEC/CPU drivers via a common DAI op, enabling the explicit configuration of bus keepers where required. Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Link: https://patch.msgid.link/20260301-tdm-idle-slots-v3-4-c6ac5351489a@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-16ASoC: amd: Move to GPIO descriptorsMark Brown18-88/+148
Linus Walleij <linusw@kernel.org> says: After a quick look and test-compile I can determine that all of these drivers include <linux/gpio.h> for no reason whatsoever, so fixing it is low hanging fruit. Link: https://patch.msgid.link/20260314-asoc-amd-v1-0-31afed06e022@kernel.org
2026-03-15Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds2-48/+43
Pull kvm fixes from Paolo Bonzini: "Quite a large pull request, partly due to skipping last week and therefore having material from ~all submaintainers in this one. About a fourth of it is a new selftest, and a couple more changes are large in number of files touched (fixing a -Wflex-array-member-not-at-end compiler warning) or lines changed (reformatting of a table in the API documentation, thanks rST). But who am I kidding---it's a lot of commits and there are a lot of bugs being fixed here, some of them on the nastier side like the RISC-V ones. ARM: - Correctly handle deactivation of interrupts that were activated from LRs. Since EOIcount only denotes deactivation of interrupts that are not present in an LR, start EOIcount deactivation walk *after* the last irq that made it into an LR - Avoid calling into the stubs to probe for ICH_VTR_EL2.TDS when pKVM is already enabled -- not only thhis isn't possible (pKVM will reject the call), but it is also useless: this can only happen for a CPU that has already booted once, and the capability will not change - Fix a couple of low-severity bugs in our S2 fault handling path, affecting the recently introduced LS64 handling and the even more esoteric handling of hwpoison in a nested context - Address yet another syzkaller finding in the vgic initialisation, where we would end-up destroying an uninitialised vgic with nasty consequences - Address an annoying case of pKVM failing to boot when some of the memblock regions that the host is faulting in are not page-aligned - Inject some sanity in the NV stage-2 walker by checking the limits against the advertised PA size, and correctly report the resulting faults PPC: - Fix a PPC e500 build error due to a long-standing wart that was exposed by the recent conversion to kmalloc_obj(); rip out all the ugliness that led to the wart RISC-V: - Prevent speculative out-of-bounds access using array_index_nospec() in APLIC interrupt handling, ONE_REG regiser access, AIA CSR access, float register access, and PMU counter access - Fix potential use-after-free issues in kvm_riscv_gstage_get_leaf(), kvm_riscv_aia_aplic_has_attr(), and kvm_riscv_aia_imsic_has_attr() - Fix potential null pointer dereference in kvm_riscv_vcpu_aia_rmw_topei() - Fix off-by-one array access in SBI PMU - Skip THP support check during dirty logging - Fix error code returned for Smstateen and Ssaia ONE_REG interface - Check host Ssaia extension when creating AIA irqchip x86: - Fix cases where CPUID mitigation features were incorrectly marked as available whenever the kernel used scattered feature words for them - Validate _all_ GVAs, rather than just the first GVA, when processing a range of GVAs for Hyper-V's TLB flush hypercalls - Fix a brown paper bug in add_atomic_switch_msr() - Use hlist_for_each_entry_srcu() when traversing mask_notifier_list, to fix a lockdep warning; KVM doesn't hold RCU, just irq_srcu - Ensure AVIC VMCB fields are initialized if the VM has an in-kernel local APIC (and AVIC is enabled at the module level) - Update CR8 write interception when AVIC is (de)activated, to fix a bug where the guest can run in perpetuity with the CR8 intercept enabled - Add a quirk to skip the consistency check on FREEZE_IN_SMM, i.e. to allow L1 hypervisors to set FREEZE_IN_SMM. This reverts (by default) an unintentional tightening of userspace ABI in 6.17, and provides some amount of backwards compatibility with hypervisors who want to freeze PMCs on VM-Entry - Validate the VMCS/VMCB on return to a nested guest from SMM, because either userspace or the guest could stash invalid values in memory and trigger the processor's consistency checks Generic: - Remove a subtle pseudo-overlay of kvm_stats_desc, which, aside from being unnecessary and confusing, triggered compiler warnings due to -Wflex-array-member-not-at-end - Document that vcpu->mutex is take outside of kvm->slots_lock and kvm->slots_arch_lock, which is intentional and desirable despite being rather unintuitive Selftests: - Increase the maximum number of NUMA nodes in the guest_memfd selftest to 64 (from 8)" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (43 commits) KVM: selftests: Verify SEV+ guests can read and write EFER, CR0, CR4, and CR8 Documentation: kvm: fix formatting of the quirks table KVM: x86: clarify leave_smm() return value selftests: kvm: add a test that VMX validates controls on RSM selftests: kvm: extract common functionality out of smm_test.c KVM: SVM: check validity of VMCB controls when returning from SMM KVM: VMX: check validity of VMCS controls when returning from SMM KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated KVM: SVM: Initialize AVIC VMCB fields if AVIC is enabled with in-kernel APIC KVM: x86: Introduce KVM_X86_QUIRK_VMCS12_ALLOW_FREEZE_IN_SMM KVM: x86: Fix SRCU list traversal in kvm_fire_mask_notifiers() KVM: VMX: Fix a wrong MSR update in add_atomic_switch_msr() KVM: x86: hyper-v: Validate all GVAs during PV TLB flush KVM: x86: synthesize CPUID bits only if CPU capability is set KVM: PPC: e500: Rip out "struct tlbe_ref" KVM: PPC: e500: Fix build error due to using kmalloc_obj() with wrong type KVM: selftests: Increase 'maxnode' for guest_memfd tests KVM: arm64: pkvm: Don't reprobe for ICH_VTR_EL2.TDS on CPU hotplug KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tail KVM: arm64: Remove the redundant ISB in __kvm_at_s1e2() ...
2026-03-15Merge tag 'sched-urgent-2026-03-15' of ↵Linus Torvalds2-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: "More MM-CID fixes, mostly fixing hangs/races: - Fix CID hangs due to a race between concurrent forks - Fix vfork()/CLONE_VM MMCID bug causing hangs - Remove pointless preemption guard - Fix CID task list walk performance regression on large systems by removing the known-flaky and slow counting logic using for_each_process_thread() in mm_cid_*fixup_tasks_to_cpus(), and implementing a simple sched_mm_cid::node list instead" * tag 'sched-urgent-2026-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/mmcid: Avoid full tasklist walks sched/mmcid: Remove pointless preempt guard sched/mmcid: Handle vfork()/CLONE_VM correctly sched/mmcid: Prevent CID stalls due to concurrent forks
2026-03-15PCI: endpoint: Introduce pci_epc_bar_type BAR_DISABLEDNiklas Cassel1-1/+9
Add a pci_epc_bar_type BAR_DISABLED to more clearly differentiate from BAR_RESERVED. This BAR type will only be used to describe a BAR that the EPC driver should disable, and will thus never be available to an EPF driver. (Unlike BAR_RESERVED, which will never be disabled by default by an EPC driver.) Co-developed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Koichiro Den <den@valinux.co.jp> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Link: https://patch.msgid.link/20260312130229.2282001-17-cassel@kernel.org
2026-03-15PCI: endpoint: Describe reserved subregions within BARsKoichiro Den1-0/+28
Some endpoint controllers expose platform-owned, fixed register windows within a BAR that EPF drivers must not reprogram (e.g. a BAR marked BAR_RESERVED). Even in that case, EPF drivers may need to reference a well-defined subset of that BAR, e.g. to reuse an integrated DMA controller MMIO window as a doorbell target. Introduce struct pci_epc_bar_rsvd_region and extend struct pci_epc_bar_desc so EPC drivers can advertise such fixed subregions in a controller-agnostic way. No functional change for existing users. Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-15-cassel@kernel.org
2026-03-15PCI: endpoint: Allow only_64bit on BAR_RESERVEDManikanta Maddireddy1-5/+0
Remove the documentation that forbids setting only_64bit on a BAR of type BAR_RESERVED. When a reserved BAR is 64-bit by default, setting only_64bit is the most accurate description. If we later add support to disable a reserved BAR (e.g. disable_bar() for BARs that were never set via set_bar()), the implementation will need to clear the adjacent BAR (upper 32 bits) as well; having only_64bit set documents that requirement. Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260312130229.2282001-14-cassel@kernel.org
2026-03-15PCI: endpoint: Do not mark the BAR succeeding a 64-bit BAR as BAR_RESERVEDNiklas Cassel1-2/+1
A BAR that can only be configured as a 64-bit BAR by an EPC driver is marked as such using the "only_64bit" flag. Currently, the documentation says that an EPC driver should explicitly mark the BAR succeeding an "only_64bit" BAR as BAR_RESERVED. However, a 64-bit BAR will always take up two BARs. It is thus redundant to mark both BARs. pci_epc_get_next_free_bar() already skips the BAR succeeding a "only_64bit" BAR, regardless if the succeeding BAR is marked as BAR_RESERVED or not. Thus, drop the BAR_RESERVED for a BAR succeeding a "only_64bit" BAR. No functional changes. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260312130229.2282001-13-cassel@kernel.org
2026-03-14net/mlx5: Add a shared devlink instance for PFs on same chipJiri Pirko1-0/+1
Use the previously introduced shared devlink infrastructure to create a shared devlink instance for mlx5 PFs that reside on the same physical chip. The shared instance is identified by the chip's serial number extracted from PCI VPD (V3 keyword, with fallback to serial number for older devices). Each PF that probes calls mlx5_shd_init() which extracts the chip serial number and uses devlink_shd_get() to get or create the shared instance. When a PF is removed, mlx5_shd_uninit() calls devlink_shd_put() to release the reference. The shared instance is automatically destroyed when the last PF is removed. Make the PF devlink instances nested in this shared devlink instance, allowing userspace to identify which PFs belong to the same physical chip. Example: pci/0000:08:00.0: index 0 nested_devlink: auxiliary/mlx5_core.eth.0 devlink_index/1: index 1 nested_devlink: pci/0000:08:00.0 pci/0000:08:00.1 auxiliary/mlx5_core.eth.0: index 2 pci/0000:08:00.1: index 3 nested_devlink: auxiliary/mlx5_core.eth.1 auxiliary/mlx5_core.eth.1: index 4 Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260312100407.551173-14-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14devlink: introduce shared devlink instance for PFs on same chipJiri Pirko1-0/+7
Multiple PFs may reside on the same physical chip, running a single firmware. Some of the resources and configurations may be shared among these PFs. Currently, there is no good object to pin the configuration knobs on. Introduce a shared devlink instance, instantiated upon probe of the first PF and removed during remove of the last PF. The shared devlink instance is not backed by any device device, as there is no PCI device related to it. The implementation uses reference counting to manage the lifecycle: each PF that probes calls devlink_shd_get() to get or create the shared instance, and calls devlink_shd_put() when it removes. The shared instance is automatically destroyed when the last PF removes. Example: pci/0000:08:00.0: index 0 nested_devlink: auxiliary/mlx5_core.eth.0 devlink_index/1: index 1 nested_devlink: pci/0000:08:00.0 pci/0000:08:00.1 auxiliary/mlx5_core.eth.0: index 2 pci/0000:08:00.1: index 3 nested_devlink: auxiliary/mlx5_core.eth.1 auxiliary/mlx5_core.eth.1: index 4 Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260312100407.551173-12-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14devlink: add devlink_dev_driver_name() helper and use it in trace eventsJiri Pirko2-6/+7
In preparation to dev-less devlinks, add devlink_dev_driver_name() that returns the driver name stored in devlink struct, and use it in all trace events. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260312100407.551173-9-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14devlink: support index-based lookup via bus_name/dev_name handleJiri Pirko1-0/+2
Devlink instances without a backing device use bus_name "devlink_index" and dev_name set to the decimal index string. When user space sends this handle, detect the pattern and perform a direct xarray lookup by index instead of iterating all instances. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260312100407.551173-6-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14devlink: add helpers to get bus_name/dev_nameJiri Pirko2-12/+14
Introduce devlink_bus_name() and devlink_dev_name() helpers and convert all direct accesses to devlink->dev->bus->name and dev_name(devlink->dev) to use them. This prepares for dev-less devlink instances where these helpers will be extended to handle the missing device. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260312100407.551173-3-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14devlink: expose devlink instance index over netlinkJiri Pirko1-0/+2
Each devlink instance has an internally assigned index used for xarray storage. Expose it as a new DEVLINK_ATTR_INDEX uint attribute alongside the existing bus_name and dev_name handle. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260312100407.551173-2-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14net: phy: move remaining provider code to mdio_bus_provider.cHeiner Kallweit1-3/+0
This moves definition of mdio_bus class and bus_type to the provider side, what allows to make them private to libphy. As a prerequisite MDIO statistics handling is moved to the provider side as well. Note: This patch causes a checkpatch error "Macros with complex values should be enclosed in parentheses" for MDIO_BUS_STATS_ADDR_ATTR_GROUP. I consider this a false positive here, in addition the patch just moves existing code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/47b85676-b349-4aa0-a5ef-cd37769a4c69@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14net: phy: make mdio_device.c part of libphyHeiner Kallweit1-2/+0
This patch - makes mdio_device.c part of libphy - makes mdio_device_(un)register_reset() static - moves mdiobus_(un)register_device() from mdio_bus.c to mdio_device.c, stops exporting both functions and makes them private to phylib This further decouples the MDIO consumer functionality from libphy. Note: This makes MDIO driver registration part of phylib, therefore adjust Kconfig dependencies where needed. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/c6dbf9b3-3ca0-434b-ad3a-71fe602ab809@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-14Merge tag 'usb-7.0-rc4' of ↵Linus Torvalds2-2/+9
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here is a large chunk of USB driver fixes for 7.0-rc4. Included in here are: - usb gadget reverts due to reported issues, and then a follow-on fix to hopefully resolve the reported overall problem - xhci driver fixes - dwc3 driver fixes - usb core "killable" bulk message api addition to fix a usbtmc driver bug where userspace could hang the driver for forever - small USB driver fixes for reported issues - new usb device quirks All except the last USB device quirk change have been in linux-next with no reported issues. That one came in too late, and is 'obviously correct' :)" * tag 'usb-7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (35 commits) USB: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed usb: roles: get usb role switch from parent only for usb-b-connector Revert "tcpm: allow looking for role_sw device in the main node" usb: gadget: f_ncm: Fix net_device lifecycle with device_move Revert "usb: gadget: u_ether: add gether_opts for config caching" Revert "usb: gadget: u_ether: use <linux/hex.h> header file" Revert "usb: gadget: u_ether: Add auto-cleanup helper for freeing net_device" Revert "usb: gadget: f_ncm: align net_device lifecycle with bind/unbind" Revert "usb: legacy: ncm: Fix NPE in gncm_bind" Revert "usb: gadget: f_ncm: Fix atomic context locking issue" usb: typec: altmode/displayport: set displayport signaling rate in configure message usb: dwc3: pci: add support for the Intel Nova Lake -H usb/core/quirks: Add Huawei ME906S-device to wakeup quirk usb: gadget: uvc: fix interval_duration calculation xhci: Fix NULL pointer dereference when reading portli debugfs files usb: xhci: Prevent interrupt storm on host controller error (HCE) usb: xhci: Fix memory leak in xhci_disable_slot() usb: class: cdc-wdm: fix reordering issue in read code path usb: renesas_usbhs: fix use-after-free in ISR during device removal usb: cdc-acm: Restore CAP_BRK functionnality to CH343 ...
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-13 04:57:39 +0300