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 02/11] drm/i915/bios: Make copies of VBT data blocks
Date: Fri, 18 Mar 2022 00:18:10 +0200 [thread overview]
Message-ID: <YjOzohegmD76YjXR@intel.com> (raw)
In-Reply-To: <87h77wmmg9.fsf@intel.com>
On Thu, Mar 17, 2022 at 09:02:46PM +0200, Jani Nikula wrote:
> On Thu, 17 Mar 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Make a copy of each VB data block with a guaranteed minimum
> > size. The extra (if any) will just be left zeroed.
>
> *VBT
>
> >
> > This means we don't have to worry about going out of bounds
> > when accessing any of the structure members. Otherwise that
> > could easliy happen if we simply get the version check wrong,
> > or if the VBT is broken/malicious.
>
> *easily
>
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The high level question is if we really want to save the copies until
> driver remove instead of just during parsing. The lifetime should be
> mentioned in the commit message, with rationale if you have some.
Sure, I'll amend the commit msg a bit.
I think we at least must move away from the "parse VBT once at
driver init" idea because that won't ever let us deal with the
panel_type=0xff->check PnP ID thing. I think I even have a few
real world VBTs in my stash which have panel_type=0xff, so it's
not just some theoretical thing.
So we must hang onto the blocks at least until we've finished the
output setup. But I'm thinking we can just keep them permanently
and even start thinking about moving away from the "parse once,
stash results somewhere" mentality. Ie. we could just parse on
demand instead.
> I was wondering about making the copies up front instead of as needed,
> but that means setting up a list for the min sizes. It would clean up
> the usage (avoids passing around any pointers to original data to the
> parsers). Then you could use just find_section(i915, BDB_XXX). Dunno.
At least if we go for the parse on demand apporach then we definitely
want to do that. Avoids having to deal with kmalloc() fails/etc. while
parsing.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-03-17 22:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-17 17:19 [Intel-gfx] [PATCH 00/11] drm/i915/bios: Rework BDB block handling Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 01/11] drm/i915/bios: Extract struct lvds_lfp_data_ptr_table Ville Syrjala
2022-03-17 18:33 ` Jani Nikula
2022-03-17 17:19 ` [Intel-gfx] [PATCH 02/11] drm/i915/bios: Make copies of VBT data blocks Ville Syrjala
2022-03-17 19:02 ` Jani Nikula
2022-03-17 22:18 ` Ville Syrjälä [this message]
2022-03-18 9:44 ` Jani Nikula
2022-03-17 20:21 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 03/11] drm/i915/bios: Use the copy of the LFP data table always Ville Syrjala
2022-03-17 19:10 ` Jani Nikula
2022-03-17 20:04 ` Ville Syrjälä
2022-03-17 20:08 ` Ville Syrjälä
2022-03-17 20:21 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 04/11] drm/i915/bios: Validate LFP data table pointers Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 05/11] drm/i915/bios: Trust the LFP data pointers Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 06/11] drm/i915/bios: Validate the panel_name table Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 07/11] drm/i915/bios: Reorder panel DTD parsing Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 08/11] drm/i915/bios: Generate LFP data table pointers if the VBT lacks them Ville Syrjala
2022-03-17 23:41 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 09/11] drm/i915/bios: Get access to the tail end of the LFP data block Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 10/11] drm/i915/bios: Parse the seamless DRRS min refresh rate Ville Syrjala
2022-03-17 17:19 ` [Intel-gfx] [PATCH 11/11] drm/i915: Respect VBT " Ville Syrjala
2022-03-17 17:45 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/bios: Rework BDB block handling Patchwork
2022-03-17 17:46 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-03-17 18:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-17 20:20 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-03-17 22:16 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/bios: Rework BDB block handling (rev3) Patchwork
2022-03-17 22:18 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-03-17 22:48 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-18 0:04 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/bios: Rework BDB block handling (rev4) Patchwork
2022-03-18 0:05 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-03-18 0:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-18 2:54 ` [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=YjOzohegmD76YjXR@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox