Re: [PATCH v6 07/13] drm/bridge: it6505: avoid division by zero in audio FS debug print

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Unhandled negative error code from it6505_read() is written back to REG_RESET_CTRL, inadvertently resetting the entire device.
- [High] Unhandled negative error codes from it6505_read_word() silently corrupt the video timing calculations.
--

--- Patch [7]: [PATCH v6 07/13] drm/bridge: it6505: avoid division by zero in audio FS debug print ---
commit fb85e4882527f59c0b49c06140294c57c71382ab
Author: Daniel Golle <daniel@makrotopia.org>

drm/bridge: it6505: avoid division by zero in audio FS debug print

This commit ensures the divisor is greater than zero before calculating and
printing the audio input frequency in the debug output. This prevents a division
by zero crash if the audio clock hasn't been latched and it6505_read() returns 0.

> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
> index b7eb746c8f8e5..04711c8f4a041 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -1623,8 +1623,11 @@ static void it6505_enable_audio(struct it6505 *it6505)
>  	it6505_set_bits(it6505, REG_AUDIO_SRC_CTRL, AUDIO_FIFO_RESET, 0x00);
>  	it6505_set_bits(it6505, REG_RESET_CTRL, AUDIO_RESET, 0x00);
>  	regbe = it6505_read(it6505, REG_AUDIO_INPUT_FREQ);
> -	DRM_DEV_DEBUG_DRIVER(dev, "regbe:0x%02x audio input fs: %d.%d kHz",
> -			     regbe, 6750 / regbe, (6750 % regbe) * 10 / regbe);
> +	if (regbe > 0)
> +		DRM_DEV_DEBUG_DRIVER(dev,
> +				     "regbe:0x%02x audio input fs: %d.%d kHz",
> +				     regbe, 6750 / regbe,
> +				     (6750 % regbe) * 10 / regbe);
>  	it6505_set_bits(it6505, REG_DATA_MUTE_CTRL, EN_AUD_MUTE, 0x00);
>  }

[Severity: High]
This is a pre-existing issue, but I noticed another place where it6505_read()
errors might cause problems. In it6505_audio_input(), if an I2C read fails,
does this write the negative error code back to REG_RESET_CTRL?

drivers/gpu/drm/bridge/ite-it6505.c:it6505_audio_input() {
    ...
    reg05 = it6505_read(it6505, REG_RESET_CTRL);
    ...
    it6505_write(it6505, REG_RESET_CTRL, reg05);
    ...
}

If it6505_read() returns -19 (-ENODEV), the lower 8 bits (0xED) would set
both ALL_LOGIC_RESET (BIT 2) and VIDEO_RESET (BIT 0). Could this
unintentionally reset the entire hardware state machine?

[Severity: High]
This is also a pre-existing issue, but similar unhandled negative error codes
seem to be present in it6505_calc_video_info():

drivers/gpu/drm/bridge/ite-it6505.c:it6505_calc_video_info() {
    ...
    htotal = it6505_read_word(it6505, REG_INPUT_HTOTAL) & 0x1FFF;
    hdes = it6505_read_word(it6505, REG_INPUT_HACTIVE_START) & 0x1FFF;
    ...
}

If it6505_read_word() returns a negative error code (e.g. -19), would the
bitwise AND with 0x1FFF transform it into a large positive integer (e.g.
0x1FED)?  Could these invalid values then corrupt the video timing state when
accumulated into the pixel clock calculations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784947240.git.daniel@makrotopia.org?part=7