From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/bios: Validate fp_timing terminator presence
Date: Fri, 2 Sep 2022 14:03:31 +0300 [thread overview]
Message-ID: <YxHjA4lvGvZDdFrf@intel.com> (raw)
In-Reply-To: <871qsuf3yl.fsf@intel.com>
On Fri, Sep 02, 2022 at 01:47:14PM +0300, Jani Nikula wrote:
> 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.
Not sure how much it would help. I suspect one still ends
up decoding the whole hexdump by hand.
>
> 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
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-09-02 11:03 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
2022-09-02 11:03 ` Ville Syrjälä [this message]
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=YxHjA4lvGvZDdFrf@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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.