From patchwork Sat Oct 22 07:29:56 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 7726 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1109991wrr; Sat, 22 Oct 2022 01:50:55 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7ZQnQal95yoBx8BDCDvxwjhY2MJO6XJ/zIz1RTocvpffL99N/Qvbo3RWUdxIjarJjEqW7I X-Received: by 2002:a17:907:2672:b0:780:8bb5:25a3 with SMTP id ci18-20020a170907267200b007808bb525a3mr19038989ejc.281.1666428654935; Sat, 22 Oct 2022 01:50:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666428654; cv=none; d=google.com; s=arc-20160816; b=AoZF8gUYST8e+9/fMZ4GmmDRpxekBRvFFVtW28s8scQACLlHnBN+ShQiAQfNIfZJEs eWKHjdXQCR/leApCKEOZ5H421ahU4SvrEk9kLmt99MoJXihdv/X0D55QJxBIYIw1BcVu j+40Sfw8Ro+PROwY2IMc11CIkFjJA3Tx92yJJYPAbXwZ7tXqs1oBdTV8KY7U1jdHg2vk 8gJzPE0iZDda0MSK4VUTV2OUH8tnO+U59jiuZMM/4+NK1Nnl7Qa4gca90hO+YojfhE5A k99ZFubrxkKdDTRU3XxHHVyY4lPh4fku1a6kkNQjW3AFocDVT4R8XKsp2W2El711PXT2 sVgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=IjRRUEB+Bnbq35RV7IE4rzQu3SWESDd+oB+oVykpXV0=; b=aeQZ00IlvoD4i5br1bRDq/mEBzGpxbtjE2Yp70ly+az3iEDGQkbCbdlEO8JSS+qwQQ 1VUFklS89TlrxgLYh59xjH35riWcxmYnkuRqqhSILXJyK+sXfWEPFgF2xgSEcWOdD8sb vvBET4IUj35cxZdm7QWiJLhdpAyvzIIrufgWXN9lKD0LNR8LXj2WNZeo2LgPck5cUVbI AH9DzdAsqbibexxI8ITr+Q7VJSTCFTy531fHA4PRuoP+PWPYK0F5sOcAz5lqBKHgrTjL A8owhSS4tDK8YHPECNSr4yyy6yziDdNt4UHC0Nm23YWtdHgNTTby1HJNY+GhiWo4MT7Z uKVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=SnbUCUvn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ce12-20020a170906b24c00b0073d9c29892csi18201791ejb.939.2022.10.22.01.50.30; Sat, 22 Oct 2022 01:50:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=SnbUCUvn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234940AbiJVItM (ORCPT + 99 others); Sat, 22 Oct 2022 04:49:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234649AbiJVIrW (ORCPT ); Sat, 22 Oct 2022 04:47:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25FC85D72D; Sat, 22 Oct 2022 01:10:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1422C60ACE; Sat, 22 Oct 2022 08:08:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04ECAC433D7; Sat, 22 Oct 2022 08:08:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666426121; bh=5NlSRbXHvRb/aa25XM64BKUcWStHvdySzp+8NaPB+vM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SnbUCUvnocpG6weh1QFoJNa9EwTTOpgn4HfF90TyH3Z49tUJnYY/26z69NjYO2Lxg cXykfx23bTX2qWgKcskLKtJ46Dxzq4QhsHlfcv0BTtOIBF9PlJSsqRavPHZXb7js3D 0+m6v59KxboE07AmBrfrcp7+VuT1Q2OwkjowjMXQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= , Jani Nikula Subject: [PATCH 5.19 717/717] drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers Date: Sat, 22 Oct 2022 09:29:56 +0200 Message-Id: <20221022072530.179352316@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221022072415.034382448@linuxfoundation.org> References: <20221022072415.034382448@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747377093374136202?= X-GMAIL-MSGID: =?utf-8?q?1747377093374136202?= From: Ville Syrjälä commit d3a7051841f0a4bcb1ee26a1b721c6150cc4c2b1 upstream. The current scheme for generating the LFP data table pointers (when the block including them is missing from the VBT) expects the 0xffff sequence to only appear in the fp_timing terminator entries. However some VBTs also have extra 0xffff sequences elsewhere in the LFP data. When looking for the terminators we may end up finding those extra sequeneces insted, which means we deduce the wrong size for the fp_timing table. The code then notices the inconsistent looking values and gives up on the generated data table pointers, preventing us from parsing the LFP data table entirely. Let's give up on the "search for the terminators" approach and instead just hardcode the expected size for the fp_timing table. We have enough sanity checks in place to make sure we shouldn't end up parsing total garbage even if that size should change in the future (although that seems unlikely as the fp_timing and dvo_timing tables have been declared obsolete as of VBT version 229). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/display/intel_bios.c | 46 +++++++++++------------------- 1 file changed, 18 insertions(+), 28 deletions(-) --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -336,18 +336,6 @@ static bool fixup_lfp_data_ptrs(const vo return validate_lfp_data_ptrs(bdb, ptrs); } -static const void *find_fp_timing_terminator(const u8 *data, int size) -{ - int i; - - for (i = 0; i < size - 1; i++) { - if (data[i] == 0xff && data[i+1] == 0xff) - return &data[i]; - } - - return NULL; -} - static int make_lfp_data_ptr(struct lvds_lfp_data_ptr_table *table, int table_size, int total_size) { @@ -371,11 +359,22 @@ static void next_lfp_data_ptr(struct lvd static void *generate_lfp_data_ptrs(struct drm_i915_private *i915, const void *bdb) { - int i, size, table_size, block_size, offset; - const void *t0, *t1, *block; + int i, size, table_size, block_size, offset, fp_timing_size; struct bdb_lvds_lfp_data_ptrs *ptrs; + const void *block; void *ptrs_block; + /* + * The hardcoded fp_timing_size is only valid for + * modernish VBTs. All older VBTs definitely should + * include block 41 and thus we don't need to + * generate one. + */ + if (i915->vbt.version < 155) + return NULL; + + fp_timing_size = 38; + block = find_raw_section(bdb, BDB_LVDS_LFP_DATA); if (!block) return NULL; @@ -384,17 +383,8 @@ static void *generate_lfp_data_ptrs(stru block_size = get_blocksize(block); - size = block_size; - t0 = find_fp_timing_terminator(block, size); - if (!t0) - return NULL; - - size -= t0 - block - 2; - t1 = find_fp_timing_terminator(t0 + 2, size); - if (!t1) - return NULL; - - size = t1 - t0; + size = fp_timing_size + sizeof(struct lvds_dvo_timing) + + sizeof(struct lvds_pnp_id); if (size * 16 > block_size) return NULL; @@ -412,7 +402,7 @@ static void *generate_lfp_data_ptrs(stru table_size = sizeof(struct lvds_dvo_timing); size = make_lfp_data_ptr(&ptrs->ptr[0].dvo_timing, table_size, size); - table_size = t0 - block + 2; + table_size = fp_timing_size; size = make_lfp_data_ptr(&ptrs->ptr[0].fp_timing, table_size, size); if (ptrs->ptr[0].fp_timing.table_size) @@ -427,14 +417,14 @@ static void *generate_lfp_data_ptrs(stru return NULL; } - size = t1 - t0; + size = fp_timing_size + sizeof(struct lvds_dvo_timing) + + sizeof(struct lvds_pnp_id); for (i = 1; i < 16; i++) { next_lfp_data_ptr(&ptrs->ptr[i].fp_timing, &ptrs->ptr[i-1].fp_timing, size); next_lfp_data_ptr(&ptrs->ptr[i].dvo_timing, &ptrs->ptr[i-1].dvo_timing, size); next_lfp_data_ptr(&ptrs->ptr[i].panel_pnp_id, &ptrs->ptr[i-1].panel_pnp_id, size); } - size = t1 - t0; table_size = sizeof(struct lvds_lfp_panel_name); if (16 * (size + table_size) <= block_size) {