RE: [PATCH v2] drm/ast: DisplayPort edid supports 256 bytes

[Jani Nikula <jani.nikula@linux.intel.com>]

On Tue, 21 Jul 2026, Jammy Huang <jammy_huang@aspeedtech.com> wrote:
> Hi Thomas,
>
> Good catch - returning 0 without writing to buf wasn't safe. But I
> also found that returning -EIO isn't right either: _drm_do_get_edid()
> treats EDID_BLOCK_READ_FAIL as fatal for any block index, not just
> block 0, so that would have discarded the whole EDID for any monitor
> reporting more than one extension.
>
> In v3, for block > 1 I now zero the buffer explicitly and return
> 0. That makes drm_edid's block checker classify it as EDID_BLOCK_ZERO
> instead, which is non-fatal - it gets trimmed via
> edid_filter_invalid_blocks() (extensions count reduced, checksum
> recomputed), and blocks 0 and 1 still come through fine. This also
> directly addresses your point about the buffer not being guaranteed
> zeroed, since we zero it ourselves now.

There's a long-term goal to *not* modify the EDID in kernel, but rather
return even the broken EDID extensions to userspace, if that's what the
display has.

There are probably a bunch of hurdles in making that happen, but
intentionally returning zeroed out EDID blocks is just adding another
unnecessary hurdle.


BR,
Jani.


-- 
Jani Nikula, Intel