[PATCH v2] drm/amd/display: Fix warning about overflow

[Harry Wentland]

On 2017-10-16 04:56 AM, Michel Dänzer wrote:
> On 13/10/17 09:02 PM, Harry Wentland wrote:
>> v2: convert value to bool using !!
>>
>> Signed-off-by: Harry Wentland <harry.wentland at amd.com>
>> ---
>>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
>> index cb94e18cc455..43e9a9959288 100644
>> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
>> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
>> @@ -1042,13 +1042,13 @@ static enum bp_result get_embedded_panel_info_v2_1(
>>  	info->lcd_timing.misc_info.VERTICAL_CUT_OFF = 0;
>>  
>>  	info->lcd_timing.misc_info.H_REPLICATION_BY2 =
>> -		lvds->lcd_timing.miscinfo & ATOM_H_REPLICATIONBY2;
>> +		!!(lvds->lcd_timing.miscinfo & ATOM_H_REPLICATIONBY2);
>>  	info->lcd_timing.misc_info.V_REPLICATION_BY2 =
>> -		lvds->lcd_timing.miscinfo & ATOM_V_REPLICATIONBY2;
>> +		!!(lvds->lcd_timing.miscinfo & ATOM_V_REPLICATIONBY2);
>>  	info->lcd_timing.misc_info.COMPOSITE_SYNC =
>> -		lvds->lcd_timing.miscinfo & ATOM_COMPOSITESYNC;
>> +		!!(lvds->lcd_timing.miscinfo & ATOM_COMPOSITESYNC);
>>  	info->lcd_timing.misc_info.INTERLACE =
>> -		lvds->lcd_timing.miscinfo & ATOM_INTERLACE;
>> +		!!(lvds->lcd_timing.miscinfo & ATOM_INTERLACE);
>>  
>>  	/* not provided by VBIOS*/
>>  	info->lcd_timing.misc_info.DOUBLE_CLOCK = 0;
>> @@ -1056,7 +1056,7 @@ static enum bp_result get_embedded_panel_info_v2_1(
>>  	info->ss_id = 0;
>>  
>>  	info->realtek_eDPToLVDS =
>> -			(lvds->dplvdsrxid == eDP_TO_LVDS_REALTEK_ID ? 1:0);
>> +			!!(lvds->dplvdsrxid == eDP_TO_LVDS_REALTEK_ID);
>>  
>>  	return BP_RESULT_OK;
>>  }
>>
> 
> The commit log doesn't fit the change very well anymore.
> 
> 
> Pet peeve alert:
> 
> In general, IMHO one doesn't "fix a warning". One either fixes a problem
> which was highlighted by a warning, such as in this case, or one
> silences the warning instead. One should always make sure carefully
> there's no actual problem behind a warning before simply silencing it.
> 
> 

Very good points and thanks for preaching it. We've been doing quite badly on
this front in the DC team and I often get lazy myself. Will keep an eye on this
going forward.

> That said, the actual fix is
> 

Thanks.

Harry

> Reviewed-by: Michel Dänzer <michel.daenzer at amd.com>
> 
>