summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-12-15spi: dt-bindings: st,stm32-spi: add 'power-domains' propertyAlain Volmat
STM32 SPI may be in a power domain which is the case for the STM32MP2x based boards. Allow a single 'power-domains' entry for STM32 SPI. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20251215-stm32-spi-mp2x-dt-updates-v1-1-464a5fd20f13@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: hda: Only check SSP MCLK mask in case of IPC3Peter Ujfalusi
IPC4 is using the NHLT blob itself and sends the SSP blob from it directly to the firmware, there is no need for the MCLK quirk based on the SSP blob since the SSP blob is in use. At the same time reword the error, info and debug messages for clarity. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Balamurugan C <balamurugan.c@intel.com> Link: https://patch.msgid.link/20251215130819.31218-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: Fix acronym for Intel Gemini LakeAndy Shevchenko
While the used GML is consistent with the pattern for other Intel * Lake SoCs, the de facto use is GLK. Update the acronym and users accordingly. Note, a handful of the drivers for Gemini Lake in the Linux kernel use GLK already (LPC, MEI, pin control, SDHCI, ...) and even some in ASoC. The only ones in this patch used the inconsistent one. Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20251212181742.3944789-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: Intel: soc-acpi-intel-nvl-match: Drop rt722 l3 from the match tablePeter Ujfalusi
Revert "ASoC: Intel: soc-acpi-intel-nvl-match: add rt722 l3 support" NVL should be only using functional topologies for products, no monolithic topologies are planned to be released. In parallel a feature has been landed [1] which allows to remove the entries from the match table for sdca codecs to rely solely on function fragments. This reverts commit 41566e3de40616375e8dfe5455344558b79f9354. Link: https://lore.kernel.org/linux-sound/20251014071335.3844631-1-yung-chuan.liao@linux.intel.com/ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20251215101036.9370-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: soc-acpi / SOF: Add best_effort flag to get_function_tplg_files opPeter Ujfalusi
When there is no fallback possibility available for the function topology use it is better to try to create a profile for the card in best effort manner, leaving out non supported links for example. As an example: some laptops present SSPx-BT link but we don't have fragment yet to support this. If we only have support for functional topology without monolithic fallback then we would fail the card creation. The reason why the monolithic topology works on the same device is that it does not have the SSPx-BT link handled, it is ignored. In case when there is no fallback possibility we should try to create the card with links that we support as best effort instead of failing and leaving the user without a card. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20251215101036.9370-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-nvl: Set on_demand_dsp_boot for NVL-SPeter Ujfalusi
NVL-S can be used with on-demand DSP booting, set the flag to enable it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20251215132946.2155-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-ptl: Set on_demand_dsp_boot for PTL and WCLPeter Ujfalusi
PTL and WCL can be used with on-demand DSP booting, set the flag to enable it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-lnl: Set on_demand_dsp_boot for LNLPeter Ujfalusi
LNL can be used with on-demand DSP booting, set the flag to enable it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: hda-sdw-bpt: Add support for on-demand DSP bootPeter Ujfalusi
If on-demand DSP boot is used we need to make sure that the DSP is booted up - which might not be the case - since we need ChainDMA in normal, non DSPless mode for the BRA to work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: sof-client: Add support for on-demand DSP bootPeter Ujfalusi
With the introduction of on-demand DSP boot the rpm status not necessary tells that the DSP firmware is booted up. Introduce the sof_client_boot_dsp() which can be used to make sure that the DSP is booted and it can handle IPCs. Update the client drivers to use the new function where it is expected that the DSP is booted up. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Add support for on-demand DSP bootPeter Ujfalusi
On system suspend / resume we always power up the DSP and boot the firmware, which is not strictly needed as right after the firmware booted up we power the DSP down again on suspend and we also power it down after resume after some inactivity. Out of caution, add a new platform descriptor flag to enable on-demand DSP boot since this might not work without changes to platform code on certain platforms. With the on-demand dsp boot enabled we will not boot the DSP and firmware up on system or rpm resume, just enable audio subsystem since audio IPs, like HDA and SoundWire might be needed (codecs suspend/resume operation). Only boot up the DSP during the first hw_params() call when the DSP is really going to be needed. In this way we can handle the audio related use cases: normal audio use (rpm suspend/resume) system suspend/resume without active audio system suspend/resume with active audio system suspend/resume without active audio, and audio start before the rpm suspend timeout Add module option to force the on-demand DSP boot to allow it to be disabled or enabled without kernel change for testing. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: control: skip rpm calls in ext_volatile_get if not implementedPeter Ujfalusi
Test earlier for the existence of ext_volatile_get callback and if it is missing, skip the rpm calls to avoid needles DSP power on. No change in functionality, we just skip the DSP power on in the unlikely case when the ext_volatile _get is not supported and yet the topology adds such control. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: ipc4-loader: Remove redundant rpm resume_and_get from load_libraryPeter Ujfalusi
The initial library loading is happening during topology loading, which is already protected with pm_runtime_resume_and_get() via pcm.c The redundant rpm code can be dropped from sof_ipc4_load_library() Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-mtl: Change the topology path to intel/sof-ipc4-tplgPeter Ujfalusi
The default topology path for IPC4 is intel/sof-ipc4-tplg with a symlink to it as intel/sof-ace-tplg to support old kernels. sof-bin has been released in this manner for almost two years now, it is time to change the default path for MTL family. Link: https://thesofproject.github.io/latest/getting_started/intel_debug/introduction.html#topology-file Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20251215130805.31146-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: ipc4-topology: set playback channel maskBard Liao
Currently, we send all channels to all amps and copy the channel_mask to all ALH DMAs in playback. However, the amp may not have the capability to run any process and SOF may need to split the channels and send specific data channel to each amp. In that case, we need to split the channel_mask in ALH DMA. Copy the channel mask only if the widget channel count is the same the FE channels for playback, otherwise, split the channels among the aggregated DAIs. Like what we did in capture. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/20251215130723.31081-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: topology: Add context when sink or source widget is missingPeter Ujfalusi
Add some context to the error prints when sink or source widget is not found by printing the name of the other side of the connection. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20251215130741.31106-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15fs/buffer: add alert in try_to_free_buffers() for folios without buffersDeepakkumar Karn
try_to_free_buffers() can be called on folios with no buffers attached when filemap_release_folio() is invoked on a folio belonging to a mapping with AS_RELEASE_ALWAYS set but no release_folio operation defined. In such cases, folio_needs_release() returns true because of the AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This causes try_to_free_buffers() to call drop_buffers() on a folio with no buffers, leading to a null pointer dereference. Adding a check in try_to_free_buffers() to return early if the folio has no buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration. This provides defensive hardening. Signed-off-by: Deepakkumar Karn <dkarn@redhat.com> Link: https://patch.msgid.link/20251211131211.308021-1-dkarn@redhat.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15ASoC: SOF: ipc4-topology: Convert FLOAT to S32 during blob selectionPeter Ujfalusi
SSP/DMIC blobs have no support for FLOAT type, they are using S32 on data bus. Convert the format from FLOAT_LE to S32_LE to make sure that the correct format is used within the path. FLOAT conversion will be done on the host side (or within the path). Fixes: f7c41911ad74 ("ASoC: SOF: ipc4-topology: Add support for float sample type") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20251215120648.4827-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: ipc4-topology: Prefer 32-bit DMIC blobs for 8-bit formats as wellPeter Ujfalusi
With the introduction of 8-bit formats the DMIC blob lookup also needs to be modified to prefer the 32-bit blob when 8-bit format is used on FE. At the same time we also need to make sure that in case 8-bit format is used, but only 16-bit blob is available for DMIC then we will not try to look for 8-bit blob (which is invalid) as fallback, but for a 16-bit one. Fixes: c04c2e829649 ("ASoC: SOF: ipc4-topology: Add support for 8-bit formats") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20251215120648.4827-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15platform/x86/uniwill: Add TUXEDO Book BA15 Gen10Werner Sembach
Add TUXEDO Book BA15 Gen10 to the list of supported devices of the Uniwill driver. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://patch.msgid.link/20251212180319.712913-1-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15platform/x86: alienware-wmi-wmax: Add support for Alienware 16X AuroraKurt Borja
Add AWCC support for Alienware 16X Aurora laptops. Cc: stable@vger.kernel.org Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20251205-area-51-v1-3-d2cb13530851@gmail.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16Kurt Borja
Add AWCC support for Alienware x16 laptops. Cc: stable@vger.kernel.org Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20251205-area-51-v1-2-d2cb13530851@gmail.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptopsKurt Borja
Add AWCC support for new Alienware Area-51 laptops. Cc: stable@vger.kernel.org Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20251205-area-51-v1-1-d2cb13530851@gmail.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15selftests: netfilter: packetdrill: avoid failure on HZ=100 kernelFlorian Westphal
packetdrill --ip_version=ipv4 --mtu=1500 --tolerance_usecs=1000000 --non_fatal packet conntrack_syn_challenge_ack.pkt conntrack v1.4.8 (conntrack-tools): 1 flow entries have been shown. conntrack_syn_challenge_ack.pkt:32: error executing `conntrack -f $NFCT_IP_VERSION \ -L -p tcp --dport 8080 | grep UNREPLIED | grep -q SYN_SENT` command: non-zero status 1 Affected kernel had CONFIG_HZ=100; reset packet was still sitting in backlog. Reported-by: Yi Chen <yiche@redhat.com> Fixes: a8a388c2aae4 ("selftests: netfilter: add packetdrill based conntrack tests") Signed-off-by: Florian Westphal <fw@strlen.de>
2025-12-15netfilter: nf_tables: avoid softlockup warnings in nft_chain_validateFlorian Westphal
This reverts commit 314c82841602 ("netfilter: nf_tables: can't schedule in nft_chain_validate"): Since commit a60a5abe19d6 ("netfilter: nf_tables: allow iter callbacks to sleep") the iterator callback is invoked without rcu read lock held, so this cond_resched() is now valid. Signed-off-by: Florian Westphal <fw@strlen.de>
2025-12-15netfilter: nf_tables: avoid chain re-validation if possibleFlorian Westphal
Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation. Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth. Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains. Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location. Reported-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Closes: https://lore.kernel.org/netfilter-devel/20251118221735.GA5477@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net/ Tested-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Signed-off-by: Florian Westphal <fw@strlen.de>
2025-12-15drm/rockchip: hdmi: add RK3368 controller variantHeiko Stuebner
The RK3368 has only one VOP, so there is no source selection happening and the controller uses an internal PHY for the HDMI output. Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Andy Yan <andyshrk@163.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251021074254.87065-3-heiko@sntech.de
2025-12-15dt-bindings: display: rockchip: dw-hdmi: Add compatible for RK3368 HDMIHeiko Stuebner
Define a new compatible for RK3368 HDMI. The RK3368 HDMI also uses a PHY internal to the controller, so works similar to other controllers, with the exception that the RK3368 only has one VOP, so there is no source selection needed. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251021074254.87065-2-heiko@sntech.de
2025-12-15fs: Remove internal old mount API codeEric Sandeen
Now that the last in-tree filesystem has been converted to the new mount API, remove all legacy mount API code designed to handle un-converted filesystems, and remove associated documentation as well. (The code to handle the legacy mount(2) syscall from userspace is still in place, of course.) Tested with an allmodconfig build on x86_64, and a sanity check of an old mount(2) syscall mount. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Link: https://patch.msgid.link/20251212174403.2882183-1-sandeen@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15Merge patch series "further damage-control lack of clone scalability"Christian Brauner
Mateusz Guzik <mjguzik@gmail.com> says: When spawning and killing threads in separate processes in parallel the primary bottleneck on the stock kernel is pidmap_lock, largely because of a back-to-back acquire in the common case. Benchmark code at the end. With this patchset alloc_pid() only takes the lock once and consequently alleviates the problem. While scalability improves, the lock remains the primary bottleneck by a large margin. I believe idr is a poor choice for the task at hand to begin with, but sorting out that out beyond the scope of this patchset. At the same time any replacement would be best evaluated against a state where the above relock problem is fixed. Performance improvement varies between reboots. When benchmarking with 20 processes creating and killing threads in a loop, the unpatched baseline hovers around 465k ops/s, while patched is anything between ~510k ops/s and ~560k depending on false-sharing (which I only minimally sanitized). So this is at least 10% if you are unlucky. bench from will-it-scale: char *testcase_description = "Thread creation and teardown"; static void *worker(void *arg) { return (NULL); } void testcase(unsigned long long *iterations, unsigned long nr) { pthread_t thread[1]; int error; while (1) { for (int i = 0; i < 1; i++) { error = pthread_create(&thread[i], NULL, worker, NULL); assert(error == 0); } for (int i = 0; i < 1; i++) { error = pthread_join(thread[i], NULL); assert(error == 0); } (*iterations)++; } } v2: - cosmetic fixes from Oleg - drop idr_preload_many, relock pidmap + call idr_preload again instead - write a commit message for the alloc pid patch * patches from https://patch.msgid.link/20251203092851.287617-1-mjguzik@gmail.com: pid: only take pidmap_lock once on alloc ns: pad refcount Link: https://patch.msgid.link/20251203092851.287617-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15fs: track the inode having file locks with a flag in ->i_opflagsMateusz Guzik
Opening and closing an inode dirties the ->i_readcount field. Depending on the alignment of the inode, it may happen to false-share with other fields loaded both for both operations to various extent. This notably concerns the ->i_flctx field. Since most inodes don't have the field populated, this bit can be managed with a flag in ->i_opflags instead which bypasses the problem. Here are results I obtained while opening a file read-only in a loop with 24 cores doing the work on Sapphire Rapids. Utilizing the flag as opposed to reading ->i_flctx field was toggled at runtime as the benchmark was running, to make sure both results come from the same alignment. before: 3233740 after: 3373346 (+4%) before: 3284313 after: 3518711 (+7%) before: 3505545 after: 4092806 (+16%) Or to put it differently, this varies wildly depending on how (un)lucky you get. The primary bottleneck before and after is the avoidable lockref trip in do_dentry_open(). Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20251203094837.290654-2-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15pid: only take pidmap_lock once on allocMateusz Guzik
When spawning and killing threads in separate processes in parallel the primary bottleneck on the stock kernel is pidmap_lock, largely because of a back-to-back acquire in the common case. This aspect is fixed with the patch. Performance improvement varies between reboots. When benchmarking with 20 processes creating and killing threads in a loop, the unpatched baseline hovers around 465k ops/s, while patched is anything between ~510k ops/s and ~560k depending on false-sharing (which I only minimally sanitized). So this is at least 10% if you are unlucky. The change also facilitated some cosmetic fixes. It has an unintentional side effect of no longer issuing spurious idr_preload() around idr_replace(). Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20251203092851.287617-3-mjguzik@gmail.com Reviewed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15filelock: use a consume fence in locks_inode_context()Mateusz Guzik
Matches the idiom of storing a pointer with a release fence and safely getting the content with a consume fence after. Eliminates an actual fence on some archs. Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20251203094837.290654-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15ns: pad refcountMateusz Guzik
Note no effort is made to make sure structs embedding the namespace are themselves aligned, so this is not guaranteed to eliminate cacheline bouncing due to refcount management. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20251203092851.287617-2-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15fs: annotate cdev_lock with __cacheline_aligned_in_smpMateusz Guzik
No need for the crapper to be susceptible to false-sharing. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20251203095508.291073-1-mjguzik@gmail.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15fs: use min() or umin() instead of min_t()David Laight
min_t(unsigned int, a, b) casts an 'unsigned long' to 'unsigned int'. Use min(a, b) instead as it promotes any 'unsigned int' to 'unsigned long' and so cannot discard significant bits. A couple of places need umin() because of loops like: nfolios = DIV_ROUND_UP(ret + start, PAGE_SIZE); for (i = 0; i < nfolios; i++) { struct folio *folio = page_folio(pages[i]); ... unsigned int len = umin(ret, PAGE_SIZE - start); ... ret -= len; ... } where the compiler doesn't track things well enough to know that 'ret' is never negative. The alternate loop: for (i = 0; ret > 0; i++) { struct folio *folio = page_folio(pages[i]); ... unsigned int len = min(ret, PAGE_SIZE - start); ... ret -= len; ... } would be equivalent and doesn't need 'nfolios'. Most of the 'unsigned long' actually come from PAGE_SIZE. Detected by an extra check added to min_t(). Signed-off-by: David Laight <david.laight.linux@gmail.com> Link: https://patch.msgid.link/20251119224140.8616-31-david.laight.linux@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15init: remove deprecated "load_ramdisk" and "prompt_ramdisk" command line ↵Askar Safin
parameters ...which do nothing. They were deprecated (in documentation) in 6b99e6e6aa62 ("Documentation/admin-guide: blockdev/ramdisk: remove use of "rdev"") in 2020 and in kernel messages in c8376994c86c ("initrd: remove support for multiple floppies") in 2020. Signed-off-by: Askar Safin <safinaskar@gmail.com> Link: https://patch.msgid.link/20251119222407.3333257-2-safinaskar@gmail.com Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15Merge drm/drm-next into drm-intel-nextRodrigo Vivi
Sync-up some display code needed for Async flips refactor. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-15arm64: dts: ti: k3-am62-lp-sk-nand: Rename pinctrls to fix schema warningsWadim Egorov
Rename pinctrl nodes to comply with naming conventions required by pinctrl-single schema. Fixes: e569152274fec ("arm64: dts: ti: am62-lp-sk: Add overlay for NAND expansion card") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251127122733.2523367-3-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-15arm64: dts: ti: k3-am642-phyboard-electra-x27-gpio1-spi1-uart3: Fix schema ↵Wadim Egorov
warnings Rename pinctrl nodes to comply with naming conventions required by pinctrl-single schema. Also, replace invalid integer assignment in SPI node with a boolean to align with omap-spi schema. Fixes: 638ab30ce4c6 ("arm64: dts: ti: am64-phyboard-electra: Add DT overlay for X27 connector") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251127122733.2523367-2-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-15arm64: dts: ti: k3-am642-phyboard-electra-peb-c-010: Fix icssg-prueth schema ↵Wadim Egorov
warning Reduce length of dma-names and dmas properties for icssg1-ethernet node to comply with ti,icssg-prueth schema constraints. The previous entries exceeded the allowed count and triggered dtschema warnings during validation. Fixes: e53fbf955ea7 ("arm64: dts: ti: k3-am642-phyboard-electra: Add PEB-C-010 Overlay") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251127122733.2523367-1-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-15drm/xe: Restore engine registers before restarting schedulers after GT resetJan Maslak
During GT reset recovery in do_gt_restart(), xe_uc_start() was called before xe_reg_sr_apply_mmio() restored engine-specific registers. This created a race window where the scheduler could run jobs before hardware state was fully restored. This caused failures in eudebug tests (xe_exec_sip_eudebug@breakpoint- waitsip-*) where TD_CTL register (containing TD_CTL_GLOBAL_DEBUG_ENABLE) wasn't restored before jobs started executing. Breakpoints would fail to trigger SIP entry because the debug enable bit wasn't set yet. Fix by moving xe_uc_start() after all MMIO register restoration, including engine registers and CCS mode configuration, ensuring all hardware state is fully restored before any jobs can be scheduled. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Jan Maslak <jan.maslak@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251210145618.169625-2-jan.maslak@intel.com (cherry picked from commit 825aed0328588b2837636c1c5a0c48795d724617) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-15drm/xe: Increase TDF timeoutJagmeet Randhawa
There are some corner cases where flushing transient data may take slightly longer than the 150us timeout we currently allow. Update the driver to use a 300us timeout instead based on the latest guidance from the hardware team. An update to the bspec to formally document this is expected to arrive soon. Fixes: c01c6066e6fa ("drm/xe/device: implement transient flush") Signed-off-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/0201b1d6ec64d3651fcbff1ea21026efa915126a.1765487866.git.jagmeet.randhawa@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit d69d3636f5f7a84bae7cd43473b3701ad9b7d544) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-15firmware: ti_sci.h: fix all kernel-doc warningsRandy Dunlap
Modify kernel-doc comments in ti_sci.h to eliminate all kernel-doc warnings: * use correct/matching struct names in kdoc comments * use correct struct member names in kdoc comments * add a ':' after struct member names where needed * change a blank kdoc line to " *" * convert 3 structs to kernel-doc comments: struct ti_sci_msg_rm_udmap_tx_ch_cfg_req struct ti_sci_msg_rm_udmap_rx_ch_cfg_req struct ti_sci_msg_rm_udmap_flow_cfg_req Fixes 13 kernel-doc warnings: Warning: drivers/firmware/ti_sci.h:609 expecting prototype for struct tisci_msg_req_prepare_sleep. Prototype was for struct ti_sci_msg_req_prepare_sleep instead Warning: drivers/firmware/ti_sci.h:609 struct member 'hdr' not described in 'ti_sci_msg_req_prepare_sleep' Warning: drivers/firmware/ti_sci.h:609 struct member 'mode' not described in 'ti_sci_msg_req_prepare_sleep' Warning: drivers/firmware/ti_sci.h:609 struct member 'ctx_lo' not described in 'ti_sci_msg_req_prepare_sleep' Warning: drivers/firmware/ti_sci.h:609 struct member 'ctx_hi' not described in 'ti_sci_msg_req_prepare_sleep' Warning: drivers/firmware/ti_sci.h:609 struct member 'debug_flags' not described in 'ti_sci_msg_req_prepare_sleep' Warning: drivers/firmware/ti_sci.h:623 expecting prototype for struct tisci_msg_set_io_isolation_req. Prototype was for struct ti_sci_msg_req_set_io_isolation instead Warning: drivers/firmware/ti_sci.h:696 struct member 'latency' not described in 'ti_sci_msg_req_lpm_set_latency_constraint' Warning: drivers/firmware/ti_sci.h:857 bad line: Warning: drivers/firmware/ti_sci.h:1002 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst * Configures a Navigator Subsystem UDMAP transmit channel Warning: drivers/firmware/ti_sci.h:1130 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst * Configures a Navigator Subsystem UDMAP receive channel Warning: drivers/firmware/ti_sci.h:1249 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst * Configures a Navigator Subsystem UDMAP receive flow Warning: drivers/firmware/ti_sci.h:1421 struct member 'valid_params' not described in 'ti_sci_msg_rm_udmap_flow_cfg_req' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251128055731.812460-1-rdunlap@infradead.org Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-15drm/xe/vf: Fix queuing of recovery workSatyanarayana K V P
Ensure VF migration recovery work is only queued when no recovery is already queued and teardown is not in progress. Fixes: b47c0c07c350 ("drm/xe/vf: Teardown VF post migration worker on driver unload") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251210052546.622809-5-satyanarayana.k.v.p@intel.com (cherry picked from commit 8d8cf42b03f149dcb545b547906306f3b474565e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-15drm/xe/bo: Don't include the CCS metadata in the dma-buf sg-tableThomas Hellström
Some Xe bos are allocated with extra backing-store for the CCS metadata. It's never been the intention to share the CCS metadata when exporting such bos as dma-buf. Don't include it in the dma-buf sg-table. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://patch.msgid.link/20251209204920.224374-1-thomas.hellstrom@linux.intel.com (cherry picked from commit a4ebfb9d95d78a12512b435a698ee6886d712571) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-15drm/me/gsc: mei interrupt top half should be in irq disabled contextJunxiao Chang
MEI GSC interrupt comes from i915 or xe driver. It has top half and bottom half. Top half is called from i915/xe interrupt handler. It should be in irq disabled context. With RT kernel(PREEMPT_RT enabled), by default IRQ handler is in threaded IRQ. MEI GSC top half might be in threaded IRQ context. generic_handle_irq_safe API could be called from either IRQ or process context, it disables local IRQ then calls MEI GSC interrupt top half. This change fixes B580 GPU boot issue with RT enabled. Fixes: e02cea83d32d ("drm/xe/gsc: add Battlemage support") Tested-by: Baoli Zhang <baoli.zhang@intel.com> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251107033152.834960-1-junxiao.chang@intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> (cherry picked from commit 3efadf028783a49ab2941294187c8b6dd86bf7da) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-15drm/xe/vf: Stop waiting for ring space on VF post migration recoveryTomasz Lis
If wait for ring space started just before migration, it can delay the recovery process, by waiting without bailout path for up to 2 seconds. Two second wait for recovery is not acceptable, and if the ring was completely filled even without the migration temporarily stopping execution, then such a wait will result in up to a thousand new jobs (assuming constant flow) being added while the wait is happening. While this will not cause data corruption, it will lead to warning messages getting logged due to reset being scheduled on a GT under recovery. Also several seconds of unresponsiveness, as the backlog of jobs gets progressively executed. Add a bailout condition, to make sure the recovery starts without much delay. The recovery is expected to finish in about 100 ms when under moderate stress, so the condition verification period needs to be below that - settling at 64 ms. The theoretical max time which the recovery can take depends on how many requests can be emitted to engine rings and be pending execution. While stress testing, it was possible to reach 10k pending requests on rings when a platform with two GTs was used. This resulted in max recovery time of 5 seconds. But in real life situations, it is very unlikely that the amount of pending requests will ever exceed 100, and for that the recovery time will be around 50 ms - well within our claimed limit of 100ms. Fixes: a4dae94aad6a ("drm/xe/vf: Wakeup in GuC backend on VF post migration recovery") Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251204200820.2206168-1-tomasz.lis@intel.com (cherry picked from commit a00e305fba02a915cf2745bf6ef3f55537e65d57) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-15drm/xe/throttle: Skip reason prefix while emitting arrayRaag Jadav
The newly introduced "reasons" attribute already signifies possible reasons for throttling and makes the prefix in individual attribute names redundant while emitting them as an array. Skip the prefix. Fixes: 83ccde67a3f7 ("drm/xe/gt_throttle: Avoid TOCTOU when monitoring reasons") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Sk Anirban <sk.anirban@intel.com> Link: https://patch.msgid.link/20251203123355.571606-1-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit b64a14334ef3ebbcf70d11bc67d0934bdc0e390d) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-15drm/xe: fix drm_gpusvm_init() argumentsArnd Bergmann
The Xe driver fails to build when CONFIG_DRM_XE_GPUSVM is disabled but CONFIG_DRM_GPUSVM is turned on, due to the clash of two commits: In file included from drivers/gpu/drm/xe/xe_vm_madvise.c:8: drivers/gpu/drm/xe/xe_svm.h: In function 'xe_svm_init': include/linux/stddef.h:8:14: error: passing argument 5 of 'drm_gpusvm_init' makes integer from pointer without a cast [-Wint-conversion] drivers/gpu/drm/xe/xe_svm.h:217:38: note: in expansion of macro 'NULL' 217 | NULL, NULL, 0, 0, 0, NULL, NULL, 0); | ^~~~ In file included from drivers/gpu/drm/xe/xe_bo_types.h:11, from drivers/gpu/drm/xe/xe_bo.h:11, from drivers/gpu/drm/xe/xe_vm_madvise.c:11: include/drm/drm_gpusvm.h:254:35: note: expected 'long unsigned int' but argument is of type 'void *' 254 | unsigned long mm_start, unsigned long mm_range, | ~~~~~~~~~~~~~~^~~~~~~~ In file included from drivers/gpu/drm/xe/xe_vm_madvise.c:14: drivers/gpu/drm/xe/xe_svm.h:216:16: error: too many arguments to function 'drm_gpusvm_init'; expected 10, have 11 216 | return drm_gpusvm_init(&vm->svm.gpusvm, "Xe SVM (simple)", &vm->xe->drm, | ^~~~~~~~~~~~~~~ 217 | NULL, NULL, 0, 0, 0, NULL, NULL, 0); | ~ include/drm/drm_gpusvm.h:251:5: note: declared here Adapt the caller to the new argument list by removing the extraneous NULL argument. Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Fixes: 10aa5c806030 ("drm/gpusvm, drm/xe: Fix userptr to not allow device private pages") 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://patch.msgid.link/20251204094704.1030933-1-arnd@kernel.org (cherry picked from commit 29bce9c8b41d5c378263a927acb9a9074d0e7a0e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-02 06:51:27 +0000