[PATCH 3/3] drm/komeda - Fix handling of pending crtc state commit to avoid lock-up

[Carsten Haitzler]

On 7/14/22 13:20, Robin Murphy wrote:
> On 2022-07-11 11:13, Liviu Dudau wrote:
> [...]
>>> But nothing worrying. It does work, though doesn't compile due to:
>>>
>>> drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function
>>> ‘komeda_kms_atomic_commit_hw_done’:
>>> drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: error: ‘for’ loop
>>> initial declarations are only allowed in C99 or C11 mode
>>>     77 |         for (int i = 0; i < kms->n_crtcs; i++) {
>>>        |         ^~~
>>> drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: note: use option
>>> ‘-std=c9
>>> ’, ‘-std=gnu99’, ‘-std=c11’ or ‘-std=gnu11’ to compile your code
>>>
>>> but that was a trivial fixup.
>>
>> Interesting that I'm not seeing that, probably due to using GCC12? 
>> Anyway, I'll fix
>> that and send a proper patch.
> 
> FWIW we do use -std=gnu11 since 5.18 (see e8c07082a810), but I'm not 
> entirely sure what the status quo is for using the new features in fixes 
> which might also warrant backporting to stable. I believe Carsten's 
> stuck on an older kernel thanks to constraints of the rest of that 
> project ;)

Not that old - my last sync was like end of April, but i was basing my 
commits off a stable kernel release tree (5.17.4), I have multiple 
kernels for different purposes and for this stuck to something released 
vaguely recently (i synced my tree to latest release before sending off 
the patch set). I'm not sure on the kernel policy for the above for (int 
i = 0;...) etc. usage. I tend to still be more conservative and keep my 
vars at top of the block anyway out of decades of habit.