Hello Michael, Thanks for the CoCo context, that lines up with what is in vmbus_devs[] for the framebuffer device. The piecemeal approach is what I am aiming for here.
v3 is on the list and addresses your three concrete points: > This change should probably be a separate patch, as it's not really > related to the bounds checking issue. > [...] > All that notwithstanding, I don't think your fix is needed in its > current form. Dropped from v3. You are right that the negotiate-version and update-vram-location timeouts let hyperv_vmbus_probe() bail out and free the device, so the stale-completion path is only reachable from hyperv_vmbus_resume() after a get_supported_resolution() timeout. That is a narrower fix and belongs in a separate patch against the resume path, which I will send afterwards. > Is there a separate problem here in that preferred_width and > preferred_height are not set in the pre-WIN10 case? Yes, separate problem, and I missed it in v2. The pre-WIN10 branch in hyperv_connect_vsp() sets only screen_*_max and leaves preferred_* at zero, which is inconsistent with the WIN10-failure path. > Also, having to duplicate the fallback code is distasteful. Instead > of having an "else" clause, maybe have a follow-up test for > screen_width_max [...] being zero as an indicator [...] Adopted in v3. The else branch is gone; the WIN10 path runs the probe and the post-probe block applies the WIN8 defaults whenever screen_width_max is still zero. One source of truth, both paths converge on it. > In my view, your commit message is a bit too detailed. Rewritten in v3. The bounds check and the WIN8 fallback are now one short paragraph each, focused on the "why". Series: <[email protected]> The v3 patches carry an `Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline` trailer per the kernel coding-assistants policy. Code, analysis and review responses are mine; the model is used as a structured reviewer under human verification. Thanks, Berkant
