Hi Jani, Thanks for the guidance. I've set the quirk revision aside and attached the full, uncompressed boot-to-failure dmesg from the unpatched control kernel, with the requested DRM debug parameters:
https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3678430 The failure reproduced at 1920x1080, with the native 3440x1440 mode missing. Only identifying strings were redacted; no log lines were removed. I'll continue the root-cause investigation on the GitLab issue and use those findings to guide a revised patch. Best, Conor On Thu, 24 Sept 2026 at 09:03, Jani Nikula <[email protected]> wrote: > On Wed, 23 Sep 2026, Conor Svensson <[email protected]> wrote: > > Reconnecting an Anker 565 A8388 USB-C hub with a DisplayPort monitor > > attached can leave the branch reporting a DVI downstream descriptor > > with 25-165 MHz TMDS limits. On a ThinkPad L14 Gen 4 Intel with a Dell > > S3422DWG, this removes the native 3440x1440 mode from the connector's > > mode list even though the EDID still contains it. An explicit native > > modeline works with the same hardware state. > > > > Ignore the derived TMDS limits only for the captured branch identity, > > firmware and downstream descriptor when EDID 1.4 identifies a digital > > DisplayPort input. Retain the raw descriptor and other mode checks. > > Do not restrict the match to a particular monitor or laptop model. > > > > With otherwise matching upstream Linux 7.2.5 control/patched builds, > > the control loses native modes after USB-C reconnect, while the patched > > kernel selects 3440x1440 at 59.973 Hz automatically. Repeated reconnects, > > both USB-C ports, suspend/resume, undocking while asleep and docked boot > > pass. HDMI also works and does not activate the workaround. Periodic > > picture cycling observed on the control stops with the patch. > > > > The branch identity is not proven unique to this retail adapter. This > > is an experimental workaround for review, not an explanation of why the > > branch reports inconsistent capabilities. Other adapters and monitors > > have not been tested. > > > > Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180 > > Assisted-by: LLM > > Signed-off-by: Conor Svensson <[email protected]> > > --- > > RFC: is this best handled as a branch quirk here, or in the common DP > > helpers? The captured identity and descriptor match is deliberately > narrow; > > there is no monitor/laptop model restriction. The informational log > marker > > is retained to show exactly when this experimental workaround executes. > > The commit introducing the underlying problem has not been identified, so > > there is no speculative Fixes tag. > > > > Hardware A/B testing used upstream Linux 7.2.5 with otherwise identical > > configurations. This RFC applies the same 48 added lines to drm-tip at > the > > base commit below. This drm-tip revision has not been boot-tested. The > affected intel_dp.o > > compiles successfully here with no compiler warnings; strict checkpatch > > passes (human sign-off pending), and 426 predicate boundary cases pass > > with ASan/UBSan. These predicate tests are not DRM integration tests. > > > > Results: three USB-C reconnects, alternate USB-C port, docked s2idle > > resume plus reconnect, undock while asleep/wake/reconnect, and docked > > DisplayPort reboot all passed. HDMI also passed without activating the > > workaround. The control lost native modes and showed periodic picture > > cycling; that cycling stopped on the patched kernel. No custom modeline > > was used in either test kernel. Other hardware and higher refresh rates > > remain untested. > > > > AI assistance: Codex (GPT-6) helped investigate the reported hotplug > > failure, wrote the match/limit-clearing change, prepared the predicate > > tests, collected diagnostics and drafted this message. The human reporter > > performed the physical reconnect, suspend and reboot tests and confirmed > > the visible results. The assistance arose from an extended > troubleshooting > > session, rather than a single code-generation prompt. > > > > Evidence and detailed test results: > > > https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/17180#note_3677750 > > > > This is my first kernel patch submission. I'd appreciate feedback on > > whether this belongs here or in the common DP helpers, and whether the > > matching criteria are appropriate. > > Thanks for the patch. Please let's first root cause the issue (on the > gitlab issue) before jumping into quirking specific devices. > > Regardless, a few comments below. > > > > > Thanks, > > Conor > > > > drivers/gpu/drm/i915/display/intel_dp.c | 48 +++++++++++++++++++++++++ > > 1 file changed, 48 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > > index ffddf4b33..6d6767ca7 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -6153,6 +6153,39 @@ intel_dp_get_edid(struct intel_dp *intel_dp) > > return drm_edid_read_ddc(&connector->base, &intel_dp->aux.ddc); > > } > > > > +static bool > > +intel_dp_has_anker_tmds_mismatch(struct intel_dp *intel_dp, > > + const struct drm_edid *drm_edid) > > +{ > > + static const struct drm_dp_dpcd_ident branch = { > > + .oui = { 0x90, 0xcc, 0x24 }, > > + .device_id = { 'S', 'Y', 'N', 'A', 'b', 0x10 }, > > + .hw_rev = 0x10, > > + .sw_major_rev = 0x06, > > + .sw_minor_rev = 0x05, > > + }; > > + static const u8 downstream_ports[] = { > > + 0x0a, 0x42, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > + }; > > intel_dp->downstream_ports is read from DPCD address 0x80, and it > dynamically reflects the downstream port information, i.e. what's > currently connected to the branch device. Having a fixed comparison like > this will only work for a specific type of downstream device connected > to a specific downstream port. > > > + const struct edid *edid = drm_edid_raw(drm_edid); > > No new drm_edid_raw() calls are to be added. > > > + > > + if (intel_dp_is_edp(intel_dp) || intel_dp->is_mst || > > + !drm_dp_is_branch(intel_dp->dpcd) || !edid) > > + return false; > > + > > + /* HDMI and DVI inputs must retain their downstream limits. */ > > + if (edid->version != 1 || edid->revision < 4 || > > + !(edid->input & DRM_EDID_INPUT_DIGITAL) || > > + (edid->input & DRM_EDID_DIGITAL_TYPE_MASK) != > DRM_EDID_DIGITAL_TYPE_DP) > > + return false; > > + > > + return !memcmp(&intel_dp->desc.ident, &branch, sizeof(branch)) && > > + !memcmp(intel_dp->downstream_ports, downstream_ports, > > + sizeof(downstream_ports)) && > > + intel_dp->dfp.min_tmds_clock == 25000 && > > + intel_dp->dfp.max_tmds_clock == 165000; > > +} > > We have intel_quirks.c with various structured mechanisms for > identifying quirks. If we end up needing a quirk for this, the existing > mechanisms need to be used instead of adding a bunch of code inline like > this. > > Again, please let's first root cause and debug the issue instead of > trying to fix the patch. > > BR, > Jani. > > > > + > > static void > > intel_dp_update_dfp(struct intel_dp *intel_dp, > > const struct drm_edid *drm_edid) > > @@ -6181,6 +6214,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp, > > drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd, > > intel_dp->downstream_ports); > > > > + /* > > + * Experimental workaround for the branch observed in an Anker > A8388. > > + * USB-C hotplug can expose a DVI descriptor for the DP output. The > > + * monitor's native timing works when requested explicitly, despite > > + * the reported 165 MHz limit. Keep the captured identity and > failure > > + * signature checks narrow until the underlying cause is > understood. > > + */ > > + if (intel_dp_has_anker_tmds_mismatch(intel_dp, drm_edid)) { > > + intel_dp->dfp.min_tmds_clock = 0; > > + intel_dp->dfp.max_tmds_clock = 0; > > + drm_info(display->drm, > > + "[CONNECTOR:%d:%s] experimental Anker DP TMDS > limit workaround\n", > > + connector->base.base.id, connector->base.name); > > + } > > + > > drm_dbg_kms(display->drm, > > "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, > TMDS clock %d-%d, PCON Max FRL BW %dGbps\n", > > connector->base.base.id, connector->base.name, > > > > base-commit: 703cd271db3a35088460ab3fec0a96bd48e7fe04 > > -- > Jani Nikula, Intel > -- *Conor Svensson* Schedule a Meeting <https://calendar.app.google/qwPdNGAewy95Bmbn9> +44 (0) 7497 376 365 LinkedIn <https://www.linkedin.com/in/conorsvensson/> X (Twitter) <https://twitter.com/conorsvensson> Telegram <https://t.me/conor10>
