--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:17 +0530
+Subject: ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520
+To: stable@vger.kernel.org
+Cc: Alex Hung <alex.hung@canonical.com>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-18-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Alex Hung <alex.hung@canonical.com>
+
+[ Upstream commit 9523b9bf6dceef6b0215e90b2348cd646597f796 ]
+
+Precision 5520 and 3520 either hang at login and during suspend or reboot.
+
+It turns out that that adding them to acpi_rev_dmi_table[] helps to work
+around those issues.
+
+Signed-off-by: Alex Hung <alex.hung@canonical.com>
+[ rjw: Changelog ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/blacklist.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/drivers/acpi/blacklist.c
++++ b/drivers/acpi/blacklist.c
+@@ -346,6 +346,22 @@ static struct dmi_system_id acpi_osi_dmi
+ DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9343"),
+ },
+ },
++ {
++ .callback = dmi_enable_rev_override,
++ .ident = "DELL Precision 5520",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Precision 5520"),
++ },
++ },
++ {
++ .callback = dmi_enable_rev_override,
++ .ident = "DELL Precision 3520",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3520"),
++ },
++ },
+ #endif
+ {}
+ };
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:18 +0530
+Subject: ACPI / blacklist: Make Dell Latitude 3350 ethernet work
+To: stable@vger.kernel.org
+Cc: Michael Pobega <mpobega@neverware.com>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-19-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Michael Pobega <mpobega@neverware.com>
+
+[ Upstream commit 708f5dcc21ae9b35f395865fc154b0105baf4de4 ]
+
+The Dell Latitude 3350's ethernet card attempts to use a reserved
+IRQ (18), resulting in ACPI being unable to enable the ethernet.
+
+Adding it to acpi_rev_dmi_table[] helps to work around this problem.
+
+Signed-off-by: Michael Pobega <mpobega@neverware.com>
+[ rjw: Changelog ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/blacklist.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/acpi/blacklist.c
++++ b/drivers/acpi/blacklist.c
+@@ -362,6 +362,18 @@ static struct dmi_system_id acpi_osi_dmi
+ DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3520"),
+ },
+ },
++ /*
++ * Resolves a quirk with the Dell Latitude 3350 that
++ * causes the ethernet adapter to not function.
++ */
++ {
++ .callback = dmi_enable_rev_override,
++ .ident = "DELL Latitude 3350",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Latitude 3350"),
++ },
++ },
+ #endif
+ {}
+ };
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:14 +0530
+Subject: block: allow WRITE_SAME commands with the SG_IO ioctl
+To: stable@vger.kernel.org
+Cc: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>, Brahadambal Srinivasan <latha@linux.vnet.ibm.com>, Jens Axboe <axboe@fb.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-15-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
+
+[ Upstream commit 25cdb64510644f3e854d502d69c73f21c6df88a9 ]
+
+The WRITE_SAME commands are not present in the blk_default_cmd_filter
+write_ok list, and thus are failed with -EPERM when the SG_IO ioctl()
+is executed without CAP_SYS_RAWIO capability (e.g., unprivileged users).
+[ sg_io() -> blk_fill_sghdr_rq() > blk_verify_command() -> -EPERM ]
+
+The problem can be reproduced with the sg_write_same command
+
+ # sg_write_same --num 1 --xferlen 512 /dev/sda
+ #
+
+ # capsh --drop=cap_sys_rawio -- -c \
+ 'sg_write_same --num 1 --xferlen 512 /dev/sda'
+ Write same: pass through os error: Operation not permitted
+ #
+
+For comparison, the WRITE_VERIFY command does not observe this problem,
+since it is in that list:
+
+ # capsh --drop=cap_sys_rawio -- -c \
+ 'sg_write_verify --num 1 --ilen 512 --lba 0 /dev/sda'
+ #
+
+So, this patch adds the WRITE_SAME commands to the list, in order
+for the SG_IO ioctl to finish successfully:
+
+ # capsh --drop=cap_sys_rawio -- -c \
+ 'sg_write_same --num 1 --xferlen 512 /dev/sda'
+ #
+
+That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices
+(qemu "-device scsi-block" [1], libvirt "<disk type='block' device='lun'>" [2]),
+which employs the SG_IO ioctl() and runs as an unprivileged user (libvirt-qemu).
+
+In that scenario, when a filesystem (e.g., ext4) performs its zero-out calls,
+which are translated to write-same calls in the guest kernel, and then into
+SG_IO ioctls to the host kernel, SCSI I/O errors may be observed in the guest:
+
+ [...] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
+ [...] sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
+ [...] sd 0:0:0:0: [sda] tag#0 Add. Sense: I/O process terminated
+ [...] sd 0:0:0:0: [sda] tag#0 CDB: Write Same(10) 41 00 01 04 e0 78 00 00 08 00
+ [...] blk_update_request: I/O error, dev sda, sector 17096824
+
+Links:
+[1] http://git.qemu.org/?p=qemu.git;a=commit;h=336a6915bc7089fb20fea4ba99972ad9a97c5f52
+[2] https://libvirt.org/formatdomain.html#elementsDisks (see 'disk' -> 'device')
+
+Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
+Signed-off-by: Brahadambal Srinivasan <latha@linux.vnet.ibm.com>
+Reported-by: Manjunatha H R <manjuhr1@in.ibm.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/scsi_ioctl.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/block/scsi_ioctl.c
++++ b/block/scsi_ioctl.c
+@@ -182,6 +182,9 @@ static void blk_set_cmd_filter_defaults(
+ __set_bit(WRITE_16, filter->write_ok);
+ __set_bit(WRITE_LONG, filter->write_ok);
+ __set_bit(WRITE_LONG_2, filter->write_ok);
++ __set_bit(WRITE_SAME, filter->write_ok);
++ __set_bit(WRITE_SAME_16, filter->write_ok);
++ __set_bit(WRITE_SAME_32, filter->write_ok);
+ __set_bit(ERASE, filter->write_ok);
+ __set_bit(GPCMD_MODE_SELECT_10, filter->write_ok);
+ __set_bit(MODE_SELECT, filter->write_ok);
--- /dev/null
+From 6207119444595d287b1e9e83a2066c17209698f3 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Thu, 15 Dec 2016 14:31:01 +0100
+Subject: crypto: algif_hash - avoid zero-sized array
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit 6207119444595d287b1e9e83a2066c17209698f3 upstream.
+
+With this reproducer:
+ struct sockaddr_alg alg = {
+ .salg_family = 0x26,
+ .salg_type = "hash",
+ .salg_feat = 0xf,
+ .salg_mask = 0x5,
+ .salg_name = "digest_null",
+ };
+ int sock, sock2;
+
+ sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
+ bind(sock, (struct sockaddr *)&alg, sizeof(alg));
+ sock2 = accept(sock, NULL, NULL);
+ setsockopt(sock, SOL_ALG, ALG_SET_KEY, "\x9b\xca", 2);
+ accept(sock2, NULL, NULL);
+
+==== 8< ======== 8< ======== 8< ======== 8< ====
+
+one can immediatelly see an UBSAN warning:
+UBSAN: Undefined behaviour in crypto/algif_hash.c:187:7
+variable length array bound value 0 <= 0
+CPU: 0 PID: 15949 Comm: syz-executor Tainted: G E 4.4.30-0-default #1
+...
+Call Trace:
+...
+ [<ffffffff81d598fd>] ? __ubsan_handle_vla_bound_not_positive+0x13d/0x188
+ [<ffffffff81d597c0>] ? __ubsan_handle_out_of_bounds+0x1bc/0x1bc
+ [<ffffffffa0e2204d>] ? hash_accept+0x5bd/0x7d0 [algif_hash]
+ [<ffffffffa0e2293f>] ? hash_accept_nokey+0x3f/0x51 [algif_hash]
+ [<ffffffffa0e206b0>] ? hash_accept_parent_nokey+0x4a0/0x4a0 [algif_hash]
+ [<ffffffff8235c42b>] ? SyS_accept+0x2b/0x40
+
+It is a correct warning, as hash state is propagated to accept as zero,
+but creating a zero-length variable array is not allowed in C.
+
+Fix this as proposed by Herbert -- do "?: 1" on that site. No sizeof or
+similar happens in the code there, so we just allocate one byte even
+though we do not use the array.
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Cc: Herbert Xu <herbert@gondor.apana.org.au>
+Cc: "David S. Miller" <davem@davemloft.net> (maintainer:CRYPTO API)
+Reported-by: Sasha Levin <sasha.levin@oracle.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/algif_hash.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/crypto/algif_hash.c
++++ b/crypto/algif_hash.c
+@@ -184,7 +184,7 @@ static int hash_accept(struct socket *so
+ struct alg_sock *ask = alg_sk(sk);
+ struct hash_ctx *ctx = ask->private;
+ struct ahash_request *req = &ctx->req;
+- char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
++ char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req)) ? : 1];
+ struct sock *sk2;
+ struct alg_sock *ask2;
+ struct hash_ctx *ctx2;
--- /dev/null
+From 8aac7f34369726d1a158788ae8aff3002d5eb528 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 11 Jan 2017 17:09:50 +0100
+Subject: fbcon: Fix vc attr at deinit
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.
+
+fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
+the vc attrs dynamically when vc_hi_font_mask is changed at
+fbcon_init(). When the vc_hi_font_mask is set, it remaps the attrs in
+the existing console buffer with one bit shift up (for 9 bits), while
+it remaps with one bit shift down (for 8 bits) when the value is
+cleared. It works fine as long as the font gets updated after fbcon
+was initialized.
+
+However, we hit a bizarre problem when the console is switched to
+another fb driver (typically from vesafb or efifb to drmfb). At
+switching to the new fb driver, we temporarily rebind the console to
+the dummy console, then rebind to the new driver. During the
+switching, we leave the modified attrs as is. Thus, the new fbcon
+takes over the old buffer as if it were to contain 8 bits chars
+(although the attrs are still shifted for 9 bits), and effectively
+this results in the yellow color texts instead of the original white
+color, as found in the bugzilla entry below.
+
+An easy fix for this is to re-adjust the attrs before leaving the
+fbcon at con_deinit callback. Since the code to adjust the attrs is
+already present in the current fbcon code, in this patch, we simply
+factor out the relevant code, and call it from fbcon_deinit().
+
+Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/console/fbcon.c | 67 +++++++++++++++++++++++++-----------------
+ 1 file changed, 40 insertions(+), 27 deletions(-)
+
+--- a/drivers/video/console/fbcon.c
++++ b/drivers/video/console/fbcon.c
+@@ -1168,6 +1168,8 @@ static void fbcon_free_font(struct displ
+ p->userfont = 0;
+ }
+
++static void set_vc_hi_font(struct vc_data *vc, bool set);
++
+ static void fbcon_deinit(struct vc_data *vc)
+ {
+ struct display *p = &fb_display[vc->vc_num];
+@@ -1203,6 +1205,9 @@ finished:
+ if (free_font)
+ vc->vc_font.data = NULL;
+
++ if (vc->vc_hi_font_mask)
++ set_vc_hi_font(vc, false);
++
+ if (!con_is_bound(&fb_con))
+ fbcon_exit();
+
+@@ -2439,32 +2444,10 @@ static int fbcon_get_font(struct vc_data
+ return 0;
+ }
+
+-static int fbcon_do_set_font(struct vc_data *vc, int w, int h,
+- const u8 * data, int userfont)
++/* set/clear vc_hi_font_mask and update vc attrs accordingly */
++static void set_vc_hi_font(struct vc_data *vc, bool set)
+ {
+- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+- struct fbcon_ops *ops = info->fbcon_par;
+- struct display *p = &fb_display[vc->vc_num];
+- int resize;
+- int cnt;
+- char *old_data = NULL;
+-
+- if (CON_IS_VISIBLE(vc) && softback_lines)
+- fbcon_set_origin(vc);
+-
+- resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
+- if (p->userfont)
+- old_data = vc->vc_font.data;
+- if (userfont)
+- cnt = FNTCHARCNT(data);
+- else
+- cnt = 256;
+- vc->vc_font.data = (void *)(p->fontdata = data);
+- if ((p->userfont = userfont))
+- REFCOUNT(data)++;
+- vc->vc_font.width = w;
+- vc->vc_font.height = h;
+- if (vc->vc_hi_font_mask && cnt == 256) {
++ if (!set) {
+ vc->vc_hi_font_mask = 0;
+ if (vc->vc_can_do_color) {
+ vc->vc_complement_mask >>= 1;
+@@ -2487,7 +2470,7 @@ static int fbcon_do_set_font(struct vc_d
+ ((c & 0xfe00) >> 1) | (c & 0xff);
+ vc->vc_attr >>= 1;
+ }
+- } else if (!vc->vc_hi_font_mask && cnt == 512) {
++ } else {
+ vc->vc_hi_font_mask = 0x100;
+ if (vc->vc_can_do_color) {
+ vc->vc_complement_mask <<= 1;
+@@ -2519,8 +2502,38 @@ static int fbcon_do_set_font(struct vc_d
+ } else
+ vc->vc_video_erase_char = c & ~0x100;
+ }
+-
+ }
++}
++
++static int fbcon_do_set_font(struct vc_data *vc, int w, int h,
++ const u8 * data, int userfont)
++{
++ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
++ struct fbcon_ops *ops = info->fbcon_par;
++ struct display *p = &fb_display[vc->vc_num];
++ int resize;
++ int cnt;
++ char *old_data = NULL;
++
++ if (CON_IS_VISIBLE(vc) && softback_lines)
++ fbcon_set_origin(vc);
++
++ resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
++ if (p->userfont)
++ old_data = vc->vc_font.data;
++ if (userfont)
++ cnt = FNTCHARCNT(data);
++ else
++ cnt = 256;
++ vc->vc_font.data = (void *)(p->fontdata = data);
++ if ((p->userfont = userfont))
++ REFCOUNT(data)++;
++ vc->vc_font.width = w;
++ vc->vc_font.height = h;
++ if (vc->vc_hi_font_mask && cnt == 256)
++ set_vc_hi_font(vc, false);
++ else if (!vc->vc_hi_font_mask && cnt == 512)
++ set_vc_hi_font(vc, true);
+
+ if (resize) {
+ int cols, rows;
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:03 +0530
+Subject: igb: add i211 to i210 PHY workaround
+To: stable@vger.kernel.org
+Cc: Todd Fujinaka <todd.fujinaka@intel.com>, Jeff Kirsher <jeffrey.t.kirsher@intel.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-4-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Todd Fujinaka <todd.fujinaka@intel.com>
+
+[ Upstream commit 5bc8c230e2a993b49244f9457499f17283da9ec7 ]
+
+i210 and i211 share the same PHY but have different PCI IDs. Don't
+forget i211 for any i210 workarounds.
+
+Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/igb/e1000_phy.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
++++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
+@@ -78,7 +78,7 @@ s32 igb_get_phy_id(struct e1000_hw *hw)
+ u16 phy_id;
+
+ /* ensure PHY page selection to fix misconfigured i210 */
+- if (hw->mac.type == e1000_i210)
++ if ((hw->mac.type == e1000_i210) || (hw->mac.type == e1000_i211))
+ phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0);
+
+ ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:02 +0530
+Subject: igb: Workaround for igb i210 firmware issue
+To: stable@vger.kernel.org
+Cc: Chris J Arges <christopherarges@gmail.com>, Jeff Kirsher <jeffrey.t.kirsher@intel.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-3-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Chris J Arges <christopherarges@gmail.com>
+
+[ Upstream commit 4e684f59d760a2c7c716bb60190783546e2d08a1 ]
+
+Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT causing
+the probe of an igb i210 NIC to fail. This patch adds an addition zeroing
+of this register during igb_get_phy_id to workaround this issue.
+
+Thanks for Jochen Henneberg for the idea and original patch.
+
+Signed-off-by: Chris J Arges <christopherarges@gmail.com>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/igb/e1000_phy.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
++++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
+@@ -77,6 +77,10 @@ s32 igb_get_phy_id(struct e1000_hw *hw)
+ s32 ret_val = 0;
+ u16 phy_id;
+
++ /* ensure PHY page selection to fix misconfigured i210 */
++ if (hw->mac.type == e1000_i210)
++ phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0);
++
+ ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
+ if (ret_val)
+ goto out;
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:07 +0530
+Subject: PCI: Add comments about ROM BAR updating
+To: stable@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-8-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+[ Upstream commit 0b457dde3cf8b7c76a60f8e960f21bbd4abdc416 ]
+
+pci_update_resource() updates a hardware BAR so its address matches the
+kernel's struct resource UNLESS it's a disabled ROM BAR. We only update
+those when we enable the ROM.
+
+It's not obvious from the code why ROM BARs should be handled specially.
+Apparently there are Matrox devices with defective ROM BARs that read as
+zero when disabled. That means that if pci_enable_rom() reads the disabled
+BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and
+writes it back, it would enable the ROM at address zero.
+
+Add comments and references to explain why we can't make the code look more
+rational.
+
+The code changes are from 755528c860b0 ("Ignore disabled ROM resources at
+setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping").
+
+Link: https://lkml.org/lkml/2005/8/30/138
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+ [sumits: minor fixup in rom.c for 4.4.y]
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/rom.c | 5 +++++
+ drivers/pci/setup-res.c | 6 ++++++
+ 2 files changed, 11 insertions(+)
+
+--- a/drivers/pci/rom.c
++++ b/drivers/pci/rom.c
+@@ -31,6 +31,11 @@ int pci_enable_rom(struct pci_dev *pdev)
+ if (!res->flags)
+ return -1;
+
++ /*
++ * Ideally pci_update_resource() would update the ROM BAR address,
++ * and we would only set the enable bit here. But apparently some
++ * devices have buggy ROM BARs that read as zero when disabled.
++ */
+ pcibios_resource_to_bus(pdev->bus, ®ion, res);
+ pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr);
+ rom_addr &= ~PCI_ROM_ADDRESS_MASK;
+--- a/drivers/pci/setup-res.c
++++ b/drivers/pci/setup-res.c
+@@ -68,6 +68,12 @@ static void pci_std_update_resource(stru
+ if (resno < PCI_ROM_RESOURCE) {
+ reg = PCI_BASE_ADDRESS_0 + 4 * resno;
+ } else if (resno == PCI_ROM_RESOURCE) {
++
++ /*
++ * Apparently some Matrox devices have ROM BARs that read
++ * as zero when disabled, so don't update ROM BARs unless
++ * they're enabled. See https://lkml.org/lkml/2005/8/30/138.
++ */
+ if (!(res->flags & IORESOURCE_ROM_ENABLE))
+ return;
+
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:08 +0530
+Subject: PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE
+To: stable@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-9-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+[ Upstream commit 7a6d312b50e63f598f5b5914c4fd21878ac2b595 ]
+
+Remove the assumption that IORESOURCE_ROM_ENABLE == PCI_ROM_ADDRESS_ENABLE.
+PCI_ROM_ADDRESS_ENABLE is the ROM enable bit defined by the PCI spec, so if
+we're reading or writing a BAR register value, that's what we should use.
+IORESOURCE_ROM_ENABLE is a corresponding bit in struct resource flags.
+
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/probe.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/probe.c
++++ b/drivers/pci/probe.c
+@@ -226,7 +226,8 @@ int __pci_read_base(struct pci_dev *dev,
+ mask64 = (u32)PCI_BASE_ADDRESS_MEM_MASK;
+ }
+ } else {
+- res->flags |= (l & IORESOURCE_ROM_ENABLE);
++ if (l & PCI_ROM_ADDRESS_ENABLE)
++ res->flags |= IORESOURCE_ROM_ENABLE;
+ l64 = l & PCI_ROM_ADDRESS_MASK;
+ sz64 = sz & PCI_ROM_ADDRESS_MASK;
+ mask64 = (u32)PCI_ROM_ADDRESS_MASK;
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:12 +0530
+Subject: PCI: Do any VF BAR updates before enabling the BARs
+To: stable@vger.kernel.org
+Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>, Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-13-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+
+[ Upstream commit f40ec3c748c6912f6266c56a7f7992de61b255ed ]
+
+Previously we enabled VFs and enable their memory space before calling
+pcibios_sriov_enable(). But pcibios_sriov_enable() may update the VF BARs:
+for example, on PPC PowerNV we may change them to manage the association of
+VFs to PEs.
+
+Because 64-bit BARs cannot be updated atomically, it's unsafe to update
+them while they're enabled. The half-updated state may conflict with other
+devices in the system.
+
+Call pcibios_sriov_enable() before enabling the VFs so any BAR updates
+happen while the VF BARs are disabled.
+
+[bhelgaas: changelog]
+Tested-by: Carol Soto <clsoto@us.ibm.com>
+Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/iov.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/pci/iov.c
++++ b/drivers/pci/iov.c
+@@ -303,13 +303,6 @@ static int sriov_enable(struct pci_dev *
+ return rc;
+ }
+
+- pci_iov_set_numvfs(dev, nr_virtfn);
+- iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE;
+- pci_cfg_access_lock(dev);
+- pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
+- msleep(100);
+- pci_cfg_access_unlock(dev);
+-
+ iov->initial_VFs = initial;
+ if (nr_virtfn < initial)
+ initial = nr_virtfn;
+@@ -320,6 +313,13 @@ static int sriov_enable(struct pci_dev *
+ goto err_pcibios;
+ }
+
++ pci_iov_set_numvfs(dev, nr_virtfn);
++ iov->ctrl |= PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE;
++ pci_cfg_access_lock(dev);
++ pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
++ msleep(100);
++ pci_cfg_access_unlock(dev);
++
+ for (i = 0; i < initial; i++) {
+ rc = virtfn_add(dev, i, 0);
+ if (rc)
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:09 +0530
+Subject: PCI: Don't update VF BARs while VF memory space is enabled
+To: stable@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-10-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+[ Upstream commit 546ba9f8f22f71b0202b6ba8967be5cc6dae4e21 ]
+
+If we update a VF BAR while it's enabled, there are two potential problems:
+
+ 1) Any driver that's using the VF has a cached BAR value that is stale
+ after the update, and
+
+ 2) We can't update 64-bit BARs atomically, so the intermediate state
+ (new lower dword with old upper dword) may conflict with another
+ device, and an access by a driver unrelated to the VF may cause a bus
+ error.
+
+Warn about attempts to update VF BARs while they are enabled. This is a
+programming error, so use dev_WARN() to get a backtrace.
+
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/iov.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/pci/iov.c
++++ b/drivers/pci/iov.c
+@@ -567,6 +567,7 @@ void pci_iov_update_resource(struct pci_
+ struct resource *res = dev->resource + resno;
+ int vf_bar = resno - PCI_IOV_RESOURCES;
+ struct pci_bus_region region;
++ u16 cmd;
+ u32 new;
+ int reg;
+
+@@ -578,6 +579,13 @@ void pci_iov_update_resource(struct pci_
+ if (!iov)
+ return;
+
++ pci_read_config_word(dev, iov->pos + PCI_SRIOV_CTRL, &cmd);
++ if ((cmd & PCI_SRIOV_CTRL_VFE) && (cmd & PCI_SRIOV_CTRL_MSE)) {
++ dev_WARN(&dev->dev, "can't update enabled VF BAR%d %pR\n",
++ vf_bar, res);
++ return;
++ }
++
+ /*
+ * Ignore unimplemented BARs, unused resource slots for 64-bit
+ * BARs, and non-movable resources, e.g., those described via
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:11 +0530
+Subject: PCI: Ignore BAR updates on virtual functions
+To: stable@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-12-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+[ Upstream commit 63880b230a4af502c56dde3d4588634c70c66006 ]
+
+VF BARs are read-only zero, so updating VF BARs will not have any effect.
+See the SR-IOV spec r1.1, sec 3.4.1.11.
+
+We already ignore these updates because of 70675e0b6a1a ("PCI: Don't try to
+restore VF BARs"); this merely restructures it slightly to make it easier
+to split updates for standard and SR-IOV BARs.
+
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pci.c | 4 ----
+ drivers/pci/setup-res.c | 5 ++---
+ 2 files changed, 2 insertions(+), 7 deletions(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -519,10 +519,6 @@ static void pci_restore_bars(struct pci_
+ {
+ int i;
+
+- /* Per SR-IOV spec 3.4.1.11, VF BARs are RO zero */
+- if (dev->is_virtfn)
+- return;
+-
+ for (i = 0; i < PCI_BRIDGE_RESOURCES; i++)
+ pci_update_resource(dev, i);
+ }
+--- a/drivers/pci/setup-res.c
++++ b/drivers/pci/setup-res.c
+@@ -34,10 +34,9 @@ static void pci_std_update_resource(stru
+ int reg;
+ struct resource *res = dev->resource + resno;
+
+- if (dev->is_virtfn) {
+- dev_warn(&dev->dev, "can't update VF BAR%d\n", resno);
++ /* Per SR-IOV spec 3.4.1.11, VF BARs are RO zero */
++ if (dev->is_virtfn)
+ return;
+- }
+
+ /*
+ * Ignore resources for unimplemented BARs and unused resource slots
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:06 +0530
+Subject: PCI: Remove pci_resource_bar() and pci_iov_resource_bar()
+To: stable@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-7-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+[ Upstream commit 286c2378aaccc7343ebf17ec6cd86567659caf70 ]
+
+pci_std_update_resource() only deals with standard BARs, so we don't have
+to worry about the complications of VF BARs in an SR-IOV capability.
+
+Compute the BAR address inline and remove pci_resource_bar(). That makes
+pci_iov_resource_bar() unused, so remove that as well.
+
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/iov.c | 18 ------------------
+ drivers/pci/pci.c | 30 ------------------------------
+ drivers/pci/pci.h | 6 ------
+ drivers/pci/setup-res.c | 13 +++++++------
+ 4 files changed, 7 insertions(+), 60 deletions(-)
+
+--- a/drivers/pci/iov.c
++++ b/drivers/pci/iov.c
+@@ -555,24 +555,6 @@ void pci_iov_release(struct pci_dev *dev
+ }
+
+ /**
+- * pci_iov_resource_bar - get position of the SR-IOV BAR
+- * @dev: the PCI device
+- * @resno: the resource number
+- *
+- * Returns position of the BAR encapsulated in the SR-IOV capability.
+- */
+-int pci_iov_resource_bar(struct pci_dev *dev, int resno)
+-{
+- if (resno < PCI_IOV_RESOURCES || resno > PCI_IOV_RESOURCE_END)
+- return 0;
+-
+- BUG_ON(!dev->is_physfn);
+-
+- return dev->sriov->pos + PCI_SRIOV_BAR +
+- 4 * (resno - PCI_IOV_RESOURCES);
+-}
+-
+-/**
+ * pci_iov_update_resource - update a VF BAR
+ * @dev: the PCI device
+ * @resno: the resource number
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -4472,36 +4472,6 @@ int pci_select_bars(struct pci_dev *dev,
+ }
+ EXPORT_SYMBOL(pci_select_bars);
+
+-/**
+- * pci_resource_bar - get position of the BAR associated with a resource
+- * @dev: the PCI device
+- * @resno: the resource number
+- * @type: the BAR type to be filled in
+- *
+- * Returns BAR position in config space, or 0 if the BAR is invalid.
+- */
+-int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type)
+-{
+- int reg;
+-
+- if (resno < PCI_ROM_RESOURCE) {
+- *type = pci_bar_unknown;
+- return PCI_BASE_ADDRESS_0 + 4 * resno;
+- } else if (resno == PCI_ROM_RESOURCE) {
+- *type = pci_bar_mem32;
+- return dev->rom_base_reg;
+- } else if (resno < PCI_BRIDGE_RESOURCES) {
+- /* device specific resource */
+- *type = pci_bar_unknown;
+- reg = pci_iov_resource_bar(dev, resno);
+- if (reg)
+- return reg;
+- }
+-
+- dev_err(&dev->dev, "BAR %d: invalid resource\n", resno);
+- return 0;
+-}
+-
+ /* Some architectures require additional programming to enable VGA */
+ static arch_set_vga_state_t arch_set_vga_state;
+
+--- a/drivers/pci/pci.h
++++ b/drivers/pci/pci.h
+@@ -232,7 +232,6 @@ bool pci_bus_read_dev_vendor_id(struct p
+ int pci_setup_device(struct pci_dev *dev);
+ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
+ struct resource *res, unsigned int reg);
+-int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type);
+ void pci_configure_ari(struct pci_dev *dev);
+ void __pci_bus_size_bridges(struct pci_bus *bus,
+ struct list_head *realloc_head);
+@@ -276,7 +275,6 @@ static inline void pci_restore_ats_state
+ #ifdef CONFIG_PCI_IOV
+ int pci_iov_init(struct pci_dev *dev);
+ void pci_iov_release(struct pci_dev *dev);
+-int pci_iov_resource_bar(struct pci_dev *dev, int resno);
+ void pci_iov_update_resource(struct pci_dev *dev, int resno);
+ resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno);
+ void pci_restore_iov_state(struct pci_dev *dev);
+@@ -291,10 +289,6 @@ static inline void pci_iov_release(struc
+
+ {
+ }
+-static inline int pci_iov_resource_bar(struct pci_dev *dev, int resno)
+-{
+- return 0;
+-}
+ static inline void pci_restore_iov_state(struct pci_dev *dev)
+ {
+ }
+--- a/drivers/pci/setup-res.c
++++ b/drivers/pci/setup-res.c
+@@ -32,7 +32,6 @@ static void pci_std_update_resource(stru
+ u16 cmd;
+ u32 new, check, mask;
+ int reg;
+- enum pci_bar_type type;
+ struct resource *res = dev->resource + resno;
+
+ if (dev->is_virtfn) {
+@@ -66,14 +65,16 @@ static void pci_std_update_resource(stru
+ else
+ mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
+
+- reg = pci_resource_bar(dev, resno, &type);
+- if (!reg)
+- return;
+- if (type != pci_bar_unknown) {
++ if (resno < PCI_ROM_RESOURCE) {
++ reg = PCI_BASE_ADDRESS_0 + 4 * resno;
++ } else if (resno == PCI_ROM_RESOURCE) {
+ if (!(res->flags & IORESOURCE_ROM_ENABLE))
+ return;
++
++ reg = dev->rom_base_reg;
+ new |= PCI_ROM_ADDRESS_ENABLE;
+- }
++ } else
++ return;
+
+ /*
+ * We can't update a 64-bit BAR atomically, so when possible,
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:05 +0530
+Subject: PCI: Separate VF BAR updates from standard BAR updates
+To: stable@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-6-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+[ Upstream commit 6ffa2489c51da77564a0881a73765ea2169f955d ]
+
+Previously pci_update_resource() used the same code path for updating
+standard BARs and VF BARs in SR-IOV capabilities.
+
+Split the VF BAR update into a new pci_iov_update_resource() internal
+interface, which makes it simpler to compute the BAR address (we can get
+rid of pci_resource_bar() and pci_iov_resource_bar()).
+
+This patch:
+
+ - Renames pci_update_resource() to pci_std_update_resource(),
+ - Adds pci_iov_update_resource(),
+ - Makes pci_update_resource() a wrapper that calls the appropriate one,
+
+No functional change intended.
+
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/iov.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
+ drivers/pci/pci.h | 1
+ drivers/pci/setup-res.c | 13 ++++++++++--
+ 3 files changed, 62 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/iov.c
++++ b/drivers/pci/iov.c
+@@ -572,6 +572,56 @@ int pci_iov_resource_bar(struct pci_dev
+ 4 * (resno - PCI_IOV_RESOURCES);
+ }
+
++/**
++ * pci_iov_update_resource - update a VF BAR
++ * @dev: the PCI device
++ * @resno: the resource number
++ *
++ * Update a VF BAR in the SR-IOV capability of a PF.
++ */
++void pci_iov_update_resource(struct pci_dev *dev, int resno)
++{
++ struct pci_sriov *iov = dev->is_physfn ? dev->sriov : NULL;
++ struct resource *res = dev->resource + resno;
++ int vf_bar = resno - PCI_IOV_RESOURCES;
++ struct pci_bus_region region;
++ u32 new;
++ int reg;
++
++ /*
++ * The generic pci_restore_bars() path calls this for all devices,
++ * including VFs and non-SR-IOV devices. If this is not a PF, we
++ * have nothing to do.
++ */
++ if (!iov)
++ return;
++
++ /*
++ * Ignore unimplemented BARs, unused resource slots for 64-bit
++ * BARs, and non-movable resources, e.g., those described via
++ * Enhanced Allocation.
++ */
++ if (!res->flags)
++ return;
++
++ if (res->flags & IORESOURCE_UNSET)
++ return;
++
++ if (res->flags & IORESOURCE_PCI_FIXED)
++ return;
++
++ pcibios_resource_to_bus(dev->bus, ®ion, res);
++ new = region.start;
++ new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
++
++ reg = iov->pos + PCI_SRIOV_BAR + 4 * vf_bar;
++ pci_write_config_dword(dev, reg, new);
++ if (res->flags & IORESOURCE_MEM_64) {
++ new = region.start >> 16 >> 16;
++ pci_write_config_dword(dev, reg + 4, new);
++ }
++}
++
+ resource_size_t __weak pcibios_iov_resource_alignment(struct pci_dev *dev,
+ int resno)
+ {
+--- a/drivers/pci/pci.h
++++ b/drivers/pci/pci.h
+@@ -277,6 +277,7 @@ static inline void pci_restore_ats_state
+ int pci_iov_init(struct pci_dev *dev);
+ void pci_iov_release(struct pci_dev *dev);
+ int pci_iov_resource_bar(struct pci_dev *dev, int resno);
++void pci_iov_update_resource(struct pci_dev *dev, int resno);
+ resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno);
+ void pci_restore_iov_state(struct pci_dev *dev);
+ int pci_iov_bus_range(struct pci_bus *bus);
+--- a/drivers/pci/setup-res.c
++++ b/drivers/pci/setup-res.c
+@@ -25,8 +25,7 @@
+ #include <linux/slab.h>
+ #include "pci.h"
+
+-
+-void pci_update_resource(struct pci_dev *dev, int resno)
++static void pci_std_update_resource(struct pci_dev *dev, int resno)
+ {
+ struct pci_bus_region region;
+ bool disable;
+@@ -110,6 +109,16 @@ void pci_update_resource(struct pci_dev
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+ }
+
++void pci_update_resource(struct pci_dev *dev, int resno)
++{
++ if (resno <= PCI_ROM_RESOURCE)
++ pci_std_update_resource(dev, resno);
++#ifdef CONFIG_PCI_IOV
++ else if (resno >= PCI_IOV_RESOURCES && resno <= PCI_IOV_RESOURCE_END)
++ pci_iov_update_resource(dev, resno);
++#endif
++}
++
+ int pci_claim_resource(struct pci_dev *dev, int resource)
+ {
+ struct resource *res = &dev->resource[resource];
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:10 +0530
+Subject: PCI: Update BARs using property bits appropriate for type
+To: stable@vger.kernel.org
+Cc: Bjorn Helgaas <bhelgaas@google.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-11-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+[ Upstream commit 45d004f4afefdd8d79916ee6d97a9ecd94bb1ffe ]
+
+The BAR property bits (0-3 for memory BARs, 0-1 for I/O BARs) are supposed
+to be read-only, but we do save them in res->flags and include them when
+updating the BAR.
+
+Mask the I/O property bits with ~PCI_BASE_ADDRESS_IO_MASK (0x3) instead of
+PCI_REGION_FLAG_MASK (0xf) to make it obvious that we can't corrupt bits
+2-3 of I/O addresses.
+
+Use PCI_ROM_ADDRESS_MASK for ROM BARs. This means we'll only check the top
+21 bits (instead of the 28 bits we used to check) of a ROM BAR to see if
+the update was successful.
+
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/setup-res.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/pci/setup-res.c
++++ b/drivers/pci/setup-res.c
+@@ -58,12 +58,17 @@ static void pci_std_update_resource(stru
+ return;
+
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
++ new = region.start;
+
+- new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
+- if (res->flags & IORESOURCE_IO)
++ if (res->flags & IORESOURCE_IO) {
+ mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
+- else
++ new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
++ } else if (resno == PCI_ROM_RESOURCE) {
++ mask = (u32)PCI_ROM_ADDRESS_MASK;
++ } else {
+ mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
++ new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
++ }
+
+ if (resno < PCI_ROM_RESOURCE) {
+ reg = PCI_BASE_ADDRESS_0 + 4 * resno;
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:15 +0530
+Subject: s390/zcrypt: Introduce CEX6 toleration
+To: stable@vger.kernel.org
+Cc: Harald Freudenberger <freude@linux.vnet.ibm.com>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-16-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Harald Freudenberger <freude@linux.vnet.ibm.com>
+
+[ Upstream commit b3e8652bcbfa04807e44708d4d0c8cdad39c9215 ]
+
+Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/crypto/ap_bus.c | 3 +++
+ drivers/s390/crypto/ap_bus.h | 1 +
+ 2 files changed, 4 insertions(+)
+
+--- a/drivers/s390/crypto/ap_bus.c
++++ b/drivers/s390/crypto/ap_bus.c
+@@ -1651,6 +1651,9 @@ static void ap_scan_bus(struct work_stru
+ ap_dev->queue_depth = queue_depth;
+ ap_dev->raw_hwtype = device_type;
+ ap_dev->device_type = device_type;
++ /* CEX6 toleration: map to CEX5 */
++ if (device_type == AP_DEVICE_TYPE_CEX6)
++ ap_dev->device_type = AP_DEVICE_TYPE_CEX5;
+ ap_dev->functions = device_functions;
+ spin_lock_init(&ap_dev->lock);
+ INIT_LIST_HEAD(&ap_dev->pendingq);
+--- a/drivers/s390/crypto/ap_bus.h
++++ b/drivers/s390/crypto/ap_bus.h
+@@ -105,6 +105,7 @@ static inline int ap_test_bit(unsigned i
+ #define AP_DEVICE_TYPE_CEX3C 9
+ #define AP_DEVICE_TYPE_CEX4 10
+ #define AP_DEVICE_TYPE_CEX5 11
++#define AP_DEVICE_TYPE_CEX6 12
+
+ /*
+ * Known function facilities
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:19 +0530
+Subject: serial: 8250_pci: Detach low-level driver during PCI error recovery
+To: stable@vger.kernel.org
+Cc: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sasha Levin <alexander.levin@verizon.com>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-20-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
+
+[ Upstream commit f209fa03fc9d131b3108c2e4936181eabab87416 ]
+
+During a PCI error recovery, like the ones provoked by EEH in the ppc64
+platform, all IO to the device must be blocked while the recovery is
+completed. Current 8250_pci implementation only suspends the port
+instead of detaching it, which doesn't prevent incoming accesses like
+TIOCMGET and TIOCMSET calls from reaching the device. Those end up
+racing with the EEH recovery, crashing it. Similar races were also
+observed when opening the device and when shutting it down during
+recovery.
+
+This patch implements a more robust IO blockage for the 8250_pci
+recovery by unregistering the port at the beginning of the procedure and
+re-adding it afterwards. Since the port is detached from the uart
+layer, we can be sure that no request will make through to the device
+during recovery. This is similar to the solution used by the JSM serial
+driver.
+
+I thank Peter Hurley <peter@hurleysoftware.com> for valuable input on
+this one over one year ago.
+
+Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_pci.c | 23 +++++++++++++++++++----
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_pci.c
++++ b/drivers/tty/serial/8250/8250_pci.c
+@@ -57,6 +57,7 @@ struct serial_private {
+ unsigned int nr;
+ void __iomem *remapped_bar[PCI_NUM_BAR_RESOURCES];
+ struct pci_serial_quirk *quirk;
++ const struct pciserial_board *board;
+ int line[0];
+ };
+
+@@ -4058,6 +4059,7 @@ pciserial_init_ports(struct pci_dev *dev
+ }
+ }
+ priv->nr = i;
++ priv->board = board;
+ return priv;
+
+ err_deinit:
+@@ -4068,7 +4070,7 @@ err_out:
+ }
+ EXPORT_SYMBOL_GPL(pciserial_init_ports);
+
+-void pciserial_remove_ports(struct serial_private *priv)
++void pciserial_detach_ports(struct serial_private *priv)
+ {
+ struct pci_serial_quirk *quirk;
+ int i;
+@@ -4088,7 +4090,11 @@ void pciserial_remove_ports(struct seria
+ quirk = find_quirk(priv->dev);
+ if (quirk->exit)
+ quirk->exit(priv->dev);
++}
+
++void pciserial_remove_ports(struct serial_private *priv)
++{
++ pciserial_detach_ports(priv);
+ kfree(priv);
+ }
+ EXPORT_SYMBOL_GPL(pciserial_remove_ports);
+@@ -5819,7 +5825,7 @@ static pci_ers_result_t serial8250_io_er
+ return PCI_ERS_RESULT_DISCONNECT;
+
+ if (priv)
+- pciserial_suspend_ports(priv);
++ pciserial_detach_ports(priv);
+
+ pci_disable_device(dev);
+
+@@ -5844,9 +5850,18 @@ static pci_ers_result_t serial8250_io_sl
+ static void serial8250_io_resume(struct pci_dev *dev)
+ {
+ struct serial_private *priv = pci_get_drvdata(dev);
++ const struct pciserial_board *board;
+
+- if (priv)
+- pciserial_resume_ports(priv);
++ if (!priv)
++ return;
++
++ board = priv->board;
++ kfree(priv);
++ priv = pciserial_init_ports(dev, board);
++
++ if (!IS_ERR(priv)) {
++ pci_set_drvdata(dev, priv);
++ }
+ }
+
+ static const struct pci_error_handlers serial8250_err_handler = {
xfs-fix-up-xfs_swap_extent_forks-inline-extent-handling.patch
nl80211-fix-dumpit-error-path-rtnl-deadlocks.patch
usb-usbtmc-add-missing-endpoint-sanity-check.patch
+xfs-clear-_xbf_pages-from-buffers-when-readahead-page.patch
+xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
+igb-workaround-for-igb-i210-firmware-issue.patch
+igb-add-i211-to-i210-phy-workaround.patch
+x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
+pci-separate-vf-bar-updates-from-standard-bar-updates.patch
+pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
+pci-add-comments-about-rom-bar-updating.patch
+pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
+pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
+pci-update-bars-using-property-bits-appropriate-for-type.patch
+pci-ignore-bar-updates-on-virtual-functions.patch
+pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
+vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
+block-allow-write_same-commands-with-the-sg_io-ioctl.patch
+s390-zcrypt-introduce-cex6-toleration.patch
+uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch
+acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
+acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
+serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
+fbcon-fix-vc-attr-at-deinit.patch
+crypto-algif_hash-avoid-zero-sized-array.patch
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:16 +0530
+Subject: uvcvideo: uvc_scan_fallback() for webcams with broken chain
+To: stable@vger.kernel.org
+Cc: Henrik Ingo <henrik.ingo@avoinelama.fi>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Mauro Carvalho Chehab <mchehab@s-opensource.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-17-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Henrik Ingo <henrik.ingo@avoinelama.fi>
+
+[ Upstream commit e950267ab802c8558f1100eafd4087fd039ad634 ]
+
+Some devices have invalid baSourceID references, causing uvc_scan_chain()
+to fail, but if we just take the entities we can find and put them
+together in the most sensible chain we can think of, turns out they do
+work anyway. Note: This heuristic assumes there is a single chain.
+
+At the time of writing, devices known to have such a broken chain are
+ - Acer Integrated Camera (5986:055a)
+ - Realtek rtl157a7 (0bda:57a7)
+
+Signed-off-by: Henrik Ingo <henrik.ingo@avoinelama.fi>
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_driver.c | 118 +++++++++++++++++++++++++++++++++++--
+ 1 file changed, 112 insertions(+), 6 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_driver.c
++++ b/drivers/media/usb/uvc/uvc_driver.c
+@@ -1595,6 +1595,114 @@ static const char *uvc_print_chain(struc
+ return buffer;
+ }
+
++static struct uvc_video_chain *uvc_alloc_chain(struct uvc_device *dev)
++{
++ struct uvc_video_chain *chain;
++
++ chain = kzalloc(sizeof(*chain), GFP_KERNEL);
++ if (chain == NULL)
++ return NULL;
++
++ INIT_LIST_HEAD(&chain->entities);
++ mutex_init(&chain->ctrl_mutex);
++ chain->dev = dev;
++ v4l2_prio_init(&chain->prio);
++
++ return chain;
++}
++
++/*
++ * Fallback heuristic for devices that don't connect units and terminals in a
++ * valid chain.
++ *
++ * Some devices have invalid baSourceID references, causing uvc_scan_chain()
++ * to fail, but if we just take the entities we can find and put them together
++ * in the most sensible chain we can think of, turns out they do work anyway.
++ * Note: This heuristic assumes there is a single chain.
++ *
++ * At the time of writing, devices known to have such a broken chain are
++ * - Acer Integrated Camera (5986:055a)
++ * - Realtek rtl157a7 (0bda:57a7)
++ */
++static int uvc_scan_fallback(struct uvc_device *dev)
++{
++ struct uvc_video_chain *chain;
++ struct uvc_entity *iterm = NULL;
++ struct uvc_entity *oterm = NULL;
++ struct uvc_entity *entity;
++ struct uvc_entity *prev;
++
++ /*
++ * Start by locating the input and output terminals. We only support
++ * devices with exactly one of each for now.
++ */
++ list_for_each_entry(entity, &dev->entities, list) {
++ if (UVC_ENTITY_IS_ITERM(entity)) {
++ if (iterm)
++ return -EINVAL;
++ iterm = entity;
++ }
++
++ if (UVC_ENTITY_IS_OTERM(entity)) {
++ if (oterm)
++ return -EINVAL;
++ oterm = entity;
++ }
++ }
++
++ if (iterm == NULL || oterm == NULL)
++ return -EINVAL;
++
++ /* Allocate the chain and fill it. */
++ chain = uvc_alloc_chain(dev);
++ if (chain == NULL)
++ return -ENOMEM;
++
++ if (uvc_scan_chain_entity(chain, oterm) < 0)
++ goto error;
++
++ prev = oterm;
++
++ /*
++ * Add all Processing and Extension Units with two pads. The order
++ * doesn't matter much, use reverse list traversal to connect units in
++ * UVC descriptor order as we build the chain from output to input. This
++ * leads to units appearing in the order meant by the manufacturer for
++ * the cameras known to require this heuristic.
++ */
++ list_for_each_entry_reverse(entity, &dev->entities, list) {
++ if (entity->type != UVC_VC_PROCESSING_UNIT &&
++ entity->type != UVC_VC_EXTENSION_UNIT)
++ continue;
++
++ if (entity->num_pads != 2)
++ continue;
++
++ if (uvc_scan_chain_entity(chain, entity) < 0)
++ goto error;
++
++ prev->baSourceID[0] = entity->id;
++ prev = entity;
++ }
++
++ if (uvc_scan_chain_entity(chain, iterm) < 0)
++ goto error;
++
++ prev->baSourceID[0] = iterm->id;
++
++ list_add_tail(&chain->list, &dev->chains);
++
++ uvc_trace(UVC_TRACE_PROBE,
++ "Found a video chain by fallback heuristic (%s).\n",
++ uvc_print_chain(chain));
++
++ return 0;
++
++error:
++ kfree(chain);
++ return -EINVAL;
++}
++
+ /*
+ * Scan the device for video chains and register video devices.
+ *
+@@ -1617,15 +1725,10 @@ static int uvc_scan_device(struct uvc_de
+ if (term->chain.next || term->chain.prev)
+ continue;
+
+- chain = kzalloc(sizeof(*chain), GFP_KERNEL);
++ chain = uvc_alloc_chain(dev);
+ if (chain == NULL)
+ return -ENOMEM;
+
+- INIT_LIST_HEAD(&chain->entities);
+- mutex_init(&chain->ctrl_mutex);
+- chain->dev = dev;
+- v4l2_prio_init(&chain->prio);
+-
+ term->flags |= UVC_ENTITY_FLAG_DEFAULT;
+
+ if (uvc_scan_chain(chain, term) < 0) {
+@@ -1639,6 +1742,9 @@ static int uvc_scan_device(struct uvc_de
+ list_add_tail(&chain->list, &dev->chains);
+ }
+
++ if (list_empty(&dev->chains))
++ uvc_scan_fallback(dev);
++
+ if (list_empty(&dev->chains)) {
+ uvc_printk(KERN_INFO, "No valid video chain found.\n");
+ return -1;
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:13 +0530
+Subject: vfio/spapr: Postpone allocation of userspace version of TCE table
+To: stable@vger.kernel.org
+Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, Michael Ellerman <mpe@ellerman.id.au>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-14-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Alexey Kardashevskiy <aik@ozlabs.ru>
+
+[ Upstream commit 39701e56f5f16ea0cf8fc9e8472e645f8de91d23 ]
+
+The iommu_table struct manages a hardware TCE table and a vmalloc'd
+table with corresponding userspace addresses. Both are allocated when
+the default DMA window is created and this happens when the very first
+group is attached to a container.
+
+As we are going to allow the userspace to configure container in one
+memory context and pas container fd to another, we have to postpones
+such allocations till a container fd is passed to the destination
+user process so we would account locked memory limit against the actual
+container user constrainsts.
+
+This postpones the it_userspace array allocation till it is used first
+time for mapping. The unmapping patch already checks if the array is
+allocated.
+
+Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
+Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
+Acked-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/vfio/vfio_iommu_spapr_tce.c | 20 +++++++-------------
+ 1 file changed, 7 insertions(+), 13 deletions(-)
+
+--- a/drivers/vfio/vfio_iommu_spapr_tce.c
++++ b/drivers/vfio/vfio_iommu_spapr_tce.c
+@@ -511,6 +511,12 @@ static long tce_iommu_build_v2(struct tc
+ unsigned long hpa;
+ enum dma_data_direction dirtmp;
+
++ if (!tbl->it_userspace) {
++ ret = tce_iommu_userspace_view_alloc(tbl);
++ if (ret)
++ return ret;
++ }
++
+ for (i = 0; i < pages; ++i) {
+ struct mm_iommu_table_group_mem_t *mem = NULL;
+ unsigned long *pua = IOMMU_TABLE_USERSPACE_ENTRY(tbl,
+@@ -584,15 +590,6 @@ static long tce_iommu_create_table(struc
+ WARN_ON(!ret && !(*ptbl)->it_ops->free);
+ WARN_ON(!ret && ((*ptbl)->it_allocated_size != table_size));
+
+- if (!ret && container->v2) {
+- ret = tce_iommu_userspace_view_alloc(*ptbl);
+- if (ret)
+- (*ptbl)->it_ops->free(*ptbl);
+- }
+-
+- if (ret)
+- decrement_locked_vm(table_size >> PAGE_SHIFT);
+-
+ return ret;
+ }
+
+@@ -1064,10 +1061,7 @@ static int tce_iommu_take_ownership(stru
+ if (!tbl || !tbl->it_map)
+ continue;
+
+- rc = tce_iommu_userspace_view_alloc(tbl);
+- if (!rc)
+- rc = iommu_take_ownership(tbl);
+-
++ rc = iommu_take_ownership(tbl);
+ if (rc) {
+ for (j = 0; j < i; ++j)
+ iommu_release_ownership(
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:04 +0530
+Subject: x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic
+To: stable@vger.kernel.org
+Cc: Vitaly Kuznetsov <vkuznets@redhat.com>, devel@linuxdriverproject.org, Haiyang Zhang <haiyangz@microsoft.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-5-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+
+[ Upstream commit 59107e2f48831daedc46973ce4988605ab066de3 ]
+
+There is a feature in Hyper-V ('Debug-VM --InjectNonMaskableInterrupt')
+which injects NMI to the guest. We may want to crash the guest and do kdump
+on this NMI by enabling unknown_nmi_panic. To make kdump succeed we need to
+allow the kdump kernel to re-establish VMBus connection so it will see
+VMBus devices (storage, network,..).
+
+To properly unload VMBus making it possible to start over during kdump we
+need to do the following:
+
+ - Send an 'unload' message to the hypervisor. This can be done on any CPU
+ so we do this the crashing CPU.
+
+ - Receive the 'unload finished' reply message. WS2012R2 delivers this
+ message to the CPU which was used to establish VMBus connection during
+ module load and this CPU may differ from the CPU sending 'unload'.
+
+Receiving a VMBus message means the following:
+
+ - There is a per-CPU slot in memory for one message. This slot can in
+ theory be accessed by any CPU.
+
+ - We get an interrupt on the CPU when a message was placed into the slot.
+
+ - When we read the message we need to clear the slot and signal the fact
+ to the hypervisor. In case there are more messages to this CPU pending
+ the hypervisor will deliver the next message. The signaling is done by
+ writing to an MSR so this can only be done on the appropriate CPU.
+
+To avoid doing cross-CPU work on crash we have vmbus_wait_for_unload()
+function which checks message slots for all CPUs in a loop waiting for the
+'unload finished' messages. However, there is an issue which arises when
+these conditions are met:
+
+ - We're crashing on a CPU which is different from the one which was used
+ to initially contact the hypervisor.
+
+ - The CPU which was used for the initial contact is blocked with interrupts
+ disabled and there is a message pending in the message slot.
+
+In this case we won't be able to read the 'unload finished' message on the
+crashing CPU. This is reproducible when we receive unknown NMIs on all CPUs
+simultaneously: the first CPU entering panic() will proceed to crash and
+all other CPUs will stop themselves with interrupts disabled.
+
+The suggested solution is to handle unknown NMIs for Hyper-V guests on the
+first CPU which gets them only. This will allow us to rely on VMBus
+interrupt handler being able to receive the 'unload finish' message in
+case it is delivered to a different CPU.
+
+The issue is not reproducible on WS2016 as Debug-VM delivers NMI to the
+boot CPU only, WS2012R2 and earlier Hyper-V versions are affected.
+
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Acked-by: K. Y. Srinivasan <kys@microsoft.com>
+Cc: devel@linuxdriverproject.org
+Cc: Haiyang Zhang <haiyangz@microsoft.com>
+Link: http://lkml.kernel.org/r/20161202100720.28121-1-vkuznets@redhat.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mshyperv.c | 24 ++++++++++++++++++++++++
+ 1 file changed, 24 insertions(+)
+
+--- a/arch/x86/kernel/cpu/mshyperv.c
++++ b/arch/x86/kernel/cpu/mshyperv.c
+@@ -30,6 +30,7 @@
+ #include <asm/apic.h>
+ #include <asm/timer.h>
+ #include <asm/reboot.h>
++#include <asm/nmi.h>
+
+ struct ms_hyperv_info ms_hyperv;
+ EXPORT_SYMBOL_GPL(ms_hyperv);
+@@ -157,6 +158,26 @@ static unsigned char hv_get_nmi_reason(v
+ return 0;
+ }
+
++#ifdef CONFIG_X86_LOCAL_APIC
++/*
++ * Prior to WS2016 Debug-VM sends NMIs to all CPUs which makes
++ * it dificult to process CHANNELMSG_UNLOAD in case of crash. Handle
++ * unknown NMI on the first CPU which gets it.
++ */
++static int hv_nmi_unknown(unsigned int val, struct pt_regs *regs)
++{
++ static atomic_t nmi_cpu = ATOMIC_INIT(-1);
++
++ if (!unknown_nmi_panic)
++ return NMI_DONE;
++
++ if (atomic_cmpxchg(&nmi_cpu, -1, raw_smp_processor_id()) != -1)
++ return NMI_HANDLED;
++
++ return NMI_DONE;
++}
++#endif
++
+ static void __init ms_hyperv_init_platform(void)
+ {
+ /*
+@@ -182,6 +203,9 @@ static void __init ms_hyperv_init_platfo
+ printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
+ lapic_timer_frequency);
+ }
++
++ register_nmi_handler(NMI_UNKNOWN, hv_nmi_unknown, NMI_FLAG_FIRST,
++ "hv_nmi_unknown");
+ #endif
+
+ if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
--- /dev/null
+From foo@baz Tue Mar 28 13:59:27 CEST 2017
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Sat, 25 Mar 2017 21:48:01 +0530
+Subject: xen: do not re-use pirq number cached in pci device msi msg data
+To: stable@vger.kernel.org
+Cc: Dan Streetman <ddstreet@ieee.org>, Dan Streetman <dan.streetman@canonical.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Sasha Levin <alexander.levin@verizon.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>
+Message-ID: <1490458699-24484-2-git-send-email-sumit.semwal@linaro.org>
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+
+From: Dan Streetman <ddstreet@ieee.org>
+
+[ Upstream commit c74fd80f2f41d05f350bb478151021f88551afe8 ]
+
+Revert the main part of commit:
+af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
+
+That commit introduced reading the pci device's msi message data to see
+if a pirq was previously configured for the device's msi/msix, and re-use
+that pirq. At the time, that was the correct behavior. However, a
+later change to Qemu caused it to call into the Xen hypervisor to unmap
+all pirqs for a pci device, when the pci device disables its MSI/MSIX
+vectors; specifically the Qemu commit:
+c976437c7dba9c7444fb41df45468968aaa326ad
+("qemu-xen: free all the pirqs for msi/msix when driver unload")
+
+Once Qemu added this pirq unmapping, it was no longer correct for the
+kernel to re-use the pirq number cached in the pci device msi message
+data. All Qemu releases since 2.1.0 contain the patch that unmaps the
+pirqs when the pci device disables its MSI/MSIX vectors.
+
+This bug is causing failures to initialize multiple NVMe controllers
+under Xen, because the NVMe driver sets up a single MSIX vector for
+each controller (concurrently), and then after using that to talk to
+the controller for some configuration data, it disables the single MSIX
+vector and re-configures all the MSIX vectors it needs. So the MSIX
+setup code tries to re-use the cached pirq from the first vector
+for each controller, but the hypervisor has already given away that
+pirq to another controller, and its initialization fails.
+
+This is discussed in more detail at:
+https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
+
+Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
+Signed-off-by: Dan Streetman <dan.streetman@canonical.com>
+Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
+Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/pci/xen.c | 23 +++++++----------------
+ 1 file changed, 7 insertions(+), 16 deletions(-)
+
+--- a/arch/x86/pci/xen.c
++++ b/arch/x86/pci/xen.c
+@@ -231,23 +231,14 @@ static int xen_hvm_setup_msi_irqs(struct
+ return 1;
+
+ for_each_pci_msi_entry(msidesc, dev) {
+- __pci_read_msi_msg(msidesc, &msg);
+- pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
+- ((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+- if (msg.data != XEN_PIRQ_MSI_DATA ||
+- xen_irq_from_pirq(pirq) < 0) {
+- pirq = xen_allocate_pirq_msi(dev, msidesc);
+- if (pirq < 0) {
+- irq = -ENODEV;
+- goto error;
+- }
+- xen_msi_compose_msg(dev, pirq, &msg);
+- __pci_write_msi_msg(msidesc, &msg);
+- dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq);
+- } else {
+- dev_dbg(&dev->dev,
+- "xen: msi already bound to pirq=%d\n", pirq);
++ pirq = xen_allocate_pirq_msi(dev, msidesc);
++ if (pirq < 0) {
++ irq = -ENODEV;
++ goto error;
+ }
++ xen_msi_compose_msg(dev, pirq, &msg);
++ __pci_write_msi_msg(msidesc, &msg);
++ dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq);
+ irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
+ (type == PCI_CAP_ID_MSI) ? nvec : 1,
+ (type == PCI_CAP_ID_MSIX) ?
--- /dev/null
+From 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b Mon Sep 17 00:00:00 2001
+From: "Darrick J. Wong" <darrick.wong@oracle.com>
+Date: Wed, 25 Jan 2017 20:24:57 -0800
+Subject: xfs: clear _XBF_PAGES from buffers when readahead page
+
+From: Darrick J. Wong <darrick.wong@oracle.com>
+
+commit 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b upstream.
+
+If we try to allocate memory pages to back an xfs_buf that we're trying
+to read, it's possible that we'll be so short on memory that the page
+allocation fails. For a blocking read we'll just wait, but for
+readahead we simply dump all the pages we've collected so far.
+
+Unfortunately, after dumping the pages we neglect to clear the
+_XBF_PAGES state, which means that the subsequent call to xfs_buf_free
+thinks that b_pages still points to pages we own. It then double-frees
+the b_pages pages.
+
+This results in screaming about negative page refcounts from the memory
+manager, which xfs oughtn't be triggering. To reproduce this case,
+mount a filesystem where the size of the inodes far outweighs the
+availalble memory (a ~500M inode filesystem on a VM with 300MB memory
+did the trick here) and run bulkstat in parallel with other memory
+eating processes to put a huge load on the system. The "check summary"
+phase of xfs_scrub also works for this purpose.
+
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Reviewed-by: Eric Sandeen <sandeen@redhat.com>
+Cc: Ivan Kozik <ivan@ludios.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/xfs_buf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/xfs/xfs_buf.c
++++ b/fs/xfs/xfs_buf.c
+@@ -375,6 +375,7 @@ retry:
+ out_free_pages:
+ for (i = 0; i < bp->b_page_count; i++)
+ __free_page(bp->b_pages[i]);
++ bp->b_flags &= ~_XBF_PAGES;
+ return error;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
