On Wed, 30 Mar 2022, Jani Nikula <jani.nik...@intel.com> wrote:
> On Wed, 30 Mar 2022, Ville Syrjälä <ville.syrj...@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.
--
Jani Nikula, Intel Open Source Graphics Center
