All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/bios: Validate fp_timing terminator presence
Date: Fri, 02 Sep 2022 13:47:14 +0300	[thread overview]
Message-ID: <871qsuf3yl.fsf@intel.com> (raw)
In-Reply-To: <20220818192223.29881-2-ville.syrjala@linux.intel.com>

On Thu, 18 Aug 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Validate the LFP data block a bit hardwer by making sure the
> fp_timing terminators (0xffff) are where we expect them to be.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

I wonder if it would be good to debug log at each of the "return false"
sites in fixup_lfp_data_ptrs() and validate_lfp_data_ptrs(). Anyway,
that's a separate change.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>

> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 60 ++++++++++++-----------
>  1 file changed, 32 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
> index 198a2f4920cc..f1f861da9e93 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -135,18 +135,6 @@ static u32 raw_block_offset(const void *bdb, enum bdb_block_id section_id)
>  	return block - bdb;
>  }
>  
> -/* size of the block excluding the header */
> -static u32 raw_block_size(const void *bdb, enum bdb_block_id section_id)
> -{
> -	const void *block;
> -
> -	block = find_raw_section(bdb, section_id);
> -	if (!block)
> -		return 0;
> -
> -	return get_blocksize(block);
> -}
> -
>  struct bdb_block_entry {
>  	struct list_head node;
>  	enum bdb_block_id section_id;
> @@ -231,9 +219,14 @@ static bool validate_lfp_data_ptrs(const void *bdb,
>  {
>  	int fp_timing_size, dvo_timing_size, panel_pnp_id_size, panel_name_size;
>  	int data_block_size, lfp_data_size;
> +	const void *data_block;
>  	int i;
>  
> -	data_block_size = raw_block_size(bdb, BDB_LVDS_LFP_DATA);
> +	data_block = find_raw_section(bdb, BDB_LVDS_LFP_DATA);
> +	if (!data_block)
> +		return false;
> +
> +	data_block_size = get_blocksize(data_block);
>  	if (data_block_size == 0)
>  		return false;
>  
> @@ -261,21 +254,6 @@ static bool validate_lfp_data_ptrs(const void *bdb,
>  	if (16 * lfp_data_size > data_block_size)
>  		return false;
>  
> -	/*
> -	 * Except for vlv/chv machines all real VBTs seem to have 6
> -	 * unaccounted bytes in the fp_timing table. And it doesn't
> -	 * appear to be a really intentional hole as the fp_timing
> -	 * 0xffff terminator is always within those 6 missing bytes.
> -	 */
> -	if (fp_timing_size + dvo_timing_size + panel_pnp_id_size != lfp_data_size &&
> -	    fp_timing_size + 6 + dvo_timing_size + panel_pnp_id_size != lfp_data_size)
> -		return false;
> -
> -	if (ptrs->ptr[0].fp_timing.offset + fp_timing_size > ptrs->ptr[0].dvo_timing.offset ||
> -	    ptrs->ptr[0].dvo_timing.offset + dvo_timing_size != ptrs->ptr[0].panel_pnp_id.offset ||
> -	    ptrs->ptr[0].panel_pnp_id.offset + panel_pnp_id_size != lfp_data_size)
> -		return false;
> -
>  	/* make sure the table entries have uniform size */
>  	for (i = 1; i < 16; i++) {
>  		if (ptrs->ptr[i].fp_timing.table_size != fp_timing_size ||
> @@ -289,6 +267,23 @@ static bool validate_lfp_data_ptrs(const void *bdb,
>  			return false;
>  	}
>  
> +	/*
> +	 * Except for vlv/chv machines all real VBTs seem to have 6
> +	 * unaccounted bytes in the fp_timing table. And it doesn't
> +	 * appear to be a really intentional hole as the fp_timing
> +	 * 0xffff terminator is always within those 6 missing bytes.
> +	 */
> +	if (fp_timing_size + 6 + dvo_timing_size + panel_pnp_id_size == lfp_data_size)
> +		fp_timing_size += 6;
> +
> +	if (fp_timing_size + dvo_timing_size + panel_pnp_id_size != lfp_data_size)
> +		return false;
> +
> +	if (ptrs->ptr[0].fp_timing.offset + fp_timing_size != ptrs->ptr[0].dvo_timing.offset ||
> +	    ptrs->ptr[0].dvo_timing.offset + dvo_timing_size != ptrs->ptr[0].panel_pnp_id.offset ||
> +	    ptrs->ptr[0].panel_pnp_id.offset + panel_pnp_id_size != lfp_data_size)
> +		return false;
> +
>  	/* make sure the tables fit inside the data block */
>  	for (i = 0; i < 16; i++) {
>  		if (ptrs->ptr[i].fp_timing.offset + fp_timing_size > data_block_size ||
> @@ -300,6 +295,15 @@ static bool validate_lfp_data_ptrs(const void *bdb,
>  	if (ptrs->panel_name.offset + 16 * panel_name_size > data_block_size)
>  		return false;
>  
> +	/* make sure fp_timing terminators are present at expected locations */
> +	for (i = 0; i < 16; i++) {
> +		const u16 *t = data_block + ptrs->ptr[i].fp_timing.offset +
> +			fp_timing_size - 2;
> +
> +		if (*t != 0xffff)
> +			return false;
> +	}
> +
>  	return true;
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-09-02 10:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18 19:22 [Intel-gfx] [PATCH 0/2] drm/i915/bios: Rethink LFP data pointer generation Ville Syrjala
2022-08-18 19:22 ` [Intel-gfx] [PATCH 1/2] drm/i915/bios: Validate fp_timing terminator presence Ville Syrjala
2022-09-02 10:47   ` Jani Nikula [this message]
2022-09-02 11:03     ` Ville Syrjälä
2022-08-18 19:22 ` [Intel-gfx] [PATCH 2/2] drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers Ville Syrjala
2022-09-02 11:12   ` Jani Nikula
2022-09-02 11:23     ` Ville Syrjälä
2022-08-23 18:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: Rethink LFP data pointer generation Patchwork
2022-08-24 21:55 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871qsuf3yl.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.