• Daniel Vetter's avatar
    drm/probe-helper: don't lose hotplug event · 162b6a57
    Daniel Vetter authored
    There's a race window (small for hpd, 10s large for polled outputs)
    where userspace could sneak in with an unrelated connnector probe
    ioctl call and eat the hotplug event (since neither the hpd nor the
    poll code see a state change).
    
    To avoid this, check whether the connector state changes in all other
    ->detect calls (in the current helper code that's only probe_single)
    and if that's the case, fire off a hotplug event. Note that we can't
    directly call the hotplug event handler, since that expects that no
    locks are held (due to reentrancy with the fb code to update the kms
    console).
    
    Also, this requires that drivers using the probe_single helper
    function set up the poll work. All current drivers do that already,
    and with the reworked hpd handling there'll be no downside to
    unconditionally setting up the poll work any more.
    
    v2: Review from Rob Clark
    - Don't bail out of the output poll work immediately if it's disabled
      to make sure we deliver the delayed hoptplug events. Instead just
      jump to the tail.
    - Don't scheduel the work when it's not set up. Would be a driver bug
      since using probe helpers for anything dynamic without them
      initialized makes them all noops.
    
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
    Cc: Rob Clark <robdclark@gmail.com>
    Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
    Tested-by: default avatarRob Clark <robdclark@gmail.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    162b6a57
drm_probe_helper.c 16 KB