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 483031A76A1; Tue, 30 Jul 2024 17:25:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722360325; cv=none; b=CfOU3UQCrTGOtk40pt/zd8lL9bGoccwQHOS3Arn12YJbROCq76sj4229WP6Km+ORYQ4YtSQUf8OD6PkB5XepicKymNOR/SOMGg9+iSJVl5/EMq58hwcCWhVq5z7Ucf6o//cdr3N+tqM+FrwnClcUa8jq72cf9STgruVqaJNpcbM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722360325; c=relaxed/simple; bh=LunbCZIHiLyel9aX/hrjUe0wLeqwA87ukeEJz4pmckw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H7+a3bzViSJhnN4jKr99C/2f54WLK55CIV1Wd8CekxqCq/D001AJ9z87AuZn6zaKPW5QuiDroFF8Ysyp+DNTWxeCsiYpzEVLXiGCSUx6trVB1aIqm8elaV3YY0HrzNgXRTBnEBb3zQfGaU0RZH5cf4LQAHzuxjdIDFR8cijiJfQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=YdE4oMth; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="YdE4oMth" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5FC4C4AF12; Tue, 30 Jul 2024 17:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1722360325; bh=LunbCZIHiLyel9aX/hrjUe0wLeqwA87ukeEJz4pmckw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YdE4oMthiMoFBNk2rNyhTIjtZ99FggwQHibkDpdKuX1p6VkGeG4d6IaN0m9Ft5496 qm3RTo50ahgenKVsjAgH8N0U55+FeIkl4ArU5T+WXhOQZwiVZhcnz8o0hWFEsw5Stt 2t93Vp7ApzVzpylui5qrIGQDZY94h4b5fHydtJbU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Thomas Zimmermann , Javier Martinez Canillas , Helge Deller Subject: [PATCH 6.10 633/809] fbdev: vesafb: Detect VGA compatibility from screen infos VESA attributes Date: Tue, 30 Jul 2024 17:48:29 +0200 Message-ID: <20240730151749.843861066@linuxfoundation.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20240730151724.637682316@linuxfoundation.org> References: <20240730151724.637682316@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Zimmermann commit c2bc958b2b03e361f14df99983bc64a39a7323a3 upstream. Test the vesa_attributes field in struct screen_info for compatibility with VGA hardware. Vesafb currently tests bit 1 in screen_info's capabilities field which indicates a 64-bit lfb address and is unrelated to VGA compatibility. Section 4.4 of the Vesa VBE 2.0 specifications defines that bit 5 in the mode's attributes field signals VGA compatibility. The mode is compatible with VGA hardware if the bit is clear. In that case, the driver can access VGA state of the VBE's underlying hardware. The vesafb driver uses this feature to program the color LUT in palette modes. Without, colors might be incorrect. The problem got introduced in commit 89ec4c238e7a ("[PATCH] vesafb: Fix incorrect logo colors in x86_64"). It incorrectly stores the mode attributes in the screen_info's capabilities field and updates vesafb accordingly. Later, commit 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code") fixed the screen_info, but did not update vesafb. Color output still tends to work, because bit 1 in capabilities is usually 0. Besides fixing the bug in vesafb, this commit introduces a helper that reads the correct bit from screen_info. Signed-off-by: Thomas Zimmermann Fixes: 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code") Reviewed-by: Javier Martinez Canillas Cc: # v2.6.23+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman --- drivers/video/fbdev/vesafb.c | 2 +- include/linux/screen_info.h | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) --- a/drivers/video/fbdev/vesafb.c +++ b/drivers/video/fbdev/vesafb.c @@ -271,7 +271,7 @@ static int vesafb_probe(struct platform_ if (si->orig_video_isVGA != VIDEO_TYPE_VLFB) return -ENODEV; - vga_compat = (si->capabilities & 2) ? 0 : 1; + vga_compat = !__screen_info_vbe_mode_nonvga(si); vesafb_fix.smem_start = si->lfb_base; vesafb_defined.bits_per_pixel = si->lfb_depth; if (15 == vesafb_defined.bits_per_pixel) --- a/include/linux/screen_info.h +++ b/include/linux/screen_info.h @@ -49,6 +49,16 @@ static inline u64 __screen_info_lfb_size return lfb_size; } +static inline bool __screen_info_vbe_mode_nonvga(const struct screen_info *si) +{ + /* + * VESA modes typically run on VGA hardware. Set bit 5 signals that this + * is not the case. Drivers can then not make use of VGA resources. See + * Sec 4.4 of the VBE 2.0 spec. + */ + return si->vesa_attributes & BIT(5); +} + static inline unsigned int __screen_info_video_type(unsigned int type) { switch (type) {