From: Andrew Morton <akpm@linux-foundation.org>
To: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-fbdev@vger.kernel.org, nouveau@lists.freedesktop.org
Subject: Re: [PATCH] vga16fb: refuse to load in face of other driver
Date: Fri, 23 Jul 2010 00:20:39 +0000 [thread overview]
Message-ID: <20100722172039.e935c67d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100720191923.GA11056@joi.lan>
On Tue, 20 Jul 2010 21:19:23 +0200
Marcin Slusarz <marcin.slusarz@gmail.com> wrote:
> We don't want vga16fb to mess with hardware initialized by other driver.
> Detect it and refuse to load.
> It fixes nouveau interrupt storm on some machines.
>
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> ---
> drivers/video/vga16fb.c | 13 ++++++++++++-
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
> index 28ccab4..4505446 100644
> --- a/drivers/video/vga16fb.c
> +++ b/drivers/video/vga16fb.c
> @@ -22,6 +22,7 @@
> #include <linux/platform_device.h>
> #include <linux/screen_info.h>
>
> +#include <asm/fb.h>
> #include <asm/io.h>
> #include <video/vga.h>
>
> @@ -1415,7 +1416,7 @@ static struct platform_device *vga16fb_device;
>
> static int __init vga16fb_init(void)
> {
> - int ret;
> + int ret, i;
> #ifndef MODULE
> char *option = NULL;
>
> @@ -1424,6 +1425,16 @@ static int __init vga16fb_init(void)
>
> vga16fb_setup(option);
> #endif
> + for (i = 0 ; i < FB_MAX; i++) {
> + if (!registered_fb[i])
> + continue;
> + if (fb_is_primary_device(registered_fb[i])) {
> + printk(KERN_INFO "vga16fb: %s is driving the primary card, refusing to load\n",
> + registered_fb[i]->fix.id);
> + return -EBUSY;
> + }
> + }
> +
> ret = platform_driver_register(&vga16fb_driver);
>
> if (!ret) {
This seems pretty hacky, and specific to vga16fb.
Is vga16fb.c the only fbdev driver (now and forever more) which can
grab the hardware from under a different driver's feet?
This is the basic and very common problem of two drivers diddling the
same hardware, yes? A common way of preventing such collisions is to
perform a suitably-checked request_region() in both drivers. Whichever
driver gets there second will get a failure and will bale out cleanly.
Can that mechanism be made to work in this case?
next prev parent reply other threads:[~2010-07-23 0:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 19:19 [PATCH] vga16fb: refuse to load in face of other driver Marcin Slusarz
2010-07-23 0:20 ` Andrew Morton [this message]
2010-07-23 13:10 ` [PATCH v2] " Marcin Slusarz
2010-07-23 15:00 ` Geert Uytterhoeven
2010-07-25 8:42 ` [Nouveau] [PATCH v2] vga16fb: refuse to load in face of other Dave Airlie
2010-07-25 11:54 ` Marcin Slusarz
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=20100722172039.e935c67d.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.slusarz@gmail.com \
--cc=nouveau@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).