From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()
Date: Wed, 30 Mar 2022 16:05:14 +0300 [thread overview]
Message-ID: <YkRViiFfSOJQnsoI@intel.com> (raw)
In-Reply-To: <380b903fb91b1e20a1a7af61db40b6c7c5617005.1648578814.git.jani.nikula@intel.com>
On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote:
> Mixing u8 * and struct edid * is confusing, switch to the latter.
>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/drm_edid.c | 31 +++++++++++++++----------------
> 1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d79b06f7f34c..0650b9217aa2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1991,29 +1991,28 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
> void *data)
> {
> int i, j = 0, valid_extensions = 0;
> - u8 *edid, *new;
> - struct edid *override;
> + struct edid *edid, *new, *override;
>
> override = drm_get_override_edid(connector);
> if (override)
> return override;
>
> - edid = (u8 *)drm_do_get_edid_base_block(connector, get_edid_block, data);
> + edid = drm_do_get_edid_base_block(connector, get_edid_block, data);
> if (!edid)
> return NULL;
>
> /* if there's no extensions or no connector, we're done */
> - valid_extensions = edid[0x7e];
> + valid_extensions = edid->extensions;
> if (valid_extensions == 0)
> - return (struct edid *)edid;
> + return edid;
>
> new = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
> if (!new)
> goto out;
> edid = new;
>
> - for (j = 1; j <= edid[0x7e]; j++) {
> - u8 *block = edid + j * EDID_LENGTH;
> + for (j = 1; j <= edid->extensions; j++) {
> + void *block = edid + j;
>
> for (i = 0; i < 4; i++) {
> if (get_edid_block(data, block, j, EDID_LENGTH))
> @@ -2026,13 +2025,13 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
> valid_extensions--;
> }
>
> - if (valid_extensions != edid[0x7e]) {
> - u8 *base;
> + if (valid_extensions != edid->extensions) {
> + struct edid *base;
This one points to extension blocks too so using
struct edid doesn't seem entirely appropriate.
>
> - connector_bad_edid(connector, edid, edid[0x7e] + 1);
> + connector_bad_edid(connector, (u8 *)edid, edid->extensions + 1);
>
> - edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
> - edid[0x7e] = valid_extensions;
> + edid->checksum += edid->extensions - valid_extensions;
> + edid->extensions = valid_extensions;
>
> new = kmalloc_array(valid_extensions + 1, EDID_LENGTH,
> GFP_KERNEL);
> @@ -2040,21 +2039,21 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
> goto out;
>
> base = new;
> - for (i = 0; i <= edid[0x7e]; i++) {
> - u8 *block = edid + i * EDID_LENGTH;
> + for (i = 0; i <= edid->extensions; i++) {
> + void *block = edid + i;
Hmm. This code seems very broken to me. We read each block
into its expected offset based on the original base block extension
count, but here we only iterate up to the new ext block count. So
if we had eg. a 4 block EDID where block 2 is busted, we set
the new ext count to 2, copy over blocks 0 and 1, skip block 2,
and then terminate the loop. So instead of copying block 3 from
the orignal EDID into block 2 of the new EDID, we leave the
original garbage block 2 in place.
Also this memcpy() business seems entirely poinless in the sense
that we could just read each ext block into the final offset
directly AFAICS.
>
> if (!drm_edid_block_valid(block, i, false, NULL))
> continue;
>
> memcpy(base, block, EDID_LENGTH);
> - base += EDID_LENGTH;
> + base++;
> }
>
> kfree(edid);
> edid = new;
> }
>
> - return (struct edid *)edid;
> + return edid;
>
> out:
> kfree(edid);
> --
> 2.30.2
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-03-30 13:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 18:42 [Intel-gfx] [PATCH 00/12] drm/edid: cleanup and refactoring around validity checks Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid() Jani Nikula
2022-03-30 13:05 ` Ville Syrjälä [this message]
2022-03-30 15:16 ` Jani Nikula
2022-03-30 15:39 ` Ville Syrjälä
2022-03-30 16:28 ` Jani Nikula
2022-03-30 16:50 ` Ville Syrjälä
2022-03-30 17:09 ` Jani Nikula
2022-03-30 21:01 ` Jani Nikula
2022-03-31 18:46 ` Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 02/12] drm/edid: clean up EDID block checksum functions Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 03/12] drm/edid: add edid_block_tag() helper to get the EDID extension tag Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 04/12] drm/edid: make drm_edid_header_is_valid() accept void pointer Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 05/12] drm/edid: clean up edid_is_zero() Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 06/12] drm/edid: split out edid_header_fix() Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 07/12] drm/edid: split drm_edid_block_valid() to check and act parts Jani Nikula
2022-03-31 14:54 ` Ville Syrjälä
2022-03-31 15:54 ` Jani Nikula
2022-03-31 16:49 ` Jani Nikula
2022-03-31 16:58 ` Ville Syrjälä
2022-03-29 18:42 ` [Intel-gfx] [PATCH 08/12] drm/edid: use a better variable name for EDID block read retries Jani Nikula
2022-03-31 14:55 ` Ville Syrjälä
2022-03-29 18:42 ` [Intel-gfx] [PATCH 09/12] drm/edid: simplify block check when filtering invalid blocks Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 10/12] drm/edid: split out invalid block filtering to a separate function Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 11/12] drm/edid: track invalid blocks in drm_do_get_edid() Jani Nikula
2022-03-29 18:42 ` [Intel-gfx] [PATCH 12/12] drm/edid: reduce magic when updating the EDID block checksum Jani Nikula
2022-03-31 14:59 ` Ville Syrjälä
2022-03-29 19:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: cleanup and refactoring around validity checks Patchwork
2022-03-29 19:37 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2022-03-29 20:09 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-29 21:26 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-03-31 17:07 ` [Intel-gfx] [PATCH 00/12] " Ville Syrjälä
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=YkRViiFfSOJQnsoI@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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;
as well as URLs for NNTP newsgroup(s).