Linux Recent Activity: AMDGPU, CAN, and SMB Stability Fixes
The Linux kernel is the upstream kernel behind most Linux systems, and this recent activity is worth reading if you ship kernels or debug hardware oddities. The headline change is AMDGPU display and resume stability, backed by a wider batch of CAN BCM, SMB, and suspend fixes across 189 commits in the staged review.
AMDGPU display timing drops a workaround
The most visible AMDGPU thread is in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c, which was touched seven times. This is not new user API work. It is the kind of driver timing repair that users only notice when it fails: cursor updates hang, page flips time out, or the screen shows stale content at exactly the wrong moment.
The maintainers consolidated DCN vblank and flip handling onto VUPDATE_NO_LOCK. The commit message explains why that matters. On DCN hardware, older interrupt sources can be masked by display pipe power gating, global sync lock, or MALL scanout. VUPDATE_NO_LOCK keeps firing while the output timing generator is active, so it is a better single source for vblank and flip completion events.
That refactor only works if userspace gets a flip event after hardware has really latched the new buffer. The follow up checks the hardware flip pending state before sending the event. That closes a nasty window where userspace could be told a flip had completed while the old buffer was still active. That is how you get corruption that looks random until someone reads the interrupt path with coffee and patience.
With those fixes in place, the project then reverted the five second vblank off delay workaround. That is a good signal. A timeout bandage disappeared because the underlying event path became less fragile.
Resume and reset paths get less fragile
Another AMD theme is machine resume. The maintainers created an AMD APU display to XHCI device link so the GPU display function can finish resume before the related USB controller resumes devices. The failure mode in the commit message is practical: xhci_hcd reports that the host is not responding, then the controller dies during cleanup.
For laptop fleets, this is the type of fix that matters more than a benchmark. It targets systems where integrated display and USB sit under the same PCIe root path and where GPU resume is slower than the USB resume path. If users report USB devices failing only after suspend, this commit belongs on the shortlist.
AMDGPU reset handling also moved. The team fixed an indefinite fence wait during GPU reset by force completing every queue fence, not only queues in the mapped state. Without that, a queue caught during eviction could leave a fence pending forever, blocking the eviction or suspend worker. Kernel hangs with blocked workqueue traces are not subtle. They just waste afternoons.
There are smaller but still useful AMD fixes in the same cluster:
- Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge to avoid freezes during GPU init on affected CPUs.
- Fix AC/DC switch notification for SMU7 so clock limits are recomputed when power source changes.
- Avoid thermal work scheduling when DPM is disabled because an uninitialized work queue is not a lifestyle choice.
AMDGPU crash dumps become more useful
Debug output also improved. drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c appears in the top changed files, and the changes are small but high value when a GPU fault lands on your desk.
The maintainers added VMID, PASID, and more task data to AMDGPU device dumps. They also reserved space for IB contents in devcoredumps, so the dump does not cut off the interesting command buffer data too early.
This is mostly internal plumbing, but it changes support quality. When a reset or fault happens under load, the difference between a useful dump and a truncated one is often the difference between a patch and a shrug. More context in the dump also reduces the need to scrape matching details from dmesg by hand.
CAN BCM and SMB fixes harden old edges
The busiest file in the staged summary is net/can/bcm.c, with 11 commits touching it. The theme is concurrency and lifetime hygiene in the CAN broadcast manager. That area has old state machines, timers, sockets, RCU, device removal, and receive filters meeting in one room. No surprise that the fixes are detailed.
The BCM batch tightens several concrete cases:
- Timer teardown moves to sleepable context so high resolution timers can be cancelled safely.
ANYDEVreceive operations now keep one detected source interface while timeout or throttle timers are active.RX_SETUPand RTR reply paths get better validation and less silent failure.- Device removal no longer leaves stale receive or transmit operations behind.
SMB saw similar edge cleanup. Client side changes in fs/smb/client/smb2ops.c focus on fallocate behavior, dirty data, hole punching, allocation size refresh, and buffer sizing. Server side changes in fs/smb/server/smb2pdu.c include multichannel session key handling and read alignment safety. These are not glamorous paths, but file systems earn trust in exactly this kind of boring corner.
The storage side has a similar flavor. The i.MX SDHCI host work is about suspend and resume ordering: restore pin state before timing, disable IRQs during suspend, handle resume failures without touching unclocked registers, and keep WiFi wake cases from turning into irq xxx: nobody cared.
What to watch
Backports matter here. Many AMDGPU commits in the staged set carry stable tags, so distribution kernels may receive these fixes without waiting for a large release train.
Test real workflows, not only boot. For AMD systems, cover suspend, resume, USB after resume, brightness controls, DP MST, GPU reset, and workloads that use user queues.
For CAN BCM users, pay attention to multi interface receive setups, ifindex == 0, timeout timers, RTR replies, and device removal. For SMB users, retest fallocate and hole punching against both Samba and ksmbd. This is where small kernel fixes either prove themselves or come back with teeth.