From patchwork Mon Oct 24 11:31:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 8357 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp391821wru; Mon, 24 Oct 2022 04:34:03 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4eO8W/mWxevrFaCix9aMboBncsdzjM92p2xx6fJ9IefCv+2K+EhnlByAf4SruKN28GUs6N X-Received: by 2002:a17:903:22c1:b0:186:5f78:44c5 with SMTP id y1-20020a17090322c100b001865f7844c5mr23870308plg.16.1666611243418; Mon, 24 Oct 2022 04:34:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666611243; cv=none; d=google.com; s=arc-20160816; b=V39QCMAV3LpvDLTl1SGu8RGBJ2hv3MZybWrjkrG2ytphv1rHOUHwbxpTcuBtAECZWz drOVyV/ZwW4iFBxjZpHobd57Ezsz8Y8E/LVMnNpU2lZqRsSQTYb392SUpAycVdu7dQ4C FqbIOUoiF9YU9n8615fLo+AtDJ5Adb6v0h1EU3JBbGaj7g4hujHZDV/MxMyjiVLfzJAc boI4nA4rJQ9c5jDN8DO/8iRYm4ptV66IiFdyCWJKAPV+UygCRy/M1CLTkCJjR3yhx61b caYeK21HxTNoHd1nN/EFMjToffm9HO1wKpUEHzd8g86wuc08mHc3mzYCRgC1uxepuq7z TURQ== 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=UwXdO4AJzoO29mdB7+tRRTDunT0+BfG9R1O9Jm08440=; b=MNcoCeCoVzeOi9bY2OuQ4ONQ6eFF27p/iXc0huFkzALGOj3yV3Uly+DnyK76VHMyIr wOzH2zFj0uGiDI3ZdSaT1uqeWRbegnzlNyVjp2f068Z3Ar4QfsXI0uJ6GwZ7x1I4V2pO QtcTdycX9INcqMa4/D+t+e7H62aP1NtW5jXDpXMwRV6nRTemtpDhHO1MyMiOF8JOUS/k 0rSAdWCqtZLm3Wmp+bhGQtreNRoKVCQZ4jtS2P3dutxDGbLpNrPGQgc580z4eEZ+My+L KhMM2t2A57vg6WD8AiIIj2O+Jc30ZU6yu7N6KiugMCPrYfP0PL4btZSiPROj3xoNNQno CsdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=WbIK7KWO; 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 l10-20020a170902f68a00b001733a212ccfsi40253114plg.330.2022.10.24.04.33.50; Mon, 24 Oct 2022 04:34:03 -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=WbIK7KWO; 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 S229891AbiJXLcv (ORCPT + 99 others); Mon, 24 Oct 2022 07:32:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230345AbiJXLc2 (ORCPT ); Mon, 24 Oct 2022 07:32:28 -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 59EA05726D; Mon, 24 Oct 2022 04:32:12 -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 EFCA161257; Mon, 24 Oct 2022 11:32:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02CFBC433C1; Mon, 24 Oct 2022 11:32:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666611129; bh=3OvWPyMcLqjL4YA7kf1WwcIcmYqLuyCFPIa5p8Kn9iM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WbIK7KWOhP4H7BkXLbME059EM+iCt4VnSeqNe2YJFeeX7a4LzS8pFm/zL7/1hINFF 7pARmez+bCllusFy8RqMX0jSooL4vtEiP/5b9fLRBDMs/v16/isqRkCbfuV8Bssrg6 wCKFeMB2efSgFid6BR92O3QuDy+8yGg6Mi4hZjgo= 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 6.0 02/20] drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers Date: Mon, 24 Oct 2022 13:31:04 +0200 Message-Id: <20221024112934.517947061@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024112934.415391158@linuxfoundation.org> References: <20221024112934.415391158@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 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?1747568551216764732?= X-GMAIL-MSGID: =?utf-8?q?1747568551216764732?= 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 @@ -337,18 +337,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) { @@ -372,11 +360,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; @@ -385,17 +384,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; @@ -413,7 +403,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) @@ -428,14 +418,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) {