linux/drivers, branch v6.7

Merge tag 'i2c-for-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2024-01-06T19:35:37Z

Pull i2c fixes from Wolfram Sang: "Improve the detection when to run atomic transfer handlers for kernels with preemption disabled. This removes some false positive splats a number of users were seeing if their driver didn't have support for atomic transfers. Also, fix a typo in the docs while we are here" * tag 'i2c-for-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: core: Fix atomic xfer check for non-preempt config Documentation/i2c: fix spelling error in i2c-address-translators

i2c: core: Fix atomic xfer check for non-preempt config

2024-01-06T13:10:10Z

Since commit aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible"), the whole reboot/power off sequence on non-preempt kernels is using atomic i2c xfer, as !preemptible() always results to 1. During device_shutdown(), the i2c might be used a lot and not all busses have implemented an atomic xfer handler. This results in a lot of avoidable noise, like: [ 12.687169] No atomic I2C transfer handler for 'i2c-0' [ 12.692313] WARNING: CPU: 6 PID: 275 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x118 ... Fix this by allowing non-atomic xfer when the interrupts are enabled, as it was before. Link: https://lore.kernel.org/r/20231222230106.73f030a5@yea Link: https://lore.kernel.org/r/20240102150350.3180741-1-mwalle@kernel.org Link: https://lore.kernel.org/linux-i2c/13271b9b-4132-46ef-abf8-2c311967bb46@mailbox.org/ Fixes: aa49c90894d0 ("i2c: core: Run atomic i2c xfer when !preemptible") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Benjamin Bara Tested-by: Michael Walle Tested-by: Tor Vic [wsa: removed a comment which needs more work, code is ok] Signed-off-by: Wolfram Sang

Merge tag 'firewire-fixes-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394

2024-01-05T20:26:26Z

Pull firewire fix from Takashi Sakamoto: "A single patch to suppress unexpected system reboot in AMD Ryzen machines with PCIe card consisting of Asmedia ASM1083/1085 and VT6306/6307/6308. When the 1394 OHCI driver for the card accesses a specific register in PCI memory space, the system reboot often occurs. The issue affects all versions of Linux kernel as long as the 1394 OHCI driver is included. The mechanism of unexpected system reboot is not clear, so the driver is changed to avoid the access itself when detecting the combination of hardware" * tag 'firewire-fixes-6.7-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards

Merge tag 'mmc-v6.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

2024-01-05T20:12:33Z

Pull MMC fixes from Ulf Hansson: "MMC core: - Fix releasing the host by canceling the delayed work - Fix pause retune on all RPMB partitions MMC host: - meson-mx-sdhc: Fix HW hang during card initialization - sdhci-sprd: Fix eMMC init failure after HW reset" * tag 'mmc-v6.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-sprd: Fix eMMC init failure after hw reset mmc: core: Cancel delayed work before releasing host mmc: rpmb: fixes pause retune on all RPMB partitions. mmc: meson-mx-sdhc: Fix initialization frozen issue

Merge tag 'drm-fixes-2024-01-05' of git://anongit.freedesktop.org/drm/drm

2024-01-05T20:02:20Z

Pull more drm fixes from Dave Airlie: "The amdgpu ones are fairly normal, the one that is a bit large is a fix for a newly introduced IP in 6.7 so unlikely to cause regressions. The nouveau ones are mostly memory leaks and debugging cleanups from the GSP (new nvidia firmware) enablement. There are some GSP changes to the message passing code and a subsequent fix for eDP panel turn on, that means my laptop can turn on the panel in GSP mode. These are fairly low chance of disrupting things since GSP is new in 6.7. The final not all in GSP fix is a deadlock seen with i915/nouveau when GSP is used where the the fence and irq paths have locking inversions, I've pushed some irq enablement out to a workqueue, and this has seen some fairly decent testing. amdgpu: - DP MST fix - SMU 13.0.6 fixes - fix displays on macbooks using vega12 - fix VSC and colorimetry on DP/eDP nouveau: - fix deadlock between fence signalling and irq paths - fix GSP memory leaks - fix GSP leftover debug - hide some GSP callback messages - fix GSP display disable path - fix GSP ACPI interaction - handle errors in ctrl messages - use errors info to fix DP link training" * tag 'drm-fixes-2024-01-05' of git://anongit.freedesktop.org/drm/drm: drm/nouveau/dp: Honor GSP link training retry timeouts nouveau: push event block/allowing out of the fence context nouveau/gsp: always free the alloc messages on r535 nouveau/gsp: don't free ctrl messages on errors nouveau/gsp: convert gsp errors to generic errors drm/nouveau/gsp: Fix ACPI MXDM/MXDS method invocations nouveau/gsp: free userd allocation. nouveau/gsp: free acpi object after use nouveau: fix disp disabling with GSP nouveau/gsp: drop some acpi related debug nouveau/gsp: add three notifier callbacks that we see in normal operation (v2) drm/amd/pm: Use gpu_metrics_v1_5 for SMUv13.0.6 drm/amd/pm: Add gpu_metrics_v1_5 drm/amd/pm: Add mem_busy_percent for GCv9.4.3 apu drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays without PSR drm/amdgpu: skip gpu_info fw loading on navi12 drm/amd/display: add nv12 bounding box drm/amd/pm: Update metric table for jpeg/vcn data drm/amd/pm: Use separate metric table for APU drm/amd/display: pbn_div need be updated for hotplug event

firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards

2024-01-05T12:28:08Z

VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge, it appears that accesses to its 'Isochronous Cycle Timer' register (offset 0xf0 on PCI memory space) often causes unexpected system reboot in any type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not appears in the other type of machine (AMD pre-Ryzen machine, Intel machine, at least), or in the other OHCI 1394 hardware (e.g. Texas Instruments). The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion") added to v6.5 kernel. It changed 1394 OHCI driver to access to the register every time to dispatch local asynchronous transaction. However, the issue exists in older version of kernel as long as it runs in AMD Ryzen machine, since the access to the register is required to maintain bus time. It is not hard to imagine that users experience the unexpected system reboot when generating bus reset by plugging any devices in, or reading the register by time-aware application programs; e.g. audio sample processing. This commit suppresses the unexpected system reboot in the combination of hardware. It avoids the access itself. As a result, the software stack can not provide the hardware time anymore to unit drivers, userspace applications, and nodes in the same IEEE 1394 bus. It brings apparent disadvantage since time-aware application programs require it, while time-unaware applications are available again; e.g. sbp2. Cc: stable@vger.kernel.org Reported-by: Jiri Slaby Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 Reported-by: Mario Limonciello Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 Reported-by: Tobias Gruetzmacher Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/ Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973 Closes: https://bugs.launchpad.net/linux/+bug/2043905 Link: https://lore.kernel.org/r/20240102110150.244475-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto

drm/nouveau/dp: Honor GSP link training retry timeouts

2024-01-05T02:27:53Z

Turns out that one of the ways that Nvidia's driver handles the pre-LT timeout for eDP panels is by providing a retry timeout in their link training callbacks that we're expected to wait for. Up until now we didn't pay any attention to this parameter. So, start honoring the timeout if link training fails - and retry up to 3 times. The "3 times" bit comes from OpenRM's link training code. [airlied: this fixes the panel on one of my laptops] Signed-off-by: Lyude Paul Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-12-airlied@gmail.com

nouveau: push event block/allowing out of the fence context

2024-01-05T02:27:53Z

There is a deadlock between the irq and fctx locks, the irq handling takes irq then fctx lock the fence signalling takes fctx then irq lock This splits the fence signalling path so the code that hits the irq lock is done in a separate work queue. This seems to fix crashes/hangs when using nouveau gsp with i915 primary GPU. Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-11-airlied@gmail.com

nouveau/gsp: always free the alloc messages on r535

2024-01-05T02:27:53Z

Fixes a memory leak seen with kmemleak. Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-10-airlied@gmail.com

nouveau/gsp: don't free ctrl messages on errors

2024-01-05T02:27:53Z

It looks like for some messages the upper layers need to get access to the results of the message so we can interpret it. Rework the ctrl push interface to not free things and cleanup properly whereever it errors out. Requested-by: Lyude Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-9-airlied@gmail.com