On Thu, Oct 15, 2026 at 10:26:15PM +0200, Lukas Wunner wrote: > I'd love to, but both v1 and v2 have sashiko findings that nobody bothered > to debunk or fix. (The fix for v1 consisted of removing a callback, which > triggered other sashiko findings.) I'm neither an expert on this driver > nor the tiny drm library, but I'd like to help improve Linux Mac support. > Please help me understand whether the sashiko findings are valid.
Thanks for looking at it, and sorry for leaving the findings unanswered. I went through all of them; in short, the v1 finding and the first two v2 findings are valid. v3 brings back reset_resume with the error path fixed: https://lore.kernel.org/all/[email protected]/ v1, "memory leak of suspend_state on reset_resume error": valid. If appletbdrm_get_information() or appletbdrm_signal_readiness() fails, reset_resume returns before drm_mode_config_helper_resume(), so the state saved by drm_mode_config_helper_suspend() is never put, and fbdev/polling stay suspended. The USB core only logs a reset_resume error and keeps the driver bound, so nothing else cleans it up. v3 logs the handshake error and still calls drm_mode_config_helper_resume(), the same way udl and gm12u320 do it. v2, "missing reset_resume breaks reset recovery": valid, and not only in theory. v2 dropped reset_resume because the device was not reset on resume, but with the current t2linux 7.2.11 kernel (which carries v2) the Touch Bar is reset on every resume here (MacBookPro16,2, S3): usb 5-6: reset high-speed USB device number 7 using t2bce_core [drm] Initialized appletbdrm 1.0.0 for 5-6:2.1 on minor 2 Without reset_resume the USB core unbinds and probes the driver again, tiny-dfr loses its device and the Touch Bar stays dark, which is the bug the patch is meant to fix. With v1 (reset_resume doing the probe handshake) on the same kernel the reset still happens, but the driver is not probed again and the Touch Bar works after resume. v2, "suspend_state leaked on unbind while suspended": with reset_resume back, a reset no longer unbinds the driver, which was the scenario sashiko described. What is left is the device going away while the system sleeps: then disconnect runs without a resume and the saved state is not freed. As far as I can see udl and gm12u320 have the same gap, and drm_mode_config_cleanup() does not free suspend_state either. v3 leaves it out; I can drop the saved state in appletbdrm_disconnect() in a follow-up, or it could be fixed once in the helpers if the DRM maintainers prefer that. v3 is tested on the t2linux 7.2.11 kernel: 7 suspend/resume cycles, the Touch Bar was reset on each resume, the driver was not probed again, tiny-dfr kept running and the Touch Bar worked every time. (I went through the findings with the help of an AI assistant, Claude; the logs and tests are from my machine.) Thanks, Vasilij
