aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-02btrfs: fix double inode unlock for direct IO sync writesFilipe Manana1-1/+4
If we do a direct IO sync write, at btrfs_sync_file(), and we need to skip inode logging or we get an error starting a transaction or an error when flushing delalloc, we end up unlocking the inode when we shouldn't under the 'out_release_extents' label, and then unlock it again at btrfs_direct_write(). Fix that by checking if we have to skip inode unlocking under that label. Reported-by: [email protected] Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Fixes: 939b656bc8ab ("btrfs: fix corruption after buffer fault in during direct IO append write") Reviewed-by: Josef Bacik <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]>
2024-08-02ASoC: cs43130: Constify snd_soc_component_driver structChristophe JAILLET1-41/+32
In order to constify `snd_soc_component_driver` struct, duplicate `soc_component_dev_cs43130` into a `soc_component_dev_cs43130_digital` and `soc_component_dev_cs43130_analog`. These 2 new structures share the same .dapm_widgets and .dapm_routes arrays but differ for .num_dapm_widgets and .num_dapm_routes. In the digital case, the last entries are not taken into account. Doing so has several advantages: - `snd_soc_component_driver` can be declared as const to move their declarations to read-only sections. - code in the probe is simpler. There is no need to concatenate some arrays to handle the "analog" case - this saves some memory because all_hp_widgets and analog_hp_routes can be removed. Before : ====== text data bss dec hex filename 53965 8265 4512 66742 104b6 sound/soc/codecs/cs43130.o After : ===== text data bss dec hex filename 54409 7881 64 62354 f392 sound/soc/codecs/cs43130.o Signed-off-by: Christophe JAILLET <[email protected]> Link: https://patch.msgid.link/1f04bb0366d9640d7ee361dae114ff79e4b381c1.1722274212.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <[email protected]>
2024-08-02Merge tag 'ceph-for-6.11-rc2' of https://github.com/ceph/ceph-clientLinus Torvalds2-14/+28
Pull ceph fix from Ilya Dryomov: "A fix for a potential hang in the MDS when cap revocation races with the client releasing the caps in question, marked for stable" * tag 'ceph-for-6.11-rc2' of https://github.com/ceph/ceph-client: ceph: force sending a cap update msg back to MDS for revoke op
2024-08-02Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds13-147/+202
Pull kvm updates from Paolo Bonzini: "The bulk of the changes here is a largish change to guest_memfd, delaying the clearing and encryption of guest-private pages until they are actually added to guest page tables. This started as "let's make it impossible to misuse the API" for SEV-SNP; but then it ballooned a bit. The new logic is generally simpler and more ready for hugepage support in guest_memfd. Summary: - fix latent bug in how usage of large pages is determined for confidential VMs - fix "underline too short" in docs - eliminate log spam from limited APIC timer periods - disallow pre-faulting of memory before SEV-SNP VMs are initialized - delay clearing and encrypting private memory until it is added to guest page tables - this change also enables another small cleanup: the checks in SNP_LAUNCH_UPDATE that limit it to non-populated, private pages can now be moved in the common kvm_gmem_populate() function - fix compilation error that the RISC-V merge introduced in selftests" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86/mmu: fix determination of max NPT mapping level for private pages KVM: riscv: selftests: Fix compile error KVM: guest_memfd: abstract how prepared folios are recorded KVM: guest_memfd: let kvm_gmem_populate() operate only on private gfns KVM: extend kvm_range_has_memory_attributes() to check subset of attributes KVM: cleanup and add shortcuts to kvm_range_has_memory_attributes() KVM: guest_memfd: move check for already-populated page to common code KVM: remove kvm_arch_gmem_prepare_needed() KVM: guest_memfd: make kvm_gmem_prepare_folio() operate on a single struct kvm KVM: guest_memfd: delay kvm_gmem_prepare_folio() until the memory is passed to the guest KVM: guest_memfd: return locked folio from __kvm_gmem_get_pfn KVM: rename CONFIG_HAVE_KVM_GMEM_* to CONFIG_HAVE_KVM_ARCH_GMEM_* KVM: guest_memfd: do not go through struct page KVM: guest_memfd: delay folio_mark_uptodate() until after successful preparation KVM: guest_memfd: return folio from __kvm_gmem_get_pfn() KVM: x86: disallow pre-fault for SNP VMs before initialization KVM: Documentation: Fix title underline too short warning KVM: x86: Eliminate log spam from limited APIC timer periods
2024-08-02Merge branch 'kvm-fixes' into HEADPaolo Bonzini12-143/+198
* fix latent bug in how usage of large pages is determined for confidential VMs * fix "underline too short" in docs * eliminate log spam from limited APIC timer periods * disallow pre-faulting of memory before SEV-SNP VMs are initialized * delay clearing and encrypting private memory until it is added to guest page tables * this change also enables another small cleanup: the checks in SNP_LAUNCH_UPDATE that limit it to non-populated, private pages can now be moved in the common kvm_gmem_populate() function
2024-08-02Merge tag 'riscv-for-linus-6.11-rc2' of ↵Linus Torvalds13-27/+37
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A fix to avoid dropping some of the internal pseudo-extensions, which breaks *envcfg dependency parsing - The kernel entry address is now aligned in purgatory, which avoids a misaligned load that can lead to crash on systems that don't support misaligned accesses early in boot - The FW_SFENCE_VMA_RECEIVED perf event was duplicated in a handful of perf JSON configurations, one of them been updated to FW_SFENCE_VMA_ASID_SENT - The starfive cache driver is now restricted to 64-bit systems, as it isn't 32-bit clean - A fix for to avoid aliasing legacy-mode perf counters with software perf counters - VM_FAULT_SIGSEGV is now handled in the page fault code - A fix for stalls during CPU hotplug due to IPIs being disabled - A fix for memblock bounds checking. This manifests as a crash on systems with discontinuous memory maps that have regions that don't fit in the linear map * tag 'riscv-for-linus-6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Fix linear mapping checks for non-contiguous memory regions RISC-V: Enable the IPI before workqueue_online_cpu() riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() perf: riscv: Fix selecting counters in legacy mode cache: StarFive: Require a 64-bit system perf arch events: Fix duplicate RISC-V SBI firmware event name riscv/purgatory: align riscv_kernel_entry riscv: cpufeature: Do not drop Linux-internal extensions
2024-08-02Merge tag 'kvm-riscv-fixes-6.11-1' of https://github.com/kvm-riscv/linux ↵Paolo Bonzini1-4/+4
into HEAD KVM/riscv fixes for 6.11, take #1 - Fix compile error in get-reg-list selftests
2024-08-02Merge tag 's390-6.11-3' of ↵Linus Torvalds8-88/+95
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - remove unused empty CPU alternatives header file - fix recently and erroneously removed exception handling when loading an invalid floating point register - ptdump fixes to reflect the recent changes due to the uncoupling of physical vs virtual kernel address spaces - changes to avoid the unnecessary splitting of large pages in kernel mappings - add the missing MODULE_DESCRIPTION for the CIO modules * tag 's390-6.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: Keep inittext section writable s390/vmlinux.lds.S: Move ro_after_init section behind rodata section s390/mm: Get rid of RELOC_HIDE() s390/mm/ptdump: Improve sorting of markers s390/mm/ptdump: Add support for relocated lowcore mapping s390/mm/ptdump: Fix handling of identity mapping area s390/cio: Add missing MODULE_DESCRIPTION() macros s390/alternatives: Remove unused empty header file s390/fpu: Re-add exception handling in load_fpu_state()
2024-08-02clocksource: Fix brown-bag boolean thinko in cs_watchdog_read()Paul E. McKenney1-1/+1
The current "nretries > 1 || nretries >= max_retries" check in cs_watchdog_read() will always evaluate to true, and thus pr_warn(), if nretries is greater than 1. The intent is instead to never warn on the first try, but otherwise warn if the successful retry was the last retry. Therefore, change that "||" to "&&". Fixes: db3a34e17433 ("clocksource: Retry clock read if long delays detected") Reported-by: Borislav Petkov <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/[email protected]
2024-08-02Merge tag 'asm-generic-fixes-6.11-1' of ↵Linus Torvalds8-14/+11
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull asm-generic fixes from Arnd Bergmann: "These are three important bug fixes for the cross-architecture tree, fixing a regression with the new syscall.tbl file, the inconsistent numbering for the new uretprobe syscall and a bug with iowrite64be on alpha" * tag 'asm-generic-fixes-6.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: syscalls: fix syscall macros for newfstat/newfstatat uretprobe: change syscall number, again alpha: fix ioread64be()/iowrite64be() helpers
2024-08-02Merge tag 'sound-6.11-rc2' of ↵Linus Torvalds13-142/+241
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A small collection of fixes: - Revert of FireWire changes that caused a long-time regression - Another long-time regression fix for AMD HDMI - MIDI2 UMP fixes - HD-audio Conexant codec fixes and a quirk" * tag 'sound-6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda: Conditionally use snooping for AMD HDMI ALSA: usb-audio: Correct surround channels in UAC1 channel map ALSA: seq: ump: Explicitly reset RPN with Null RPN ALSA: seq: ump: Transmit RPN/NRPN message at each MSB/LSB data reception ALSA: seq: ump: Use the common RPN/bank conversion context ALSA: ump: Explicitly reset RPN with Null RPN ALSA: ump: Transmit RPN/NRPN message at each MSB/LSB data reception Revert "ALSA: firewire-lib: operate for period elapse event in process context" Revert "ALSA: firewire-lib: obsolete workqueue for period update" ALSA: hda/realtek: Add quirk for Acer Aspire E5-574G ALSA: seq: ump: Optimize conversions from SysEx to UMP ALSA: hda/conexant: Mute speakers at suspend / shutdown ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown ALSA: hda: conexant: Fix headset auto detect fail in the polling mode
2024-08-02Merge tag 'drm-fixes-2024-08-02' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds50-650/+1202
Pull drm fixes from Dave Airlie: "Regular weekly fixes. This is a bit larger than usual but doesn't seem too crazy. Most of it is vmwgfx changes that fix a bunch of issues with wayland userspaces with dma-buf/external buffers and modesetting fixes. Otherwise it's kinda spread out, v3d fixes some new ioctls, nouveau has regression revert and fixes, amdgpu, i915 and ast have some small fixes, and some core fixes spread about. client: - fix error code atomic: - allow damage clips with async flips - allow explicit sync with async flips kselftests: - fix dmabuf-heaps test panic: - fix schedule_work in panic paths panel: - fix OrangePi Neo orientation gpuvm: - fix missing dependency amdgpu: - SMU 14.x update - Fix contiguous VRAM handling for IB parsing - GFX 12 fix - Regression fix for old APUs i915: - Static analysis fix for int overflow - Fix for HDCP2_STREAM_STATUS macro and removal of PWR_CLK_STATE for gen12 nouveau: - revert busy wait change that caused a resume regression - fix buffer placement fault on dynamic pm s/r - fix refcount underflow ast: - fix black screen on resume - wake during connector status detect v3d: - fix issues with perf/timestamp ioctls vmwgfx: - fix deadlock in dma-buf fence polling - fix screen surface refcounting - fix dumb buffer handling - fix support for external buffers - fix overlay with screen targets - trigger modeset on screen moves" * tag 'drm-fixes-2024-08-02' of https://gitlab.freedesktop.org/drm/kernel: (31 commits) Revert "nouveau: rip out busy fence waits" nouveau: set placement to original placement on uvmm validate. drm/atomic: Allow userspace to use damage clips with async flips drm/atomic: Allow userspace to use explicit sync with atomic async flips drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll() drm/i915/hdcp: Fix HDCP2_STREAM_STATUS macro drm/ast: astdp: Wake up during connector status detection i915/perf: Remove code to update PWR_CLK_STATE for gen12 kselftests: dmabuf-heaps: Ensure the driver name is null-terminated drm/client: Fix error code in drm_client_buffer_vmap_local() drm/amdgpu: Fix APU handling in amdgpu_pm_load_smu_firmware() drm/amdgpu: increase mes log buffer size for gfx12 drm/amdgpu: fix contiguous handling for IB parsing v2 drm/amdgpu/pm: support gpu_metrics sysfs interface for smu v14.0.2/3 drm/vmwgfx: Trigger a modeset when the screen moves drm/vmwgfx: Fix overlay when using Screen Targets drm/vmwgfx: Add basic support for external buffers drm/vmwgfx: Fix handling of dumb buffers drm/vmwgfx: Make sure the screen surface is ref counted drm/vmwgfx: Fix a deadlock in dma buf fence polling ...
2024-08-02cifs: update internal version numberSteve French1-2/+2
To 2.50 Signed-off-by: Steve French <[email protected]>
2024-08-02smb: client: fix FSCTL_GET_REPARSE_POINT against NetAppPaulo Alcantara1-2/+4
NetApp server requires the file to be open with FILE_READ_EA access in order to support FSCTL_GET_REPARSE_POINT, otherwise it will return STATUS_INVALID_DEVICE_REQUEST. It doesn't make any sense because there's no requirement for FILE_READ_EA bit to be set nor STATUS_INVALID_DEVICE_REQUEST being used for something other than "unsupported reparse points" in MS-FSA. To fix it and improve compatibility, set FILE_READ_EA & SYNCHRONIZE bits to match what Windows client currently does. Tested-by: Sebastian Steinbeisser <[email protected]> Acked-by: Tom Talpey <[email protected]> Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]>
2024-08-02smb3: add dynamic tracepoints for shutdown ioctlSteve French2-8/+75
For debugging an umount failure in xfstests generic/043 generic/044 in some configurations, we needed more information on the shutdown ioctl which was suspected of being related to the cause, so tracepoints are added in this patch e.g. "trace-cmd record -e smb3_shutdown_enter -e smb3_shutdown_done -e smb3_shutdown_err" Sample output: godown-47084 [011] ..... 3313.756965: smb3_shutdown_enter: flags=0x1 tid=0x733b3e75 godown-47084 [011] ..... 3313.756968: smb3_shutdown_done: flags=0x1 tid=0x733b3e75 Tested-by: Anthony Nandaa (Microsoft) <[email protected]> Signed-off-by: Steve French <[email protected]>
2024-08-02cifs: Remove cifs_aio_ctxDavid Howells3-80/+0
Remove struct cifs_aio_ctx and its associated alloc/release functions as it is no longer used, the functions being taken over by netfslib. Signed-off-by: David Howells <[email protected]> cc: Steve French <[email protected]> cc: [email protected] Signed-off-by: Steve French <[email protected]>
2024-08-02smb: client: handle lack of FSCTL_GET_REPARSE_POINT supportPaulo Alcantara4-4/+38
As per MS-FSA 2.1.5.10.14, support for FSCTL_GET_REPARSE_POINT is optional and if the server doesn't support it, STATUS_INVALID_DEVICE_REQUEST must be returned for the operation. If we find files with reparse points and we can't read them due to lack of client or server support, just ignore it and then treat them as regular files or junctions. Fixes: 5f71ebc41294 ("smb: client: parse reparse point flag in create response") Reported-by: Sebastian Steinbeisser <[email protected]> Tested-by: Sebastian Steinbeisser <[email protected]> Acked-by: Tom Talpey <[email protected]> Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]>
2024-08-02Merge tag 'ata-6.11-rc2' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fix from Damien Le Moal: - Add missing power-domains property to the device tree bindings for the Rockchip Designware AHCI adapter (from Heiko) * tag 'ata-6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: dt-bindings: ata: rockchip-dwc-ahci: add missing power-domains
2024-08-02Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds1-0/+1
Pull vfs fix from Al Viro: "do_dup2() out-of-bounds array speculation fix" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: protect the fetch of ->fd[fd] in do_dup2() from mispredictions
2024-08-02arm64: jump_label: Ensure patched jump_labels are visible to all CPUsWill Deacon2-2/+10
Although the Arm architecture permits concurrent modification and execution of NOP and branch instructions, it still requires some synchronisation to ensure that other CPUs consistently execute the newly written instruction: > When the modified instructions are observable, each PE that is > executing the modified instructions must execute an ISB or perform a > context synchronizing event to ensure execution of the modified > instructions Prior to commit f6cc0c501649 ("arm64: Avoid calling stop_machine() when patching jump labels"), the arm64 jump_label patching machinery performed synchronisation using stop_machine() after each modification, however this was problematic when flipping static keys from atomic contexts (namely, the arm_arch_timer CPU hotplug startup notifier) and so we switched to the _nosync() patching routines to avoid "scheduling while atomic" BUG()s during boot. In hindsight, the analysis of the issue in f6cc0c501649 isn't quite right: it cites the use of IPIs in the default patching routines as the cause of the lockup, whereas stop_machine() does not rely on IPIs and the I-cache invalidation is performed using __flush_icache_range(), which elides the call to kick_all_cpus_sync(). In fact, the blocking wait for other CPUs is what triggers the BUG() and the problem remains even after f6cc0c501649, for example because we could block on the jump_label_mutex. Eventually, the arm_arch_timer driver was fixed to avoid the static key entirely in commit a862fc2254bd ("clocksource/arm_arch_timer: Remove use of workaround static key"). This all leaves the jump_label patching code in a funny situation on arm64 as we do not synchronise with other CPUs to reduce the likelihood of a bug which no longer exists. Consequently, toggling a static key on one CPU cannot be assumed to take effect on other CPUs, leading to potential issues, for example with missing preempt notifiers. Rather than revert f6cc0c501649 and go back to stop_machine() for each patch site, implement arch_jump_label_transform_apply() and kick all the other CPUs with an IPI at the end of patching. Cc: Alexander Potapenko <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Marc Zyngier <[email protected]> Fixes: f6cc0c501649 ("arm64: Avoid calling stop_machine() when patching jump labels") Signed-off-by: Will Deacon <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2024-08-02syscalls: fix syscall macros for newfstat/newfstatatArnd Bergmann4-5/+6
The __NR_newfstat and __NR_newfstatat macros accidentally got renamed in the conversion to the syscall.tbl format, dropping the 'new' portion of the name. In an unrelated change, the two syscalls are no longer architecture specific but are once more defined on all 64-bit architectures, so the 'newstat' ABI keyword can be dropped from the table as a simplification. Fixes: Fixes: 4fe53bf2ba0a ("syscalls: add generic scripts/syscall.tbl") Closes: https://lore.kernel.org/lkml/[email protected]/T/#t Reported-by: Florian Weimer <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2024-08-02uretprobe: change syscall number, againArnd Bergmann4-7/+3
Despite multiple attempts to get the syscall number assignment right for the newly added uretprobe syscall, we ended up with a bit of a mess: - The number is defined as 467 based on the assumption that the xattrat family of syscalls would use 463 through 466, but those did not make it into 6.11. - The include/uapi/asm-generic/unistd.h file still lists the number 463, but the new scripts/syscall.tbl that was supposed to have the same data lists 467 instead as the number for arc, arm64, csky, hexagon, loongarch, nios2, openrisc and riscv. None of these architectures actually provide a uretprobe syscall. - All the other architectures (powerpc, arm, mips, ...) don't list this syscall at all. There are two ways to make it consistent again: either list it with the same syscall number on all architectures, or only list it on x86 but not in scripts/syscall.tbl and asm-generic/unistd.h. Based on the most recent discussion, it seems like we won't need it anywhere else, so just remove the inconsistent assignment and instead move the x86 number to the next available one in the architecture specific range, which is 335. Fixes: 5c28424e9a34 ("syscalls: Fix to add sys_uretprobe to syscall.tbl") Fixes: 190fec72df4a ("uprobe: Wire up uretprobe system call") Fixes: 63ded110979b ("uprobe: Change uretprobe syscall scope and number") Acked-by: Masami Hiramatsu (Google) <[email protected]> Reviewed-by: Jiri Olsa <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2024-08-02ASoC: fsl: lpc3xxx: Make some symbols staticYue Haibing2-3/+3
These symbols are not used outside of the files, make them static to fix sparse warnings: sound/soc/fsl/lpc3xxx-i2s.c:261:30: warning: symbol 'lpc3xxx_i2s_dai_ops' was not declared. Should it be static? sound/soc/fsl/lpc3xxx-i2s.c:271:27: warning: symbol 'lpc3xxx_i2s_dai_driver' was not declared. Should it be static? sound/soc/fsl/lpc3xxx-pcm.c:55:39: warning: symbol 'lpc3xxx_soc_platform_driver' was not declared. Should it be static? Signed-off-by: Yue Haibing <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: sti-sas: Constify snd_soc_component_driver structChristophe JAILLET1-16/+5
In order to constify `snd_soc_component_driver` struct, simplify the logic and the `sti_sas_dev_data` struct. Since commit 165a57a3df02 ("ASoC: sti-sas: clean legacy in sti-sas") only only chip is supported and `sti_sas_driver` can be fully defined at compilation time. Before: ====== text data bss dec hex filename 8033 1547 16 9596 257c sound/soc/codecs/sti-sas.o After: ===== text data bss dec hex filename 8257 1163 16 9436 24dc sound/soc/codecs/sti-sas.o Signed-off-by: Christophe JAILLET <[email protected]> Link: https://patch.msgid.link/2c08558813e3bbfae0a5302199cf6ca226e7cde1.1722544073.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to ↵Shenghao Ding3-260/+280
adding tas2563_dvc_table Move tas2563_dvc_table into a separate Header file, as only tas2781 codec driver use this table, and hda side codec driver won't use it. Fixes: 75ed63a5ab5d ("ASoC: tas2781: Add new Kontrol to set tas2563 digital Volume") Signed-off-by: Shenghao Ding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: SOF: sof-audio.h: optimize snd_sof_pcm_stream_pipeline_listPierre-Louis Bossart1-2/+2
Invert members to remove hole. Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: SOF: sof-priv.h: optimize snd_sof_ipc_msgPierre-Louis Bossart1-3/+4
Move waitq to make sure it's entirely in the same cache line, and move ipc_complete to reduce padding. struct snd_sof_ipc_msg { void * msg_data; /* 0 8 */ void * reply_data; /* 8 8 */ size_t msg_size; /* 16 8 */ size_t reply_size; /* 24 8 */ int reply_error; /* 32 4 */ bool ipc_complete; /* 36 1 */ /* XXX 3 bytes hole, try to pack */ wait_queue_head_t waitq; /* 40 88 */ /* --- cacheline 2 boundary (128 bytes) --- */ void * rx_data; /* 128 8 */ /* size: 136, cachelines: 3, members: 8 */ /* sum members: 133, holes: 1, sum holes: 3 */ /* last cacheline: 8 bytes */ }; Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: SOF: sof-priv.h: optimize snd_sof_mailboxPierre-Louis Bossart1-1/+1
Reverse the two members to remove a hole. Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: SOF: sof-priv.h: optimize snd_sof_platform_stream_paramsPierre-Louis Bossart1-3/+4
reshuffle members to remove hole. Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: Intel: soc-acpi-intel-ptl-match: Add rt722 supportBard Liao1-0/+73
This patch adds match table for rt722 multiple function codec on link 0 and link3. The topology does not internally refer to link0 or link3, so we can simplify and use the same topology file name. We do need different tables though. Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Signed-off-by: Bard Liao <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: Intel: soc-acpi-intel-ptl-match: add rt711-sdca tableBard Liao1-0/+31
Add rt711-sdca on sdw link0. Reviewed-by: Péter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Bard Liao <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: SOF: Intel: add initial support for PTLPierre-Louis Bossart7-0/+126
Clone LNL for now. Reviewed-by: Péter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: SOF: Intel: add PTL specific power control registerFred Oh2-2/+16
PTL has some differences from MTL/LNL. Need to use different register to power up. Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Signed-off-by: Fred Oh <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: Intel: soc-acpi: add PTL match tablesPierre-Louis Bossart3-0/+44
For now the tables are basic for mockup devices and headset codec support Reviewed-by: Péter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: cs42l43: Cache shutter IRQ control pointersCharles Keepax2-17/+58
The microphone/speaker privacy shutter ALSA control handlers need to call pm_runtime_resume, since the hardware needs to be powered up to check the hardware state of the shutter. The IRQ handler for the shutters also needs to notify the ALSA control to inform user-space the shutters updated. However this leads to a mutex inversion, between the sdw_dev_lock and the controls_rwsem. To avoid this mutex inversion cache the kctl pointers before the IRQ handler, which avoids the need to lookup the control and take the controls_rwsem. Suggested-by: Jaroslav Kysela <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: cs35l45: Use new snd_soc_component_get_kcontrol_locked() helperCharles Keepax1-9/+2
No longer any need to hard code the addition of the name prefix, use the new helper function. Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: soc-component: Add new snd_soc_component_get_kcontrol() helpersCharles Keepax2-8/+39
Add new helper functions snd_soc_component_get_kcontrol() and snd_soc_component_get_kcontrol_locked() that returns a kcontrol by name, but will factor in the components name_prefix, to handle situations where multiple components are present with the same controls. Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: cs42l43: Remove redundant semi-colon at end of functionCharles Keepax1-1/+1
Signed-off-by: Charles Keepax <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02cpufreq: intel_pstate: Update Balance performance EPP for Emerald RapidsPedro Henrique Kopper1-0/+1
On Intel Emerald Rapids machines, we ship the Energy Performance Preference (EPP) default for balance_performance as 128. However, during an internal investigation together with Intel, we have determined that 32 is a more suitable value. This leads to significant improvements in both performance and energy: POV-Ray: 32% faster | 12% less energy OpenSSL: 12% faster | energy within 1% Build Linux Kernel: 29% faster | 18% less energy Therefore, we should move the default EPP for balance_performance to 32. This is in line with what has already been done for Sapphire Rapids. Signed-off-by: Pedro Henrique Kopper <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://patch.msgid.link/Zqu6zjVMoiXwROBI@capivara Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-08-02thermal: core: Update thermal zone registration documentationRafael J. Wysocki1-35/+30
The thermal sysfs API document is outdated. One of the problems with it is that is still documents thermal_zone_device_register() which does not exit any more and it does not reflect the current thermal zone operations definition. Replace the thermal_zone_device_register() description in it with a thermal_zone_device_register_with_trips() description, including an update of the thermal zone operations list. Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Lukasz Luba <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-02drm/test: fix the gem shmem test to map the sg table.Dave Airlie1-0/+11
The test here creates an sg table, but never maps it, when we get to drm_gem_shmem_free, the helper tries to unmap and this causes warnings on some platforms and debug kernels. This also sets a 64-bit dma mask, as I see an swiotlb warning if I stick with the default 32-bit one. Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Marco Pagani <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2024-08-02drm/client: fix null pointer dereference in drm_client_modeset_probeMa Ke1-0/+5
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: [email protected] Fixes: cf13909aee05 ("drm/fb-helper: Move out modeset config code") Signed-off-by: Ma Ke <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-02Revert "nouveau: rip out busy fence waits"Dave Airlie6-6/+34
This reverts commit d45bb9c5f7a6f7b6e47939856b28cb1da0cdc119. Just got a report that this causes some suspend/resume issues, so back it out and I'll investigate it later. Reported-by: Mike Galbraith <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2024-08-02Merge tag 'drm-misc-fixes-2024-08-01' of ↵Dave Airlie32-588/+1050
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A couple drm_panic fixes, several v3d fixes to increase the new timestamp API safety, several fixes for vmwgfx for various modesetting issues, PM fixes for ast, async flips improvements and two fixes for nouveau to fix resource refcounting and buffer placement. Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240801-interesting-antique-bat-2fe4c0@houat
2024-08-01scsi: sd: Move sd_read_cpr() out of the q->limits_lock regionShin'ichiro Kawasaki1-1/+8
Commit 804e498e0496 ("sd: convert to the atomic queue limits API") introduced pairs of function calls to queue_limits_start_update() and queue_limits_commit_update(). These two functions lock and unlock q->limits_lock. In sd_revalidate_disk(), sd_read_cpr() is called after queue_limits_start_update() call and before queue_limits_commit_update() call. sd_read_cpr() locks q->sysfs_dir_lock and &q->sysfs_lock. Then new lock dependencies were created between q->limits_lock, q->sysfs_dir_lock and q->sysfs_lock, as follows: sd_revalidate_disk queue_limits_start_update mutex_lock(&q->limits_lock) sd_read_cpr disk_set_independent_access_ranges mutex_lock(&q->sysfs_dir_lock) mutex_lock(&q->sysfs_lock) mutex_unlock(&q->sysfs_lock) mutex_unlock(&q->sysfs_dir_lock) queue_limits_commit_update mutex_unlock(&q->limits_lock) However, the three locks already had reversed dependencies in other places. Then the new dependencies triggered the lockdep WARN "possible circular locking dependency detected" [1]. This WARN was observed by running the blktests test case srp/002. To avoid the WARN, move the sd_read_cpr() call in sd_revalidate_disk() after the queue_limits_commit_update() call. In other words, move the sd_read_cpr() call out of the q->limits_lock region. [1] https://lore.kernel.org/linux-scsi/vlmv53ni3ltwxplig5qnw4xsl2h6ccxijfbqzekx76vxoim5a5@dekv7q3es3tx/ Fixes: 804e498e0496 ("sd: convert to the atomic queue limits API") Signed-off-by: Shin'ichiro Kawasaki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Luca Coelho <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-01scsi: ufs: core: Fix hba->last_dme_cmd_tstamp timestamp updating logicVamshi Gajjela1-3/+8
The ufshcd_add_delay_before_dme_cmd() always introduces a delay of MIN_DELAY_BEFORE_DME_CMDS_US between DME commands even when it's not required. The delay is added when the UFS host controller supplies the quirk UFSHCD_QUIRK_DELAY_BEFORE_DME_CMDS. Fix the logic to update hba->last_dme_cmd_tstamp to ensure subsequent DME commands have the correct delay in the range of 0 to MIN_DELAY_BEFORE_DME_CMDS_US. Update the timestamp at the end of the function to ensure it captures the latest time after any necessary delay has been applied. Signed-off-by: Vamshi Gajjela <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: cad2e03d8607 ("ufs: add support to allow non standard behaviours (quirks)") Cc: [email protected] Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-01Merge branch 'mptcp-fix-endpoints-with-signal-and-subflow-flags'Jakub Kicinski3-32/+73
Matthieu Baerts says: ==================== mptcp: fix endpoints with 'signal' and 'subflow' flags When looking at improving the user experience around the MPTCP endpoints setup, I noticed that setting an endpoint with both the 'signal' and the 'subflow' flags -- as it has been done in the past by users according to bug reports we got -- was resulting on only announcing the endpoint, but not using it to create subflows: the 'subflow' flag was then ignored. My initial thought was to modify IPRoute2 to warn the user when the two flags were set, but it doesn't sound normal to ignore one of them. I then looked at modifying the kernel not to allow having the two flags set, but when discussing about that with Mat, we thought it was maybe not ideal to do that, as there might be use-cases, we might break some configs. Then I saw it was working before v5.17. So instead, I fixed the support on the kernel side (patch 5) using Paolo's suggestion. This also includes a fix on the options side (patch 1: for v5.11+), an explicit deny of some options combinations (patch 2: for v5.18+), and some refactoring (patches 3 and 4) to ease the inclusion of the patch 5. While at it, I added a new selftest (patch 7) to validate this case -- including a modification of the chk_add_nr helper to inverse the sides were the counters are checked (patch 6) -- and allowed ADD_ADDR echo just after the MP_JOIN 3WHS. The selftests modification have the same Fixes tag as the previous commit, but no 'Cc: Stable': if the backport can work, that's good -- but it still need to be verified by running the selftests -- if not, no need to worry, many CIs will use the selftests from the last stable version to validate previous stable releases. ==================== Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-01selftests: mptcp: join: test both signal & subflowMatthieu Baerts (NGI0)1-0/+15
It should be quite uncommon to set both the subflow and the signal flags: the initiator of the connection is typically the one creating new subflows, not the other peer, then no need to announce additional local addresses, and use it to create subflows. But some people might be confused about the flags, and set both "just to be sure at least the right one is set". To verify the previous fix, and avoid future regressions, this specific case is now validated: the client announces a new address, and initiates a new subflow from the same address. While working on this, another bug has been noticed, where the client reset the new subflow because an ADD_ADDR echo got received as the 3rd ACK: this new test also explicitly checks that no RST have been sent by the client and server. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk") Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-7-c8a9b036493b@kernel.org Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-01selftests: mptcp: join: ability to invert ADD_ADDR checkMatthieu Baerts (NGI0)1-14/+26
In the following commit, the client will initiate the ADD_ADDR, instead of the server. We need to way to verify the ADD_ADDR have been correctly sent. Note: the default expected counters for when the port number is given are never changed by the caller, no need to accept them as parameter then. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk") Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-6-c8a9b036493b@kernel.org Signed-off-by: Jakub Kicinski <[email protected]>
2024-08-01mptcp: pm: do not ignore 'subflow' if 'signal' flag is also setMatthieu Baerts (NGI0)1-4/+12
Up to the 'Fixes' commit, having an endpoint with both the 'signal' and 'subflow' flags, resulted in the creation of a subflow and an address announcement using the address linked to this endpoint. After this commit, only the address announcement was done, ignoring the 'subflow' flag. That's because the same bitmap is used for the two flags. It is OK to keep this single bitmap, the already selected local endpoint simply have to be re-used, but not via select_local_address() not to look at the just modified bitmap. Note that it is unusual to set the two flags together: creating a new subflow using a new local address will implicitly advertise it to the other peer. So in theory, no need to advertise it explicitly as well. Maybe there are use-cases -- the subflow might not reach the other peer that way, we can ask the other peer to try initiating the new subflow without delay -- or very likely the user is confused, and put both flags "just to be sure at least the right one is set". Still, if it is allowed, the kernel should do what has been asked: using this endpoint to announce the address and to create a new subflow from it. An alternative is to forbid the use of the two flags together, but that's probably too late, there are maybe use-cases, and it was working before. This patch will avoid people complaining subflows are not created using the endpoint they added with the 'subflow' and 'signal' flag. Note that with the current patch, the subflow might not be created in some corner cases, e.g. if the 'subflows' limit was reached when sending the ADD_ADDR, but changed later on. It is probably not worth splitting id_avail_bitmap per target ('signal', 'subflow'), which will add another large field to the msk "just" to track (again) endpoints. Anyway, currently when the limits are changed, the kernel doesn't check if new subflows can be created or removed, because we would need to keep track of the received ADD_ADDR, and more. It sounds OK to assume that the limits should be properly configured before establishing new connections. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk") Cc: [email protected] Suggested-by: Paolo Abeni <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-5-c8a9b036493b@kernel.org Signed-off-by: Jakub Kicinski <[email protected]>