forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test/v6.8 #4855
Closed
Closed
Test/v6.8 #4855
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…org/git/drm/drm-misc into drm-fixes A reset fix for host1x, a resource leak fix and a probe fix for aux-hpd, a use-after-free fix and a boot fix for a pmic_glink qcom driver in drivers/soc, a fix for the simpledrm/tegra transition, a kunit fix for the TTM tests, a font handling fix for fbcon, two allocation fixes and a kunit test to cover them for drm/buddy Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240229-angelic-adorable-teal-fbfabb@houat
…/drm/xe/kernel into drm-fixes UAPI Changes: - A couple of tracepoint updates from Priyanka and Lucas. - Make sure BINDs are completed before accepting UNBINDs on LR vms. - Don't arbitrarily restrict max number of batched binds. - Add uapi for dumpable bos (agreed on IRC). - Remove unused uapi flags and a leftover comment. Driver Changes: - A couple of fixes related to the execlist backend. Signed-off-by: Dave Airlie <[email protected]> From: Thomas Hellstrom <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ZeCBg4MA2hd1oggN@fedora
…g/drm/msm into drm-fixes Fixes for v6.8-rc7 DP: - Revert a change which was causing a HDP regression Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvhWvHiPGQ1pRD2XPAQoHEM2M35kjhrsSAEtzh8AMSRvg@mail.gmail.com
…p.org/agd5f/linux into drm-fixes amd-drm-fixes-6.8-2024-02-29: amdgpu: - Fix potential buffer overflow - Fix power min cap - Suspend/resume fix - SI PM fix - eDP fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Turns out usage is always in bytes not shifted. Fixes: 72fa02f ("nouveau: add an ioctl to report vram usage") Signed-off-by: Dave Airlie <[email protected]>
Nouveau deallocates a few buffers post GPU init which are required for GPU suspend/resume to function correctly. This is likely not as big an issue on systems where the NVGPU is the only GPU, but on multi-GPU set ups it leads to a regression where the kernel module errors and results in a system-wide rendering freeze. This commit addresses that regression by moving the two buffers required for suspend and resume to be deallocated at driver unload instead of post init. Fixes: 042b5f8 ("drm/nouveau: fix several DMA buffer leaks") Signed-off-by: Sid Pranjale <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
Chip outputs are enabled[1] before actual reset is performed[2] which might cause pin output value to flip flop if previous pin value was set to 1. Fix that behavior by making sure chip is fully reset before all outputs are enabled. Flip-flop can be noticed when module is removed and inserted again and one of the pins was changed to 1 before removal. 100 microsecond flipping is noticeable on oscilloscope (100khz SPI bus). For a properly reset chip - output is enabled around 100 microseconds (on 100khz SPI bus) later during probing process hence should be irrelevant behavioral change. Fixes: 7ebc194 (gpio: 74x164: Introduce 'enable-gpios' property) Link: https://elixir.bootlin.com/linux/v6.7.4/source/drivers/gpio/gpio-74x164.c#L130 [1] Link: https://elixir.bootlin.com/linux/v6.7.4/source/drivers/gpio/gpio-74x164.c#L150 [2] Signed-off-by: Arturas Moskvinas <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
After shuffling the code, error path wasn't updated correctly. Fix it here. Fixes: 2f4133b ("gpiolib: No need to call gpiochip_remove_pin_ranges() twice") Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
Hyper-V hosts can omit the _SYNC flag to due a bug on resume from modern suspend. In such a case, the guest may fail to update its time-of-day to account for the period when it was suspended, and could proceed with a significantly wrong time-of-day. In such a case when the guest is significantly behind, fix it by treating a _SAMPLE the same as if _SYNC was received so that the guest time-of-day is updated. This is hidden behind param hv_utils.timesync_implicit. Signed-off-by: Peter Martincic <[email protected]> Acked-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
… of memory The VMBUS_RING_SIZE macro adds space for a ring buffer header to the requested ring buffer size. The header size is always 1 page, and so its size varies based on the PAGE_SIZE for which the kernel is built. If the requested ring buffer size is a large power-of-2 size and the header size is small, the resulting size is inefficient in its use of memory. For example, a 512 Kbyte ring buffer with a 4 Kbyte page size results in a 516 Kbyte allocation, which is rounded to up 1 Mbyte by the memory allocator, and wastes 508 Kbytes of memory. In such situations, the exact size of the ring buffer isn't that important, and it's OK to allocate the 4 Kbyte header at the beginning of the 512 Kbytes, leaving the ring buffer itself with just 508 Kbytes. The memory allocation can be 512 Kbytes instead of 1 Mbyte and nothing is wasted. Update VMBUS_RING_SIZE to implement this approach for "large" ring buffer sizes. "Large" is somewhat arbitrarily defined as 8 times the size of the ring buffer header (which is of size PAGE_SIZE). For example, for 4 Kbyte PAGE_SIZE, ring buffers of 32 Kbytes and larger use the first 4 Kbytes as the ring buffer header. For 64 Kbyte PAGE_SIZE, ring buffers of 512 Kbytes and larger use the first 64 Kbytes as the ring buffer header. In both cases, smaller sizes add space for the header so the ring size isn't reduced too much by using part of the space for the header. For example, with a 64 Kbyte page size, we don't want a 128 Kbyte ring buffer to be reduced to 64 Kbytes by allocating half of the space for the header. In such a case, the memory allocation is less efficient, but it's the best that can be done. While the new algorithm slightly changes the amount of space allocated for ring buffers by drivers that use VMBUS_RING_SIZE, the devices aren't known to be sensitive to small changes in ring buffer size, so there shouldn't be any effect. Fixes: c1135c7 ("Drivers: hv: vmbus: Introduce types of GPADL") Fixes: 6941f67 ("hv_netvsc: Calculate correct ring size when PAGE_SIZE is not 4 Kbytes") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218502 Cc: [email protected] Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Saurabh Sengar <[email protected]> Reviewed-by: Dexuan Cui <[email protected]> Tested-by: Souradeep Chakrabarti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
A recent commit removing the use of screen_info introduced a logic error. The error causes hvfb_getmem() to always return -ENOMEM for Generation 2 VMs. As a result, the Hyper-V frame buffer device fails to initialize. The error was introduced by removing an "else if" clause, leaving Gen2 VMs to always take the -ENOMEM error path. Fix the problem by removing the error path "else" clause. Gen 2 VMs now always proceed through the MMIO memory allocation code, but with "base" and "size" defaulting to 0. Fixes: 0aa0838 ("fbdev/hyperv_fb: Remove firmware framebuffers with aperture helpers") Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Saurabh Sengar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
…dl_header() create_gpadl_header() creates a message header, and one or more message bodies if the number of GPADL entries exceeds what fits in the header. Currently the code for creating the message header is duplicated in the two halves of the main "if" statement governing whether message bodies are created. Eliminate the duplication by making minor tweaks to the logic and associated comments. While here, simplify the handling of memory allocation errors, and use umin() instead of open coding it. For ease of review, the indentation of sizable chunks of code is *not* changed. A follow-on patch updates only the indentation. No functional change. Suggested-by: Dan Carpenter <[email protected]> Signed-off-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
A previous commit left the indentation in create_gpadl_header() unchanged for ease of review. Update the indentation and remove line wrap in two places where it is no longer necessary. No functional change. Signed-off-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
Add documentation topic for PCI pass-thru devices in Linux guests on Hyper-V and for the associated PCI controller driver (pci-hyperv.c). Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Easwar Hariharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
…lback In preparation for temporarily marking pages not present during a transition between encrypted and decrypted, use slow_virt_to_phys() in the hypervisor callback. As long as the PFN is correct, slow_virt_to_phys() works even if the leaf PTE is not present. The existing functions that depend on vmalloc_to_page() all require that the leaf PTE be marked present, so they don't work. Update the comments for slow_virt_to_phys() to note this broader usage and the requirement to work even if the PTE is not marked present. Signed-off-by: Michael Kelley <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Reviewed-by: Rick Edgecombe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
set_memory_p() is currently static. It has parameters that don't match set_memory_p() under arch/powerpc and that aren't congruent with the other set_memory_* functions. There's no good reason for the difference. Fix this by making the parameters consistent, and update the one existing call site. Make the function non-static and add it to include/asm/set_memory.h so that it is completely parallel to set_memory_np() and is usable in other modules. No functional change. Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Rick Edgecombe <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
…zeropad() In a CoCo VM, when transitioning memory from encrypted to decrypted, or vice versa, the caller of set_memory_encrypted() or set_memory_decrypted() is responsible for ensuring the memory isn't in use and isn't referenced while the transition is in progress. The transition has multiple steps, and the memory is in an inconsistent state until all steps are complete. A reference while the state is inconsistent could result in an exception that can't be cleanly fixed up. However, the kernel load_unaligned_zeropad() mechanism could cause a stray reference that can't be prevented by the caller of set_memory_encrypted() or set_memory_decrypted(), so there's specific code to handle this case. But a CoCo VM running on Hyper-V may be configured to run with a paravisor, with the #VC or #VE exception routed to the paravisor. There's no architectural way to forward the exceptions back to the guest kernel, and in such a case, the load_unaligned_zeropad() specific code doesn't work. To avoid this problem, mark pages as "not present" while a transition is in progress. If load_unaligned_zeropad() causes a stray reference, a normal page fault is generated instead of #VC or #VE, and the page-fault-based fixup handlers for load_unaligned_zeropad() resolve the reference. When the encrypted/decrypted transition is complete, mark the pages as "present" again. Signed-off-by: Michael Kelley <[email protected]> Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
The internal delay properties are not mandatory and should have a documented default value. The device only supports either no delay or a fixed delay and the device reset default is no delay, document the default as no delay. Signed-off-by: Niklas Söderlund <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Hogs are added *after* ACPI so should be removed *before* in error path. Fixes: a411e81 ("gpiolib: add hogs support for machine code") Signed-off-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]>
The current method for signaling the compatibility of a Hyper-V host with MSIs featuring 15-bit APIC IDs relies on a synthetic cpuid leaf. However, for higher VTLs, this leaf is not reported, due to the absence of an IO-APIC. As an alternative, assume that when running at a high VTL, the host supports 15-bit APIC IDs. This assumption is safe, as Hyper-V does not employ any architectural MSIs at higher VTLs This unblocks startup of VTL2 environments with more than 256 CPUs. Signed-off-by: Saurabh Sengar <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Message-ID: <[email protected]>
Current driver has some asymmetry in the runtime PM calls. On lan78xx_open() it will call usb_autopm_get() and unconditionally usb_autopm_put(). And on lan78xx_stop() it will call only usb_autopm_put(). So far, it was working only because this driver do not activate autosuspend by default, so it was visible only by warning "Runtime PM usage count underflow!". Since, with current driver, we can't use runtime PM with active link, execute lan78xx_open()->usb_autopm_put() only in error case. Otherwise, keep ref counting high as long as interface is open. Fixes: 55d7de9 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
It is now possible to disable BQL, but that causes the cpsw driver to break: drivers/net/ethernet/ti/am65-cpsw-nuss.c:297:28: error: no member named 'dql' in 'struct netdev_queue' 297 | dql_avail(&netif_txq->dql), There is already a helper function in net/sch_generic.h that could be used to help here. Move its implementation into the common linux/netdevice.h along with the other bql interfaces and change both users over to the new interface. Fixes: ea7f3cf ("net: bql: allow the config to be disabled") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Add myself as co-maintainer for Socionext netsec driver. This commit also removes Jassi from maintainer since he no longer has a Developerbox. Cc: Jassi Brar <[email protected]> Cc: Ilias Apalodimas <[email protected]> Signed-off-by: Masahisa Kojima <[email protected]> Acked-by: Ilias Apalodimas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
The unprepare call must be carried out before the finalize call as the latter can free the request. Fixes: c66c17a ("crypto: rk3288 - Remove prepare/unprepare request") Reported-by: Andrey Skvortsov <[email protected]> Cc: <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Reviewed-by: Andrey Skvortsov <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
… ALC897 platform Headset Mic will no show at resume back. This patch will fix this issue. Fixes: d7f3279 ("ALSA: hda/realtek - Add headset Mic support for Lenovo ALC897 platform") Cc: <[email protected]> Signed-off-by: Kailang Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
In azx_probe_codecs function, when bus->codec_mask is becomes to 0(no codecs), execute azx_init_chip, bus->codec_mask will be initialized to a value again, this causes snd_hda_codec_new function to run, the process is as follows: -->snd_hda_codec_new -->snd_hda_codec_device_init -->snd_hdac_device_init---snd_hdac_read_parm(...AC_PAR_VENDOR_ID) 2s ---snd_hdac_read_parm(...AC_PAR_VENDOR_ID) 2s ---snd_hdac_read_parm(...AC_PAR_SUBSYSTEM_ID) 2s ---snd_hdac_read_parm(...AC_PAR_REV_ID) 2s ---snd_hdac_read_parm(...AC_PAR_NODE_COUNT) 2s when no codecs, read communication is error, each command will be polled for 2 second, a total of 10s, it is easy to some problem. like this: 2 [ 14.833404][ 6] [ T164] hda 0006:00: Codec #0 probe error; disabling it... 3 [ 14.844178][ 6] [ T164] hda 0006:00: codec_mask = 0x1 4 [ 14.880532][ 6] [ T164] hda 0006:00: too slow response, last cmd=0x0f0000 5 [ 15.891988][ 6] [ T164] hda 0006:00: too slow response, last cmd=0x0f0000 6 [ 16.978090][ 6] [ T164] hda 0006:00: too slow response, last cmd=0x0f0001 7 [ 18.140895][ 6] [ T164] hda 0006:00: too slow response, last cmd=0x0f0002 8 [ 19.135516][ 6] [ T164] hda 0006:00: too slow response, last cmd=0x0f0004 10 [ 19.900086][ 6] [ T164] hda 0006:00: no codecs initialized 11 [ 45.573398][ 2] [ C2] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kworker/2:0:25] Here, when bus->codec_mask is 0, use a direct break to avoid execute snd_hda_codec_new function. Signed-off-by: songxiebing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
My recent commit e5d00aa ("selftests/powerpc: Check all FPRs in fpu_preempt") inadvertently broke the fpu_signal test. It needs to take into account that fpu_preempt now loads 32 FPRs, so enlarge darray. Also use the newly added randomise_darray() to properly randomise darray. Finally the checking done in signal_fpu_sig() needs to skip checking f30/f31, because they are used as scratch registers in check_all_fprs(), called by preempt_fpu(), and so could hold other values when the signal is taken. Fixes: e5d00aa ("selftests/powerpc: Check all FPRs in fpu_preempt") Reported-by: Spoorthy <[email protected]> Depends-on: 2ba107f ("selftests/powerpc: Generate better bit patterns for FPU tests") Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected]
iommu_sva_bind_device will directly goto out in multi-device case when found existing domain, ignoring list_add handle, which causes the handle to fail to be shared. Fixes: 65d4418 ("iommu/sva: Restore SVA handle sharing") Signed-off-by: Zhangfei Gao <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
Limit the WiFi PCIe link speed to Gen2 speed (500 MB/s), which is the speed that Windows uses. Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
Limit the WiFi PCIe link speed to Gen2 speed (500 MB/s), which is the speed that the boot firmware has brought up the link at (and that Windows uses). This is specifically needed to avoid a large amount of link errors when restarting the link during boot (but which are currently not reported). This also appears to fix intermittent failures to download the ath11k firmware during boot which can be seen when there is a longer delay between restarting the link and loading the WiFi driver (e.g. when using full disk encryption). Fixes: 123b30a ("arm64: dts: qcom: sc8280xp-x13s: enable WiFi controller") Cc: [email protected] # 6.2 Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]>
i801_probe_optional_slaves() is called before i801_add_mux(). This results in mux_pdev being checked before it's set by i801_add_mux(). Fix this by changing the order of the calls. I consider this safe as I see no dependencies. Fixes: 80e56b8 ("i2c: i801: Simplify class-based client device instantiation") Cc: [email protected] Signed-off-by: Heiner Kallweit <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]>
If registering the platform device fails, the lookup table is removed in the error path. On module removal we would try to remove the lookup table again. Fix this by setting priv->lookup only if registering the platform device was successful. In addition free the memory allocated for the lookup table in the error path. Fixes: d308dfb ("i2c: mux/i801: Switch to use descriptor passing") Cc: [email protected] Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Andi Shyti <[email protected]>
wmt_i2c_reset_hardware() calls clk_prepare_enable(). So, should an error occur after it, it should be undone by a corresponding clk_disable_unprepare() call, as already done in the remove function. Fixes: 560746e ("i2c: vt8500: Add support for I2C bus on Wondermedia SoCs") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Andi Shyti <[email protected]>
When the i2c error condition occurred and master state was not idle, the master irq function will goto complete state without any other interrupt handling. It would cause dummy irq expected print. Under this condition, assign the irq_status into irq_handle. For example, when the abnormal start / stop occurred (bit 5) with normal stop status (bit 4) at same time. Then the normal stop status would not be handled and it would cause irq expected print in the aspeed_i2c_bus_irq. ... aspeed-i2c-bus x. i2c-bus: irq handled != irq. Expected 0x00000030, but was 0x00000020 ... Fixes: 3e9efc3 ("i2c: aspeed: Handle master/slave combined irq events properly") Cc: Jae Hyun Yoo <[email protected]> Signed-off-by: Tommy Huang <[email protected]> Signed-off-by: Andi Shyti <[email protected]>
…m/kernel Pull drm fixes from Dave Airlie: "Regular fixes (two weeks for i915), scattered across drivers, amdgpu and i915 being the main ones, with nouveau having a couple of fixes. One patch got applied for udl, but reverted soon after as the maintainer has missed some crucial prior discussion. Seems quiet and normal enough for this stage. MAINTAINERS - update email address core: - fix polling in certain configurations buddy: - fix kunit test warning panel: - boe-tv101wum-nl6: timing tuning fixes i915: - Fix to extract HDCP information from primary connector - Check for NULL mmu_interval_notifier before removing - Fix for #10184: Kernel crash on UHD Graphics 730 (Cc stable) - Fix for #10284: Boot delay regresion with PSR - Fix DP connector DSC HW state readout - Selftest fix to convert msecs to jiffies xe: - error path fix amdgpu: - SMU14 fix - Fix possible NULL pointer - VRR fix - pwm fix nouveau: - fix deadlock in new ioctls fail path - fix missing locking around object rbtree udl: - apply and revert format change" * tag 'drm-fixes-2024-03-08' of https://gitlab.freedesktop.org/drm/kernel: (21 commits) nouveau: lock the client object tree. drm/tests/buddy: fix print format drm/xe: Return immediately on tile_init failure drm/amdgpu/pm: Fix the error of pwm1_enable setting drm/amd/display: handle range offsets in VRR ranges drm/amd/display: check dc_link before dereferencing drm/amd/swsmu: modify the gfx activity scaling Revert "drm/udl: Add ARGB8888 as a format" drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector() drm/i915/dp: Fix connector DSC HW state readout drm/i915/selftests: Fix dependency of some timeouts on HZ drm/udl: Add ARGB8888 as a format drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf drm/i915: Don't explode when the dig port we don't have an AUX CH MAINTAINERS: Update email address for Tvrtko Ursulin drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBP (again) drm: Fix output poll work for drm_kms_helper_poll=n drm/i915: Check before removing mm notifier drm/i915/hdcp: Extract hdcp structure from correct connector drm/i915/hdcp: Remove additional timing for reading mst hdcp message ...
…t/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes. Half of them are HD-audio quirks while the rest are various device-specific ASoC fixes" * tag 'sound-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: wm8962: Fix up incorrect error message in wm8962_set_fll ASoC: wm8962: Enable both SPKOUTR_ENA and SPKOUTL_ENA in mono mode ASoC: wm8962: Enable oscillator if selecting WM8962_FLL_OSC ASoC: dt-bindings: nvidia: Fix 'lge' vendor prefix ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook ASoC: amd: yc: Add HP Pavilion Aero Laptop 13-be2xxx(8BD6) into DMI quirk table ASoC: rcar: adg: correct TIMSEL setting for SSI9 ALSA: hda: cs35l41: Overwrite CS35L41 configuration for ASUS UM5302LA ALSA: hda/realtek: Add quirks for Lenovo Thinkbook 16P laptops ALSA: hda: cs35l41: Support Lenovo Thinkbook 16P ALSA: hda/realtek - Add Headset Mic supported Acer NB platform ALSA: hda: optimize the probe codec process ALSA: hda/realtek - Fix headset Mic no show at resume back for Lenovo ALC897 platform ASoC: Intel: bytcr_rt5640: Add an extra entry for the Chuwi Vi8 tablet ASoC: madera: Fix typo in madera_set_fll_clks shift value
…kernel/git/dtor/input Pull input updates from Dmitry Torokhov: - a revert of endpoint checks in bcm5974 - the driver is being naughty and pokes at unclaimed USB interface, so the check fails. We need to fix the driver to claim both interfaces, and then re-implement the endpoints check - a fix to Synaptics RMI driver to avoid UAF on driver unload or device unbinding - a few new VID/PIDs added to xpad game controller driver - a change to gpio_keys_polled driver to quiet it when GPIO causes probe deferral. * tag 'input-for-v6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: synaptics-rmi4 - fix UAF of IRQ domain on driver removal Input: gpio_keys_polled - suppress deferred probe error for gpio Revert "Input: bcm5974 - check endpoint type before starting traffic" Input: xpad - add additional HyperX Controller Identifiers
…el/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Fix the PM suspend callback in the STM32 ST32MP257 driver to properly support suspend - Drop an extraneous reference put in the debugfs code, this was confusing the reference counts and causing unsolicited calls to __free() * tag 'pinctrl-v6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: don't put the reference to GPIO device in pinctrl_pins_show() pinctrl: stm32: fix PM support for stm32mp257
…git/gregkh/usb Pull USB / Thunderbolt fixes from Greg KH: "Here are some small remaining fixes for USB and Thunderbolt drivers. Included in here are fixes for: - thunderbold NULL dereference fix - typec driver fixes - xhci driver regression fix - usb-storage divide-by-0 fix - ncm gadget driver fix All of these have been in linux-next with no reported issues" * tag 'usb-6.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: xhci: Fix failure to detect ring expansion need. usb: port: Don't try to peer unused USB ports based on location usb: gadget: ncm: Fix handling of zero block length packets usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group usb: typec: tpcm: Fix PORT_RESET behavior for self powered devices usb: typec: ucsi: fix UCSI on SM8550 & SM8650 Qualcomm devices USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command thunderbolt: Fix NULL pointer dereference in tb_port_update_credits()
…git/gregkh/tty Pull tty / serial fixes from Greg KH: "Here are some small remaining tty/serial driver fixes. Included in here is fixes for: - vt unicode buffer corruption fix - imx serial driver fixes, again - port suspend fix - 8250_dw driver fix - fsl_lpuart driver fix - revert for the qcom_geni_serial driver to fix a reported regression All of these have been in linux-next with no reported issues" * tag 'tty-6.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: Revert "tty: serial: simplify qcom_geni_serial_send_chunk_fifo()" tty: serial: fsl_lpuart: avoid idle preamble pending if CTS is enabled vt: fix unicode buffer corruption when deleting characters serial: port: Don't suspend if the port is still busy serial: 8250_dw: Do not reclock if already at correct rate tty: serial: imx: Fix broken RS485
…ernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are a few small char/misc and other driver subsystem fixes for reported issues that have been in my tree. Included in here are fixes for: - iio driver fixes for reported problems - much reported bugfix for a lis3lv02d_i2c regression - comedi driver bugfix - mei new device ids - mei driver fixes - counter core fix All of these have been in linux-next with no reported issues, some for many weeks" * tag 'char-misc-6.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: mei: gsc_proxy: match component when GSC is on different bus misc: fastrpc: Pass proper arguments to scm call comedi: comedi_test: Prevent timers rescheduling during deletion comedi: comedi_8255: Correct error in subdevice initialization misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume iio: accel: adxl367: fix I2C FIFO data register iio: accel: adxl367: fix DEVID read after reset iio: pressure: dlhl60d: Initialize empty DLH bytes iio: imu: inv_mpu6050: fix frequency setting when chip is off iio: pressure: Fixes BMP38x and BMP390 SPI support iio: imu: inv_mpu6050: fix FIFO parsing when empty mei: Add Meteor Lake support for IVSC device mei: me: add arrow lake point H DID mei: me: add arrow lake point S DID counter: fix privdata alignment
Pull ceph fix from Ilya Dryomov: "A follow-up for sparse read fixes that went into -rc4 -- msgr2 case was missed and is corrected here" * tag 'ceph-for-6.8-rc8' of https://github.com/ceph/ceph-client: libceph: init the cursor when preparing sparse read in msgr2
…nto HEAD KVM x86 fixes for 6.8, round 2: - When emulating an atomic access, mark the gfn as dirty in the memslot to fix a bug where KVM could fail to mark the slot as dirty during live migration, ultimately resulting in guest data corruption due to a dirty page not being re-copied from the source to the target. - Check for mmu_notifier invalidation events before faulting in the pfn, and before acquiring mmu_lock, to avoid unnecessary work and lock contention. Contending mmu_lock is especially problematic on preemptible kernels, as KVM may yield mmu_lock in response to the contention, which severely degrades overall performance due to vCPUs making it difficult for the task that triggered invalidation to make forward progress. Note, due to another kernel bug, this fix isn't limited to preemtible kernels, as any kernel built with CONFIG_PREEMPT_DYNAMIC=y will yield contended rwlocks and spinlocks. https://lore.kernel.org/all/[email protected]
…86/linux into HEAD KVM GUEST_MEMFD fixes for 6.8: - Make KVM_MEM_GUEST_MEMFD mutually exclusive with KVM_MEM_READONLY to avoid creating ABI that KVM can't sanely support. - Update documentation for KVM_SW_PROTECTED_VM to make it abundantly clear that such VMs are purely a development and testing vehicle, and come with zero guarantees. - Limit KVM_SW_PROTECTED_VM guests to the TDP MMU, as the long term plan is to support confidential VMs with deterministic private memory (SNP and TDX) only in the TDP MMU. - Fix a bug in a GUEST_MEMFD negative test that resulted in false passes when verifying that KVM_MEM_GUEST_MEMFD memslots can't be dirty logged.
The DebugSwap feature of SEV-ES provides a way for confidential guests to use data breakpoints. However, because the status of the DebugSwap feature is recorded in the VMSA, enabling it by default invalidates the attestation signatures. In 6.10 we will introduce a new API to create SEV VMs that will allow enabling DebugSwap based on what the user tells KVM to do. Contextually, we will change the legacy KVM_SEV_ES_INIT API to never enable DebugSwap. For compatibility with kernels that pre-date the introduction of DebugSwap, as well as with those where KVM_SEV_ES_INIT will never enable it, do not enable the feature by default. If anybody wants to use it, for now they can enable the sev_es_debug_swap_enabled module parameter, but this will result in a warning. Fixes: d1f85fb ("KVM: SEV: Enable data breakpoints in SEV-ES") Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
…linux/kernel/git/ieee1394/linux1394 Pull firewire fix from Takashi Sakamoto: "A fix to suppress a warning about unreleased IRQ for 1394 OHCI hardware when disabling MSI. In Linux kernel v6.5, a PCI driver for 1394 OHCI hardware was optimized into the managed device resources. Edmund Raile points out that the change brings the warning about unreleased IRQ at the call of pci_disable_msi(), since the API expects that the relevant IRQ has already been released in advance. As long as the API is called in .remove callback of PCI device operation, it is prohibited to maintain the IRQ as the part of managed device resource. As a workaround, the IRQ is explicitly released at .remove callback, before the call of pci_disable_msi(). pci_disable_msi() is legacy API nowadays in PCI MSI implementation. I have a plan to replace it with the modern API in the development for the future version of Linux kernel. So at present I keep them as is" * tag 'firewire-fixes-6.8-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: prevent leak of left-over IRQ on unbind
…nel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Two patches from Heiner for the i801 are targeting muxes discovered while working on some other features. Essentially, there is a reordering when adding optional slaves and proper cleanup upon registering a mux device. Christophe fixes the exit path in the wmt driver that was leaving the clocks hanging, and the last fix from Tommy avoids false error reports in IRQ" * tag 'i2c-for-6.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: aspeed: Fix the dummy irq expected print i2c: wmt: Fix an error handling path in wmt_i2c_probe() i2c: i801: Avoid potential double call to gpiod_remove_lookup_table i2c: i801: Fix using mux_pdev before it's set
A task can wait on a ring buffer for when it fills up to a specific watermark. The writer will check the minimum watermark that waiters are waiting for and if the ring buffer is past that, it will wake up all the waiters. The waiters are in a wait loop, and will first check if a signal is pending and then check if the ring buffer is at the desired level where it should break out of the loop. If a file that uses a ring buffer closes, and there's threads waiting on the ring buffer, it needs to wake up those threads. To do this, a "wait_index" was used. Before entering the wait loop, the waiter will read the wait_index. On wakeup, it will check if the wait_index is different than when it entered the loop, and will exit the loop if it is. The waker will only need to update the wait_index before waking up the waiters. This had a couple of bugs. One trivial one and one broken by design. The trivial bug was that the waiter checked the wait_index after the schedule() call. It had to be checked between the prepare_to_wait() and the schedule() which it was not. The main bug is that the first check to set the default wait_index will always be outside the prepare_to_wait() and the schedule(). That's because the ring_buffer_wait() doesn't have enough context to know if it should break out of the loop. The loop itself is not needed, because all the callers to the ring_buffer_wait() also has their own loop, as the callers have a better sense of what the context is to decide whether to break out of the loop or not. Just have the ring_buffer_wait() block once, and if it gets woken up, exit the function and let the callers decide what to do next. Link: https://lore.kernel.org/all/CAHk-=whs5MdtNjzFkTyaUy=vHi=qwWgPi0JgTe6OYUYMNSRZfg@mail.gmail.com/ Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: linke li <[email protected]> Cc: Rabin Vincent <[email protected]> Fixes: e30f53a ("tracing: Do not busy wait in buffer splice") Signed-off-by: Steven Rostedt (Google) <[email protected]>
Pull kvm fixes from Paolo Bonzini: "KVM GUEST_MEMFD fixes for 6.8: - Make KVM_MEM_GUEST_MEMFD mutually exclusive with KVM_MEM_READONLY to avoid creating an inconsistent ABI (KVM_MEM_GUEST_MEMFD is not writable from userspace, so there would be no way to write to a read-only guest_memfd). - Update documentation for KVM_SW_PROTECTED_VM to make it abundantly clear that such VMs are purely for development and testing. - Limit KVM_SW_PROTECTED_VM guests to the TDP MMU, as the long term plan is to support confidential VMs with deterministic private memory (SNP and TDX) only in the TDP MMU. - Fix a bug in a GUEST_MEMFD dirty logging test that caused false passes. x86 fixes: - Fix missing marking of a guest page as dirty when emulating an atomic access. - Check for mmu_notifier invalidation events before faulting in the pfn, and before acquiring mmu_lock, to avoid unnecessary work and lock contention with preemptible kernels (including CONFIG_PREEMPT_DYNAMIC in non-preemptible mode). - Disable AMD DebugSwap by default, it breaks VMSA signing and will be re-enabled with a better VM creation API in 6.10. - Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock, to avoid a race with unregistering of the same region and the consequent use-after-free issue" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: SEV: disable SEV-ES DebugSwap by default KVM: x86/mmu: Retry fault before acquiring mmu_lock if mapping is changing KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() KVM: selftests: Add a testcase to verify GUEST_MEMFD and READONLY are exclusive KVM: selftests: Create GUEST_MEMFD for relevant invalid flags testcases KVM: x86/mmu: Restrict KVM_SW_PROTECTED_VM to the TDP MMU KVM: x86: Update KVM_SW_PROTECTED_VM docs to make it clear they're a WIP KVM: Make KVM_MEM_GUEST_MEMFD mutually exclusive with KVM_MEM_READONLY KVM: x86: Mark target gfn of emulated atomic instruction as dirty
The "shortest_full" variable is used to keep track of the waiter that is waiting for the smallest amount on the ring buffer before being woken up. When a tasks waits on the ring buffer, it passes in a "full" value that is a percentage. 0 means wake up on any data. 1-100 means wake up from 1% to 100% full buffer. As all waiters are on the same wait queue, the wake up happens for the waiter with the smallest percentage. The problem is that the smallest_full on the cpu_buffer that stores the smallest amount doesn't get reset when all the waiters are woken up. It does get reset when the ring buffer is reset (echo > /sys/kernel/tracing/trace). This means that tasks may be woken up more often then when they want to be. Instead, have the shortest_full field get reset just before waking up all the tasks. If the tasks wait again, they will update the shortest_full before sleeping. Also add locking around setting of shortest_full in the poll logic, and change "work" to "rbwork" to match the variable name for rb_irq_work structures that are used in other places. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: linke li <[email protected]> Cc: Rabin Vincent <[email protected]> Fixes: 2c2b0a7 ("ring-buffer: Add percentage of ring buffer full to wake up reader") Signed-off-by: Steven Rostedt (Google) <[email protected]>
The .release() function does not get called until all readers of a file descriptor are finished. If a thread is blocked on reading a file descriptor in ring_buffer_wait(), and another thread closes the file descriptor, it will not wake up the other thread as ring_buffer_wake_waiters() is called by .release(), and that will not get called until the .read() is finished. The issue originally showed up in trace-cmd, but the readers are actually other processes with their own file descriptors. So calling close() would wake up the other tasks because they are blocked on another descriptor then the one that was closed(). But there's other wake ups that solve that issue. When a thread is blocked on a read, it can still hang even when another thread closed its descriptor. This is what the .flush() callback is for. Have the .flush() wake up the readers. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: linke li <[email protected]> Cc: Rabin Vincent <[email protected]> Fixes: f3ddb74 ("tracing: Wake up ring buffer waiters on closing of the file") Signed-off-by: Steven Rostedt (Google) <[email protected]>
…el/git/phy/linux-phy Pull phy fixes from Vinod Koul: - fixes for Qualcomm qmp-combo driver for ordering of drm and type-c switch registartion due to drivers might not probe defer after having registered child devices to avoid triggering a probe deferral loop. This fixes internal display on Lenovo ThinkPad X13s * tag 'phy-fixes3-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: qcom-qmp-combo: fix type-c switch registration phy: qcom-qmp-combo: fix drm bridge registration
…m/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Do not allow large strings (> 4096) as single write to trace_marker The size of a string written into trace_marker was determined by the size of the sub-buffer in the ring buffer. That size is dependent on the PAGE_SIZE of the architecture as it can be mapped into user space. But on PowerPC, where PAGE_SIZE is 64K, that made the limit of the string of writing into trace_marker 64K. One of the selftests looks at the size of the ring buffer sub-buffers and writes that plus more into the trace_marker. The write will take what it can and report back what it consumed so that the user space application (like echo) will write the rest of the string. The string is stored in the ring buffer and can be read via the "trace" or "trace_pipe" files. The reading of the ring buffer uses vsnprintf(), which uses a precision "%.*s" to make sure it only reads what is stored in the buffer, as a bug could cause the string to be non terminated. With the combination of the precision change and the PAGE_SIZE of 64K allowing huge strings to be added into the ring buffer, plus the test that would actually stress that limit, a bug was reported that the precision used was too big for "%.*s" as the string was close to 64K in size and the max precision of vsnprintf is 32K. Linus suggested not to have that precision as it could hide a bug if the string was again stored without a nul byte. Another issue that was brought up is that the trace_seq buffer is also based on PAGE_SIZE even though it is not tied to the architecture limit like the ring buffer sub-buffer is. Having it be 64K * 2 is simply just too big and wasting memory on systems with 64K page sizes. It is now hardcoded to 8K which is what all other architectures with 4K PAGE_SIZE has. Finally, the write to trace_marker is now limited to 4K as there is no reason to write larger strings into trace_marker. - ring_buffer_wait() should not loop. The ring_buffer_wait() does not have the full context (yet) on if it should loop or not. Just exit the loop as soon as its woken up and let the callers decide to loop or not (they already do, so it's a bit redundant). - Fix shortest_full field to be the smallest amount in the ring buffer that a waiter is waiting for. The "shortest_full" field is updated when a new waiter comes in and wants to wait for a smaller amount of data in the ring buffer than other waiters. But after all waiters are woken up, it's not reset, so if another waiter comes in wanting to wait for more data, it will be woken up when the ring buffer has a smaller amount from what the previous waiters were waiting for. - The wake up all waiters on close is incorrectly called frome .release() and not from .flush() so it will never wake up any waiters as the .release() will not get called until all .read() calls are finished. And the wakeup is for the waiters in those .read() calls. * tag 'trace-ring-buffer-v6.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Use .flush() call to wake up readers ring-buffer: Fix resetting of shortest_full ring-buffer: Fix waking up ring buffer readers tracing: Limit trace_marker writes to just 4K tracing: Limit trace_seq size to just 8K and not depend on architecture PAGE_SIZE tracing: Remove precision vsnprintf() check from print event
Linux 6.8
the ipc timeouts have now become DSP panics, not sure what to make of all this @kv2019i ... |
SOFCI TEST |
@plbossart The fails are caused by thesofproject/sof#8942 and thesofproject/sof#8908 . Latter is fixed in SOF main now, I have a bugfix for former , test build at thesofproject/sof#8944 |
SOFCI TEST |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
quick merge to see if any of the 6.8 patches broke our platforms.