Message ID | 20230111154112.90575-11-daniel.vetter@ffwll.ch |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp3391547wrt; Wed, 11 Jan 2023 07:42:40 -0800 (PST) X-Google-Smtp-Source: AMrXdXugJ/KXYnBJsxOZ8scY6j79iDnl8Ts0WIQ/LvldWkFOA43RdWDKRXfZjWbgq50SKuh6vLOc X-Received: by 2002:a62:1c8d:0:b0:58a:541a:8b6f with SMTP id c135-20020a621c8d000000b0058a541a8b6fmr6613470pfc.10.1673451760182; Wed, 11 Jan 2023 07:42:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673451760; cv=none; d=google.com; s=arc-20160816; b=STdgemqpxy2yDcg8KUYhnevx1GJad6GXFWbjz6O1a83xolNHsOpc3jP01zP5RW3Mgu 34f8EUgKLu7ecObyvOJC99Zplni/srO9nAwfRILW2gd3/C27fZskTphMV96rRCbN9DhX NJ3NVDG1ScvC4SKTAdz3fem88eYokv2STi/5g1ejEcP6XUy1aPK3umqGinRwaasV2jJD LA+HvqAQM6q1a2IKEykTbmSsOZKBEI7ru4bt1P3WuEBPRfQtk4XLeO7CoVsq/Jh0Fwpa 7CW6ynClN4/+aRS5hggUJlEKd7Nd60dLNnAc5JojZJgepWBixy3d+N+Z/SIqsIn3pxid oUVQ== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=6J5rucn+hYvg3m1RRrffzZkT45tj6msLk6PzkRA+oVc=; b=1JeEgNy2IadIdSKODjp34kzDeRkW7xsYeZ36KIL5Wy7bVPIq/g3HGuQvm0ZQyA4339 obVENutUdZxZlQ8TsFBDWIG0lwWo8MnkczBkWXz5VONYNW9lywGQKE5QiWMtINBRZQVo KCgNqg0TdHRcL7aCYNlstIvdEPTlI4aw2sZfznMumBw36aQ89eGZX9vZsqT9miDUf8qO Jj5gtFmC1E6H7gSumvwBsilm0WzE2Htvq1YGarVECeEZRCagn0Lc/JybVsoujYwmLeWo qpvJr0vX7jwTjafSbplTKxo+JnhK77yTe+pKZGpmgDjUBFkK19SzXOerVYNCnAu+fDXd e/lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=UVhq2xNF; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g13-20020a056a001a0d00b00572899f993fsi15209582pfv.306.2023.01.11.07.42.26; Wed, 11 Jan 2023 07:42:40 -0800 (PST) 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=@ffwll.ch header.s=google header.b=UVhq2xNF; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238964AbjAKPmS (ORCPT <rfc822;syz17693488234@gmail.com> + 99 others); Wed, 11 Jan 2023 10:42:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235423AbjAKPlg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 11 Jan 2023 10:41:36 -0500 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7846386 for <linux-kernel@vger.kernel.org>; Wed, 11 Jan 2023 07:41:35 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id k22-20020a05600c1c9600b003d1ee3a6289so12978154wms.2 for <linux-kernel@vger.kernel.org>; Wed, 11 Jan 2023 07:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6J5rucn+hYvg3m1RRrffzZkT45tj6msLk6PzkRA+oVc=; b=UVhq2xNFtKTEbVePhTQcD+DkCgbC/RTrE0C4YZitCzyqe4S737uZqLY3u5UyA5WYdh DU1EQp1fcY/CsFWajQS4me7Fr87/4MjvTP/R0kLn9HFvOw1ZaYON/UzLgbPfAX349II2 SzM9iGgw+0+m+eT166Z18NC4dIm8W4gJUqyaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6J5rucn+hYvg3m1RRrffzZkT45tj6msLk6PzkRA+oVc=; b=AjnX5vl7+29NXfQNtNLambGNx4ECgIuyYHcD+FysVvNS75UDnd+/SruV3FFTfk2p/d ofbP/xNpWeHHkwmgrEvCdT8tRng5O5LLevmjZIJBlXhNioMw4oGsVMyjH+rBByfCc+lR 1xDqcqW4jVKIycLITED/9vFg3jj0uVBLKiPOWfPupxYxsRem6VKUgQDSk+g0PcZYz+jK QqCxgytW2RMqZU3FpKVPbx5JCuawV40R3/xy+4vEPLcCpslUW8ij8Sm9qys5Y5Ii9zpb 6t09AbTwY7sjRuhVp4jxKKbfF8d3AvPpbszilyXhtKgSelIiMo3x4qiFSEMYAKa0WiGa lUXQ== X-Gm-Message-State: AFqh2krb4oFAHFum8itpv3Y/49iLqv6oUIYCVdvMr1n8wh8ZHXsnFCjk vJf9gg5Kzxf36trf0tlzOuunEA== X-Received: by 2002:a05:600c:3b8f:b0:3d0:480b:ac53 with SMTP id n15-20020a05600c3b8f00b003d0480bac53mr55362290wms.12.1673451695486; Wed, 11 Jan 2023 07:41:35 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id t9-20020a05600c198900b003d9e74dd9b2sm15936149wmq.9.2023.01.11.07.41.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 07:41:34 -0800 (PST) From: Daniel Vetter <daniel.vetter@ffwll.ch> To: DRI Development <dri-devel@lists.freedesktop.org> Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>, LKML <linux-kernel@vger.kernel.org>, Daniel Vetter <daniel.vetter@ffwll.ch>, Daniel Vetter <daniel.vetter@intel.com>, Aaron Plattner <aplattner@nvidia.com>, Javier Martinez Canillas <javierm@redhat.com>, Thomas Zimmermann <tzimmermann@suse.de>, Helge Deller <deller@gmx.de>, Sam Ravnborg <sam@ravnborg.org>, Alex Deucher <alexander.deucher@amd.com>, stable@vger.kernel.org Subject: [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device Date: Wed, 11 Jan 2023 16:41:12 +0100 Message-Id: <20230111154112.90575-11-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230111154112.90575-1-daniel.vetter@ffwll.ch> References: <20230111154112.90575-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754741352906225885?= X-GMAIL-MSGID: =?utf-8?q?1754741352906225885?= |
Series |
[01/11] drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers
|
|
Commit Message
Daniel Vetter
Jan. 11, 2023, 3:41 p.m. UTC
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restor a working console.
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptons. That bug is fixed now, see
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Aaron Plattner <aplattner@nvidia.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Helge Deller <deller@gmx.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org> # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Comments
Hi Am 11.01.23 um 16:41 schrieb Daniel Vetter: > This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable > sysfb device registration when removing conflicting FBs"), where we > remove the sysfb when loading a driver for an unrelated pci device, > resulting in the user loosing their efifb console or similar. > > Note that in practice this only is a problem with the nvidia blob, > because that's the only gpu driver people might install which does not > come with an fbdev driver of it's own. For everyone else the real gpu > driver will restor a working console. > > Also note that in the referenced bug there's confusion that this same > bug also happens on amdgpu. But that was just another amdgpu specific > regression, which just happened to happen at roughly the same time and > with the same user-observable symptons. That bug is fixed now, see > https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 > > For the above reasons the cc: stable is just notionally, this patch > will need a backport and that's up to nvidia if they care enough. > > References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Aaron Plattner <aplattner@nvidia.com> > Cc: Javier Martinez Canillas <javierm@redhat.com> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: Helge Deller <deller@gmx.de> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: <stable@vger.kernel.org> # v5.19+ (if someone else does the backport) > --- > drivers/video/aperture.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c > index ba565515480d..a1821d369bb1 100644 > --- a/drivers/video/aperture.c > +++ b/drivers/video/aperture.c > @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na > > primary = pdev == vga_default_device(); > > + if (primary) > + sysfb_disable(); > + There's another sysfb_disable() in aperture_remove_conflicting_devices() without the branch but with a long comment. I find this slightly confusing. I'd rather add a branched sysfb_disable() plus the comment to aperture_detach_devices(). And then add a 'primary' parameter to aperture_detach_devices(). In aperture_remove_conflicting_devices() the parameter would be unconditionally true. Best regards Thomas > for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { > if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) > continue; > > base = pci_resource_start(pdev, bar); > size = pci_resource_len(pdev, bar); > - ret = aperture_remove_conflicting_devices(base, size, name); > - if (ret) > - return ret; > + aperture_detach_devices(base, size); > } > > if (!primary) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
On Wed, Jan 11, 2023 at 05:20:00PM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.01.23 um 16:41 schrieb Daniel Vetter: > > This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable > > sysfb device registration when removing conflicting FBs"), where we > > remove the sysfb when loading a driver for an unrelated pci device, > > resulting in the user loosing their efifb console or similar. > > > > Note that in practice this only is a problem with the nvidia blob, > > because that's the only gpu driver people might install which does not > > come with an fbdev driver of it's own. For everyone else the real gpu > > driver will restor a working console. > > > > Also note that in the referenced bug there's confusion that this same > > bug also happens on amdgpu. But that was just another amdgpu specific > > regression, which just happened to happen at roughly the same time and > > with the same user-observable symptons. That bug is fixed now, see > > https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 > > > > For the above reasons the cc: stable is just notionally, this patch > > will need a backport and that's up to nvidia if they care enough. > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > Cc: Aaron Plattner <aplattner@nvidia.com> > > Cc: Javier Martinez Canillas <javierm@redhat.com> > > Cc: Thomas Zimmermann <tzimmermann@suse.de> > > Cc: Helge Deller <deller@gmx.de> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Alex Deucher <alexander.deucher@amd.com> > > Cc: <stable@vger.kernel.org> # v5.19+ (if someone else does the backport) > > --- > > drivers/video/aperture.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c > > index ba565515480d..a1821d369bb1 100644 > > --- a/drivers/video/aperture.c > > +++ b/drivers/video/aperture.c > > @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na > > primary = pdev == vga_default_device(); > > + if (primary) > > + sysfb_disable(); > > + > > There's another sysfb_disable() in aperture_remove_conflicting_devices() > without the branch but with a long comment. I find this slightly confusing. > > I'd rather add a branched sysfb_disable() plus the comment to > aperture_detach_devices(). And then add a 'primary' parameter to > aperture_detach_devices(). In aperture_remove_conflicting_devices() the > parameter would be unconditionally true. Yeah I was on the fence, but should be easy to redo with all the prep work out of the way. It does mean we call sysfb_disable once for every bar, but that shouldn't matter in any reasonable case :-) -Daniel > > Best regards > Thomas > > > for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { > > if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) > > continue; > > base = pci_resource_start(pdev, bar); > > size = pci_resource_len(pdev, bar); > > - ret = aperture_remove_conflicting_devices(base, size, name); > > - if (ret) > > - return ret; > > + aperture_detach_devices(base, size); > > } > > if (!primary) > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev
On 1/11/23 17:20, Thomas Zimmermann wrote: [...] >> >> diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c >> index ba565515480d..a1821d369bb1 100644 >> --- a/drivers/video/aperture.c >> +++ b/drivers/video/aperture.c >> @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na >> >> primary = pdev == vga_default_device(); >> >> + if (primary) >> + sysfb_disable(); >> + > > There's another sysfb_disable() in aperture_remove_conflicting_devices() > without the branch but with a long comment. I find this slightly confusing. > > I'd rather add a branched sysfb_disable() plus the comment to > aperture_detach_devices(). And then add a 'primary' parameter to > aperture_detach_devices(). In aperture_remove_conflicting_devices() the > parameter would be unconditionally true. > Or just remove that long comment since there's already kernel-doc for the sysfb_disable() function definition. This feels to me that any approach to parameterize this will lead to code that is harder to read. Since is just a single function call, I would just duplicate like $subject does to be honest.
Hello Daniel, On 1/11/23 16:41, Daniel Vetter wrote: > This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable > sysfb device registration when removing conflicting FBs"), where we > remove the sysfb when loading a driver for an unrelated pci device, > resulting in the user loosing their efifb console or similar. > > Note that in practice this only is a problem with the nvidia blob, > because that's the only gpu driver people might install which does not > come with an fbdev driver of it's own. For everyone else the real gpu > driver will restor a working console. restore > > Also note that in the referenced bug there's confusion that this same > bug also happens on amdgpu. But that was just another amdgpu specific > regression, which just happened to happen at roughly the same time and > with the same user-observable symptons. That bug is fixed now, see symptoms > https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 > > For the above reasons the cc: stable is just notionally, this patch > will need a backport and that's up to nvidia if they care enough. > Maybe adding a Fixes: ee7a69aa38d8 tag here too ? > References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Aaron Plattner <aplattner@nvidia.com> > Cc: Javier Martinez Canillas <javierm@redhat.com> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: Helge Deller <deller@gmx.de> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: <stable@vger.kernel.org> # v5.19+ (if someone else does the backport) > --- > drivers/video/aperture.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c > index ba565515480d..a1821d369bb1 100644 > --- a/drivers/video/aperture.c > +++ b/drivers/video/aperture.c > @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na > > primary = pdev == vga_default_device(); > > + if (primary) > + sysfb_disable(); > + > for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { > if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) > continue; > > base = pci_resource_start(pdev, bar); > size = pci_resource_len(pdev, bar); > - ret = aperture_remove_conflicting_devices(base, size, name); > - if (ret) > - return ret; > + aperture_detach_devices(base, size); Maybe mention in the commit message that you are doing this change, something like: "Instead of calling aperture_remove_conflicting_devices() to remove the conflicting devices, just call to aperture_detach_devices() to detach the device that matches the same PCI BAR / aperture range. Since the former is just a wrapper of the latter plus a sysfb_disable() call, and now that's done in this function but only for the primary devices" Patch looks good to me: Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
On 1/11/23 8:58 AM, Javier Martinez Canillas wrote: > Hello Daniel, > > On 1/11/23 16:41, Daniel Vetter wrote: >> This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable >> sysfb device registration when removing conflicting FBs"), where we >> remove the sysfb when loading a driver for an unrelated pci device, >> resulting in the user loosing their efifb console or similar. >> >> Note that in practice this only is a problem with the nvidia blob, >> because that's the only gpu driver people might install which does not >> come with an fbdev driver of it's own. For everyone else the real gpu >> driver will restor a working console. > > restore > >> >> Also note that in the referenced bug there's confusion that this same >> bug also happens on amdgpu. But that was just another amdgpu specific >> regression, which just happened to happen at roughly the same time and >> with the same user-observable symptons. That bug is fixed now, see > > symptoms > >> https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 >> >> For the above reasons the cc: stable is just notionally, this patch >> will need a backport and that's up to nvidia if they care enough. >> > > Maybe adding a Fixes: ee7a69aa38d8 tag here too ? > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 >> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >> Cc: Aaron Plattner <aplattner@nvidia.com> >> Cc: Javier Martinez Canillas <javierm@redhat.com> >> Cc: Thomas Zimmermann <tzimmermann@suse.de> >> Cc: Helge Deller <deller@gmx.de> >> Cc: Sam Ravnborg <sam@ravnborg.org> >> Cc: Alex Deucher <alexander.deucher@amd.com> >> Cc: <stable@vger.kernel.org> # v5.19+ (if someone else does the backport) >> --- >> drivers/video/aperture.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c >> index ba565515480d..a1821d369bb1 100644 >> --- a/drivers/video/aperture.c >> +++ b/drivers/video/aperture.c >> @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na >> >> primary = pdev == vga_default_device(); >> >> + if (primary) >> + sysfb_disable(); >> + >> for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { >> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) >> continue; >> >> base = pci_resource_start(pdev, bar); >> size = pci_resource_len(pdev, bar); >> - ret = aperture_remove_conflicting_devices(base, size, name); >> - if (ret) >> - return ret; >> + aperture_detach_devices(base, size); > > Maybe mention in the commit message that you are doing this change, something like: > > "Instead of calling aperture_remove_conflicting_devices() to remove the conflicting > devices, just call to aperture_detach_devices() to detach the device that matches > the same PCI BAR / aperture range. Since the former is just a wrapper of the latter > plus a sysfb_disable() call, and now that's done in this function but only for the > primary devices" > > Patch looks good to me: > > Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Thanks Daniel and Javier! I wasn't able to reproduce the original problem on my hybrid laptop since it refuses to boot with the console on an external display, but I was able to reproduce it by switching the configuration around: booting with i915.modeset=0 and with an experimental version of nvidia-drm that registers a framebuffer console. I verified that loading nvidia-drm breaks the efi-firmware framebuffer on Intel on Arch's linux-6.1.4-arch1-1 kernel and that applying this patch series fixes it. So Tested-by: Aaron Plattner <aplattner@nvidia.com> FWIW, the bug ought to be reproducible with i915.modeset=0 + any other drm driver that registers a framebuffer. -- Aaron
Hi Am 11.01.23 um 17:37 schrieb Daniel Vetter: > On Wed, Jan 11, 2023 at 05:20:00PM +0100, Thomas Zimmermann wrote: >> Hi >> >> Am 11.01.23 um 16:41 schrieb Daniel Vetter: >>> This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable >>> sysfb device registration when removing conflicting FBs"), where we >>> remove the sysfb when loading a driver for an unrelated pci device, >>> resulting in the user loosing their efifb console or similar. >>> >>> Note that in practice this only is a problem with the nvidia blob, >>> because that's the only gpu driver people might install which does not >>> come with an fbdev driver of it's own. For everyone else the real gpu >>> driver will restor a working console. >>> >>> Also note that in the referenced bug there's confusion that this same >>> bug also happens on amdgpu. But that was just another amdgpu specific >>> regression, which just happened to happen at roughly the same time and >>> with the same user-observable symptons. That bug is fixed now, see >>> https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 >>> >>> For the above reasons the cc: stable is just notionally, this patch >>> will need a backport and that's up to nvidia if they care enough. >>> >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>> Cc: Aaron Plattner <aplattner@nvidia.com> >>> Cc: Javier Martinez Canillas <javierm@redhat.com> >>> Cc: Thomas Zimmermann <tzimmermann@suse.de> >>> Cc: Helge Deller <deller@gmx.de> >>> Cc: Sam Ravnborg <sam@ravnborg.org> >>> Cc: Alex Deucher <alexander.deucher@amd.com> >>> Cc: <stable@vger.kernel.org> # v5.19+ (if someone else does the backport) >>> --- >>> drivers/video/aperture.c | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c >>> index ba565515480d..a1821d369bb1 100644 >>> --- a/drivers/video/aperture.c >>> +++ b/drivers/video/aperture.c >>> @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na >>> primary = pdev == vga_default_device(); >>> + if (primary) >>> + sysfb_disable(); >>> + >> >> There's another sysfb_disable() in aperture_remove_conflicting_devices() >> without the branch but with a long comment. I find this slightly confusing. >> >> I'd rather add a branched sysfb_disable() plus the comment to >> aperture_detach_devices(). And then add a 'primary' parameter to >> aperture_detach_devices(). In aperture_remove_conflicting_devices() the >> parameter would be unconditionally true. > > Yeah I was on the fence, but should be easy to redo with all the prep work > out of the way. It does mean we call sysfb_disable once for every bar, but > that shouldn't matter in any reasonable case :-) Or leave it as is. It's not so important. The idea of the current design was that aperture_remove_conflicting_device() would be the general implementation and aperture_remove_conflicting_pci_device() would be a helper that only detects the correct PCI BAR. That never really worked in practice. Best regards Thomas > -Daniel > >> >> Best regards >> Thomas >> >>> for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { >>> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) >>> continue; >>> base = pci_resource_start(pdev, bar); >>> size = pci_resource_len(pdev, bar); >>> - ret = aperture_remove_conflicting_devices(base, size, name); >>> - if (ret) >>> - return ret; >>> + aperture_detach_devices(base, size); >>> } >>> if (!primary) >> >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 Nürnberg, Germany >> (HRB 36809, AG Nürnberg) >> Geschäftsführer: Ivo Totev > > > > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Hi Am 11.01.23 um 20:21 schrieb Aaron Plattner: > On 1/11/23 8:58 AM, Javier Martinez Canillas wrote: >> Hello Daniel, >> >> On 1/11/23 16:41, Daniel Vetter wrote: >>> This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable >>> sysfb device registration when removing conflicting FBs"), where we >>> remove the sysfb when loading a driver for an unrelated pci device, >>> resulting in the user loosing their efifb console or similar. >>> >>> Note that in practice this only is a problem with the nvidia blob, >>> because that's the only gpu driver people might install which does not >>> come with an fbdev driver of it's own. For everyone else the real gpu >>> driver will restor a working console. >> >> restore >> >>> >>> Also note that in the referenced bug there's confusion that this same >>> bug also happens on amdgpu. But that was just another amdgpu specific >>> regression, which just happened to happen at roughly the same time and >>> with the same user-observable symptons. That bug is fixed now, see >> >> symptoms >> >>> https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15 >>> >>> For the above reasons the cc: stable is just notionally, this patch >>> will need a backport and that's up to nvidia if they care enough. >>> >> >> Maybe adding a Fixes: ee7a69aa38d8 tag here too ? >> >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28 >>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> >>> Cc: Aaron Plattner <aplattner@nvidia.com> >>> Cc: Javier Martinez Canillas <javierm@redhat.com> >>> Cc: Thomas Zimmermann <tzimmermann@suse.de> >>> Cc: Helge Deller <deller@gmx.de> >>> Cc: Sam Ravnborg <sam@ravnborg.org> >>> Cc: Alex Deucher <alexander.deucher@amd.com> >>> Cc: <stable@vger.kernel.org> # v5.19+ (if someone else does the >>> backport) >>> --- >>> drivers/video/aperture.c | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c >>> index ba565515480d..a1821d369bb1 100644 >>> --- a/drivers/video/aperture.c >>> +++ b/drivers/video/aperture.c >>> @@ -321,15 +321,16 @@ int >>> aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const >>> char *na >>> primary = pdev == vga_default_device(); >>> + if (primary) >>> + sysfb_disable(); >>> + >>> for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { >>> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) >>> continue; >>> base = pci_resource_start(pdev, bar); >>> size = pci_resource_len(pdev, bar); >>> - ret = aperture_remove_conflicting_devices(base, size, name); >>> - if (ret) >>> - return ret; >>> + aperture_detach_devices(base, size); >> >> Maybe mention in the commit message that you are doing this change, >> something like: >> >> "Instead of calling aperture_remove_conflicting_devices() to remove >> the conflicting >> devices, just call to aperture_detach_devices() to detach the device >> that matches >> the same PCI BAR / aperture range. Since the former is just a wrapper >> of the latter >> plus a sysfb_disable() call, and now that's done in this function but >> only for the >> primary devices" >> >> Patch looks good to me: >> >> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> > > Thanks Daniel and Javier! > > I wasn't able to reproduce the original problem on my hybrid laptop > since it refuses to boot with the console on an external display, but I > was able to reproduce it by switching the configuration around: booting > with i915.modeset=0 and with an experimental version of nvidia-drm that > registers a framebuffer console. I verified that loading nvidia-drm Thank you for testing. One thing I'd like to note is that using DRM's fbdev emulation is the correct way to support a console. Nvidia-drm's current approach of utilizing efifb is fragile and requires workarounds from distributions (at least here at SUSE). Steps towards fbdev emulation are much appreciated. Best regards Thomas > breaks the efi-firmware framebuffer on Intel on Arch's > linux-6.1.4-arch1-1 kernel and that applying this patch series fixes it. So > > Tested-by: Aaron Plattner <aplattner@nvidia.com> > > FWIW, the bug ought to be reproducible with i915.modeset=0 + any other > drm driver that registers a framebuffer. > > -- Aaron -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
On 1/12/23 08:55, Thomas Zimmermann wrote: [...] >> Thanks Daniel and Javier! >> >> I wasn't able to reproduce the original problem on my hybrid laptop >> since it refuses to boot with the console on an external display, but I >> was able to reproduce it by switching the configuration around: booting >> with i915.modeset=0 and with an experimental version of nvidia-drm that >> registers a framebuffer console. I verified that loading nvidia-drm > > Thank you for testing. > > One thing I'd like to note is that using DRM's fbdev emulation is the > correct way to support a console. Nvidia-drm's current approach of > utilizing efifb is fragile and requires workarounds from distributions > (at least here at SUSE). Steps towards fbdev emulation are much appreciated. > I was meaning to mention the same. Fedora also is carrying a workaround just for the Nvidia proprietary driver since all other drivers provide a emulated fbdev device. So getting this finally fixed will be indeed highly appreciated.
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c index ba565515480d..a1821d369bb1 100644 --- a/drivers/video/aperture.c +++ b/drivers/video/aperture.c @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na primary = pdev == vga_default_device(); + if (primary) + sysfb_disable(); + for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) continue; base = pci_resource_start(pdev, bar); size = pci_resource_len(pdev, bar); - ret = aperture_remove_conflicting_devices(base, size, name); - if (ret) - return ret; + aperture_detach_devices(base, size); } if (!primary)