[PATCH for-4.4 00/19] Stable commits from Ubuntu Yakkety 4.9-lts

[PATCH for-4.4 00/19] Stable commits from Ubuntu Yakkety 4.9-lts

[Sumit Semwal]

Hi Greg,

For your consideration, I've just tried to pick commits applicable on 4.4 out
of the stable commits shared by Sasha Levin from Ubuntu Yakkety for 4.9.

This is the set of patches that cleanly applies on 4.4.55, and is build tested
for x86.

(Thanks Sasha for all the heavy lifting :) )


Alex Hung (1):
  ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520

Alexey Kardashevskiy (1):
  vfio/spapr: Postpone allocation of userspace version of TCE table

Bjorn Helgaas (7):
  PCI: Separate VF BAR updates from standard BAR updates
  PCI: Remove pci_resource_bar() and pci_iov_resource_bar()
  PCI: Add comments about ROM BAR updating
  PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE
  PCI: Don't update VF BARs while VF memory space is enabled
  PCI: Update BARs using property bits appropriate for type
  PCI: Ignore BAR updates on virtual functions

Chris J Arges (1):
  igb: Workaround for igb i210 firmware issue

Dan Streetman (1):
  xen: do not re-use pirq number cached in pci device msi msg data

Gabriel Krisman Bertazi (1):
  serial: 8250_pci: Detach low-level driver during PCI error recovery

Gavin Shan (1):
  PCI: Do any VF BAR updates before enabling the BARs

Harald Freudenberger (1):
  s390/zcrypt: Introduce CEX6 toleration

Henrik Ingo (1):
  uvcvideo: uvc_scan_fallback() for webcams with broken chain

Mauricio Faria de Oliveira (1):
  block: allow WRITE_SAME commands with the SG_IO ioctl

Michael Pobega (1):
  ACPI / blacklist: Make Dell Latitude 3350 ethernet work

Todd Fujinaka (1):
  igb: add i211 to i210 PHY workaround

Vitaly Kuznetsov (1):
  x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic

 arch/x86/kernel/cpu/mshyperv.c             |  24 ++++++
 arch/x86/pci/xen.c                         |  23 ++----
 block/scsi_ioctl.c                         |   3 +
 drivers/acpi/blacklist.c                   |  28 +++++++
 drivers/media/usb/uvc/uvc_driver.c         | 118 +++++++++++++++++++++++++++--
 drivers/net/ethernet/intel/igb/e1000_phy.c |   4 +
 drivers/pci/iov.c                          |  70 +++++++++++++----
 drivers/pci/pci.c                          |  34 ---------
 drivers/pci/pci.h                          |   7 +-
 drivers/pci/probe.c                        |   3 +-
 drivers/pci/rom.c                          |   5 ++
 drivers/pci/setup-res.c                    |  48 ++++++++----
 drivers/s390/crypto/ap_bus.c               |   3 +
 drivers/s390/crypto/ap_bus.h               |   1 +
 drivers/tty/serial/8250/8250_pci.c         |  23 +++++-
 drivers/vfio/vfio_iommu_spapr_tce.c        |  20 ++---
 16 files changed, 305 insertions(+), 109 deletions(-)

-- 
2.7.4

[PATCH for-4.4 01/19] xen: do not re-use pirq number cached in pci device msi msg data

[Sumit Semwal]

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>
---
 arch/x86/pci/xen.c | 23 +++++++----------------
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index c6d6efe..7575f07 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -231,23 +231,14 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 		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) ?
-- 
2.7.4

Patch "xen: do not re-use pirq number cached in pci device msi msg data" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    xen: do not re-use pirq number cached in pci device msi msg data

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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) ?


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 02/19] igb: Workaround for igb i210 firmware issue

[Sumit Semwal]

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>
---
 drivers/net/ethernet/intel/igb/e1000_phy.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 23ec28f..13ad20b 100644
--- 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;
-- 
2.7.4

Patch "igb: Workaround for igb i210 firmware issue" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    igb: Workaround for igb i210 firmware issue

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     igb-workaround-for-igb-i210-firmware-issue.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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;


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 03/19] igb: add i211 to i210 PHY workaround

[Sumit Semwal]

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>
---
 drivers/net/ethernet/intel/igb/e1000_phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 13ad20b..afaa98d 100644
--- 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);
-- 
2.7.4

Patch "igb: add i211 to i210 PHY workaround" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    igb: add i211 to i210 PHY workaround

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     igb-add-i211-to-i210-phy-workaround.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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);


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 04/19] x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic

[Sumit Semwal]

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>
---
 arch/x86/kernel/cpu/mshyperv.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index cfc4a96..83b5f7a 100644
--- 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(void)
 	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_platform(void)
 		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)
-- 
2.7.4

Patch "x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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)


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 05/19] PCI: Separate VF BAR updates from standard BAR updates

[Sumit Semwal]

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>
---
 drivers/pci/iov.c       | 50 +++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/pci.h       |  1 +
 drivers/pci/setup-res.c | 13 +++++++++++--
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 31f31d4..a6b1001 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -572,6 +572,56 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno)
 		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, &region, 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)
 {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index d390fc1..eda77d1 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -277,6 +277,7 @@ static inline void pci_restore_ats_state(struct pci_dev *dev)
 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);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 604011e..ac58c56 100644
--- 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 *dev, int resno)
 		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];
-- 
2.7.4

Patch "PCI: Separate VF BAR updates from standard BAR updates" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Separate VF BAR updates from standard BAR updates

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-separate-vf-bar-updates-from-standard-bar-updates.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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, &region, 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];


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 06/19] PCI: Remove pci_resource_bar() and pci_iov_resource_bar()

[Sumit Semwal]

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>
---
 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(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index a6b1001..2f8ea6f 100644
--- 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
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e311a9b..a01e6d5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4472,36 +4472,6 @@ int pci_select_bars(struct pci_dev *dev, unsigned long flags)
 }
 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;
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index eda77d1..c43e448 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -232,7 +232,6 @@ bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *pl,
 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(struct pci_dev *dev)
 #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(struct pci_dev *dev)
 
 {
 }
-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)
 {
 }
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index ac58c56..674e76c 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -32,7 +32,6 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)
 	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(struct pci_dev *dev, int resno)
 	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,
-- 
2.7.4

Patch "PCI: Remove pci_resource_bar() and pci_iov_resource_bar()" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Remove pci_resource_bar() and pci_iov_resource_bar()

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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,


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 07/19] PCI: Add comments about ROM BAR updating

[Sumit Semwal]

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>
---
 drivers/pci/rom.c       | 5 +++++
 drivers/pci/setup-res.c | 6 ++++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index eb0ad53..3eea7fc 100644
--- 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, &region, res);
 	pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr);
 	rom_addr &= ~PCI_ROM_ADDRESS_MASK;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 674e76c..d1ba5e0 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -68,6 +68,12 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)
 	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;
 
-- 
2.7.4

Patch "PCI: Add comments about ROM BAR updating" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Add comments about ROM BAR updating

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-add-comments-about-rom-bar-updating.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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, &region, 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;
 


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 08/19] PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE

[Sumit Semwal]

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>
---
 drivers/pci/probe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 71d9a6d..b83df94 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -226,7 +226,8 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
 			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;
-- 
2.7.4

Patch "PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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;


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 09/19] PCI: Don't update VF BARs while VF memory space is enabled

[Sumit Semwal]

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>
---
 drivers/pci/iov.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 2f8ea6f..47c46d0 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -567,6 +567,7 @@ void pci_iov_update_resource(struct pci_dev *dev, int resno)
 	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_dev *dev, int resno)
 	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
-- 
2.7.4

Patch "PCI: Don't update VF BARs while VF memory space is enabled" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Don't update VF BARs while VF memory space is enabled

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 10/19] PCI: Update BARs using property bits appropriate for type

[Sumit Semwal]

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>
---
 drivers/pci/setup-res.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index d1ba5e0..032a6b1 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -58,12 +58,17 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)
 		return;
 
 	pcibios_resource_to_bus(dev->bus, &region, 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;
-- 
2.7.4

Patch "PCI: Update BARs using property bits appropriate for type" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Update BARs using property bits appropriate for type

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-update-bars-using-property-bits-appropriate-for-type.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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, &region, 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;


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 11/19] PCI: Ignore BAR updates on virtual functions

[Sumit Semwal]

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>
---
 drivers/pci/pci.c       | 4 ----
 drivers/pci/setup-res.c | 5 ++---
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a01e6d5..0e53488 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -519,10 +519,6 @@ static void pci_restore_bars(struct pci_dev *dev)
 {
 	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);
 }
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 032a6b1..2506296 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -34,10 +34,9 @@ static void pci_std_update_resource(struct pci_dev *dev, int resno)
 	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
-- 
2.7.4

Patch "PCI: Ignore BAR updates on virtual functions" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Ignore BAR updates on virtual functions

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-ignore-bar-updates-on-virtual-functions.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 12/19] PCI: Do any VF BAR updates before enabling the BARs

[Sumit Semwal]

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>
---
 drivers/pci/iov.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 47c46d0..3575277 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -303,13 +303,6 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn)
 			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 *dev, int nr_virtfn)
 		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)
-- 
2.7.4

Patch "PCI: Do any VF BAR updates before enabling the BARs" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    PCI: Do any VF BAR updates before enabling the BARs

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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)


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 13/19] vfio/spapr: Postpone allocation of userspace version of TCE table

[Sumit Semwal]

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>
---
 drivers/vfio/vfio_iommu_spapr_tce.c | 20 +++++++-------------
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index 0582b72..1a9f18b 100644
--- 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 tce_container *container,
 	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(struct tce_container *container,
 	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(struct tce_container *container,
 		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(
-- 
2.7.4

Patch "vfio/spapr: Postpone allocation of userspace version of TCE table" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    vfio/spapr: Postpone allocation of userspace version of TCE table

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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(


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 14/19] block: allow WRITE_SAME commands with the SG_IO ioctl

[Sumit Semwal]

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>
---
 block/scsi_ioctl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 0774799..c6fee74 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -182,6 +182,9 @@ static void blk_set_cmd_filter_defaults(struct blk_cmd_filter *filter)
 	__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);
-- 
2.7.4

Patch "block: allow WRITE_SAME commands with the SG_IO ioctl" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    block: allow WRITE_SAME commands with the SG_IO ioctl

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     block-allow-write_same-commands-with-the-sg_io-ioctl.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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);


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 15/19] s390/zcrypt: Introduce CEX6 toleration

[Sumit Semwal]

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>
---
 drivers/s390/crypto/ap_bus.c | 3 +++
 drivers/s390/crypto/ap_bus.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index 24ec282..7c3b8d3 100644
--- 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_struct *unused)
 		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);
diff --git a/drivers/s390/crypto/ap_bus.h b/drivers/s390/crypto/ap_bus.h
index 6adcbdf..cc741e9 100644
--- 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 int *ptr, unsigned int nr)
 #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
-- 
2.7.4

Patch "s390/zcrypt: Introduce CEX6 toleration" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    s390/zcrypt: Introduce CEX6 toleration

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     s390-zcrypt-introduce-cex6-toleration.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 16/19] uvcvideo: uvc_scan_fallback() for webcams with broken chain

[Sumit Semwal]

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>
---
 drivers/media/usb/uvc/uvc_driver.c | 118 +++++++++++++++++++++++++++++++++++--
 1 file changed, 112 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 5cefca9..885f689 100644
--- 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(struct uvc_video_chain *chain)
 	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_device *dev)
 		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_device *dev)
 		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;
-- 
2.7.4

Patch "uvcvideo: uvc_scan_fallback() for webcams with broken chain" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    uvcvideo: uvc_scan_fallback() for webcams with broken chain

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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;


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 17/19] ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520

[Sumit Semwal]

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>
---
 drivers/acpi/blacklist.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 96809cd..b2e9395 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -346,6 +346,22 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		      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
 	{}
 };
-- 
2.7.4

Patch "ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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
 	{}
 };


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 18/19] ACPI / blacklist: Make Dell Latitude 3350 ethernet work

[Sumit Semwal]

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>
---
 drivers/acpi/blacklist.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index b2e9395..2f24b57 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -362,6 +362,18 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		      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
 	{}
 };
-- 
2.7.4

Patch "ACPI / blacklist: Make Dell Latitude 3350 ethernet work" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    ACPI / blacklist: Make Dell Latitude 3350 ethernet work

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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
 	{}
 };


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch

[PATCH for-4.4 19/19] serial: 8250_pci: Detach low-level driver during PCI error recovery

[Sumit Semwal]

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>
---
 drivers/tty/serial/8250/8250_pci.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 5b24ffd..83ff172 100644
--- 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, const struct pciserial_board *board)
 		}
 	}
 	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 serial_private *priv)
 	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_error_detected(struct pci_dev *dev,
 		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_slot_reset(struct pci_dev *dev)
 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 = {
-- 
2.7.4

Patch "serial: 8250_pci: Detach low-level driver during PCI error recovery" has been added to the 4.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    serial: 8250_pci: Detach low-level driver during PCI error recovery

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>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 = {


Patches currently in stable-queue which might be from sumit.semwal@linaro.org are

queue-4.4/pci-add-comments-about-rom-bar-updating.patch
queue-4.4/acpi-blacklist-make-dell-latitude-3350-ethernet-work.patch
queue-4.4/s390-zcrypt-introduce-cex6-toleration.patch
queue-4.4/block-allow-write_same-commands-with-the-sg_io-ioctl.patch
queue-4.4/pci-do-any-vf-bar-updates-before-enabling-the-bars.patch
queue-4.4/x86-hyperv-handle-unknown-nmis-on-one-cpu-when-unknown_nmi_panic.patch
queue-4.4/serial-8250_pci-detach-low-level-driver-during-pci-error-recovery.patch
queue-4.4/xen-do-not-re-use-pirq-number-cached-in-pci-device-msi-msg-data.patch
queue-4.4/pci-separate-vf-bar-updates-from-standard-bar-updates.patch
queue-4.4/pci-ignore-bar-updates-on-virtual-functions.patch
queue-4.4/pci-update-bars-using-property-bits-appropriate-for-type.patch
queue-4.4/vfio-spapr-postpone-allocation-of-userspace-version-of-tce-table.patch
queue-4.4/pci-don-t-update-vf-bars-while-vf-memory-space-is-enabled.patch
queue-4.4/igb-workaround-for-igb-i210-firmware-issue.patch
queue-4.4/pci-remove-pci_resource_bar-and-pci_iov_resource_bar.patch
queue-4.4/pci-decouple-ioresource_rom_enable-and-pci_rom_address_enable.patch
queue-4.4/acpi-blacklist-add-_rev-quirks-for-dell-precision-5520-and-3520.patch
queue-4.4/igb-add-i211-to-i210-phy-workaround.patch
queue-4.4/uvcvideo-uvc_scan_fallback-for-webcams-with-broken-chain.patch