On Wed, 30 Mar 2022, Jani Nikula jani.nikula@intel.com wrote:
On Wed, 30 Mar 2022, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
This one points to extension blocks too so using struct edid doesn't seem entirely appropriate.
So I've gone back and forth with this. I think I want to get rid of u8* no matter what, because it always requires casting. I've used void* here and there to allow mixed use, internally in drm_edid.c while transitioning, and in public interfaces due to usage all over the place.
OTOH I don't much like arithmetics on void*. It's a gcc extension.
struct edid * is useful for e.g. ->checksum and arithmetics. In many places I've named it struct edid *block to distinguish. We could have a struct edid_block too, which could have ->tag and ->checksum members, for example, but then it would require casting or a function for "safe" typecasting.
I've also gone back and forth with the helpers for getting a pointer to a block. For usage like this, kind of need both const and non-const versions. And, with the plans I have for future, I'm not sure I want to promote any EDID parsing outside of drm_edid.c, so maybe they should be static.
Undecided. C is a bit clunky here.
Hmm. I wonder how a flexible array member would pan out.
struct edid_extension { u8 tag; u8 revision; u8 data[EDID_LENGTH - 3]; u8 checksum; } __packed;
struct edid { /* existing stuff*/ struct edid_extension extensions[]; } __packed;
BR, Jani.