Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [Medium] drm: edid_overridden flag not set in fallback override path
--

commit e2139c9168877ee02f537cbf19084a0d24c136be
Author: Johannes Wüller <[email protected]>

drm: add edid_overridden flag to drm_connector

When an EDID override is in effect, the physical connector may not
match reported capabilities. Adds a drm_connector flag that allows
drivers to detect such mismatches.

> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 42f4e41c459fd..9ea6f5f19131f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2424,6 +2424,7 @@ static struct edid *_drm_do_get_edid(struct 
> drm_connector *connector,
>       struct edid *edid, *new;
>       size_t alloc_size = EDID_LENGTH;
>  
> +     connector->edid_overridden = false;
>       override = drm_edid_override_get(connector);
>       if (override) {
>               alloc_size = override->size;
> @@ -2431,6 +2432,7 @@ static struct edid *_drm_do_get_edid(struct 
> drm_connector *connector,
>               drm_edid_free(override);
>               if (!edid)
>                       return NULL;
> +             connector->edid_overridden = true;

[Severity: Medium]
Does this new flag also need to be set when falling back to an override EDID
after a failed DDC probe?

If an EDID override is provided but the physical DDC probe fails (e.g. due to
broken DDC lines), drm_helper_probe_get_modes() skips reading the EDID and
falls back to drm_edid_override_connector_update(). This fallback applies the
override but appears to miss setting this new flag:

drivers/gpu/drm/drm_edid.c:drm_edid_override_connector_update() {
        const struct drm_edid *override;
        int num_modes = 0;

        override = drm_edid_override_get(connector);
        if (override) {
                if (drm_edid_connector_update(connector, override) == 0)
                        num_modes = drm_edid_connector_add_modes(connector);

                drm_edid_free(override);
        ...
}

If a driver relies on this flag to apply HDMI signal type workarounds, could
this cause it to read a false value and fail to apply the necessary quirks?

>               goto ok;
>       }
>  

[ ... ]

-- 
Sashiko AI review · 
https://sashiko.dev/#/patchset/[email protected]?part=1

Reply via email to