Re: [PATCH i-g-t v5 8/8] lib/igt_kms: add macros to iterate color pipelines and colorops

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

On Thu, 03 Sep 2026, Jani Nikula <jani.nikula@intel.com> wrote:
> On Wed, 02 Sep 2026, Melissa Wen <mwen@igalia.com> wrote:
>> @@ -1027,6 +1028,31 @@ uint64_t igt_colorop_get_prop(igt_display_t *display, igt_colorop_t *colorop, en
>>  		igt_colorop_set_prop_changed(colorop, prop); \
>>  	} while (0)
>>  
>> +/**
>> + * for_each_color_pipeline:
>> + * @plane: plane to which the color pipelines belong
>> + * @color_pipeline: the color pipeline to iterate
>> + *
>> + * Iterates through all color pipelines supported by @plane. If no color
>> + * pipeline is supported, nothing happens.
>> + */
>> +#define for_each_color_pipeline(plane, color_pipeline) \
>> +	for (int igt_unique(__i) = 0; \
>> +	     igt_unique(__i) < (plane)->num_color_pipelines && \
>> +	     ((color_pipeline) = (plane)->color_pipelines[igt_unique(__i)], true); \
>> +	     igt_unique(__i)++)
>
> Hmm, I wonder if this is robust. igt_unique() is currently based on
> __LINE__, and that might work through being expanded based on the macro
> instantiation line instead of the macro definition lines here. If
> igt_unique() ever becomes truly unique, it certainly breaks, because the
> above will contain four different unique identifiers instead of one. But
> it's not silent, it'll break the build.

Okay, looks like there's a lot of this type of igt_unique() usage in
igt. Not sure how I feel about it. :/

It's all exposed by making igt_unique() actually unique:

 #define igt_unique(prefix) \
-       igt_tokencat(igt_tokencat(__igt_unique__, prefix), __LINE__)
+       igt_tokencat(igt_tokencat(__igt_unique__, prefix), __COUNTER__)

So I guess the patch at hand doesn't make things any worse, really.


BR,
Jani.


-- 
Jani Nikula, Intel