From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D1988489 for ; Fri, 10 Mar 2023 14:20:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F708C433EF; Fri, 10 Mar 2023 14:20:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1678458032; bh=BEt8FNBDAkucCQ0AlBkiit5UMQsPeSR2NYquzw/23Jg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gj1yBvTRiTppjhUnXI58tS2tWCst+3opEd6VMBKnZPeJwukrqk6QKvD9umYo1zPNb rJ/+HBlUaPtA40Hxrbr5EFzCrCk08VVzpPLOBxUP9kpNK2RxEU8/dayihWRuEIytT1 TMmaoYC8/rjQEiLZ4uoAneH1JRt+Gr87FsQLGLF8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Alper Nebi Yasak , Salvatore Bonaccorso Subject: [PATCH 4.19 140/252] firmware: coreboot: framebuffer: Ignore reserved pixel color bits Date: Fri, 10 Mar 2023 14:38:30 +0100 Message-Id: <20230310133723.035391552@linuxfoundation.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230310133718.803482157@linuxfoundation.org> References: <20230310133718.803482157@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Alper Nebi Yasak commit e6acaf25cba14661211bb72181c35dd13b24f5b3 upstream. The coreboot framebuffer doesn't support transparency, its 'reserved' bit field is merely padding for byte/word alignment of pixel colors [1]. When trying to match the framebuffer to a simplefb format, the kernel driver unnecessarily requires the format's transparency bit field to exactly match this padding, even if the former is zero-width. Due to a coreboot bug [2] (fixed upstream), some boards misreport the reserved field's size as equal to its position (0x18 for both on a 'Lick' Chromebook), and the driver fails to probe where it would have otherwise worked fine with e.g. the a8r8g8b8 or x8r8g8b8 formats. Remove the transparency comparison with reserved bits. When the bits-per-pixel and other color components match, transparency will already be in a subset of the reserved field. Not forcing it to match reserved bits allows the driver to work on the boards which misreport the reserved field. It also enables using simplefb formats that don't have transparency bits, although this doesn't currently happen due to format support and ordering in linux/platform_data/simplefb.h. [1] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.19/src/commonlib/include/commonlib/coreboot_tables.h#255 [2] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.13/src/drivers/intel/fsp2_0/graphics.c#82 Signed-off-by: Alper Nebi Yasak Link: https://lore.kernel.org/r/20230122190433.195941-1-alpernebiyasak@gmail.com Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman --- drivers/firmware/google/framebuffer-coreboot.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/drivers/firmware/google/framebuffer-coreboot.c +++ b/drivers/firmware/google/framebuffer-coreboot.c @@ -51,9 +51,7 @@ static int framebuffer_probe(struct core fb->green_mask_pos == formats[i].green.offset && fb->green_mask_size == formats[i].green.length && fb->blue_mask_pos == formats[i].blue.offset && - fb->blue_mask_size == formats[i].blue.length && - fb->reserved_mask_pos == formats[i].transp.offset && - fb->reserved_mask_size == formats[i].transp.length) + fb->blue_mask_size == formats[i].blue.length) pdata.format = formats[i].name; } if (!pdata.format)