--- /dev/null
+From ec1587d5073f29820e358f3a383850d61601d981 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:59 +0200
+Subject: fbdev: sm712fb: fix boot screen glitch when sm712fb replaces VGA
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit ec1587d5073f29820e358f3a383850d61601d981 upstream.
+
+When the machine is booted in VGA mode, loading sm712fb would cause
+a glitch of random pixels shown on the screen. To prevent it from
+happening, we first clear the entire framebuffer, and we also need
+to stop calling smtcfb_setmode() during initialization, the fbdev
+layer will call it for us later when it's ready.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712fb.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -1493,7 +1493,11 @@ static int smtcfb_pci_probe(struct pci_d
+ if (err)
+ goto failed;
+
+- smtcfb_setmode(sfb);
++ /*
++ * The screen would be temporarily garbled when sm712fb takes over
++ * vesafb or VGA text mode. Zero the framebuffer.
++ */
++ memset_io(sfb->lfb, 0, sfb->fb->fix.smem_len);
+
+ err = register_framebuffer(info);
+ if (err < 0)
--- /dev/null
+From 5481115e25e42b9215f2619452aa99c95f08492f Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:58 +0200
+Subject: fbdev: sm712fb: fix brightness control on reboot, don't set SR30
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit 5481115e25e42b9215f2619452aa99c95f08492f upstream.
+
+On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
+sm712fb framebuffer driver would cause the role of brightness up/down
+button to swap.
+
+Experiments showed the FPR30 register caused this behavior. Moreover,
+even if this register don't have side-effect on other systems, over-
+writing it is also highly questionable, since it was originally
+configurated by the motherboard manufacturer by hardwiring pull-down
+resistors to indicate the type of LCD panel. We should not mess with
+it.
+
+Stop writing to the SR30 (a.k.a FPR30) register.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712fb.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -1145,8 +1145,8 @@ static void sm7xx_set_timing(struct smtc
+
+ /* init SEQ register SR30 - SR75 */
+ for (i = 0; i < SIZE_SR30_SR75; i++)
+- if ((i + 0x30) != 0x62 && (i + 0x30) != 0x6a &&
+- (i + 0x30) != 0x6b)
++ if ((i + 0x30) != 0x30 && (i + 0x30) != 0x62 &&
++ (i + 0x30) != 0x6a && (i + 0x30) != 0x6b)
+ smtc_seqw(i + 0x30,
+ vgamode[j].init_sr30_sr75[i]);
+
--- /dev/null
+From f627caf55b8e735dcec8fa6538e9668632b55276 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:59 +0200
+Subject: fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit f627caf55b8e735dcec8fa6538e9668632b55276 upstream.
+
+On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), blanking the display
+or starting the X server will crash and freeze the system, or garble the
+display.
+
+Experiments showed this problem can mostly be solved by adjusting the
+order of register writes. Also, sm712fb failed to consider the difference
+of clock frequency when unblanking the display, and programs the clock for
+SM712 to SM720.
+
+Fix them by adjusting the order of register writes, and adding an
+additional check for SM720 for programming the clock frequency.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712fb.c | 64 ++++++++++++++++++++++++------------------
+ 1 file changed, 38 insertions(+), 26 deletions(-)
+
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -886,67 +886,79 @@ static inline unsigned int chan_to_field
+
+ static int smtc_blank(int blank_mode, struct fb_info *info)
+ {
++ struct smtcfb_info *sfb = info->par;
++
+ /* clear DPMS setting */
+ switch (blank_mode) {
+ case FB_BLANK_UNBLANK:
+ /* Screen On: HSync: On, VSync : On */
++
++ switch (sfb->chip_id) {
++ case 0x710:
++ case 0x712:
++ smtc_seqw(0x6a, 0x16);
++ smtc_seqw(0x6b, 0x02);
++ case 0x720:
++ smtc_seqw(0x6a, 0x0d);
++ smtc_seqw(0x6b, 0x02);
++ break;
++ }
++
++ smtc_seqw(0x23, (smtc_seqr(0x23) & (~0xc0)));
+ smtc_seqw(0x01, (smtc_seqr(0x01) & (~0x20)));
+- smtc_seqw(0x6a, 0x16);
+- smtc_seqw(0x6b, 0x02);
+ smtc_seqw(0x21, (smtc_seqr(0x21) & 0x77));
+ smtc_seqw(0x22, (smtc_seqr(0x22) & (~0x30)));
+- smtc_seqw(0x23, (smtc_seqr(0x23) & (~0xc0)));
+- smtc_seqw(0x24, (smtc_seqr(0x24) | 0x01));
+ smtc_seqw(0x31, (smtc_seqr(0x31) | 0x03));
++ smtc_seqw(0x24, (smtc_seqr(0x24) | 0x01));
+ break;
+ case FB_BLANK_NORMAL:
+ /* Screen Off: HSync: On, VSync : On Soft blank */
++ smtc_seqw(0x24, (smtc_seqr(0x24) | 0x01));
++ smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
++ smtc_seqw(0x23, (smtc_seqr(0x23) & (~0xc0)));
+ smtc_seqw(0x01, (smtc_seqr(0x01) & (~0x20)));
++ smtc_seqw(0x22, (smtc_seqr(0x22) & (~0x30)));
+ smtc_seqw(0x6a, 0x16);
+ smtc_seqw(0x6b, 0x02);
+- smtc_seqw(0x22, (smtc_seqr(0x22) & (~0x30)));
+- smtc_seqw(0x23, (smtc_seqr(0x23) & (~0xc0)));
+- smtc_seqw(0x24, (smtc_seqr(0x24) | 0x01));
+- smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
+ break;
+ case FB_BLANK_VSYNC_SUSPEND:
+ /* Screen On: HSync: On, VSync : Off */
++ smtc_seqw(0x24, (smtc_seqr(0x24) & (~0x01)));
++ smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
++ smtc_seqw(0x23, ((smtc_seqr(0x23) & (~0xc0)) | 0x20));
+ smtc_seqw(0x01, (smtc_seqr(0x01) | 0x20));
+- smtc_seqw(0x20, (smtc_seqr(0x20) & (~0xB0)));
+- smtc_seqw(0x6a, 0x0c);
+- smtc_seqw(0x6b, 0x02);
+ smtc_seqw(0x21, (smtc_seqr(0x21) | 0x88));
++ smtc_seqw(0x20, (smtc_seqr(0x20) & (~0xB0)));
+ smtc_seqw(0x22, ((smtc_seqr(0x22) & (~0x30)) | 0x20));
+- smtc_seqw(0x23, ((smtc_seqr(0x23) & (~0xc0)) | 0x20));
+- smtc_seqw(0x24, (smtc_seqr(0x24) & (~0x01)));
+- smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
+ smtc_seqw(0x34, (smtc_seqr(0x34) | 0x80));
++ smtc_seqw(0x6a, 0x0c);
++ smtc_seqw(0x6b, 0x02);
+ break;
+ case FB_BLANK_HSYNC_SUSPEND:
+ /* Screen On: HSync: Off, VSync : On */
++ smtc_seqw(0x24, (smtc_seqr(0x24) & (~0x01)));
++ smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
++ smtc_seqw(0x23, ((smtc_seqr(0x23) & (~0xc0)) | 0xD8));
+ smtc_seqw(0x01, (smtc_seqr(0x01) | 0x20));
+- smtc_seqw(0x20, (smtc_seqr(0x20) & (~0xB0)));
+- smtc_seqw(0x6a, 0x0c);
+- smtc_seqw(0x6b, 0x02);
+ smtc_seqw(0x21, (smtc_seqr(0x21) | 0x88));
++ smtc_seqw(0x20, (smtc_seqr(0x20) & (~0xB0)));
+ smtc_seqw(0x22, ((smtc_seqr(0x22) & (~0x30)) | 0x10));
+- smtc_seqw(0x23, ((smtc_seqr(0x23) & (~0xc0)) | 0xD8));
+- smtc_seqw(0x24, (smtc_seqr(0x24) & (~0x01)));
+- smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
+ smtc_seqw(0x34, (smtc_seqr(0x34) | 0x80));
++ smtc_seqw(0x6a, 0x0c);
++ smtc_seqw(0x6b, 0x02);
+ break;
+ case FB_BLANK_POWERDOWN:
+ /* Screen On: HSync: Off, VSync : Off */
++ smtc_seqw(0x24, (smtc_seqr(0x24) & (~0x01)));
++ smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
++ smtc_seqw(0x23, ((smtc_seqr(0x23) & (~0xc0)) | 0xD8));
+ smtc_seqw(0x01, (smtc_seqr(0x01) | 0x20));
+- smtc_seqw(0x20, (smtc_seqr(0x20) & (~0xB0)));
+- smtc_seqw(0x6a, 0x0c);
+- smtc_seqw(0x6b, 0x02);
+ smtc_seqw(0x21, (smtc_seqr(0x21) | 0x88));
++ smtc_seqw(0x20, (smtc_seqr(0x20) & (~0xB0)));
+ smtc_seqw(0x22, ((smtc_seqr(0x22) & (~0x30)) | 0x30));
+- smtc_seqw(0x23, ((smtc_seqr(0x23) & (~0xc0)) | 0xD8));
+- smtc_seqw(0x24, (smtc_seqr(0x24) & (~0x01)));
+- smtc_seqw(0x31, ((smtc_seqr(0x31) & (~0x07)) | 0x00));
+ smtc_seqw(0x34, (smtc_seqr(0x34) | 0x80));
++ smtc_seqw(0x6a, 0x0c);
++ smtc_seqw(0x6b, 0x02);
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From 9e0e59993df0601cddb95c4f6c61aa3d5e753c00 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:59 +0200
+Subject: fbdev: sm712fb: fix crashes during framebuffer writes by correctly mapping VRAM
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit 9e0e59993df0601cddb95c4f6c61aa3d5e753c00 upstream.
+
+On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), running fbtest or X
+will crash the machine instantly, because the VRAM/framebuffer is not
+mapped correctly.
+
+On SM712, the framebuffer starts at the beginning of address space, but
+SM720's framebuffer starts at the 1 MiB offset from the beginning. However,
+sm712fb fails to take this into account, as a result, writing to the
+framebuffer will destroy all the registers and kill the system immediately.
+Another problem is the driver assumes 8 MiB of VRAM for SM720, but some
+SM720 system, such as this IBM Thinkpad, only has 4 MiB of VRAM.
+
+Fix this problem by removing the hardcoded VRAM size, adding a function to
+query the amount of VRAM from register MCR76 on SM720, and adding proper
+framebuffer offset.
+
+Please note that the memory map may have additional problems on Big-Endian
+system, which is not available for testing by myself. But I highly suspect
+that the original code is also broken on Big-Endian machines for SM720, so
+at least we are not making the problem worse. More, the driver also assumed
+SM710/SM712 has 4 MiB of VRAM, but it has a 2 MiB version as well, and used
+in earlier laptops, such as IBM Thinkpad 240X, the driver would probably
+crash on them. I've never seen one of those machines and cannot fix it, but
+I have documented these problems in the comments.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712.h | 5 ----
+ drivers/video/fbdev/sm712fb.c | 48 ++++++++++++++++++++++++++++++++++++++----
+ 2 files changed, 44 insertions(+), 9 deletions(-)
+
+--- a/drivers/video/fbdev/sm712.h
++++ b/drivers/video/fbdev/sm712.h
+@@ -19,11 +19,6 @@
+ #define SCREEN_Y_RES 600
+ #define SCREEN_BPP 16
+
+-/*Assume SM712 graphics chip has 4MB VRAM */
+-#define SM712_VIDEOMEMORYSIZE 0x00400000
+-/*Assume SM722 graphics chip has 8MB VRAM */
+-#define SM722_VIDEOMEMORYSIZE 0x00800000
+-
+ #define dac_reg (0x3c8)
+ #define dac_val (0x3c9)
+
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -1329,6 +1329,11 @@ static int smtc_map_smem(struct smtcfb_i
+ {
+ sfb->fb->fix.smem_start = pci_resource_start(pdev, 0);
+
++ if (sfb->chip_id == 0x720)
++ /* on SM720, the framebuffer starts at the 1 MB offset */
++ sfb->fb->fix.smem_start += 0x00200000;
++
++ /* XXX: is it safe for SM720 on Big-Endian? */
+ if (sfb->fb->var.bits_per_pixel == 32)
+ sfb->fb->fix.smem_start += big_addr;
+
+@@ -1366,12 +1371,45 @@ static inline void sm7xx_init_hw(void)
+ outb_p(0x11, 0x3c5);
+ }
+
++static u_long sm7xx_vram_probe(struct smtcfb_info *sfb)
++{
++ u8 vram;
++
++ switch (sfb->chip_id) {
++ case 0x710:
++ case 0x712:
++ /*
++ * Assume SM712 graphics chip has 4MB VRAM.
++ *
++ * FIXME: SM712 can have 2MB VRAM, which is used on earlier
++ * laptops, such as IBM Thinkpad 240X. This driver would
++ * probably crash on those machines. If anyone gets one of
++ * those and is willing to help, run "git blame" and send me
++ * an E-mail.
++ */
++ return 0x00400000;
++ case 0x720:
++ outb_p(0x76, 0x3c4);
++ vram = inb_p(0x3c5) >> 6;
++
++ if (vram == 0x00)
++ return 0x00800000; /* 8 MB */
++ else if (vram == 0x01)
++ return 0x01000000; /* 16 MB */
++ else if (vram == 0x02)
++ return 0x00400000; /* illegal, fallback to 4 MB */
++ else if (vram == 0x03)
++ return 0x00400000; /* 4 MB */
++ }
++ return 0; /* unknown hardware */
++}
++
+ static int smtcfb_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+ {
+ struct smtcfb_info *sfb;
+ struct fb_info *info;
+- u_long smem_size = 0x00800000; /* default 8MB */
++ u_long smem_size;
+ int err;
+ unsigned long mmio_base;
+
+@@ -1428,12 +1466,15 @@ static int smtcfb_pci_probe(struct pci_d
+ mmio_base = pci_resource_start(pdev, 0);
+ pci_read_config_byte(pdev, PCI_REVISION_ID, &sfb->chip_rev_id);
+
++ smem_size = sm7xx_vram_probe(sfb);
++ dev_info(&pdev->dev, "%lu MiB of VRAM detected.\n",
++ smem_size / 1048576);
++
+ switch (sfb->chip_id) {
+ case 0x710:
+ case 0x712:
+ sfb->fb->fix.mmio_start = mmio_base + 0x00400000;
+ sfb->fb->fix.mmio_len = 0x00400000;
+- smem_size = SM712_VIDEOMEMORYSIZE;
+ sfb->lfb = ioremap(mmio_base, mmio_addr);
+ if (!sfb->lfb) {
+ dev_err(&pdev->dev,
+@@ -1465,8 +1506,7 @@ static int smtcfb_pci_probe(struct pci_d
+ case 0x720:
+ sfb->fb->fix.mmio_start = mmio_base;
+ sfb->fb->fix.mmio_len = 0x00200000;
+- smem_size = SM722_VIDEOMEMORYSIZE;
+- sfb->dp_regs = ioremap(mmio_base, 0x00a00000);
++ sfb->dp_regs = ioremap(mmio_base, 0x00200000 + smem_size);
+ sfb->lfb = sfb->dp_regs + 0x00200000;
+ sfb->mmio = (smtc_regbaseaddress =
+ sfb->dp_regs + 0x000c0000);
--- /dev/null
+From 6053d3a4793e5bde6299ac5388e76a3bf679ff65 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:59 +0200
+Subject: fbdev: sm712fb: fix support for 1024x768-16 mode
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit 6053d3a4793e5bde6299ac5388e76a3bf679ff65 upstream.
+
+In order to support the 1024x600 panel on Yeeloong Loongson MIPS
+laptop, the original 1024x768-16 table was modified to 1024x600-16,
+without leaving the original. It causes problem on x86 laptop as
+the 1024x768-16 support was still claimed but not working.
+
+Fix it by introducing the 1024x768-16 mode.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712fb.c | 59 ++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 59 insertions(+)
+
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -530,6 +530,65 @@ static const struct modeinit vgamode[] =
+ 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x15, 0x03,
+ },
+ },
++ { /* 1024 x 768 16Bpp 60Hz */
++ 1024, 768, 16, 60,
++ /* Init_MISC */
++ 0xEB,
++ { /* Init_SR0_SR4 */
++ 0x03, 0x01, 0x0F, 0x03, 0x0E,
++ },
++ { /* Init_SR10_SR24 */
++ 0xF3, 0xB6, 0xC0, 0xDD, 0x00, 0x0E, 0x17, 0x2C,
++ 0x99, 0x02, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
++ 0xC4, 0x30, 0x02, 0x01, 0x01,
++ },
++ { /* Init_SR30_SR75 */
++ 0x38, 0x03, 0x20, 0x09, 0xC0, 0x3A, 0x3A, 0x3A,
++ 0x3A, 0x3A, 0x3A, 0x3A, 0x00, 0x00, 0x03, 0xFF,
++ 0x00, 0xFC, 0x00, 0x00, 0x20, 0x18, 0x00, 0xFC,
++ 0x20, 0x0C, 0x44, 0x20, 0x00, 0x00, 0x00, 0x3A,
++ 0x06, 0x68, 0xA7, 0x7F, 0x83, 0x24, 0xFF, 0x03,
++ 0x0F, 0x60, 0x59, 0x3A, 0x3A, 0x00, 0x00, 0x3A,
++ 0x01, 0x80, 0x7E, 0x1A, 0x1A, 0x00, 0x00, 0x00,
++ 0x50, 0x03, 0x74, 0x14, 0x3B, 0x0D, 0x09, 0x02,
++ 0x04, 0x45, 0x30, 0x30, 0x40, 0x20,
++ },
++ { /* Init_SR80_SR93 */
++ 0xFF, 0x07, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0x3A,
++ 0xF7, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x3A, 0x3A,
++ 0x00, 0x00, 0x00, 0x00,
++ },
++ { /* Init_SRA0_SRAF */
++ 0x00, 0xFB, 0x9F, 0x01, 0x00, 0xED, 0xED, 0xED,
++ 0x7B, 0xFB, 0xFF, 0xFF, 0x97, 0xEF, 0xBF, 0xDF,
++ },
++ { /* Init_GR00_GR08 */
++ 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F,
++ 0xFF,
++ },
++ { /* Init_AR00_AR14 */
++ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
++ 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
++ 0x41, 0x00, 0x0F, 0x00, 0x00,
++ },
++ { /* Init_CR00_CR18 */
++ 0xA3, 0x7F, 0x7F, 0x00, 0x85, 0x16, 0x24, 0xF5,
++ 0x00, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
++ 0x03, 0x09, 0xFF, 0x80, 0x40, 0xFF, 0x00, 0xE3,
++ 0xFF,
++ },
++ { /* Init_CR30_CR4D */
++ 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x02, 0x20,
++ 0x00, 0x00, 0x00, 0x40, 0x00, 0xFF, 0xBF, 0xFF,
++ 0xA3, 0x7F, 0x00, 0x86, 0x15, 0x24, 0xFF, 0x00,
++ 0x01, 0x07, 0xE5, 0x20, 0x7F, 0xFF,
++ },
++ { /* Init_CR90_CRA7 */
++ 0x55, 0xD9, 0x5D, 0xE1, 0x86, 0x1B, 0x8E, 0x26,
++ 0xDA, 0x8D, 0xDE, 0x94, 0x00, 0x00, 0x18, 0x00,
++ 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x15, 0x03,
++ },
++ },
+ { /* mode#5: 1024 x 768 24Bpp 60Hz */
+ 1024, 768, 24, 60,
+ /* Init_MISC */
--- /dev/null
+From dcf9070595e100942c539e229dde4770aaeaa4e9 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:58 +0200
+Subject: fbdev: sm712fb: fix VRAM detection, don't set SR70/71/74/75
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit dcf9070595e100942c539e229dde4770aaeaa4e9 upstream.
+
+On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), the amount of Video
+RAM is not detected correctly by the xf86-video-siliconmotion driver.
+This is because sm712fb overwrites the GPR71 Scratch Pad Register, which
+is set by BIOS on x86 and used to indicate amount of VRAM.
+
+Other Scratch Pad Registers, including GPR70/74/75, don't have the same
+side-effect, but overwriting to them is still questionable, as they are
+not related to modesetting.
+
+Stop writing to SR70/71/74/75 (a.k.a GPR70/71/74/75).
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712fb.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -1146,7 +1146,9 @@ static void sm7xx_set_timing(struct smtc
+ /* init SEQ register SR30 - SR75 */
+ for (i = 0; i < SIZE_SR30_SR75; i++)
+ if ((i + 0x30) != 0x30 && (i + 0x30) != 0x62 &&
+- (i + 0x30) != 0x6a && (i + 0x30) != 0x6b)
++ (i + 0x30) != 0x6a && (i + 0x30) != 0x6b &&
++ (i + 0x30) != 0x70 && (i + 0x30) != 0x71 &&
++ (i + 0x30) != 0x74 && (i + 0x30) != 0x75)
+ smtc_seqw(i + 0x30,
+ vgamode[j].init_sr30_sr75[i]);
+
--- /dev/null
+From 8069053880e0ee3a75fd6d7e0a30293265fe3de4 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:58 +0200
+Subject: fbdev: sm712fb: fix white screen of death on reboot, don't set CR3B-CR3F
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit 8069053880e0ee3a75fd6d7e0a30293265fe3de4 upstream.
+
+On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
+sm712fb framebuffer driver would cause a white screen of death on
+the next POST, presumably the proper timings for the LCD panel was
+not reprogrammed properly by the BIOS.
+
+Experiments showed a few CRTC Scratch Registers, including CRT3D,
+CRT3E and CRT3F may be used internally by BIOS as some flags. CRT3B is
+a hardware testing register, we shouldn't mess with it. CRT3C has
+blanking signal and line compare control, which is not needed for this
+driver.
+
+Stop writing to CR3B-CR3F (a.k.a CRT3B-CRT3F) registers. Even if these
+registers don't have side-effect on other systems, writing to them is
+also highly questionable.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712fb.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -1173,8 +1173,12 @@ static void sm7xx_set_timing(struct smtc
+ smtc_crtcw(i, vgamode[j].init_cr00_cr18[i]);
+
+ /* init CRTC register CR30 - CR4D */
+- for (i = 0; i < SIZE_CR30_CR4D; i++)
++ for (i = 0; i < SIZE_CR30_CR4D; i++) {
++ if ((i + 0x30) >= 0x3B && (i + 0x30) <= 0x3F)
++ /* side-effect, don't write to CR3B-CR3F */
++ continue;
+ smtc_crtcw(i + 0x30, vgamode[j].init_cr30_cr4d[i]);
++ }
+
+ /* init CRTC register CR90 - CRA7 */
+ for (i = 0; i < SIZE_CR90_CRA7; i++)
--- /dev/null
+From 4ed7d2ccb7684510ec5f7a8f7ef534bc6a3d55b2 Mon Sep 17 00:00:00 2001
+From: Yifeng Li <tomli@tomli.me>
+Date: Mon, 1 Apr 2019 17:46:59 +0200
+Subject: fbdev: sm712fb: use 1024x768 by default on non-MIPS, fix garbled display
+
+From: Yifeng Li <tomli@tomli.me>
+
+commit 4ed7d2ccb7684510ec5f7a8f7ef534bc6a3d55b2 upstream.
+
+Loongson MIPS netbooks use 1024x600 LCD panels, which is the original
+target platform of this driver, but nearly all old x86 laptops have
+1024x768. Lighting 768 panels using 600's timings would partially
+garble the display. Since it's not possible to distinguish them reliably,
+we change the default to 768, but keep 600 as-is on MIPS.
+
+Further, earlier laptops, such as IBM Thinkpad 240X, has a 800x600 LCD
+panel, this driver would probably garbled those display. As we don't
+have one for testing, the original behavior of the driver is kept as-is,
+but the problem has been documented is the comments.
+
+Signed-off-by: Yifeng Li <tomli@tomli.me>
+Tested-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Cc: Teddy Wang <teddy.wang@siliconmotion.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/sm712.h | 7 +++--
+ drivers/video/fbdev/sm712fb.c | 53 +++++++++++++++++++++++++++++++-----------
+ 2 files changed, 44 insertions(+), 16 deletions(-)
+
+--- a/drivers/video/fbdev/sm712.h
++++ b/drivers/video/fbdev/sm712.h
+@@ -15,9 +15,10 @@
+
+ #define FB_ACCEL_SMI_LYNX 88
+
+-#define SCREEN_X_RES 1024
+-#define SCREEN_Y_RES 600
+-#define SCREEN_BPP 16
++#define SCREEN_X_RES 1024
++#define SCREEN_Y_RES_PC 768
++#define SCREEN_Y_RES_NETBOOK 600
++#define SCREEN_BPP 16
+
+ #define dac_reg (0x3c8)
+ #define dac_val (0x3c9)
+--- a/drivers/video/fbdev/sm712fb.c
++++ b/drivers/video/fbdev/sm712fb.c
+@@ -1463,6 +1463,43 @@ static u_long sm7xx_vram_probe(struct sm
+ return 0; /* unknown hardware */
+ }
+
++static void sm7xx_resolution_probe(struct smtcfb_info *sfb)
++{
++ /* get mode parameter from smtc_scr_info */
++ if (smtc_scr_info.lfb_width != 0) {
++ sfb->fb->var.xres = smtc_scr_info.lfb_width;
++ sfb->fb->var.yres = smtc_scr_info.lfb_height;
++ sfb->fb->var.bits_per_pixel = smtc_scr_info.lfb_depth;
++ goto final;
++ }
++
++ /*
++ * No parameter, default resolution is 1024x768-16.
++ *
++ * FIXME: earlier laptops, such as IBM Thinkpad 240X, has a 800x600
++ * panel, also see the comments about Thinkpad 240X above.
++ */
++ sfb->fb->var.xres = SCREEN_X_RES;
++ sfb->fb->var.yres = SCREEN_Y_RES_PC;
++ sfb->fb->var.bits_per_pixel = SCREEN_BPP;
++
++#ifdef CONFIG_MIPS
++ /*
++ * Loongson MIPS netbooks use 1024x600 LCD panels, which is the original
++ * target platform of this driver, but nearly all old x86 laptops have
++ * 1024x768. Lighting 768 panels using 600's timings would partially
++ * garble the display, so we don't want that. But it's not possible to
++ * distinguish them reliably.
++ *
++ * So we change the default to 768, but keep 600 as-is on MIPS.
++ */
++ sfb->fb->var.yres = SCREEN_Y_RES_NETBOOK;
++#endif
++
++final:
++ big_pixel_depth(sfb->fb->var.bits_per_pixel, smtc_scr_info.lfb_depth);
++}
++
+ static int smtcfb_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+ {
+@@ -1508,19 +1545,6 @@ static int smtcfb_pci_probe(struct pci_d
+
+ sm7xx_init_hw();
+
+- /* get mode parameter from smtc_scr_info */
+- if (smtc_scr_info.lfb_width != 0) {
+- sfb->fb->var.xres = smtc_scr_info.lfb_width;
+- sfb->fb->var.yres = smtc_scr_info.lfb_height;
+- sfb->fb->var.bits_per_pixel = smtc_scr_info.lfb_depth;
+- } else {
+- /* default resolution 1024x600 16bit mode */
+- sfb->fb->var.xres = SCREEN_X_RES;
+- sfb->fb->var.yres = SCREEN_Y_RES;
+- sfb->fb->var.bits_per_pixel = SCREEN_BPP;
+- }
+-
+- big_pixel_depth(sfb->fb->var.bits_per_pixel, smtc_scr_info.lfb_depth);
+ /* Map address and memory detection */
+ mmio_base = pci_resource_start(pdev, 0);
+ pci_read_config_byte(pdev, PCI_REVISION_ID, &sfb->chip_rev_id);
+@@ -1582,6 +1606,9 @@ static int smtcfb_pci_probe(struct pci_d
+ goto failed_fb;
+ }
+
++ /* probe and decide resolution */
++ sm7xx_resolution_probe(sfb);
++
+ /* can support 32 bpp */
+ if (sfb->fb->var.bits_per_pixel == 15)
+ sfb->fb->var.bits_per_pixel = 16;
--- /dev/null
+From b906c056b6023c390f18347169071193fda57dde Mon Sep 17 00:00:00 2001
+From: Dmitry Osipenko <digetx@gmail.com>
+Date: Fri, 12 Apr 2019 01:12:48 +0300
+Subject: memory: tegra: Fix integer overflow on tick value calculation
+
+From: Dmitry Osipenko <digetx@gmail.com>
+
+commit b906c056b6023c390f18347169071193fda57dde upstream.
+
+Multiplying the Memory Controller clock rate by the tick count results
+in an integer overflow and in result the truncated tick value is being
+programmed into hardware, such that the GR3D memory client performance is
+reduced by two times.
+
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/memory/tegra/mc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/memory/tegra/mc.c
++++ b/drivers/memory/tegra/mc.c
+@@ -72,7 +72,7 @@ static int tegra_mc_setup_latency_allowa
+ u32 value;
+
+ /* compute the number of MC clock cycles per tick */
+- tick = mc->tick * clk_get_rate(mc->clk);
++ tick = (unsigned long long)mc->tick * clk_get_rate(mc->clk);
+ do_div(tick, NSEC_PER_SEC);
+
+ value = readl(mc->regs + MC_EMEM_ARB_CFG);
--- /dev/null
+From 8ea58f1e8b11cca3087b294779bf5959bf89cc10 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Thu, 16 May 2019 12:49:42 -0500
+Subject: objtool: Allow AR to be overridden with HOSTAR
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+commit 8ea58f1e8b11cca3087b294779bf5959bf89cc10 upstream.
+
+Currently, this Makefile hardcodes GNU ar, meaning that if it is not
+available, there is no way to supply a different one and the build will
+fail.
+
+ $ make AR=llvm-ar CC=clang LD=ld.lld HOSTAR=llvm-ar HOSTCC=clang \
+ HOSTLD=ld.lld HOSTLDFLAGS=-fuse-ld=lld defconfig modules_prepare
+ ...
+ AR /out/tools/objtool/libsubcmd.a
+ /bin/sh: 1: ar: not found
+ ...
+
+Follow the logic of HOST{CC,LD} and allow the user to specify a
+different ar tool via HOSTAR (which is used elsewhere in other
+tools/ Makefiles).
+
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
+Cc: <stable@vger.kernel.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/80822a9353926c38fd7a152991c6292491a9d0e8.1558028966.git.jpoimboe@redhat.com
+Link: https://github.com/ClangBuiltLinux/linux/issues/481
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/objtool/Makefile | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/tools/objtool/Makefile
++++ b/tools/objtool/Makefile
+@@ -7,11 +7,12 @@ ARCH := x86
+ endif
+
+ # always use the host compiler
++HOSTAR ?= ar
+ HOSTCC ?= gcc
+ HOSTLD ?= ld
++AR = $(HOSTAR)
+ CC = $(HOSTCC)
+ LD = $(HOSTLD)
+-AR = ar
+
+ ifeq ($(srctree),)
+ srctree := $(patsubst %/,%,$(dir $(CURDIR)))
--- /dev/null
+From 86fa6a344209d9414ea962b1f1ac6ade9dd7563a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20M=C3=A4tje?= <stefan.maetje@esd.eu>
+Date: Fri, 29 Mar 2019 18:07:34 +0100
+Subject: PCI: Factor out pcie_retrain_link() function
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stefan Mätje <stefan.maetje@esd.eu>
+
+commit 86fa6a344209d9414ea962b1f1ac6ade9dd7563a upstream.
+
+Factor out pcie_retrain_link() to use for Pericom Retrain Link quirk. No
+functional change intended.
+
+Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pcie/aspm.c | 40 ++++++++++++++++++++++++----------------
+ 1 file changed, 24 insertions(+), 16 deletions(-)
+
+--- a/drivers/pci/pcie/aspm.c
++++ b/drivers/pci/pcie/aspm.c
+@@ -211,6 +211,29 @@ static void pcie_clkpm_cap_init(struct p
+ link->clkpm_capable = (blacklist) ? 0 : capable;
+ }
+
++static bool pcie_retrain_link(struct pcie_link_state *link)
++{
++ struct pci_dev *parent = link->pdev;
++ unsigned long start_jiffies;
++ u16 reg16;
++
++ pcie_capability_read_word(parent, PCI_EXP_LNKCTL, ®16);
++ reg16 |= PCI_EXP_LNKCTL_RL;
++ pcie_capability_write_word(parent, PCI_EXP_LNKCTL, reg16);
++
++ /* Wait for link training end. Break out after waiting for timeout */
++ start_jiffies = jiffies;
++ for (;;) {
++ pcie_capability_read_word(parent, PCI_EXP_LNKSTA, ®16);
++ if (!(reg16 & PCI_EXP_LNKSTA_LT))
++ break;
++ if (time_after(jiffies, start_jiffies + LINK_RETRAIN_TIMEOUT))
++ break;
++ msleep(1);
++ }
++ return !(reg16 & PCI_EXP_LNKSTA_LT);
++}
++
+ /*
+ * pcie_aspm_configure_common_clock: check if the 2 ends of a link
+ * could use common clock. If they are, configure them to use the
+@@ -220,7 +243,6 @@ static void pcie_aspm_configure_common_c
+ {
+ int same_clock = 1;
+ u16 reg16, parent_reg, child_reg[8];
+- unsigned long start_jiffies;
+ struct pci_dev *child, *parent = link->pdev;
+ struct pci_bus *linkbus = parent->subordinate;
+ /*
+@@ -260,21 +282,7 @@ static void pcie_aspm_configure_common_c
+ reg16 &= ~PCI_EXP_LNKCTL_CCC;
+ pcie_capability_write_word(parent, PCI_EXP_LNKCTL, reg16);
+
+- /* Retrain link */
+- reg16 |= PCI_EXP_LNKCTL_RL;
+- pcie_capability_write_word(parent, PCI_EXP_LNKCTL, reg16);
+-
+- /* Wait for link training end. Break out after waiting for timeout */
+- start_jiffies = jiffies;
+- for (;;) {
+- pcie_capability_read_word(parent, PCI_EXP_LNKSTA, ®16);
+- if (!(reg16 & PCI_EXP_LNKSTA_LT))
+- break;
+- if (time_after(jiffies, start_jiffies + LINK_RETRAIN_TIMEOUT))
+- break;
+- msleep(1);
+- }
+- if (!(reg16 & PCI_EXP_LNKSTA_LT))
++ if (pcie_retrain_link(link))
+ return;
+
+ /* Training failed. Restore common clock configurations */
--- /dev/null
+From d28ca864c493637f3c957f4ed9348a94fca6de60 Mon Sep 17 00:00:00 2001
+From: Nikolai Kostrigin <nickel@altlinux.org>
+Date: Mon, 8 Apr 2019 13:37:25 +0300
+Subject: PCI: Mark AMD Stoney Radeon R7 GPU ATS as broken
+
+From: Nikolai Kostrigin <nickel@altlinux.org>
+
+commit d28ca864c493637f3c957f4ed9348a94fca6de60 upstream.
+
+ATS is broken on the Radeon R7 GPU (at least for Stoney Ridge based laptop)
+and causes IOMMU stalls and system failure. Disable ATS on these devices
+to make them usable again with IOMMU enabled.
+
+Thanks to Joerg Roedel <jroedel@suse.de> for help.
+
+[bhelgaas: In the email thread mentioned below, Alex suspects the real
+problem is in sbios or iommu, so it may affect only certain systems, and it
+may affect other devices in those systems as well. However, per Joerg we
+lack the ability to debug further, so this quirk is the best we can do for
+now.]
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=194521
+Link: https://lore.kernel.org/lkml/20190408103725.30426-1-nickel@altlinux.org
+Fixes: 9b44b0b09dec ("PCI: Mark AMD Stoney GPU ATS as broken")
+Signed-off-by: Nikolai Kostrigin <nickel@altlinux.org>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Joerg Roedel <jroedel@suse.de>
+CC: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -4852,4 +4852,5 @@ static void quirk_no_ats(struct pci_dev
+
+ /* AMD Stoney platform GPU */
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6900, quirk_no_ats);
+ #endif /* CONFIG_PCI_ATS */
--- /dev/null
+From 6afb7e26978da5e86e57e540fdce65c8b04f398a Mon Sep 17 00:00:00 2001
+From: James Prestwood <james.prestwood@linux.intel.com>
+Date: Mon, 7 Jan 2019 13:32:48 -0800
+Subject: PCI: Mark Atheros AR9462 to avoid bus reset
+
+From: James Prestwood <james.prestwood@linux.intel.com>
+
+commit 6afb7e26978da5e86e57e540fdce65c8b04f398a upstream.
+
+When using PCI passthrough with this device, the host machine locks up
+completely when starting the VM, requiring a hard reboot. Add a quirk to
+avoid bus resets on this device.
+
+Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
+Link: https://lore.kernel.org/linux-pci/20190107213248.3034-1-james.prestwood@linux.intel.com
+Signed-off-by: James Prestwood <james.prestwood@linux.intel.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+CC: stable@vger.kernel.org # v3.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -3369,6 +3369,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_A
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0032, quirk_no_bus_reset);
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x003c, quirk_no_bus_reset);
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0033, quirk_no_bus_reset);
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0034, quirk_no_bus_reset);
+
+ static void quirk_no_pm_reset(struct pci_dev *dev)
+ {
--- /dev/null
+From 4ec73791a64bab25cabf16a6067ee478692e506d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20M=C3=A4tje?= <stefan.maetje@esd.eu>
+Date: Fri, 29 Mar 2019 18:07:35 +0100
+Subject: PCI: Work around Pericom PCIe-to-PCI bridge Retrain Link erratum
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stefan Mätje <stefan.maetje@esd.eu>
+
+commit 4ec73791a64bab25cabf16a6067ee478692e506d upstream.
+
+Due to an erratum in some Pericom PCIe-to-PCI bridges in reverse mode
+(conventional PCI on primary side, PCIe on downstream side), the Retrain
+Link bit needs to be cleared manually to allow the link training to
+complete successfully.
+
+If it is not cleared manually, the link training is continuously restarted
+and no devices below the PCI-to-PCIe bridge can be accessed. That means
+drivers for devices below the bridge will be loaded but won't work and may
+even crash because the driver is only reading 0xffff.
+
+See the Pericom Errata Sheet PI7C9X111SLB_errata_rev1.2_102711.pdf for
+details. Devices known as affected so far are: PI7C9X110, PI7C9X111SL,
+PI7C9X130.
+
+Add a new flag, clear_retrain_link, in struct pci_dev. Quirks for affected
+devices set this bit.
+
+Note that pcie_retrain_link() lives in aspm.c because that's currently the
+only place we use it, but this erratum is not specific to ASPM, and we may
+retrain links for other reasons in the future.
+
+Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
+[bhelgaas: apply regardless of CONFIG_PCIEASPM]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pcie/aspm.c | 9 +++++++++
+ drivers/pci/quirks.c | 17 +++++++++++++++++
+ include/linux/pci.h | 2 ++
+ 3 files changed, 28 insertions(+)
+
+--- a/drivers/pci/pcie/aspm.c
++++ b/drivers/pci/pcie/aspm.c
+@@ -220,6 +220,15 @@ static bool pcie_retrain_link(struct pci
+ pcie_capability_read_word(parent, PCI_EXP_LNKCTL, ®16);
+ reg16 |= PCI_EXP_LNKCTL_RL;
+ pcie_capability_write_word(parent, PCI_EXP_LNKCTL, reg16);
++ if (parent->clear_retrain_link) {
++ /*
++ * Due to an erratum in some devices the Retrain Link bit
++ * needs to be cleared again manually to allow the link
++ * training to succeed.
++ */
++ reg16 &= ~PCI_EXP_LNKCTL_RL;
++ pcie_capability_write_word(parent, PCI_EXP_LNKCTL, reg16);
++ }
+
+ /* Wait for link training end. Break out after waiting for timeout */
+ start_jiffies = jiffies;
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2085,6 +2085,23 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x10f4, quirk_disable_aspm_l0s);
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1508, quirk_disable_aspm_l0s);
+
++/*
++ * Some Pericom PCIe-to-PCI bridges in reverse mode need the PCIe Retrain
++ * Link bit cleared after starting the link retrain process to allow this
++ * process to finish.
++ *
++ * Affected devices: PI7C9X110, PI7C9X111SL, PI7C9X130. See also the
++ * Pericom Errata Sheet PI7C9X111SLB_errata_rev1.2_102711.pdf.
++ */
++static void quirk_enable_clear_retrain_link(struct pci_dev *dev)
++{
++ dev->clear_retrain_link = 1;
++ pci_info(dev, "Enable PCIe Retrain Link quirk\n");
++}
++DECLARE_PCI_FIXUP_HEADER(0x12d8, 0xe110, quirk_enable_clear_retrain_link);
++DECLARE_PCI_FIXUP_HEADER(0x12d8, 0xe111, quirk_enable_clear_retrain_link);
++DECLARE_PCI_FIXUP_HEADER(0x12d8, 0xe130, quirk_enable_clear_retrain_link);
++
+ static void fixup_rev1_53c810(struct pci_dev *dev)
+ {
+ u32 class = dev->class;
+--- a/include/linux/pci.h
++++ b/include/linux/pci.h
+@@ -350,6 +350,8 @@ struct pci_dev {
+ unsigned int hotplug_user_indicators:1; /* SlotCtl indicators
+ controlled exclusively by
+ user sysfs */
++ unsigned int clear_retrain_link:1; /* Need to clear Retrain Link
++ bit manually */
+ unsigned int d3_delay; /* D3->D0 transition time in ms */
+ unsigned int d3cold_delay; /* D3cold->D0 transition time in ms */
+
--- /dev/null
+From 61b6e08dc8e3ea80b7485c9b3f875ddd45c8466b Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 10 May 2019 15:41:42 +0300
+Subject: perf intel-pt: Fix improved sample timestamp
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 61b6e08dc8e3ea80b7485c9b3f875ddd45c8466b upstream.
+
+The decoder uses its current timestamp in samples. Usually that is a
+timestamp that has already passed, but in some cases it is a timestamp
+for a branch that the decoder is walking towards, and consequently
+hasn't reached.
+
+The intel_pt_sample_time() function decides which is which, but was not
+handling TNT packets exactly correctly.
+
+In the case of TNT, the timestamp applies to the first branch, so the
+decoder must first walk to that branch.
+
+That means intel_pt_sample_time() should return true for TNT, and this
+patch makes that change. However, if the first branch is a non-taken
+branch (i.e. a 'N'), then intel_pt_sample_time() needs to return false
+for subsequent taken branches in the same TNT packet.
+
+To handle that, introduce a new state INTEL_PT_STATE_TNT_CONT to
+distinguish the cases.
+
+Note that commit 3f04d98e972b5 ("perf intel-pt: Improve sample
+timestamp") was also a stable fix and appears, for example, in v4.4
+stable tree as commit a4ebb58fd124 ("perf intel-pt: Improve sample
+timestamp").
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org # v4.4+
+Fixes: 3f04d98e972b5 ("perf intel-pt: Improve sample timestamp")
+Link: http://lkml.kernel.org/r/20190510124143.27054-3-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -58,6 +58,7 @@ enum intel_pt_pkt_state {
+ INTEL_PT_STATE_NO_IP,
+ INTEL_PT_STATE_ERR_RESYNC,
+ INTEL_PT_STATE_IN_SYNC,
++ INTEL_PT_STATE_TNT_CONT,
+ INTEL_PT_STATE_TNT,
+ INTEL_PT_STATE_TIP,
+ INTEL_PT_STATE_TIP_PGD,
+@@ -72,8 +73,9 @@ static inline bool intel_pt_sample_time(
+ case INTEL_PT_STATE_NO_IP:
+ case INTEL_PT_STATE_ERR_RESYNC:
+ case INTEL_PT_STATE_IN_SYNC:
+- case INTEL_PT_STATE_TNT:
++ case INTEL_PT_STATE_TNT_CONT:
+ return true;
++ case INTEL_PT_STATE_TNT:
+ case INTEL_PT_STATE_TIP:
+ case INTEL_PT_STATE_TIP_PGD:
+ case INTEL_PT_STATE_FUP:
+@@ -1256,7 +1258,9 @@ static int intel_pt_walk_tnt(struct inte
+ return -ENOENT;
+ }
+ decoder->tnt.count -= 1;
+- if (!decoder->tnt.count)
++ if (decoder->tnt.count)
++ decoder->pkt_state = INTEL_PT_STATE_TNT_CONT;
++ else
+ decoder->pkt_state = INTEL_PT_STATE_IN_SYNC;
+ decoder->tnt.payload <<= 1;
+ decoder->state.from_ip = decoder->ip;
+@@ -1287,7 +1291,9 @@ static int intel_pt_walk_tnt(struct inte
+
+ if (intel_pt_insn.branch == INTEL_PT_BR_CONDITIONAL) {
+ decoder->tnt.count -= 1;
+- if (!decoder->tnt.count)
++ if (decoder->tnt.count)
++ decoder->pkt_state = INTEL_PT_STATE_TNT_CONT;
++ else
+ decoder->pkt_state = INTEL_PT_STATE_IN_SYNC;
+ if (decoder->tnt.payload & BIT63) {
+ decoder->tnt.payload <<= 1;
+@@ -2356,6 +2362,7 @@ const struct intel_pt_state *intel_pt_de
+ err = intel_pt_walk_trace(decoder);
+ break;
+ case INTEL_PT_STATE_TNT:
++ case INTEL_PT_STATE_TNT_CONT:
+ err = intel_pt_walk_tnt(decoder);
+ if (err == -EAGAIN)
+ err = intel_pt_walk_trace(decoder);
--- /dev/null
+From 7ba8fa20e26eb3c0c04d747f7fd2223694eac4d5 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 10 May 2019 15:41:41 +0300
+Subject: perf intel-pt: Fix instructions sampling rate
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 7ba8fa20e26eb3c0c04d747f7fd2223694eac4d5 upstream.
+
+The timestamp used to determine if an instruction sample is made, is an
+estimate based on the number of instructions since the last known
+timestamp. A consequence is that it might go backwards, which results in
+extra samples. Change it so that a sample is only made when the
+timestamp goes forwards.
+
+Note this does not affect a sampling period of 0 or sampling periods
+specified as a count of instructions.
+
+Example:
+
+ Before:
+
+ $ perf script --itrace=i10us
+ ls 13812 [003] 2167315.222583: 3270 instructions:u: 7fac71e2e494 __GI___tunables_init+0xf4 (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 30902 instructions:u: 7fac71e2da0f _dl_cache_libcmp+0x2f (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 10 instructions:u: 7fac71e2d9ff _dl_cache_libcmp+0x1f (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 8 instructions:u: 7fac71e2d9ea _dl_cache_libcmp+0xa (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 14 instructions:u: 7fac71e2d9ea _dl_cache_libcmp+0xa (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 6 instructions:u: 7fac71e2d9ff _dl_cache_libcmp+0x1f (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 14 instructions:u: 7fac71e2d9ff _dl_cache_libcmp+0x1f (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 4 instructions:u: 7fac71e2dab2 _dl_cache_libcmp+0xd2 (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222728: 16423 instructions:u: 7fac71e2477a _dl_map_object_deps+0x1ba (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222734: 12731 instructions:u: 7fac71e27938 _dl_name_match_p+0x68 (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ...
+
+ After:
+ $ perf script --itrace=i10us
+ ls 13812 [003] 2167315.222583: 3270 instructions:u: 7fac71e2e494 __GI___tunables_init+0xf4 (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222667: 30902 instructions:u: 7fac71e2da0f _dl_cache_libcmp+0x2f (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ls 13812 [003] 2167315.222728: 16479 instructions:u: 7fac71e2477a _dl_map_object_deps+0x1ba (/lib/x86_64-linux-gnu/ld-2.28.so)
+ ...
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: f4aa081949e7b ("perf tools: Add Intel PT decoder")
+Link: http://lkml.kernel.org/r/20190510124143.27054-2-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -888,16 +888,20 @@ static uint64_t intel_pt_next_period(str
+ timestamp = decoder->timestamp + decoder->timestamp_insn_cnt;
+ masked_timestamp = timestamp & decoder->period_mask;
+ if (decoder->continuous_period) {
+- if (masked_timestamp != decoder->last_masked_timestamp)
++ if (masked_timestamp > decoder->last_masked_timestamp)
+ return 1;
+ } else {
+ timestamp += 1;
+ masked_timestamp = timestamp & decoder->period_mask;
+- if (masked_timestamp != decoder->last_masked_timestamp) {
++ if (masked_timestamp > decoder->last_masked_timestamp) {
+ decoder->last_masked_timestamp = masked_timestamp;
+ decoder->continuous_period = true;
+ }
+ }
++
++ if (masked_timestamp < decoder->last_masked_timestamp)
++ return decoder->period_ticks;
++
+ return decoder->period_ticks - (timestamp - masked_timestamp);
+ }
+
+@@ -926,7 +930,10 @@ static void intel_pt_sample_insn(struct
+ case INTEL_PT_PERIOD_TICKS:
+ timestamp = decoder->timestamp + decoder->timestamp_insn_cnt;
+ masked_timestamp = timestamp & decoder->period_mask;
+- decoder->last_masked_timestamp = masked_timestamp;
++ if (masked_timestamp > decoder->last_masked_timestamp)
++ decoder->last_masked_timestamp = masked_timestamp;
++ else
++ decoder->last_masked_timestamp += decoder->period_ticks;
+ break;
+ case INTEL_PT_PERIOD_NONE:
+ case INTEL_PT_PERIOD_MTC:
--- /dev/null
+From 1b6599a9d8e6c9f7e9b0476012383b1777f7fc93 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 10 May 2019 15:41:43 +0300
+Subject: perf intel-pt: Fix sample timestamp wrt non-taken branches
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 1b6599a9d8e6c9f7e9b0476012383b1777f7fc93 upstream.
+
+The sample timestamp is updated to ensure that the timestamp represents
+the time of the sample and not a branch that the decoder is still
+walking towards. The sample timestamp is updated when the decoder
+returns, but the decoder does not return for non-taken branches. Update
+the sample timestamp then also.
+
+Note that commit 3f04d98e972b5 ("perf intel-pt: Improve sample
+timestamp") was also a stable fix and appears, for example, in v4.4
+stable tree as commit a4ebb58fd124 ("perf intel-pt: Improve sample
+timestamp").
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org # v4.4+
+Fixes: 3f04d98e972b ("perf intel-pt: Improve sample timestamp")
+Link: http://lkml.kernel.org/r/20190510124143.27054-4-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -1313,8 +1313,11 @@ static int intel_pt_walk_tnt(struct inte
+ return 0;
+ }
+ decoder->ip += intel_pt_insn.length;
+- if (!decoder->tnt.count)
++ if (!decoder->tnt.count) {
++ decoder->sample_timestamp = decoder->timestamp;
++ decoder->sample_insn_cnt = decoder->timestamp_insn_cnt;
+ return -EAGAIN;
++ }
+ decoder->tnt.payload <<= 1;
+ continue;
+ }
x86_64-add-gap-to-int3-to-allow-for-call-emulation.patch
x86_64-allow-breakpoints-to-emulate-call-instructions.patch
ftrace-x86_64-emulate-call-function-while-updating-in-breakpoint-handler.patch
+tracing-fix-partial-reading-of-trace-event-s-id-file.patch
+memory-tegra-fix-integer-overflow-on-tick-value-calculation.patch
+perf-intel-pt-fix-instructions-sampling-rate.patch
+perf-intel-pt-fix-improved-sample-timestamp.patch
+perf-intel-pt-fix-sample-timestamp-wrt-non-taken-branches.patch
+objtool-allow-ar-to-be-overridden-with-hostar.patch
+fbdev-sm712fb-fix-brightness-control-on-reboot-don-t-set-sr30.patch
+fbdev-sm712fb-fix-vram-detection-don-t-set-sr70-71-74-75.patch
+fbdev-sm712fb-fix-white-screen-of-death-on-reboot-don-t-set-cr3b-cr3f.patch
+fbdev-sm712fb-fix-boot-screen-glitch-when-sm712fb-replaces-vga.patch
+fbdev-sm712fb-fix-crashes-during-framebuffer-writes-by-correctly-mapping-vram.patch
+fbdev-sm712fb-fix-support-for-1024x768-16-mode.patch
+fbdev-sm712fb-use-1024x768-by-default-on-non-mips-fix-garbled-display.patch
+fbdev-sm712fb-fix-crashes-and-garbled-display-during-dpms-modesetting.patch
+pci-mark-amd-stoney-radeon-r7-gpu-ats-as-broken.patch
+pci-mark-atheros-ar9462-to-avoid-bus-reset.patch
+pci-factor-out-pcie_retrain_link-function.patch
+pci-work-around-pericom-pcie-to-pci-bridge-retrain-link-erratum.patch
--- /dev/null
+From cbe08bcbbe787315c425dde284dcb715cfbf3f39 Mon Sep 17 00:00:00 2001
+From: Elazar Leibovich <elazar@lightbitslabs.com>
+Date: Mon, 31 Dec 2018 13:58:37 +0200
+Subject: tracing: Fix partial reading of trace event's id file
+
+From: Elazar Leibovich <elazar@lightbitslabs.com>
+
+commit cbe08bcbbe787315c425dde284dcb715cfbf3f39 upstream.
+
+When reading only part of the id file, the ppos isn't tracked correctly.
+This is taken care by simple_read_from_buffer.
+
+Reading a single byte, and then the next byte would result EOF.
+
+While this seems like not a big deal, this breaks abstractions that
+reads information from files unbuffered. See for example
+https://github.com/golang/go/issues/29399
+
+This code was mentioned as problematic in
+commit cd458ba9d5a5
+("tracing: Do not (ab)use trace_seq in event_id_read()")
+
+An example C code that show this bug is:
+
+ #include <stdio.h>
+ #include <stdint.h>
+
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ #include <fcntl.h>
+ #include <unistd.h>
+
+ int main(int argc, char **argv) {
+ if (argc < 2)
+ return 1;
+ int fd = open(argv[1], O_RDONLY);
+ char c;
+ read(fd, &c, 1);
+ printf("First %c\n", c);
+ read(fd, &c, 1);
+ printf("Second %c\n", c);
+ }
+
+Then run with, e.g.
+
+ sudo ./a.out /sys/kernel/debug/tracing/events/tcp/tcp_set_state/id
+
+You'll notice you're getting the first character twice, instead of the
+first two characters in the id file.
+
+Link: http://lkml.kernel.org/r/20181231115837.4932-1-elazar@lightbitslabs.com
+
+Cc: Orit Wasserman <orit.was@gmail.com>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 23725aeeab10b ("ftrace: provide an id file for each event")
+Signed-off-by: Elazar Leibovich <elazar@lightbitslabs.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_events.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/kernel/trace/trace_events.c
++++ b/kernel/trace/trace_events.c
+@@ -1319,9 +1319,6 @@ event_id_read(struct file *filp, char __
+ char buf[32];
+ int len;
+
+- if (*ppos)
+- return 0;
+-
+ if (unlikely(!id))
+ return -ENODEV;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
