From: <gregkh@linuxfoundation.org>
To: teddy.wang@siliconmotion.com, gregkh@linuxfoundation.org,
stable@vger.kernel.org, sudipm.mukherjee@gmail.com
Subject: patch "staging: sm750fb: avoid conflicting vesafb" added to staging-linus
Date: Sun, 30 Jul 2017 08:33:41 -0700 [thread overview]
Message-ID: <1501428821123223@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
staging: sm750fb: avoid conflicting vesafb
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 17f59b925866df5d4a44f87627a83fde88fb193c Mon Sep 17 00:00:00 2001
From: Teddy Wang <teddy.wang@siliconmotion.com>
Date: Sat, 29 Jul 2017 22:17:43 +0100
Subject: staging: sm750fb: avoid conflicting vesafb
commit 740c433ec35187b45abe08bb6c45a321a791be8e upstream
If vesafb is enabled in the config then /dev/fb0 is created by vesa
and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
effectively work with xorg.
So if it has been alloted fb1, then try to remove the other fb0.
In the previous send, why #ifdef is used was asked.
https://lkml.org/lkml/2017/6/25/57
Answered at: https://lkml.org/lkml/2017/6/25/69
Also pasting here for reference.
'Did a quick research into "why".
The patch d8801e4df91e ("x86/PCI: Set IORESOURCE_ROM_SHADOW only for the
default VGA device") has started setting IORESOURCE_ROM_SHADOW in flags
for a default VGA device and that is being done only for x86.
And so, we will need that #ifdef to check IORESOURCE_ROM_SHADOW as that
needs to be checked only for a x86 and not for other arch.'
Cc: <stable@vger.kernel.org> # v4.4
Signed-off-by: Teddy Wang <teddy.wang@siliconmotion.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/sm750fb/sm750.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 67207b0554cd..5d304378d45e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -1009,6 +1009,7 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
}
}
+<<<<<<< HEAD
static void sm750fb_frambuffer_release(struct sm750_dev *sm750_dev)
{
struct fb_info *fb_info;
@@ -1053,6 +1054,28 @@ static int sm750fb_frambuffer_alloc(struct sm750_dev *sm750_dev, int fbidx)
return err;
}
+=======
+>>>>>>> staging: sm750fb: avoid conflicting vesafb
+static int lynxfb_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+ struct apertures_struct *ap;
+ bool primary = false;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, 0);
+ ap->ranges[0].size = pci_resource_len(pdev, 0);
+#ifdef CONFIG_X86
+ primary = pdev->resource[PCI_ROM_RESOURCE].flags &
+ IORESOURCE_ROM_SHADOW;
+#endif
+ remove_conflicting_framebuffers(ap, "sm750_fb1", primary);
+ kfree(ap);
+ return 0;
+}
+
static int lynxfb_kick_out_firmware_fb(struct pci_dev *pdev)
{
struct apertures_struct *ap;
@@ -1085,6 +1108,14 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
if (err)
return err;
+ err = lynxfb_kick_out_firmware_fb(pdev);
+ if (err)
+ return err;
+
+ err = lynxfb_kick_out_firmware_fb(pdev);
+ if (err)
+ return err;
+
/* enable device */
err = pcim_enable_device(pdev);
if (err)
--
2.13.3
next reply other threads:[~2017-07-30 17:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-30 15:33 gregkh [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-07-18 6:54 patch "staging: sm750fb: avoid conflicting vesafb" added to staging-linus gregkh
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=1501428821123223@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=teddy.wang@siliconmotion.com \
/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).