Re: [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()

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

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.

-- 
Jani Nikula, Intel Open Source Graphics Center