From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Thomas Zimmermann <tzimmermann@suse.de>,
Sam Ravnborg <sam@ravnborg.org>, Peter Jones <pjones@redhat.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
Hans de Goede <hdegoede@redhat.com>,
Ilya Trukhanov <lahvuun@gmail.com>,
Thorsten Leemhuis <regressions@leemhuis.info>,
Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH v2] fbdev: Prevent probing generic drivers if a FB is already registered
Date: Thu, 11 Nov 2021 12:39:28 +0100 [thread overview]
Message-ID: <YY0A8LOVhs5JbMXW@kroah.com> (raw)
In-Reply-To: <20211111111120.1344613-1-javierm@redhat.com>
On Thu, Nov 11, 2021 at 12:11:20PM +0100, Javier Martinez Canillas wrote:
> The efifb and simplefb drivers just render to a pre-allocated frame buffer
> and rely on the display hardware being initialized before the kernel boots.
>
> But if another driver already probed correctly and registered a fbdev, the
> generic drivers shouldn't be probed since an actual driver for the display
> hardware is already present.
>
> This is more likely to occur after commit d391c5827107 ("drivers/firmware:
> move x86 Generic System Framebuffers support") since the "efi-framebuffer"
> and "simple-framebuffer" platform devices are registered at a later time.
>
> Link: https://lore.kernel.org/r/20211110200253.rfudkt3edbd3nsyj@lahvuun/
> Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support")
> Reported-by: Ilya Trukhanov <lahvuun@gmail.com>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>
> Changes in v2:
> - Add a Link: tag with a reference to the bug report (Thorsten Leemhuis).
> - Add a comment explaining why the probe fails earlier (Daniel Vetter).
> - Add a Fixes: tag for stable to pick the fix (Daniel Vetter).
That does not mean that it will make it into the stable tree. Please
read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: linux-fbdev@vger.kernel.org,
Thorsten Leemhuis <regressions@leemhuis.info>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Hans de Goede <hdegoede@redhat.com>,
Peter Jones <pjones@redhat.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Ilya Trukhanov <lahvuun@gmail.com>, Borislav Petkov <bp@suse.de>,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH v2] fbdev: Prevent probing generic drivers if a FB is already registered
Date: Thu, 11 Nov 2021 12:39:28 +0100 [thread overview]
Message-ID: <YY0A8LOVhs5JbMXW@kroah.com> (raw)
In-Reply-To: <20211111111120.1344613-1-javierm@redhat.com>
On Thu, Nov 11, 2021 at 12:11:20PM +0100, Javier Martinez Canillas wrote:
> The efifb and simplefb drivers just render to a pre-allocated frame buffer
> and rely on the display hardware being initialized before the kernel boots.
>
> But if another driver already probed correctly and registered a fbdev, the
> generic drivers shouldn't be probed since an actual driver for the display
> hardware is already present.
>
> This is more likely to occur after commit d391c5827107 ("drivers/firmware:
> move x86 Generic System Framebuffers support") since the "efi-framebuffer"
> and "simple-framebuffer" platform devices are registered at a later time.
>
> Link: https://lore.kernel.org/r/20211110200253.rfudkt3edbd3nsyj@lahvuun/
> Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support")
> Reported-by: Ilya Trukhanov <lahvuun@gmail.com>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>
> Changes in v2:
> - Add a Link: tag with a reference to the bug report (Thorsten Leemhuis).
> - Add a comment explaining why the probe fails earlier (Daniel Vetter).
> - Add a Fixes: tag for stable to pick the fix (Daniel Vetter).
That does not mean that it will make it into the stable tree. Please
read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
thanks,
greg k-h
next prev parent reply other threads:[~2021-11-11 11:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 11:11 [PATCH v2] fbdev: Prevent probing generic drivers if a FB is already registered Javier Martinez Canillas
2021-11-11 11:11 ` Javier Martinez Canillas
2021-11-11 11:39 ` Greg Kroah-Hartman [this message]
2021-11-11 11:39 ` Greg Kroah-Hartman
2021-11-12 16:12 ` Daniel Vetter
2021-11-12 16:12 ` Daniel Vetter
2021-11-15 16:20 ` Geert Uytterhoeven
2021-11-15 16:20 ` Geert Uytterhoeven
2021-11-16 9:30 ` Javier Martinez Canillas
2021-11-16 9:30 ` Javier Martinez Canillas
2021-11-16 9:43 ` Geert Uytterhoeven
2021-11-16 9:43 ` Geert Uytterhoeven
2021-11-16 10:01 ` Javier Martinez Canillas
2021-11-16 10:01 ` Javier Martinez Canillas
2021-11-16 13:49 ` Javier Martinez Canillas
2021-11-16 13:49 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YY0A8LOVhs5JbMXW@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bp@suse.de \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=javierm@redhat.com \
--cc=lahvuun@gmail.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pjones@redhat.com \
--cc=regressions@leemhuis.info \
--cc=sam@ravnborg.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.