From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Al Stone <ahs3@redhat.com>

Date: Tue, 27 Feb 2018 00:21:23 -0500

Subject: [PATCH 01/34] ACPI: APEI: arm64: Ignore broken HPE moonshot APEI

 support

Message-id: <20180227002123.21608-1-ahs3@redhat.com>

Patchwork-id: 206052

O-Subject: [RHEL8 BZ1518076 PATCH] ACPI: APEI: arm64: Ignore broken HPE moonshot APEI support

Bugzilla: 1518076

RH-Acked-by: Mark Salter <msalter@redhat.com>

RH-Acked-by: Jeremy McNicoll <jmcnicol@redhat.com>

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1518076

Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=15417197

Tested: compile-only; several other patches are required for full booting

        QE has tested limited boot (see comment#12 of BZ)

This is a re-post of a RHEL-ALT-7.5 patch specific to aarch64 moonshots

that we use in beaker.  It is required for these machines to boot.

    commit 8a663a264863efedf8bb4a9d76ac603920fdd739

    Author: Robert Richter <rrichter@redhat.com>

    Date:   Wed Aug 16 19:49:30 2017 -0400

    [acpi] APEI: arm64: Ignore broken HPE moonshot APEI support

    From: Mark Salter <msalter@redhat.com>

    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1344237

    Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13768971

    Tested: Booted on moonshot with patched 4.11.0-20 kernel

    Upstream: RHEL-only

    The aarch64 HP moonshot platforms we have in beaker and elsewhere have

    a firmware bug which causes a spurious fatal memory error via APEI at

    boot time. This platform is no longer supported and no further firmware

    updates are expected. This is a downstream-only hack to avoid the problem

    by bailing out of HEST table probing if we detect a moonshot HEST table.

    Signed-off-by: Mark Salter <msalter@redhat.com>

    Signed-off-by: Robert Richter <rrichter@redhat.com>

    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only

Signed-off-by: Al Stone <ahs3@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

---

 drivers/acpi/apei/hest.c | 8 ++++++++

 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c

index 6aef1ee5e1bd..8f146b1b4972 100644

--- a/drivers/acpi/apei/hest.c

+++ b/drivers/acpi/apei/hest.c

@@ -96,6 +96,14 @@ static int apei_hest_parse(apei_hest_func_t func, void *data)

 	if (hest_disable || !hest_tab)

 		return -EINVAL;

+#ifdef CONFIG_ARM64

+	/* Ignore broken firmware */

+	if (!strncmp(hest_tab->header.oem_id, "HPE   ", 6) &&

+	    !strncmp(hest_tab->header.oem_table_id, "ProLiant", 8) &&

+	    MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM)

+		return -EINVAL;

+#endif

+

 	hest_hdr = (struct acpi_hest_header *)(hest_tab + 1);

 	for (i = 0; i < hest_tab->error_source_count; i++) {

 		len = hest_esrc_len(hest_hdr);

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Mark Salter <msalter@redhat.com>

Date: Thu, 10 May 2018 17:38:43 -0400

Subject: [PATCH 02/34] ACPI / irq: Workaround firmware issue on X-Gene based

 m400

Message-id: <20180510173844.29580-3-msalter@redhat.com>

Patchwork-id: 214383

O-Subject: [RHEL-8 BZ1519554 2/3] ACPI / irq: Workaround firmware issue on X-Gene based m400

Bugzilla: 1519554

RH-Acked-by: Al Stone <astone@redhat.com>

RH-Acked-by: Tony Camuso <tcamuso@redhat.com>

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519554

Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=16144520

The ACPI firmware on the xgene-based m400 platorms erroneously

describes its UART interrupt as ACPI_PRODUCER rather than

ACPI_CONSUMER. This leads to the UART driver being unable to

find its interrupt and the kernel unable find a console.

Work around this by avoiding the producer/consumer check

for X-Gene UARTs.

Upstream Status: RHEL only

Signed-off-by: Mark Salter <msalter@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

---

 drivers/acpi/irq.c | 17 +++++++++++++++--

 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c

index c2c786eb95ab..377cddba06dc 100644

--- a/drivers/acpi/irq.c

+++ b/drivers/acpi/irq.c

@@ -138,6 +138,7 @@ struct acpi_irq_parse_one_ctx {

 	unsigned int index;

 	unsigned long *res_flags;

 	struct irq_fwspec *fwspec;

+	bool skip_producer_check;

 };

 /**

@@ -211,7 +212,8 @@ static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,

 		return AE_CTRL_TERMINATE;

 	case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:

 		eirq = &ares->data.extended_irq;

-		if (eirq->producer_consumer == ACPI_PRODUCER)

+		if (!ctx->skip_producer_check &&

+		    eirq->producer_consumer == ACPI_PRODUCER)

 			return AE_OK;

 		if (ctx->index >= eirq->interrupt_count) {

 			ctx->index -= eirq->interrupt_count;

@@ -247,8 +249,19 @@ static acpi_status acpi_irq_parse_one_cb(struct acpi_resource *ares,

 static int acpi_irq_parse_one(acpi_handle handle, unsigned int index,

 			      struct irq_fwspec *fwspec, unsigned long *flags)

 {

-	struct acpi_irq_parse_one_ctx ctx = { -EINVAL, index, flags, fwspec };

+	struct acpi_irq_parse_one_ctx ctx = { -EINVAL, index, flags, fwspec, false };

+	/*

+	 * Firmware on arm64-based HPE m400 platform incorrectly marks

+	 * its UART interrupt as ACPI_PRODUCER rather than ACPI_CONSUMER.

+	 * Don't do the producer/consumer check for that device.

+	 */

+	if (IS_ENABLED(CONFIG_ARM64)) {

+		struct acpi_device *adev = acpi_bus_get_acpi_device(handle);

+

+		if (adev && !strcmp(acpi_device_hid(adev), "APMC0D08"))

+			ctx.skip_producer_check = true;

+	}

 	acpi_walk_resources(handle, METHOD_NAME__CRS, acpi_irq_parse_one_cb, &ctx;;

 	return ctx.rc;

 }

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Mark Salter <msalter@redhat.com>

Date: Thu, 10 May 2018 17:38:44 -0400

Subject: [PATCH 03/34] aarch64: acpi scan: Fix regression related to X-Gene

 UARTs

Message-id: <20180510173844.29580-4-msalter@redhat.com>

Patchwork-id: 214381

O-Subject: [RHEL-8 BZ1519554 3/3] aarch64: acpi scan: Fix regression related to X-Gene UARTs

Bugzilla: 1519554

RH-Acked-by: Al Stone <astone@redhat.com>

RH-Acked-by: Tony Camuso <tcamuso@redhat.com>

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519554

Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=16144520

Commit e361d1f85855 ("ACPI / scan: Fix enumeration for special UART

devices") caused a regression with some X-Gene based platforms (Mustang

and M400) with invalid DSDT. The DSDT makes it appear that the UART

device is also a slave device attached to itself. With the above commit

the UART won't be enumerated by ACPI scan (slave serial devices shouldn't

be). So check for X-Gene UART device and skip slace device check on it.

Upstream Status: RHEL only

Signed-off-by: Mark Salter <msalter@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

---

 drivers/acpi/scan.c | 9 +++++++++

 1 file changed, 9 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c

index dbfa58e799e2..69654a728e07 100644

--- a/drivers/acpi/scan.c

+++ b/drivers/acpi/scan.c

@@ -1746,6 +1746,15 @@ static bool acpi_device_enumeration_by_parent(struct acpi_device *device)

 	if (!acpi_match_device_ids(device, ignore_serial_bus_ids))

 		return false;

+	/*

+	 * Firmware on some arm64 X-Gene platforms will make the UART

+	 * device appear as both a UART and a slave of that UART. Just

+	 * bail out here for X-Gene UARTs.

+	 */

+	if (IS_ENABLED(CONFIG_ARM64) &&

+	    !strcmp(acpi_device_hid(device), "APMC0D08"))

+		return false;

+

 	INIT_LIST_HEAD(&resource_list);

 	acpi_dev_get_resources(device, &resource_list,

 			       acpi_check_serial_bus_slave,

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Robert Richter <rrichter@redhat.com>

Date: Thu, 7 Jun 2018 22:59:32 -0400

Subject: [PATCH 04/34] Vulcan: AHCI PCI bar fix for Broadcom Vulcan early

 silicon

Message-id: <1528412373-19128-2-git-send-email-rrichter@redhat.com>

Patchwork-id: 220950

O-Subject: [RHEL-8.0 BZ 1563590 v2 1/2] PCI: Vulcan: AHCI PCI bar fix for Broadcom Vulcan early silicon

Bugzilla: 1563590

RH-Acked-by: Dean Nelson <dnelson@redhat.com>

RH-Acked-by: Mark Langsdorf <mlangsdo@redhat.com>

RH-Acked-by: Mark Salter <msalter@redhat.com>

From: Ashok Kumar Sekar <asekar@redhat.com>

PCI BAR 5 is not setup correctly for the on-board AHCI

controller on Broadcom's Vulcan processor. Added a quirk to fix BAR 5

by using BAR 4's resources which are populated correctly but NOT used

by the AHCI controller actually.

RHEL-only:

Both patches are in RHEL-7.6 also. Inclusion of the patches into RHEL-8

was discussed. Since there are partners with Ax system configurations it

was decided to carry them in RHEL8 too. See:

 https://bugzilla.redhat.com/show_bug.cgi?id=1563590#c1

Upstream Status: RHEL only

Signed-off-by: Ashok Kumar Sekar <asekar@redhat.com>

Signed-off-by: Jayachandran C <jchandra@broadcom.com>

Signed-off-by: Robert Richter <rrichter@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

---

 drivers/pci/quirks.c | 24 ++++++++++++++++++++++++

 1 file changed, 24 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c

index 494fa46f5767..27bc8dd45ad8 100644

--- a/drivers/pci/quirks.c

+++ b/drivers/pci/quirks.c

@@ -4296,6 +4296,30 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_BROADCOM, 0x9000,

 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_BROADCOM, 0x9084,

 				quirk_bridge_cavm_thrx2_pcie_root);

+/*

+ * PCI BAR 5 is not setup correctly for the on-board AHCI controller

+ * on Broadcom's Vulcan processor. Added a quirk to fix BAR 5 by

+ * using BAR 4's resources which are populated correctly and NOT

+ * actually used by the AHCI controller.

+ */

+static void quirk_fix_vulcan_ahci_bars(struct pci_dev *dev)

+{

+	struct resource *r =  &dev->resource[4];

+

+	if (!(r->flags & IORESOURCE_MEM) || (r->start == 0))

+		return;

+

+	/* Set BAR5 resource to BAR4 */

+	dev->resource[5] = *r;

+

+	/* Update BAR5 in pci config space */

+	pci_write_config_dword(dev, PCI_BASE_ADDRESS_5, r->start);

+

+	/* Clear BAR4's resource */

+	memset(r, 0, sizeof(*r));

+}

+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_BROADCOM, 0x9027, quirk_fix_vulcan_ahci_bars);

+

 /*

  * Intersil/Techwell TW686[4589]-based video capture cards have an empty (zero)

  * class code.  Fix it.

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Robert Richter <rrichter@redhat.com>

Date: Thu, 7 Jun 2018 22:59:33 -0400

Subject: [PATCH 05/34] ahci: thunderx2: Fix for errata that affects stop

 engine

Message-id: <1528412373-19128-3-git-send-email-rrichter@redhat.com>

Patchwork-id: 220952

O-Subject: [RHEL-8.0 BZ 1563590 v2 2/2] ahci: thunderx2: Fix for errata that affects stop engine

Bugzilla: 1563590

RH-Acked-by: Dean Nelson <dnelson@redhat.com>

RH-Acked-by: Mark Langsdorf <mlangsdo@redhat.com>

RH-Acked-by: Mark Salter <msalter@redhat.com>

From: Jayachandran C <jnair@caviumnetworks.com>

Apply workaround for this errata:

  Synopsis: Resetting PxCMD.ST may hang the SATA device

  Description: An internal ping-pong buffer state is not reset

  correctly for an PxCMD.ST=0 command for a SATA channel. This

  may cause the SATA interface to hang when a PxCMD.ST=0 command

  is received.

  Workaround: A SATA_BIU_CORE_ENABLE.sw_init_bsi must be asserted

  by the driver whenever the PxCMD.ST needs to be de-asserted. This

  will reset both the ports. So, it may not always work in a 2

  channel SATA system.

  Resolution: Fix in B0.

Add the code to ahci_stop_engine() to do this. It is not easy to

stop the other "port" since it is associated with a different AHCI

interface. Please note that with this fix, SATA reset does not

hang any more, but it can cause failures on the other interface

if that is in active use.

Unfortunately, we have nothing other the the CPU ID to check if the

SATA block has this issue.

RHEL-only:

Both patches are in RHEL-7.6 also. Inclusion of the patches into RHEL-8

was discussed. Since there are partners with Ax system configurations it

was decided to carry them in RHEL8 too. See:

 https://bugzilla.redhat.com/show_bug.cgi?id=1563590#c1

[v3 with new delays]

Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>

Upstream Status: RHEL only

Signed-off-by: Robert Richter <rrichter@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

---

 drivers/ata/libahci.c | 18 ++++++++++++++++++

 1 file changed, 18 insertions(+)

diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c

index 954386a2b500..8f49d54e838e 100644

--- a/drivers/ata/libahci.c

+++ b/drivers/ata/libahci.c

@@ -727,6 +727,24 @@ int ahci_stop_engine(struct ata_port *ap)

 	tmp &= ~PORT_CMD_START;

 	writel(tmp, port_mmio + PORT_CMD);

+#ifdef CONFIG_ARM64

+	/* Rev Ax of Cavium CN99XX needs a hack for port stop */

+	if (dev_is_pci(ap->host->dev) &&

+	    to_pci_dev(ap->host->dev)->vendor == 0x14e4 &&

+	    to_pci_dev(ap->host->dev)->device == 0x9027 &&

+	    midr_is_cpu_model_range(read_cpuid_id(),

+			MIDR_CPU_MODEL(ARM_CPU_IMP_BRCM, BRCM_CPU_PART_VULCAN),

+			MIDR_CPU_VAR_REV(0, 0),

+			MIDR_CPU_VAR_REV(0, MIDR_REVISION_MASK))) {

+		tmp = readl(hpriv->mmio + 0x8000);

+		udelay(100);

+		writel(tmp | (1 << 26), hpriv->mmio + 0x8000);

+		udelay(100);

+		writel(tmp & ~(1 << 26), hpriv->mmio + 0x8000);

+		dev_warn(ap->host->dev, "CN99XX SATA reset workaround applied\n");

+	}

+#endif

+

 	/* wait for engine to stop. This could be as long as 500 msec */

 	tmp = ata_wait_register(ap, port_mmio + PORT_CMD,

 				PORT_CMD_LIST_ON, PORT_CMD_LIST_ON, 1, 500);

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Laura Abbott <labbott@redhat.com>

Date: Sun, 10 Feb 2019 01:27:54 +0000

Subject: [PATCH 06/34] ipmi: do not configure ipmi for HPE m400

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1670017

Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20147017

Commit 913a89f009d9 ("ipmi: Don't initialize anything in the core until

something uses it") added new locking which broke context.

    Message-id: <20180713142210.15700-1-tcamuso@redhat.com>

    Patchwork-id: 224899

    O-Subject: [RHEL8 BZ 1583537 1/1] ipmi: do not configure ipmi for HPE m400

    Bugzilla: 1583537

    RH-Acked-by: Dean Nelson <dnelson@redhat.com>

    RH-Acked-by: Al Stone <ahs3@redhat.com>

    RH-Acked-by: Mark Salter <msalter@redhat.com>

    bugzilla:https://bugzilla.redhat.com/show_bug.cgi?id=1583537

    brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=17150528

    RHEL-only

    The ARM-based HPE m400 reports host-side ipmi as residing in intel

    port-io space, which does not exist in ARM processors. Therefore, when

    running on an m400, host-side ipmi configuration code must simply return

    zero without trying to configure the host-side ipmi.

    This patch prevents panic on boot by averting attempts to configure

    host-side ipmi on this platform.

    Though HPE m400 is not certified with RHEL, and HPE has relegated it to

    EOL status, the platform is still used extensively in ARM development

    and test for RHEL.

    Testing:

    Boot without blacklisting ipmi and check to see that no ipmi modules

    are loaded.

    Signed-off-by: Tony Camuso <tcamuso@redhat.com>

    cc: Prarit Bhargava <prarit@redhat.com>

    cc: Brendan Conoboy <blc@redhat.com>

    cc: Jeff Bastian <jbastian@redhat.com>

    cc: Scott Herold <sherold@redhat.com>

    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only

Signed-off-by: Laura Abbott <labbott@redhat.com>

Acked-by: Tony Camuso <tcamuso@redhat.com>

Acked-by: Dean Nelson <dnelson@redhat.com>

Acked-by: Jarod Wilson <jarod@redhat.com>

Acked-by: Mark Salter <msalter@redhat.com>

---

 drivers/char/ipmi/ipmi_dmi.c        | 15 +++++++++++++++

 drivers/char/ipmi/ipmi_msghandler.c | 16 +++++++++++++++-

 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_dmi.c b/drivers/char/ipmi/ipmi_dmi.c

index bbf7029e224b..cf7faa970dd6 100644

--- a/drivers/char/ipmi/ipmi_dmi.c

+++ b/drivers/char/ipmi/ipmi_dmi.c

@@ -215,6 +215,21 @@ static int __init scan_for_dmi_ipmi(void)

 {

 	const struct dmi_device *dev = NULL;

+#ifdef CONFIG_ARM64

+	/* RHEL-only

+	 * If this is ARM-based HPE m400, return now, because that platform

+	 * reports the host-side ipmi address as intel port-io space, which

+	 * does not exist in the ARM architecture.

+	 */

+	const char *dmistr = dmi_get_system_info(DMI_PRODUCT_NAME);

+

+	if (dmistr && (strcmp("ProLiant m400 Server", dmistr) == 0)) {

+		pr_debug("%s does not support host ipmi\n", dmistr);

+		return 0;

+	}

+	/* END RHEL-only */

+#endif

+

 	while ((dev = dmi_find_device(DMI_DEV_TYPE_IPMI, NULL, dev)))

 		dmi_decode_ipmi((const struct dmi_header *) dev->device_data);

diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c

index 5d403fb5bd92..385747b5361f 100644

--- a/drivers/char/ipmi/ipmi_msghandler.c

+++ b/drivers/char/ipmi/ipmi_msghandler.c

@@ -35,6 +35,7 @@

 #include <linux/uuid.h>

 #include <linux/nospec.h>

 #include <linux/vmalloc.h>

+#include <linux/dmi.h>

 #include <linux/delay.h>

 #define IPMI_DRIVER_VERSION "39.2"

@@ -5516,8 +5517,21 @@ static int __init ipmi_init_msghandler_mod(void)

 {

 	int rv;

-	pr_info("version " IPMI_DRIVER_VERSION "\n");

+#ifdef CONFIG_ARM64

+	/* RHEL-only

+	 * If this is ARM-based HPE m400, return now, because that platform

+	 * reports the host-side ipmi address as intel port-io space, which

+	 * does not exist in the ARM architecture.

+	 */

+	const char *dmistr = dmi_get_system_info(DMI_PRODUCT_NAME);

+	if (dmistr && (strcmp("ProLiant m400 Server", dmistr) == 0)) {

+		pr_debug("%s does not support host ipmi\n", dmistr);

+		return -ENOSYS;

+	}

+	/* END RHEL-only */

+#endif

+	pr_info("version " IPMI_DRIVER_VERSION "\n");

 	mutex_lock(&ipmi_interfaces_mutex);

 	rv = ipmi_register_driver();

 	mutex_unlock(&ipmi_interfaces_mutex);

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Laura Abbott <labbott@redhat.com>

Date: Mon, 20 May 2019 22:21:02 -0400

Subject: [PATCH 07/34] iommu/arm-smmu: workaround DMA mode issues

Message-id: <20190520222102.19488-1-labbott@redhat.com>

Patchwork-id: 259215

O-Subject: [ARK INTERNAL PATCH] iommu/arm-smmu: workaround DMA mode issues

Bugzilla:

RH-Acked-by: Mark Langsdorf <mlangsdo@redhat.com>

RH-Acked-by: Mark Salter <msalter@redhat.com>

From: Mark Salter <msalter@redhat.com>

Rebased for v5.2-rc1

	Bugzilla: 1652259

	Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=19244562

	Upstream status: RHEL only.

	rhel8 commit 65feb1ed0ec9a088a63a90d46c0f7563ac96ad0f

	Author: Mark Salter <msalter@redhat.com>

	Date:   Wed Nov 21 17:15:59 2018 +0100

	    [iommu] iommu/arm-smmu: workaround DMA mode issues

	    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1624077

	    Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=18112820

	    Testing: Verified iommu.passthrough=1 no longer needed on gigabyte platforms.

	    Upstream Status: RHEL-only

	    In RHEL_ALT 7.5 we carried a RHEL-only patch which forced the arm smmuv2

	    into bypass mode due to performance issues on CN88xx. This was intended

	    to be a temporary hack until the issues were resolved. Another vendor

	    had issues with the iommu in bypass mode so we reverted the RHEL-only

	    patch so that iommu is in DMA mode by default (upstream default).

	    It turns on that there are remaining SMMU DMA mode issues on Gigabyte

	    platformws with CN88xx cpus. The problem manifests itself by pcie

	    card drivers failing to initialize the cards when SMMU is in DMA mode.

	    The root cause has not been determined yet, but looks likely to be

	    a hw or firmware issue. This patch forces bypass mode for Gigabyte

	    platforms. CN88xx isn't officially supported in RHEL but we have a

	    lot of them being used internally for testing, so I think we want

	    this to support that use case in RHEL8.

	    Signed-off-by: Mark Salter <msalter@redhat.com>

	    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

	Acked-by: Mark Salter <msalter@redhat.com>

	Acked-by: Donald Dutile <ddutile@redhat.com>

Upstream Status: RHEL only

Signed-off-by: Laura Abbott <labbott@redhat.com>

---

 drivers/iommu/iommu.c | 22 ++++++++++++++++++++++

 1 file changed, 22 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c

index bfb2f163c691..3e02f19e8975 100644

--- a/drivers/iommu/iommu.c

+++ b/drivers/iommu/iommu.c

@@ -8,6 +8,7 @@

 #include <linux/amba/bus.h>

 #include <linux/device.h>

+#include <linux/dmi.h>

 #include <linux/kernel.h>

 #include <linux/bits.h>

 #include <linux/bug.h>

@@ -2852,6 +2853,27 @@ u32 iommu_sva_get_pasid(struct iommu_sva *handle)

 }

 EXPORT_SYMBOL_GPL(iommu_sva_get_pasid);

+#ifdef CONFIG_ARM64

+static int __init iommu_quirks(void)

+{

+	const char *vendor, *name;

+

+	vendor = dmi_get_system_info(DMI_SYS_VENDOR);

+	name = dmi_get_system_info(DMI_PRODUCT_NAME);

+

+	if (vendor &&

+	    (strncmp(vendor, "GIGABYTE", 8) == 0 && name &&

+	     (strncmp(name, "R120", 4) == 0 ||

+	      strncmp(name, "R270", 4) == 0))) {

+		pr_warn("Gigabyte %s detected, force iommu passthrough mode", name);

+		iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY;

+	}

+

+	return 0;

+}

+arch_initcall(iommu_quirks);

+#endif

+

 /*

  * Changes the default domain of an iommu group that has *only* one device

  *

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Jeremy Cline <jcline@redhat.com>

Date: Tue, 1 Oct 2019 15:51:23 +0000

Subject: [PATCH 08/34] arm: aarch64: Drop the EXPERT setting from

 ARM64_FORCE_52BIT

Message-id: <20191001181256.22935-1-jcline@redhat.com>

Patchwork-id: 275498

O-Subject: [ARK INTERNAL PATCH] [ARK INTERNAL PATCH] [redhat] Add patch

    to drop the EXPERT setting from ARM64_FORCE_52BIT

Bugzilla:

RH-Acked-by: Laura Abbott <labbott@redhat.com>

We don't turn on EXPERT as there are few settings we actually want to

mess with. Remove the dependency for ARM64_FORCE_52BIT as we do want

that on in debug builds to help find 52-bit bugs.

Upstream Status: RHEL only

Signed-off-by: Jeremy Cline <jcline@redhat.com>

---

 arch/arm64/Kconfig | 2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig

index 43ff7c7a3ac9..efb74e176dec 100644

--- a/arch/arm64/Kconfig

+++ b/arch/arm64/Kconfig

@@ -1211,7 +1211,7 @@ endchoice

 config ARM64_FORCE_52BIT

 	bool "Force 52-bit virtual addresses for userspace"

-	depends on ARM64_VA_BITS_52 && EXPERT

+	depends on ARM64_VA_BITS_52

 	help

 	  For systems with 52-bit userspace VAs enabled, the kernel will attempt

 	  to maintain compatibility with older software by providing 48-bit VAs

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Peter Jones <pjones@redhat.com>

Date: Mon, 2 Oct 2017 18:22:13 -0400

Subject: [PATCH 09/34] Add efi_status_to_str() and rework efi_status_to_err().

This adds efi_status_to_str() for use when printing efi_status_t

messages, and reworks efi_status_to_err() so that the two use a common

list of errors.

Upstream Status: RHEL only

Signed-off-by: Peter Jones <pjones@redhat.com>

---

 drivers/firmware/efi/efi.c | 124 +++++++++++++++++++++++++++----------

 include/linux/efi.h        |   3 +

 2 files changed, 96 insertions(+), 31 deletions(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c

index b43e5e6ddaf6..3179641e9855 100644

--- a/drivers/firmware/efi/efi.c

+++ b/drivers/firmware/efi/efi.c

@@ -32,6 +32,7 @@

 #include <linux/ucs2_string.h>

 #include <linux/memblock.h>

 #include <linux/security.h>

+#include <linux/bsearch.h>

 #include <asm/early_ioremap.h>

@@ -884,40 +885,101 @@ int efi_mem_type(unsigned long phys_addr)

 }

 #endif

+struct efi_error_code {

+	efi_status_t status;

+	int errno;

+	const char *description;

+};

+

+static const struct efi_error_code efi_error_codes[] = {

+	{ EFI_SUCCESS, 0, "Success"},

+#if 0

+	{ EFI_LOAD_ERROR, -EPICK_AN_ERRNO, "Load Error"},

+#endif

+	{ EFI_INVALID_PARAMETER, -EINVAL, "Invalid Parameter"},

+	{ EFI_UNSUPPORTED, -ENOSYS, "Unsupported"},

+	{ EFI_BAD_BUFFER_SIZE, -ENOSPC, "Bad Buffer Size"},

+	{ EFI_BUFFER_TOO_SMALL, -ENOSPC, "Buffer Too Small"},

+	{ EFI_NOT_READY, -EAGAIN, "Not Ready"},

+	{ EFI_DEVICE_ERROR, -EIO, "Device Error"},

+	{ EFI_WRITE_PROTECTED, -EROFS, "Write Protected"},

+	{ EFI_OUT_OF_RESOURCES, -ENOMEM, "Out of Resources"},

+#if 0

+	{ EFI_VOLUME_CORRUPTED, -EPICK_AN_ERRNO, "Volume Corrupt"},

+	{ EFI_VOLUME_FULL, -EPICK_AN_ERRNO, "Volume Full"},

+	{ EFI_NO_MEDIA, -EPICK_AN_ERRNO, "No Media"},

+	{ EFI_MEDIA_CHANGED, -EPICK_AN_ERRNO, "Media changed"},

+#endif

+	{ EFI_NOT_FOUND, -ENOENT, "Not Found"},

+#if 0

+	{ EFI_ACCESS_DENIED, -EPICK_AN_ERRNO, "Access Denied"},

+	{ EFI_NO_RESPONSE, -EPICK_AN_ERRNO, "No Response"},

+	{ EFI_NO_MAPPING, -EPICK_AN_ERRNO, "No mapping"},

+	{ EFI_TIMEOUT, -EPICK_AN_ERRNO, "Time out"},

+	{ EFI_NOT_STARTED, -EPICK_AN_ERRNO, "Not started"},

+	{ EFI_ALREADY_STARTED, -EPICK_AN_ERRNO, "Already started"},

+#endif

+	{ EFI_ABORTED, -EINTR, "Aborted"},

+#if 0

+	{ EFI_ICMP_ERROR, -EPICK_AN_ERRNO, "ICMP Error"},

+	{ EFI_TFTP_ERROR, -EPICK_AN_ERRNO, "TFTP Error"},

+	{ EFI_PROTOCOL_ERROR, -EPICK_AN_ERRNO, "Protocol Error"},

+	{ EFI_INCOMPATIBLE_VERSION, -EPICK_AN_ERRNO, "Incompatible Version"},

+#endif

+	{ EFI_SECURITY_VIOLATION, -EACCES, "Security Policy Violation"},

+#if 0

+	{ EFI_CRC_ERROR, -EPICK_AN_ERRNO, "CRC Error"},

+	{ EFI_END_OF_MEDIA, -EPICK_AN_ERRNO, "End of Media"},

+	{ EFI_END_OF_FILE, -EPICK_AN_ERRNO, "End of File"},

+	{ EFI_INVALID_LANGUAGE, -EPICK_AN_ERRNO, "Invalid Languages"},

+	{ EFI_COMPROMISED_DATA, -EPICK_AN_ERRNO, "Compromised Data"},

+

+	// warnings

+	{ EFI_WARN_UNKOWN_GLYPH, -EPICK_AN_ERRNO, "Warning Unknown Glyph"},

+	{ EFI_WARN_DELETE_FAILURE, -EPICK_AN_ERRNO, "Warning Delete Failure"},

+	{ EFI_WARN_WRITE_FAILURE, -EPICK_AN_ERRNO, "Warning Write Failure"},

+	{ EFI_WARN_BUFFER_TOO_SMALL, -EPICK_AN_ERRNO, "Warning Buffer Too Small"},

+#endif

+};

+

+static int

+efi_status_cmp_bsearch(const void *key, const void *item)

+{

+	u64 status = (u64)(uintptr_t)key;

+	struct efi_error_code *code = (struct efi_error_code *)item;

+

+	if (status < code->status)

+		return -1;

+	if (status > code->status)

+		return 1;

+	return 0;

+}

+

 int efi_status_to_err(efi_status_t status)

 {

-	int err;

-

-	switch (status) {

-	case EFI_SUCCESS:

-		err = 0;

-		break;

-	case EFI_INVALID_PARAMETER:

-		err = -EINVAL;

-		break;

-	case EFI_OUT_OF_RESOURCES:

-		err = -ENOSPC;

-		break;

-	case EFI_DEVICE_ERROR:

-		err = -EIO;

-		break;

-	case EFI_WRITE_PROTECTED:

-		err = -EROFS;

-		break;

-	case EFI_SECURITY_VIOLATION:

-		err = -EACCES;

-		break;

-	case EFI_NOT_FOUND:

-		err = -ENOENT;

-		break;

-	case EFI_ABORTED:

-		err = -EINTR;

-		break;

-	default:

-		err = -EINVAL;

-	}

+	struct efi_error_code *found;

+	size_t num = sizeof(efi_error_codes) / sizeof(struct efi_error_code);

-	return err;

+	found = bsearch((void *)(uintptr_t)status, efi_error_codes,

+			sizeof(struct efi_error_code), num,

+			efi_status_cmp_bsearch);

+	if (!found)

+		return -EINVAL;

+	return found->errno;

+}

+

+const char *

+efi_status_to_str(efi_status_t status)

+{

+	struct efi_error_code *found;

+	size_t num = sizeof(efi_error_codes) / sizeof(struct efi_error_code);

+

+	found = bsearch((void *)(uintptr_t)status, efi_error_codes,

+			sizeof(struct efi_error_code), num,

+			efi_status_cmp_bsearch);

+	if (!found)

+		return "Unknown error code";

+	return found->description;

 }

 EXPORT_SYMBOL_GPL(efi_status_to_err);

diff --git a/include/linux/efi.h b/include/linux/efi.h

index 4e1bfee9675d..69a3074a9fbc 100644

--- a/include/linux/efi.h

+++ b/include/linux/efi.h

@@ -43,6 +43,8 @@

 #define EFI_ABORTED		(21 | (1UL << (BITS_PER_LONG-1)))

 #define EFI_SECURITY_VIOLATION	(26 | (1UL << (BITS_PER_LONG-1)))

+#define EFI_IS_ERROR(x)		((x) & (1UL << (BITS_PER_LONG-1)))

+

 typedef unsigned long efi_status_t;

 typedef u8 efi_bool_t;

 typedef u16 efi_char16_t;		/* UNICODE character */

@@ -911,6 +913,7 @@ static inline void efi_find_mirror(void) {}

 #endif

 extern int efi_status_to_err(efi_status_t status);

+extern const char *efi_status_to_str(efi_status_t status);

 /*

  * Variable Attributes

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Peter Jones <pjones@redhat.com>

Date: Mon, 2 Oct 2017 18:18:30 -0400

Subject: [PATCH 10/34] Make get_cert_list() use efi_status_to_str() to print

 error messages.

Upstream Status: RHEL only

Signed-off-by: Peter Jones <pjones@redhat.com>

Signed-off-by: Jeremy Cline <jcline@redhat.com>

---

 security/integrity/platform_certs/load_uefi.c | 6 ++++--

 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c

index d1fdd113450a..182e8090cfe8 100644

--- a/security/integrity/platform_certs/load_uefi.c

+++ b/security/integrity/platform_certs/load_uefi.c

@@ -74,7 +74,8 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,

 		return NULL;

 	if (*status != EFI_BUFFER_TOO_SMALL) {

-		pr_err("Couldn't get size: 0x%lx\n", *status);

+		pr_err("Couldn't get size: %s (0x%lx)\n",

+		       efi_status_to_str(*status), *status);

 		return NULL;

 	}

@@ -85,7 +86,8 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,

 	*status = efi.get_variable(name, guid, NULL, &lsize, db);

 	if (*status != EFI_SUCCESS) {

 		kfree(db);

-		pr_err("Error reading db var: 0x%lx\n", *status);

+		pr_err("Error reading db var: %s (0x%lx)\n",

+		       efi_status_to_str(*status), *status);

 		return NULL;

 	}

-- 

2.39.1

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001

From: Jeremy Cline <jcline@redhat.com>

Date: Mon, 30 Sep 2019 21:22:47 +0000

Subject: [PATCH 11/34] security: lockdown: expose a hook to lock the kernel

 down

In order to automatically lock down kernels running on UEFI machines

booted in Secure Boot mode, expose the lock_kernel_down() hook.

Upstream Status: RHEL only

Signed-off-by: Jeremy Cline <jcline@redhat.com>

---