On Wed Mar 18, 2026 at 1:07 PM JST, Eliot Courtney wrote: > Add locking to Cmdq. This is required e.g. for unloading the driver, > which needs to send the UnloadingGuestDriver via the command queue > on unbind which may be on a different thread. > > We have commands that need a reply and commands that don't. For > commands with a reply we want to make sure that they don't get > the reply of a different command back. The approach this patch series > takes is by making those commands block until they get a response. For > now this should be ok, and we expect GSP to be fast anyway. > > To do this, we need to know which commands expect a reply and which > don't. John's existing series[1] adds IS_ASYNC which solves part of the > problem, but we need to know a bit more. So instead, add an > associated type called Reply which tells us what the reply is. > > An alternative would be to define traits inheriting CommandToGsp, e.g. > CommandWithReply and CommandWithoutReply, instead of using the > associated type. I implemented the associated type version because it > feels more compositional rather than inherity so seemed a bit better > to me. But both of these approaches work and are fine, IMO. > > In summary, this patch series has three steps: > 1. Add the type infrastructure to know what replies are expected for a > command and update each caller to explicitly wait for the reply or > not. > 2. Make Cmdq pinned so we can use Mutex > 3. Add a Mutex to protect Cmdq by moving the relevant state to an > inner struct. > > [1]: https://lore.kernel.org/all/[email protected]/ > > Signed-off-by: Eliot Courtney <[email protected]>
Merged into drm-rust-next, thanks!
