On Fri, 01 Oct 2021, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> Quoting Lucas De Marchi (2021-10-01 08:40:41)
>> When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
>> provide much value just encapsulating it in a boolean context. So I also
>> added the support for handling undefined macros as the IS_ENABLED()
>> counterpart. However the feedback received from Masahiro Yamada was that
>> it is too ugly, not providing much value. And just wrapping in a boolean
>> context is too dumb - we could simply open code it.
>>
>> As detailed in commit babaab2f4738 ("drm/i915: Encapsulate kconfig
>> constant values inside boolean predicates"), the IS_ACTIVE macro was
>> added to workaround a compilation warning. However after checking again
>> our current uses of IS_ACTIVE it turned out there is only
>> 1 case in which it would potentially trigger a warning. All the others
>> can simply use the shorter version, without wrapping it in any macro.
>> And even that single one didn't trigger any warning in gcc 10.3.
>>
>> So here I'm dialing all the way back to simply removing the macro. If it
>> triggers warnings in future we may change the few cases to check for > 0
>> or != 0. Another possibility would be to use the great "not not
>> operator" for all positive checks, which would allow us to maintain
>> consistency. However let's try first the simplest form though, hopefully
>> we don't hit broken compilers spitting a warning:
>
> You didn't prevent the compilation warning this re-introduces.
>
> drivers/gpu/drm/i915/i915_config.c:11 i915_fence_context_timeout() warn: should this be a bitwise op?
> drivers/gpu/drm/i915/i915_request.c:1679 i915_request_wait() warn: should this be a bitwise op?
Looks like that's a Smatch warning. The immediate fix would be to just
add the != 0 in the relevant places. But this is stuff that's just going
to get broken again unless we add Smatch to CI. Most people aren't
running it on a regular basis.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
