Add i915 eDP fixes

The build 4.17.5 build failed because "fa" was not declared.

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

.gitignore

@@ -3,5 +3,8 @@ clog
 *.bz2
 *.rpm
 *.orig
+*.sign
 kernel-[234].*/
 perf-man-*.tar.gz
+kernel-tools/
+kernel-headers/

0001-platform-x86-dell-laptop-Filter-out-spurious-keyboar.patch

@@ -1,99 +0,0 @@
-From 714fe15daa07e7691c9731c88de71aa57f84b6c2 Mon Sep 17 00:00:00 2001
-From: Hans de Goede <hdegoede@redhat.com>
-Date: Wed, 3 Jan 2018 11:13:54 +0100
-Subject: [PATCH] platform/x86: dell-laptop: Filter out spurious keyboard
- backlight change events
-
-On some Dell XPS models WMI events of type 0x0000 reporting a keycode of
-0xe00c get reported when the brightness of the LCD panel changes.
-
-This leads to us reporting false-positive kbd_led change events to
-userspace which in turn leads to the kbd backlight OSD showing when it
-should not.
-
-We already read the current keyboard backlight brightness value when
-reporting events because the led_classdev_notify_brightness_hw_changed
-API requires this. Compare this value to the last known value and filter
-out duplicate events, fixing this.
-
-Note the fixed issue is esp. a problem on XPS models with an ambient light
-sensor and automatic brightness adjustments turned on, this causes the kbd
-backlight OSD to show all the time there.
-
-BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514969
-Signed-off-by: Hans de Goede <hdegoede@redhat.com>
----
- drivers/platform/x86/dell-laptop.c | 24 ++++++++++++++++++++++--
- 1 file changed, 22 insertions(+), 2 deletions(-)
-
-diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
-index cd4725e7e0b5..2ef3297a9efc 100644
---- a/drivers/platform/x86/dell-laptop.c
-+++ b/drivers/platform/x86/dell-laptop.c
-@@ -1133,6 +1133,7 @@ static u8 kbd_previous_mode_bit;
- 
- static bool kbd_led_present;
- static DEFINE_MUTEX(kbd_led_mutex);
-+static enum led_brightness kbd_led_level;
- 
- /*
-  * NOTE: there are three ways to set the keyboard backlight level.
-@@ -1947,6 +1948,7 @@ static enum led_brightness kbd_led_level_get(struct led_classdev *led_cdev)
- static int kbd_led_level_set(struct led_classdev *led_cdev,
- 			     enum led_brightness value)
- {
-+	enum led_brightness new_value = value;
- 	struct kbd_state state;
- 	struct kbd_state new_state;
- 	u16 num;
-@@ -1976,6 +1978,9 @@ static int kbd_led_level_set(struct led_classdev *led_cdev,
- 	}
- 
- out:
-+	if (ret == 0)
-+		kbd_led_level = new_value;
-+
- 	mutex_unlock(&kbd_led_mutex);
- 	return ret;
- }
-@@ -2003,6 +2008,9 @@ static int __init kbd_led_init(struct device *dev)
- 		if (kbd_led.max_brightness)
- 			kbd_led.max_brightness--;
- 	}
-+
-+	kbd_led_level = kbd_led_level_get(NULL);
-+
- 	ret = led_classdev_register(dev, &kbd_led);
- 	if (ret)
- 		kbd_led_present = false;
-@@ -2027,13 +2035,25 @@ static void kbd_led_exit(void)
- static int dell_laptop_notifier_call(struct notifier_block *nb,
- 				     unsigned long action, void *data)
- {
-+	bool changed = false;
-+	enum led_brightness new_kbd_led_level;
-+
- 	switch (action) {
- 	case DELL_LAPTOP_KBD_BACKLIGHT_BRIGHTNESS_CHANGED:
- 		if (!kbd_led_present)
- 			break;
- 
--		led_classdev_notify_brightness_hw_changed(&kbd_led,
--						kbd_led_level_get(&kbd_led));
-+		mutex_lock(&kbd_led_mutex);
-+		new_kbd_led_level = kbd_led_level_get(&kbd_led);
-+		if (kbd_led_level != new_kbd_led_level) {
-+			kbd_led_level = new_kbd_led_level;
-+			changed = true;
-+		}
-+		mutex_unlock(&kbd_led_mutex);
-+
-+		if (changed)
-+			led_classdev_notify_brightness_hw_changed(&kbd_led,
-+								kbd_led_level);
- 		break;
- 	}
- 
--- 
-2.14.3
-

0001-random-add-a-config-option-to-trust-the-CPU-s-hwrng.patch

@@ -0,0 +1,78 @@
+From 39a8883a2b989d1d21bd8dd99f5557f0c5e89694 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Tue, 17 Jul 2018 18:24:27 -0400
+Subject: [PATCH] random: add a config option to trust the CPU's hwrng
+
+This gives the user building their own kernel (or a Linux
+distribution) the option of deciding whether or not to trust the CPU's
+hardware random number generator (e.g., RDRAND for x86 CPU's) as being
+correctly implemented and not having a back door introduced (perhaps
+courtesy of a Nation State's law enforcement or intelligence
+agencies).
+
+This will prevent getrandom(2) from blocking, if there is a
+willingness to trust the CPU manufacturer.
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+---
+ drivers/char/Kconfig  | 14 ++++++++++++++
+ drivers/char/random.c | 11 ++++++++++-
+ 2 files changed, 24 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
+index 212f447938ae..ce277ee0a28a 100644
+--- a/drivers/char/Kconfig
++++ b/drivers/char/Kconfig
+@@ -554,3 +554,17 @@ config ADI
+ 
+ endmenu
+ 
++config RANDOM_TRUST_CPU
++	bool "Trust the CPU manufacturer to initialize Linux's CRNG"
++	depends on X86 || S390 || PPC
++	default n
++	help
++	Assume that CPU manufacturer (e.g., Intel or AMD for RDSEED or
++	RDRAND, IBM for the S390 and Power PC architectures) is trustworthy
++	for the purposes of initializing Linux's CRNG.  Since this is not
++	something that can be independently audited, this amounts to trusting
++	that CPU manufacturer (perhaps with the insistence or mandate
++	of a Nation State's intelligence or law enforcement agencies)
++	has not installed a hidden back door to compromise the CPU's
++	random number generation facilities.
++
+diff --git a/drivers/char/random.c b/drivers/char/random.c
+index 34ddfd57419b..f4013b8a711b 100644
+--- a/drivers/char/random.c
++++ b/drivers/char/random.c
+@@ -782,6 +782,7 @@ static void invalidate_batched_entropy(void);
+ static void crng_initialize(struct crng_state *crng)
+ {
+ 	int		i;
++	int		arch_init = 1;
+ 	unsigned long	rv;
+ 
+ 	memcpy(&crng->state[0], "expand 32-byte k", 16);
+@@ -792,10 +793,18 @@ static void crng_initialize(struct crng_state *crng)
+ 		_get_random_bytes(&crng->state[4], sizeof(__u32) * 12);
+ 	for (i = 4; i < 16; i++) {
+ 		if (!arch_get_random_seed_long(&rv) &&
+-		    !arch_get_random_long(&rv))
++		    !arch_get_random_long(&rv)) {
+ 			rv = random_get_entropy();
++			arch_init = 0;
++		}
+ 		crng->state[i] ^= rv;
+ 	}
++#ifdef CONFIG_RANDOM_TRUST_CPU
++	if (arch_init) {
++		crng_init = 2;
++		pr_notice("random: crng done (trusting CPU's manufacturer)\n");
++	}
++#endif
+ 	crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1;
+ }
+ 
+-- 
+2.17.1
+

0001-random-make-CPU-trust-a-boot-parameter.patch

@@ -0,0 +1,82 @@
+From 9b25436662d5fb4c66eb527ead53cab15f596ee0 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Mon, 27 Aug 2018 14:51:54 -0700
+Subject: [PATCH] random: make CPU trust a boot parameter
+
+Instead of forcing a distro or other system builder to choose
+at build time whether the CPU is trusted for CRNG seeding via
+CONFIG_RANDOM_TRUST_CPU, provide a boot-time parameter for end users to
+control the choice. The CONFIG will set the default state instead.
+
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+---
+ Documentation/admin-guide/kernel-parameters.txt |  6 ++++++
+ drivers/char/Kconfig                            |  4 ++--
+ drivers/char/random.c                           | 11 ++++++++---
+ 3 files changed, 16 insertions(+), 5 deletions(-)
+
+diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
+index 0c8f7889efa1..227c5c6fa4c1 100644
+--- a/Documentation/admin-guide/kernel-parameters.txt
++++ b/Documentation/admin-guide/kernel-parameters.txt
+@@ -3390,6 +3390,12 @@
+ 	ramdisk_size=	[RAM] Sizes of RAM disks in kilobytes
+ 			See Documentation/blockdev/ramdisk.txt.
+ 
++	random.trust_cpu={on,off}
++			[KNL] Enable or disable trusting the use of the
++			CPU's random number generator (if available) to
++			fully seed the kernel's CRNG. Default is controlled
++			by CONFIG_RANDOM_TRUST_CPU.
++
+ 	ras=option[,option,...]	[KNL] RAS-specific options
+ 
+ 		cec_disable	[X86]
+diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
+index ce277ee0a28a..40728491f37b 100644
+--- a/drivers/char/Kconfig
++++ b/drivers/char/Kconfig
+@@ -566,5 +566,5 @@ config RANDOM_TRUST_CPU
+ 	that CPU manufacturer (perhaps with the insistence or mandate
+ 	of a Nation State's intelligence or law enforcement agencies)
+ 	has not installed a hidden back door to compromise the CPU's
+-	random number generation facilities.
+-
++	random number generation facilities. This can also be configured
++	at boot with "random.trust_cpu=on/off".
+diff --git a/drivers/char/random.c b/drivers/char/random.c
+index bf5f99fc36f1..c75b6cdf0053 100644
+--- a/drivers/char/random.c
++++ b/drivers/char/random.c
+@@ -779,6 +779,13 @@ static struct crng_state **crng_node_pool __read_mostly;
+ 
+ static void invalidate_batched_entropy(void);
+ 
++static bool trust_cpu __ro_after_init = IS_ENABLED(CONFIG_RANDOM_TRUST_CPU);
++static int __init parse_trust_cpu(char *arg)
++{
++	return kstrtobool(arg, &trust_cpu);
++}
++early_param("random.trust_cpu", parse_trust_cpu);
++
+ static void crng_initialize(struct crng_state *crng)
+ {
+ 	int		i;
+@@ -799,12 +806,10 @@ static void crng_initialize(struct crng_state *crng)
+ 		}
+ 		crng->state[i] ^= rv;
+ 	}
+-#ifdef CONFIG_RANDOM_TRUST_CPU
+-	if (arch_init) {
++	if (trust_cpu && arch_init) {
+ 		crng_init = 2;
+ 		pr_notice("random: crng done (trusting CPU's manufacturer)\n");
+ 	}
+-#endif
+ 	crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1;
+ }
+ 
+-- 
+2.17.1
+

0001-tools-lib-subcmd-pager.c-do-not-alias-select-params.patch

@@ -1,44 +0,0 @@
-From 85721e6bfc5da3c8f7971c4acb1a0ad16fb2c16a Mon Sep 17 00:00:00 2001
-From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Date: Thu, 1 Feb 2018 13:29:38 +1100
-Subject: [PATCH] tools/lib/subcmd/pager.c: do not alias select() params
-
-Use a separate fd set for select()-s exception fds param to fix the
-following gcc warning:
-
-pager.c:36:12: error: passing argument 2 to restrict-qualified
-               parameter aliases with argument 4 [-Werror=restrict]
-  select(1, &in, NULL, &in, NULL);
-            ^~~        ~~~
-
-Link: http://lkml.kernel.org/r/20180101105626.7168-1-sergey.senozhatsky@gmail.com
-Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
----
- tools/lib/subcmd/pager.c | 5 ++++-
- 1 file changed, 4 insertions(+), 1 deletion(-)
-
-diff --git a/tools/lib/subcmd/pager.c b/tools/lib/subcmd/pager.c
-index 5ba754d17952..9997a8805a82 100644
---- a/tools/lib/subcmd/pager.c
-+++ b/tools/lib/subcmd/pager.c
-@@ -30,10 +30,13 @@ static void pager_preexec(void)
- 	 * have real input
- 	 */
- 	fd_set in;
-+	fd_set exception;
-
- 	FD_ZERO(&in);
-+	FD_ZERO(&exception);
- 	FD_SET(0, &in);
--	select(1, &in, NULL, &in, NULL);
-+	FD_SET(0, &exception);
-+	select(1, &in, NULL, &exception, NULL);
-
- 	setenv("LESS", "FRSX", 0);
- }
--- 
-2.14.3
-

ACPI-irq-Workaround-firmware-issue-on-X-Gene-based-m400.patch

@@ -0,0 +1,64 @@
+From dbdda4277cf0422a9ccb7ea98d0263c3cdbecdf6 Mon Sep 17 00:00:00 2001
+From: Mark Salter <msalter@redhat.com>
+Date: Tue, 8 May 2018 21:54:39 -0400
+Subject: [PATCH] ACPI / irq: Workaround firmware issue on X-Gene based
+ m400
+
+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.
+
+Signed-off-by: Mark Salter <msalter@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 7c352cba0528..028c1a564cff 100644
+--- a/drivers/acpi/irq.c
++++ b/drivers/acpi/irq.c
+@@ -129,6 +129,7 @@ struct acpi_irq_parse_one_ctx {
+ 	unsigned int index;
+ 	unsigned long *res_flags;
+ 	struct irq_fwspec *fwspec;
++	bool skip_producer_check;
+ };
+ 
+ /**
+@@ -200,7 +201,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;
+@@ -235,8 +237,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.17.0
+

ACPI-scan-Fix-regression-related-to-X-Gene-UARTs.patch

@@ -0,0 +1,44 @@
+From patchwork Fri Apr 20 03:29:47 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: ACPI / scan: Fix regression related to X-Gene UARTs
+From: Mark Salter <msalter@redhat.com>
+X-Patchwork-Id: 10351797
+Message-Id: <20180420032947.23023-1-msalter@redhat.com>
+To: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Danis?= <frederic.danis.oss@gmail.com>
+Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
+ linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
+Date: Thu, 19 Apr 2018 23:29:47 -0400
+
+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.
+
+Signed-off-by: Mark Salter <msalter@redhat.com>
+---
+ drivers/acpi/scan.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
+index cc234e6a6297..1dcdd0122862 100644
+--- a/drivers/acpi/scan.c
++++ b/drivers/acpi/scan.c
+@@ -1551,6 +1551,14 @@ static bool acpi_device_enumeration_by_parent(struct acpi_device *device)
+ 	     fwnode_property_present(&device->fwnode, "baud")))
+ 		return true;
+ 
++	/*
++	 * 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 (!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,

ALSA-hda-Add-mic-quirk-for-the-Lenovo-G50-30-17aa-39.patch

@@ -0,0 +1,32 @@
+From 44002a8818bc64f53d855bc8e3ee4c6bb2d3db99 Mon Sep 17 00:00:00 2001
+From: Jeremy Cline <jcline@redhat.com>
+Date: Mon, 8 Oct 2018 14:37:52 -0400
+Subject: [PATCH] ALSA: hda - Add mic quirk for the Lenovo G50-30 (17aa:3905)
+
+The Lenovo G50-30, like other G50 models, has a Conexant codec that
+requires a quirk for its inverted stereo dmic.
+
+Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1249364
+Reported-by: Alexander Ploumistos <alex.ploumistos@gmail.com>
+Tested-by: Alexander Ploumistos <alex.ploumistos@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jeremy Cline <jcline@redhat.com>
+---
+ sound/pci/hda/patch_conexant.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
+index 5592557fe50e..950e02e71766 100644
+--- a/sound/pci/hda/patch_conexant.c
++++ b/sound/pci/hda/patch_conexant.c
+@@ -943,6 +943,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
+ 	SND_PCI_QUIRK(0x17aa, 0x21da, "Lenovo X220", CXT_PINCFG_LENOVO_TP410),
+ 	SND_PCI_QUIRK(0x17aa, 0x21db, "Lenovo X220-tablet", CXT_PINCFG_LENOVO_TP410),
+ 	SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo IdeaPad Z560", CXT_FIXUP_MUTE_LED_EAPD),
++	SND_PCI_QUIRK(0x17aa, 0x3905, "Lenovo G50-30", CXT_FIXUP_STEREO_DMIC),
+ 	SND_PCI_QUIRK(0x17aa, 0x390b, "Lenovo G50-80", CXT_FIXUP_STEREO_DMIC),
+ 	SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
+ 	SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC),
+-- 
+2.19.1
+

CI-1-6-drm-i915-dp-Fix-link-retraining-comment-in-intel_dp_long_pulse.patch

@@ -0,0 +1,60 @@
+From patchwork Thu Sep 27 20:57:30 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 8bit
+Subject: [CI, 1/6] drm/i915/dp: Fix link retraining comment in
+ intel_dp_long_pulse()
+From: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
+X-Patchwork-Id: 253516
+Message-Id: <20180927205735.16651-1-dhinakaran.pandiyan@intel.com>
+To: intel-gfx@lists.freedesktop.org
+Date: Thu, 27 Sep 2018 13:57:30 -0700
+
+Comment claims link needs to be retrained because the connected sink raised
+a long pulse to indicate link loss. If the sink did so,
+intel_dp_hotplug() would have handled link retraining. Looking at the
+logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-apply
+Perform link quality check, unconditionally during long pulse"")', the
+issue is that the sink does not trigger an interrupt. What we want is
+->detect() from user space to check link status and retrain. Ville's
+review for the original patch also indicates the same root cause. So,
+rewrite the comment.
+
+v2: Patch split and rewrote comment.
+
+Cc: Lyude Paul <lyude@redhat.com>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Jani Nikula <jani.nikula@linux.intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: Jan-Marek Glogowski <glogow@fbihome.de>
+References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")
+Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+---
+ drivers/gpu/drm/i915/intel_dp.c | 13 +++----------
+ 1 file changed, 3 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
+index 256a71c8c093..207b3ea2ed1a 100644
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -5074,16 +5074,9 @@ intel_dp_long_pulse(struct intel_connector *connector,
+ 		goto out;
+ 	} else {
+ 		/*
+-		 * If display is now connected check links status,
+-		 * there has been known issues of link loss triggering
+-		 * long pulse.
+-		 *
+-		 * Some sinks (eg. ASUS PB287Q) seem to perform some
+-		 * weird HPD ping pong during modesets. So we can apparently
+-		 * end up with HPD going low during a modeset, and then
+-		 * going back up soon after. And once that happens we must
+-		 * retrain the link to get a picture. That's in case no
+-		 * userspace component reacted to intermittent HPD dip.
++		 * Some external monitors do not signal loss of link
++		 * synchronization with an IRQ_HPD, so force a link status
++		 * check.
+ 		 */
+ 		struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ 

CI-2-6-drm-i915-dp-Restrict-link-retrain-workaround-to-external-monitors.patch

@@ -0,0 +1,55 @@
+From patchwork Thu Sep 27 20:57:31 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 8bit
+Subject: [CI, 2/6] drm/i915/dp: Restrict link retrain workaround to external
+ monitors
+From: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
+X-Patchwork-Id: 253514
+Message-Id: <20180927205735.16651-2-dhinakaran.pandiyan@intel.com>
+To: intel-gfx@lists.freedesktop.org
+Date: Thu, 27 Sep 2018 13:57:31 -0700
+
+Commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check,
+unconditionally during long pulse"")' applies a work around for sinks
+that don't signal link loss. The work around does not need to have to be
+that broad as the issue was seen with only one particular monitor; limit
+this only for external displays as eDP features like PSR turn off the link
+and the driver ends up retraining the link seeeing that link is not
+synchronized.
+
+Cc: Lyude Paul <lyude@redhat.com>
+Cc: Jan-Marek Glogowski <glogow@fbihome.de>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")
+Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+---
+ drivers/gpu/drm/i915/intel_dp.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
+index 207b3ea2ed1a..4e0870f3a4a5 100644
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -5072,12 +5072,13 @@ intel_dp_long_pulse(struct intel_connector *connector,
+ 		 */
+ 		status = connector_status_disconnected;
+ 		goto out;
+-	} else {
+-		/*
+-		 * Some external monitors do not signal loss of link
+-		 * synchronization with an IRQ_HPD, so force a link status
+-		 * check.
+-		 */
++	}
++
++	/*
++	 * Some external monitors do not signal loss of link synchronization
++	 * with an IRQ_HPD, so force a link status check.
++	 */
++	if (!intel_dp_is_edp(intel_dp)) {
+ 		struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ 
+ 		intel_dp_retrain_link(encoder, ctx);

CVE-2017-7645.patch

@@ -1,180 +0,0 @@
-From: "J. Bruce Fields" <bfields@redhat.com>
-Date:       2017-04-14 15:04:40
-Subject:    [PATCH] nfsd: check for oversized NFSv2/v3 arguments
-
-A client can append random data to the end of an NFSv2 or NFSv3 RPC call
-without our complaining; we'll just stop parsing at the end of the
-expected data and ignore the rest.
-
-Encoded arguments and replies are stored together in an array of pages,
-and if a call is too large it could leave inadequate space for the
-reply.  This is normally OK because NFS RPC's typically have either
-short arguments and long replies (like READ) or long arguments and short
-replies (like WRITE).  But a client that sends an incorrectly long reply
-can violate those assumptions.  This was observed to cause crashes.
-
-So, insist that the argument not be any longer than we expect.
-
-Also, several operations increment rq_next_page in the decode routine
-before checking the argument size, which can leave rq_next_page pointing
-well past the end of the page array, causing trouble later in
-svc_free_pages.
-
-As followup we may also want to rewrite the encoding routines to check
-more carefully that they aren't running off the end of the page array.
-
-Reported-by: Tuomas Haanpää <thaan@synopsys.com>
-Reported-by: Ari Kauppi <ari@synopsys.com>
-Cc: stable@vger.kernel.org
-Signed-off-by: J. Bruce Fields <bfields@redhat.com>
----
- fs/nfsd/nfs3xdr.c          | 23 +++++++++++++++++------
- fs/nfsd/nfsxdr.c           | 13 ++++++++++---
- include/linux/sunrpc/svc.h |  3 +--
- 3 files changed, 28 insertions(+), 11 deletions(-)
-
-diff --git a/fs/nfsd/nfs3xdr.c b/fs/nfsd/nfs3xdr.c
-index dba2ff8eaa68..be66bcadfaea 100644
---- a/fs/nfsd/nfs3xdr.c
-+++ b/fs/nfsd/nfs3xdr.c
-@@ -334,8 +334,11 @@ nfs3svc_decode_readargs(struct svc_rqst *rqstp, __be32 *p,
- 	if (!p)
- 		return 0;
- 	p = xdr_decode_hyper(p, &args->offset);
--
- 	args->count = ntohl(*p++);
-+
-+	if (!xdr_argsize_check(rqstp, p))
-+		return 0;
-+
- 	len = min(args->count, max_blocksize);
- 
- 	/* set up the kvec */
-@@ -349,7 +352,7 @@ nfs3svc_decode_readargs(struct svc_rqst *rqstp, __be32 *p,
- 		v++;
- 	}
- 	args->vlen = v;
--	return xdr_argsize_check(rqstp, p);
-+	return 1;
- }
- 
- int
-@@ -536,9 +539,11 @@ nfs3svc_decode_readlinkargs(struct svc_rqst *rqstp, __be32 *p,
- 	p = decode_fh(p, &args->fh);
- 	if (!p)
- 		return 0;
-+	if (!xdr_argsize_check(rqstp, p))
-+		return 0;
- 	args->buffer = page_address(*(rqstp->rq_next_page++));
- 
--	return xdr_argsize_check(rqstp, p);
-+	return 1;
- }
- 
- int
-@@ -564,10 +569,14 @@ nfs3svc_decode_readdirargs(struct svc_rqst *rqstp, __be32 *p,
- 	args->verf   = p; p += 2;
- 	args->dircount = ~0;
- 	args->count  = ntohl(*p++);
-+
-+	if (!xdr_argsize_check(rqstp, p))
-+		return 0;
-+
- 	args->count  = min_t(u32, args->count, PAGE_SIZE);
- 	args->buffer = page_address(*(rqstp->rq_next_page++));
- 
--	return xdr_argsize_check(rqstp, p);
-+	return 1;
- }
- 
- int
-@@ -585,6 +594,9 @@ nfs3svc_decode_readdirplusargs(struct svc_rqst *rqstp, __be32 *p,
- 	args->dircount = ntohl(*p++);
- 	args->count    = ntohl(*p++);
- 
-+	if (!xdr_argsize_check(rqstp, p))
-+		return 0;
-+
- 	len = args->count = min(args->count, max_blocksize);
- 	while (len > 0) {
- 		struct page *p = *(rqstp->rq_next_page++);
-@@ -592,8 +604,7 @@ nfs3svc_decode_readdirplusargs(struct svc_rqst *rqstp, __be32 *p,
- 			args->buffer = page_address(p);
- 		len -= PAGE_SIZE;
- 	}
--
--	return xdr_argsize_check(rqstp, p);
-+	return 1;
- }
- 
- int
-diff --git a/fs/nfsd/nfsxdr.c b/fs/nfsd/nfsxdr.c
-index 41b468a6a90f..79268369f7b3 100644
---- a/fs/nfsd/nfsxdr.c
-+++ b/fs/nfsd/nfsxdr.c
-@@ -257,6 +257,9 @@ nfssvc_decode_readargs(struct svc_rqst *rqstp, __be32 *p,
- 	len = args->count     = ntohl(*p++);
- 	p++; /* totalcount - unused */
- 
-+	if (!xdr_argsize_check(rqstp, p))
-+		return 0;
-+
- 	len = min_t(unsigned int, len, NFSSVC_MAXBLKSIZE_V2);
- 
- 	/* set up somewhere to store response.
-@@ -272,7 +275,7 @@ nfssvc_decode_readargs(struct svc_rqst *rqstp, __be32 *p,
- 		v++;
- 	}
- 	args->vlen = v;
--	return xdr_argsize_check(rqstp, p);
-+	return 1;
- }
- 
- int
-@@ -360,9 +363,11 @@ nfssvc_decode_readlinkargs(struct svc_rqst *rqstp, __be32 *p, struct nfsd_readli
- 	p = decode_fh(p, &args->fh);
- 	if (!p)
- 		return 0;
-+	if (!xdr_argsize_check(rqstp, p))
-+		return 0;
- 	args->buffer = page_address(*(rqstp->rq_next_page++));
- 
--	return xdr_argsize_check(rqstp, p);
-+	return 1;
- }
- 
- int
-@@ -400,9 +405,11 @@ nfssvc_decode_readdirargs(struct svc_rqst *rqstp, __be32 *p,
- 	args->cookie = ntohl(*p++);
- 	args->count  = ntohl(*p++);
- 	args->count  = min_t(u32, args->count, PAGE_SIZE);
-+	if (!xdr_argsize_check(rqstp, p))
-+		return 0;
- 	args->buffer = page_address(*(rqstp->rq_next_page++));
- 
--	return xdr_argsize_check(rqstp, p);
-+	return 1;
- }
- 
- /*
-diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
-index e770abeed32d..6ef19cf658b4 100644
---- a/include/linux/sunrpc/svc.h
-+++ b/include/linux/sunrpc/svc.h
-@@ -336,8 +336,7 @@ xdr_argsize_check(struct svc_rqst *rqstp, __be32 *p)
- {
- 	char *cp = (char *)p;
- 	struct kvec *vec = &rqstp->rq_arg.head[0];
--	return cp >= (char*)vec->iov_base
--		&& cp <= (char*)vec->iov_base + vec->iov_len;
-+	return cp == (char *)vec->iov_base + vec->iov_len;
- }
- 
- static inline int
--- 
-2.9.3
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html

KEYS-don-t-let-add_key-update-an-uninstantiated-key.patch

@@ -1,130 +0,0 @@
-From 7289bfaee2a42bdb56eecab0625907c045d080ba Mon Sep 17 00:00:00 2001
-From: Eric Biggers <ebiggers@google.com>
-Date: Wed, 27 Sep 2017 12:50:41 -0700
-Subject: [PATCH] KEYS: don't let add_key() update an uninstantiated key
-
-Currently, add_key() will, when passed a key that already exists, call
-the key's ->update() method.  But this is heavily broken in the case
-where the key is uninstantiated because it doesn't call
-__key_instantiate_and_link().  Consequently, it doesn't do most of the
-things that are supposed to happen when the key is instantiated, such as
-setting KEY_FLAG_INSTANTIATED, clearing KEY_FLAG_USER_CONSTRUCT and
-awakening tasks waiting on it, and incrementing key->user->nikeys.
-
-It also never takes key_construction_mutex, which means that
-->instantiate() can run concurrently with ->update() on the same key.
-In the case of the "user" and "logon" key types this causes a memory
-leak, at best.  Maybe even worse, the ->update() methods of the
-"encrypted" and "trusted" key types actually just dereference a NULL
-pointer when passed an uninstantiated key.
-
-Therefore, change find_key_to_update() to return NULL if the found key
-is uninstantiated, so that add_key() replaces the key rather than
-instantiating it.  This seems to be better than fixing __key_update() to
-call __key_instantiate_and_link(), since given all the bugs noted above
-as well as that the existing behavior was undocumented and
-keyctl_instantiate() is supposed to be used instead, I doubt anyone was
-relying on the existing behavior.
-
-This patch only affects *uninstantiated* keys.  For now we still allow a
-negatively instantiated key to be updated (thereby positively
-instantiating it), although that's broken too (the next patch fixes it)
-and I'm not sure that anyone actually uses that functionality either.
-
-Here is a simple reproducer for the bug using the "encrypted" key type
-(requires CONFIG_ENCRYPTED_KEYS=y), though as noted above the bug
-pertained to more than just the "encrypted" key type:
-
-    #include <stdlib.h>
-    #include <unistd.h>
-    #include <keyutils.h>
-
-    int main(void)
-    {
-        int ringid = keyctl_join_session_keyring(NULL);
-
-        if (fork()) {
-            for (;;) {
-                const char payload[] = "update user:foo 32";
-
-                usleep(rand() % 10000);
-                add_key("encrypted", "desc", payload, sizeof(payload), ringid);
-                keyctl_clear(ringid);
-            }
-        } else {
-            for (;;)
-                request_key("encrypted", "desc", "callout_info", ringid);
-        }
-    }
-
-It causes:
-
-    BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
-    IP: encrypted_update+0xb0/0x170
-    PGD 7a178067 P4D 7a178067 PUD 77269067 PMD 0
-    PREEMPT SMP
-    CPU: 0 PID: 340 Comm: reproduce Tainted: G      D         4.14.0-rc1-00025-g428490e38b2e #796
-    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
-    task: ffff8a467a39a340 task.stack: ffffb15c40770000
-    RIP: 0010:encrypted_update+0xb0/0x170
-    RSP: 0018:ffffb15c40773de8 EFLAGS: 00010246
-    RAX: 0000000000000000 RBX: ffff8a467a275b00 RCX: 0000000000000000
-    RDX: 0000000000000005 RSI: ffff8a467a275b14 RDI: ffffffffb742f303
-    RBP: ffffb15c40773e20 R08: 0000000000000000 R09: ffff8a467a275b17
-    R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000
-    R13: 0000000000000000 R14: ffff8a4677057180 R15: ffff8a467a275b0f
-    FS:  00007f5d7fb08700(0000) GS:ffff8a467f200000(0000) knlGS:0000000000000000
-    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
-    CR2: 0000000000000018 CR3: 0000000077262005 CR4: 00000000001606f0
-    Call Trace:
-     key_create_or_update+0x2bc/0x460
-     SyS_add_key+0x10c/0x1d0
-     entry_SYSCALL_64_fastpath+0x1f/0xbe
-    RIP: 0033:0x7f5d7f211259
-    RSP: 002b:00007ffed03904c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
-    RAX: ffffffffffffffda RBX: 000000003b2a7955 RCX: 00007f5d7f211259
-    RDX: 00000000004009e4 RSI: 00000000004009ff RDI: 0000000000400a04
-    RBP: 0000000068db8bad R08: 000000003b2a7955 R09: 0000000000000004
-    R10: 000000000000001a R11: 0000000000000246 R12: 0000000000400868
-    R13: 00007ffed03905d0 R14: 0000000000000000 R15: 0000000000000000
-    Code: 77 28 e8 64 34 1f 00 45 31 c0 31 c9 48 8d 55 c8 48 89 df 48 8d 75 d0 e8 ff f9 ff ff 85 c0 41 89 c4 0f 88 84 00 00 00 4c 8b 7d c8 <49> 8b 75 18 4c 89 ff e8 24 f8 ff ff 85 c0 41 89 c4 78 6d 49 8b
-    RIP: encrypted_update+0xb0/0x170 RSP: ffffb15c40773de8
-    CR2: 0000000000000018
-
-Cc: <stable@vger.kernel.org>    [v2.6.12+]
-Signed-off-by: Eric Biggers <ebiggers@google.com>
----
- security/keys/keyring.c | 10 ++++++----
- 1 file changed, 6 insertions(+), 4 deletions(-)
-
-diff --git a/security/keys/keyring.c b/security/keys/keyring.c
-index 4fa82a8a9c0e..129a4175760b 100644
---- a/security/keys/keyring.c
-+++ b/security/keys/keyring.c
-@@ -1056,8 +1056,8 @@ EXPORT_SYMBOL(keyring_restrict);
-  * caller must also hold a lock on the keyring semaphore.
-  *
-  * Returns a pointer to the found key with usage count incremented if
-- * successful and returns NULL if not found.  Revoked and invalidated keys are
-- * skipped over.
-+ * successful and returns NULL if not found.  Revoked, invalidated, and
-+ * uninstantiated keys are skipped over.  (But negative keys are not!)
-  *
-  * If successful, the possession indicator is propagated from the keyring ref
-  * to the returned key reference.
-@@ -1084,8 +1084,10 @@ key_ref_t find_key_to_update(key_ref_t keyring_ref,
- 
- found:
- 	key = keyring_ptr_to_key(object);
--	if (key->flags & ((1 << KEY_FLAG_INVALIDATED) |
--			  (1 << KEY_FLAG_REVOKED))) {
-+	if ((key->flags & ((1 << KEY_FLAG_INVALIDATED) |
-+			   (1 << KEY_FLAG_REVOKED) |
-+			   (1 << KEY_FLAG_INSTANTIATED))) !=
-+	    (1 << KEY_FLAG_INSTANTIATED)) {
- 		kleave(" = NULL [x]");
- 		return NULL;
- 	}
--- 
-2.13.6
-

arm-clk-bcm2835-hdmi-fixes.patch

@@ -1,175 +0,0 @@
-From patchwork Thu Feb  8 13:43:35 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [1/4] clk: bcm2835: Fix ana->maskX definitions
-From: Boris Brezillon <boris.brezillon@bootlin.com>
-X-Patchwork-Id: 10207161
-Message-Id: <20180208134338.24590-1-boris.brezillon@bootlin.com>
-To: Florian Fainelli <f.fainelli@gmail.com>, Ray Jui <rjui@broadcom.com>,
- Scott Branden <sbranden@broadcom.com>,
- bcm-kernel-feedback-list@broadcom.com,
- Stephen Warren <swarren@wwwdotorg.org>,
- Lee Jones <lee@kernel.org>, Eric Anholt <eric@anholt.net>,
- linux-rpi-kernel@lists.infradead.org,
- Mike Turquette <mturquette@baylibre.com>,
- Stephen Boyd <sboyd@codeaurora.org>, linux-clk@vger.kernel.org
-Cc: Boris Brezillon <boris.brezillon@bootlin.com>, stable@vger.kernel.org
-Date: Thu,  8 Feb 2018 14:43:35 +0100
-
-ana->maskX values are already '~'-ed in bcm2835_pll_set_rate(). Remove
-the '~' in the definition to fix ANA setup.
-
-Note that this commit fixes a long standing bug preventing one from
-using an HDMI display if it's plugged after the FW has booted Linux.
-This is because PLLH is used by the HDMI encoder to generate the pixel
-clock.
-
-Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
-Reviewed-by: Eric Anholt <eric@anholt.net>
----
- drivers/clk/bcm/clk-bcm2835.c | 8 ++++----
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
-index 44301a3d9963..2108a274185a 100644
---- a/drivers/clk/bcm/clk-bcm2835.c
-+++ b/drivers/clk/bcm/clk-bcm2835.c
-@@ -449,17 +449,17 @@ struct bcm2835_pll_ana_bits {
- static const struct bcm2835_pll_ana_bits bcm2835_ana_default = {
- 	.mask0 = 0,
- 	.set0 = 0,
--	.mask1 = (u32)~(A2W_PLL_KI_MASK | A2W_PLL_KP_MASK),
-+	.mask1 = A2W_PLL_KI_MASK | A2W_PLL_KP_MASK,
- 	.set1 = (2 << A2W_PLL_KI_SHIFT) | (8 << A2W_PLL_KP_SHIFT),
--	.mask3 = (u32)~A2W_PLL_KA_MASK,
-+	.mask3 = A2W_PLL_KA_MASK,
- 	.set3 = (2 << A2W_PLL_KA_SHIFT),
- 	.fb_prediv_mask = BIT(14),
- };
- 
- static const struct bcm2835_pll_ana_bits bcm2835_ana_pllh = {
--	.mask0 = (u32)~(A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK),
-+	.mask0 = A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK,
- 	.set0 = (2 << A2W_PLLH_KA_SHIFT) | (2 << A2W_PLLH_KI_LOW_SHIFT),
--	.mask1 = (u32)~(A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK),
-+	.mask1 = A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK,
- 	.set1 = (6 << A2W_PLLH_KP_SHIFT),
- 	.mask3 = 0,
- 	.set3 = 0,
-From patchwork Thu Feb  8 13:43:36 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [2/4] clk: bcm2835: Protect sections updating shared registers
-From: Boris Brezillon <boris.brezillon@bootlin.com>
-X-Patchwork-Id: 10207155
-Message-Id: <20180208134338.24590-2-boris.brezillon@bootlin.com>
-To: Florian Fainelli <f.fainelli@gmail.com>, Ray Jui <rjui@broadcom.com>,
- Scott Branden <sbranden@broadcom.com>,
- bcm-kernel-feedback-list@broadcom.com,
- Stephen Warren <swarren@wwwdotorg.org>,
- Lee Jones <lee@kernel.org>, Eric Anholt <eric@anholt.net>,
- linux-rpi-kernel@lists.infradead.org,
- Mike Turquette <mturquette@baylibre.com>,
- Stephen Boyd <sboyd@codeaurora.org>, linux-clk@vger.kernel.org
-Cc: Boris Brezillon <boris.brezillon@bootlin.com>, stable@vger.kernel.org
-Date: Thu,  8 Feb 2018 14:43:36 +0100
-
-CM_PLLx and A2W_XOSC_CTRL registers are accessed by different clock
-handlers and must be accessed with ->regs_lock held.
-Update the sections where this protection is missing.
-
-Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
-Reviewed-by: Eric Anholt <eric@anholt.net>
----
- drivers/clk/bcm/clk-bcm2835.c | 4 ++++
- 1 file changed, 4 insertions(+)
-
-diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
-index 2108a274185a..a07f6451694a 100644
---- a/drivers/clk/bcm/clk-bcm2835.c
-+++ b/drivers/clk/bcm/clk-bcm2835.c
-@@ -623,8 +623,10 @@ static int bcm2835_pll_on(struct clk_hw *hw)
- 		     ~A2W_PLL_CTRL_PWRDN);
- 
- 	/* Take the PLL out of reset. */
-+	spin_lock(&cprman->regs_lock);
- 	cprman_write(cprman, data->cm_ctrl_reg,
- 		     cprman_read(cprman, data->cm_ctrl_reg) & ~CM_PLL_ANARST);
-+	spin_unlock(&cprman->regs_lock);
- 
- 	/* Wait for the PLL to lock. */
- 	timeout = ktime_add_ns(ktime_get(), LOCK_TIMEOUT_NS);
-@@ -701,9 +703,11 @@ static int bcm2835_pll_set_rate(struct clk_hw *hw,
- 	}
- 
- 	/* Unmask the reference clock from the oscillator. */
-+	spin_lock(&cprman->regs_lock);
- 	cprman_write(cprman, A2W_XOSC_CTRL,
- 		     cprman_read(cprman, A2W_XOSC_CTRL) |
- 		     data->reference_enable_mask);
-+	spin_unlock(&cprman->regs_lock);
- 
- 	if (do_ana_setup_first)
- 		bcm2835_pll_write_ana(cprman, data->ana_reg_base, ana);
-From patchwork Thu Feb  8 13:43:37 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [3/4] clk: bcm2835: De-assert/assert PLL reset signal when appropriate
-From: Boris Brezillon <boris.brezillon@bootlin.com>
-X-Patchwork-Id: 10207157
-Message-Id: <20180208134338.24590-3-boris.brezillon@bootlin.com>
-To: Florian Fainelli <f.fainelli@gmail.com>, Ray Jui <rjui@broadcom.com>,
- Scott Branden <sbranden@broadcom.com>,
- bcm-kernel-feedback-list@broadcom.com,
- Stephen Warren <swarren@wwwdotorg.org>,
- Lee Jones <lee@kernel.org>, Eric Anholt <eric@anholt.net>,
- linux-rpi-kernel@lists.infradead.org,
- Mike Turquette <mturquette@baylibre.com>,
- Stephen Boyd <sboyd@codeaurora.org>, linux-clk@vger.kernel.org
-Cc: Boris Brezillon <boris.brezillon@bootlin.com>, stable@vger.kernel.org
-Date: Thu,  8 Feb 2018 14:43:37 +0100
-
-In order to enable a PLL, not only the PLL has to be powered up and
-locked, but you also have to de-assert the reset signal. The last part
-was missing. Add it so PLLs that were not enabled by the FW/bootloader
-can be enabled from Linux.
-
-Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
----
- drivers/clk/bcm/clk-bcm2835.c | 7 +++++++
- 1 file changed, 7 insertions(+)
-
-diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
-index a07f6451694a..6c5d4a8e426c 100644
---- a/drivers/clk/bcm/clk-bcm2835.c
-+++ b/drivers/clk/bcm/clk-bcm2835.c
-@@ -602,6 +602,9 @@ static void bcm2835_pll_off(struct clk_hw *hw)
- 	const struct bcm2835_pll_data *data = pll->data;
- 
- 	spin_lock(&cprman->regs_lock);
-+	cprman_write(cprman, data->a2w_ctrl_reg,
-+		     cprman_read(cprman, data->a2w_ctrl_reg) &
-+		     ~A2W_PLL_CTRL_PRST_DISABLE);
- 	cprman_write(cprman, data->cm_ctrl_reg,
- 		     cprman_read(cprman, data->cm_ctrl_reg) |
- 		     CM_PLL_ANARST);
-@@ -640,6 +643,10 @@ static int bcm2835_pll_on(struct clk_hw *hw)
- 		cpu_relax();
- 	}
- 
-+	cprman_write(cprman, data->a2w_ctrl_reg,
-+		     cprman_read(cprman, data->a2w_ctrl_reg) |
-+		     A2W_PLL_CTRL_PRST_DISABLE);
-+
- 	return 0;
- }
- 

arm-crypto-sunxi-ss-Add-MODULE_ALIAS-to-sun4i-ss.patch

@@ -1,28 +0,0 @@
-From 7a2e67bfa5316e267e782477ec880e2464fd682a Mon Sep 17 00:00:00 2001
-From: Peter Robinson <pbrobinson@gmail.com>
-Date: Sun, 11 Feb 2018 21:28:41 +0000
-Subject: [PATCH] crypto: sunxi-ss: Add MODULE_ALIAS to sun4i-ss
-
-The MODULE_ALIAS is required to enable the sun4i-ss driver to load
-automatically when built at a module. Tested on a Cubietruck.
-
-Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
----
- drivers/crypto/sunxi-ss/sun4i-ss-core.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
-index 1547cbe13dc2..a81d89b3b7d8 100644
---- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
-+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
-@@ -451,6 +451,7 @@ static struct platform_driver sun4i_ss_driver = {
- 
- module_platform_driver(sun4i_ss_driver);
- 
-+MODULE_ALIAS("platform:sun4i-ss");
- MODULE_DESCRIPTION("Allwinner Security System cryptographic accelerator");
- MODULE_LICENSE("GPL");
- MODULE_AUTHOR("Corentin LABBE <clabbe.montjoie@gmail.com>");
--- 
-2.14.3
-

arm-dts-imx6qdl-udoo-Disable-usbh1-to-avoid-kernel-hang.patch

@@ -1,41 +0,0 @@
-From patchwork Thu Jan 18 12:34:18 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: ARM: dts: imx6qdl-udoo: Disable usbh1 to avoid kernel hang
-From: Fabio Estevam <fabio.estevam@nxp.com>
-X-Patchwork-Id: 10173115
-Message-Id: <1516278858-15464-1-git-send-email-fabio.estevam@nxp.com>
-To: <shawnguo@kernel.org>
-Cc: maggu2810@gmail.com, peter.chen@nxp.com, mail@maciej.szmigiero.name,
- Fabio Estevam <fabio.estevam@nxp.com>, linux-arm-kernel@lists.infradead.org
-Date: Thu, 18 Jan 2018 10:34:18 -0200
-
-Currently the kernel hangs when USB Host1 is enabled due to the lack of
-support for controlling the USB hub clock and GPIO reset line.
-
-Peter Chen has made several attempts to fix this problem, but his series
-has not been applied yet, so better disable USB host1 for now to avoid
-the kernel hang.
-
-Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
-Acked-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
-Tested-by: Markus Rathgeb <maggu2810@gmail.com>
----
- arch/arm/boot/dts/imx6qdl-udoo.dtsi | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
-index 4161b7d..1f0b9f6 100644
---- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
-+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
-@@ -274,7 +274,8 @@
- 	pinctrl-0 = <&pinctrl_usbh>;
- 	vbus-supply = <&reg_usb_h1_vbus>;
- 	clocks = <&clks IMX6QDL_CLK_CKO>;
--	status = "okay";
-+	/* currently USB support causes a kernel hang. Disable it for now */
-+	status = "disabled";
- };
- 
- &usdhc3 {

arm-revert-mmc-omap_hsmmc-Use-dma_request_chan-for-reque.patch

@@ -1,100 +0,0 @@
-From bb3e08008c0e48fd4f51a0f0957eecae61a24d69 Mon Sep 17 00:00:00 2001
-From: Peter Robinson <pbrobinson@gmail.com>
-Date: Tue, 1 Nov 2016 09:35:30 +0000
-Subject: [PATCH] Revert "mmc: omap_hsmmc: Use dma_request_chan() for
- requesting DMA channel"
-
-This reverts commit 81eef6ca92014845d40e3f1310e42b7010303acc.
----
- drivers/mmc/host/omap_hsmmc.c | 50 ++++++++++++++++++++++++++++++++++---------
- 1 file changed, 40 insertions(+), 10 deletions(-)
-
-diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
-index 24ebc9a..3563321 100644
---- a/drivers/mmc/host/omap_hsmmc.c
-+++ b/drivers/mmc/host/omap_hsmmc.c
-@@ -32,6 +32,7 @@
- #include <linux/of_irq.h>
- #include <linux/of_gpio.h>
- #include <linux/of_device.h>
-+#include <linux/omap-dmaengine.h>
- #include <linux/mmc/host.h>
- #include <linux/mmc/core.h>
- #include <linux/mmc/mmc.h>
-@@ -1992,6 +1993,8 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
- 	struct resource *res;
- 	int ret, irq;
- 	const struct of_device_id *match;
-+	dma_cap_mask_t mask;
-+	unsigned tx_req, rx_req;
- 	const struct omap_mmc_of_data *data;
- 	void __iomem *base;
- 
-@@ -2121,17 +2124,44 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
- 
- 	omap_hsmmc_conf_bus_power(host);
- 
--	host->rx_chan = dma_request_chan(&pdev->dev, "rx");
--	if (IS_ERR(host->rx_chan)) {
--		dev_err(mmc_dev(host->mmc), "RX DMA channel request failed\n");
--		ret = PTR_ERR(host->rx_chan);
-+	if (!pdev->dev.of_node) {
-+		res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
-+		if (!res) {
-+			dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
-+			ret = -ENXIO;
-+			goto err_irq;
-+		}
-+		tx_req = res->start;
-+
-+		res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
-+		if (!res) {
-+			dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
-+			ret = -ENXIO;
-+			goto err_irq;
-+		}
-+		rx_req = res->start;
-+	}
-+
-+	dma_cap_zero(mask);
-+	dma_cap_set(DMA_SLAVE, mask);
-+
-+	host->rx_chan =
-+		dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-+						 &rx_req, &pdev->dev, "rx");
-+
-+	if (!host->rx_chan) {
-+		dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel\n");
-+		ret = -ENXIO;
- 		goto err_irq;
- 	}
- 
--	host->tx_chan = dma_request_chan(&pdev->dev, "tx");
--	if (IS_ERR(host->tx_chan)) {
--		dev_err(mmc_dev(host->mmc), "TX DMA channel request failed\n");
--		ret = PTR_ERR(host->tx_chan);
-+	host->tx_chan =
-+		dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-+						 &tx_req, &pdev->dev, "tx");
-+
-+	if (!host->tx_chan) {
-+		dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel\n");
-+		ret = -ENXIO;
- 		goto err_irq;
- 	}
- 
-@@ -2189,9 +2219,9 @@ err_slot_name:
- 	mmc_remove_host(mmc);
- err_irq:
- 	device_init_wakeup(&pdev->dev, false);
--	if (!IS_ERR_OR_NULL(host->tx_chan))
-+	if (host->tx_chan)
- 		dma_release_channel(host->tx_chan);
--	if (!IS_ERR_OR_NULL(host->rx_chan))
-+	if (host->rx_chan)
- 		dma_release_channel(host->rx_chan);
- 	pm_runtime_dont_use_autosuspend(host->dev);
- 	pm_runtime_put_sync(host->dev);
--- 
-2.9.3
-

arm-sdhci-esdhc-imx-fixes.patch

@@ -0,0 +1,172 @@
+From patchwork Thu Jun 28 07:31:36 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: mmc: sdhci-esdhc-imx: support eMMC DDR mode when running at 3.3V
+From: Stefan Agner <stefan@agner.ch>
+X-Patchwork-Id: 10493185
+Message-Id: <20180628073136.21748-1-stefan@agner.ch>
+To: adrian.hunter@intel.com, ulf.hansson@linaro.org
+Cc: fabio.estevam@nxp.com, haibo.chen@nxp.com, aisheng.dong@nxp.com,
+ michael@amarulasolutions.com, linux-mmc@vger.kernel.org,
+ linux-kernel@vger.kernel.org, Stefan Agner <stefan@agner.ch>
+Date: Thu, 28 Jun 2018 09:31:36 +0200
+
+The uSDHC supports DDR modes for eMMC devices running at 3.3V. This
+allows to run eMMC with 3.3V signaling voltage at DDR52 mode:
+
+  # cat /sys/kernel/debug/mmc1/ios
+  clock:          52000000 Hz
+  vdd:            21 (3.3 ~ 3.4 V)
+  bus mode:       2 (push-pull)
+  chip select:    0 (don't care)
+  power mode:     2 (on)
+  bus width:      3 (8 bits)
+  timing spec:    8 (mmc DDR52)
+  signal voltage: 0 (3.30 V)
+  driver type:    0 (driver type B)
+
+Signed-off-by: Stefan Agner <stefan@agner.ch>
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
+index b716b933f00a..6f444731754d 100644
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -1324,7 +1324,7 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
+ 
+ 	if (esdhc_is_usdhc(imx_data)) {
+ 		host->quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN;
+-		host->mmc->caps |= MMC_CAP_1_8V_DDR;
++		host->mmc->caps |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
+ 		if (!(imx_data->socdata->flags & ESDHC_FLAG_HS200))
+ 			host->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
+ 
+From patchwork Thu Jun 28 08:13:29 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [1/3] mmc: sdhci-esdhc-imx: get rid of support_vsel
+From: Stefan Agner <stefan@agner.ch>
+X-Patchwork-Id: 10493269
+Message-Id: <20180628081331.13051-2-stefan@agner.ch>
+To: adrian.hunter@intel.com, ulf.hansson@linaro.org
+Cc: fabio.estevam@nxp.com, haibo.chen@nxp.com, aisheng.dong@nxp.com,
+ michael@amarulasolutions.com, rmk+kernel@armlinux.org.uk,
+ linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
+ Stefan Agner <stefan@agner.ch>
+Date: Thu, 28 Jun 2018 10:13:29 +0200
+
+The field support_vsel is currently only used in the device tree
+case. Get rid of it. No change in behavior.
+
+Signed-off-by: Stefan Agner <stefan@agner.ch>
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c          | 8 ++------
+ include/linux/platform_data/mmc-esdhc-imx.h | 2 --
+ 2 files changed, 2 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
+index 6f444731754d..20a420b765b3 100644
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -1145,18 +1145,14 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
+ 			     &boarddata->tuning_start_tap);
+ 
+ 	if (of_find_property(np, "no-1-8-v", NULL))
+-		boarddata->support_vsel = false;
+-	else
+-		boarddata->support_vsel = true;
++		host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
+ 
+ 	if (of_property_read_u32(np, "fsl,delay-line", &boarddata->delay_line))
+ 		boarddata->delay_line = 0;
+ 
+ 	mmc_of_parse_voltage(np, &host->ocr_mask);
+ 
+-	/* sdr50 and sdr104 need work on 1.8v signal voltage */
+-	if ((boarddata->support_vsel) && esdhc_is_usdhc(imx_data) &&
+-	    !IS_ERR(imx_data->pins_default)) {
++	if (esdhc_is_usdhc(imx_data) && !IS_ERR(imx_data->pins_default)) {
+ 		imx_data->pins_100mhz = pinctrl_lookup_state(imx_data->pinctrl,
+ 						ESDHC_PINCTRL_STATE_100MHZ);
+ 		imx_data->pins_200mhz = pinctrl_lookup_state(imx_data->pinctrl,
+diff --git a/include/linux/platform_data/mmc-esdhc-imx.h b/include/linux/platform_data/mmc-esdhc-imx.h
+index 7daa78a2f342..640dec8b5b0c 100644
+--- a/include/linux/platform_data/mmc-esdhc-imx.h
++++ b/include/linux/platform_data/mmc-esdhc-imx.h
+@@ -34,7 +34,6 @@ enum cd_types {
+  * @cd_gpio:	gpio for card_detect interrupt
+  * @wp_type:	type of write_protect method (see wp_types enum above)
+  * @cd_type:	type of card_detect method (see cd_types enum above)
+- * @support_vsel:  indicate it supports 1.8v switching
+  */
+ 
+ struct esdhc_platform_data {
+@@ -43,7 +42,6 @@ struct esdhc_platform_data {
+ 	enum wp_types wp_type;
+ 	enum cd_types cd_type;
+ 	int max_bus_width;
+-	bool support_vsel;
+ 	unsigned int delay_line;
+ 	unsigned int tuning_step;       /* The delay cell steps in tuning procedure */
+ 	unsigned int tuning_start_tap;	/* The start delay cell point in tuning procedure */
+From patchwork Thu Jun 28 08:13:30 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [2/3] mmc: sdhci: add quirk to prevent higher speed modes
+From: Stefan Agner <stefan@agner.ch>
+X-Patchwork-Id: 10493273
+Message-Id: <20180628081331.13051-3-stefan@agner.ch>
+To: adrian.hunter@intel.com, ulf.hansson@linaro.org
+Cc: fabio.estevam@nxp.com, haibo.chen@nxp.com, aisheng.dong@nxp.com,
+ michael@amarulasolutions.com, rmk+kernel@armlinux.org.uk,
+ linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
+ Stefan Agner <stefan@agner.ch>
+Date: Thu, 28 Jun 2018 10:13:30 +0200
+
+Some hosts are capable of running higher speed modes but do not
+have the board support for it. Introduce a quirk which prevents
+the stack from using modes running at 100MHz or faster.
+
+Signed-off-by: Stefan Agner <stefan@agner.ch>
+---
+ drivers/mmc/host/sdhci.c | 8 ++++++++
+ drivers/mmc/host/sdhci.h | 2 ++
+ 2 files changed, 10 insertions(+)
+
+diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
+index 1c828e0e9905..8ac257dfaab3 100644
+--- a/drivers/mmc/host/sdhci.c
++++ b/drivers/mmc/host/sdhci.c
+@@ -3749,6 +3749,14 @@ int sdhci_setup_host(struct sdhci_host *host)
+ 		}
+ 	}
+ 
++	if (host->quirks2 & SDHCI_QUIRK2_NO_UHS_HS200_HS400) {
++		host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
++				 SDHCI_SUPPORT_DDR50);
++
++		mmc->caps2 &= ~(MMC_CAP2_HSX00_1_8V | MMC_CAP2_HSX00_1_2V |
++				MMC_CAP2_HS400_ES);
++	}
++
+ 	if (host->quirks2 & SDHCI_QUIRK2_NO_1_8_V) {
+ 		host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
+ 				 SDHCI_SUPPORT_DDR50);
+diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
+index 23966f887da6..cb2433d6d61f 100644
+--- a/drivers/mmc/host/sdhci.h
++++ b/drivers/mmc/host/sdhci.h
+@@ -450,6 +450,8 @@ struct sdhci_host {
+  * obtainable timeout.
+  */
+ #define SDHCI_QUIRK2_DISABLE_HW_TIMEOUT			(1<<17)
++/* Do not support any higher speeds (>50MHz) */
++#define SDHCI_QUIRK2_NO_UHS_HS200_HS400			(1<<18)
+ 
+ 	int irq;		/* Device IRQ */
+ 	void __iomem *ioaddr;	/* Mapped address */

arm64-Revert-allwinner-a64-pine64-Use-dcdc1-regulato.patch

@@ -1,41 +0,0 @@
-From 90e388ca5d8bbee022f9ed5fc24137b31579fa6e Mon Sep 17 00:00:00 2001
-From: Peter Robinson <pbrobinson@gmail.com>
-Date: Wed, 22 Nov 2017 15:52:36 +0000
-Subject: [PATCH] Revert "arm64: allwinner: a64: pine64: Use dcdc1 regulator
- for mmc0"
-
-This reverts commit 3f241bfa60bdc9c4fde63fa6664a8ce00fd668c6.
----
- arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
-diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
-index d06e34b5d192..caf8b6fbe5e3 100644
---- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
-+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
-@@ -61,6 +61,13 @@
- 	chosen {
- 		stdout-path = "serial0:115200n8";
- 	};
-+
-+	reg_vcc3v3: vcc3v3 {
-+		compatible = "regulator-fixed";
-+		regulator-name = "vcc3v3";
-+		regulator-min-microvolt = <3300000>;
-+		regulator-max-microvolt = <3300000>;
-+	};
- };
- 
- &ehci0 {
-@@ -84,7 +91,7 @@
- &mmc0 {
- 	pinctrl-names = "default";
- 	pinctrl-0 = <&mmc0_pins>;
--	vmmc-supply = <&reg_dcdc1>;
-+	vmmc-supply = <&reg_vcc3v3>;
- 	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
- 	cd-inverted;
- 	disable-wp;
--- 
-2.14.3
-

arm64-arch_timer-Workaround-for-Allwinner-A64-timer-instability.patch

@@ -0,0 +1,184 @@
+From patchwork Fri May 11 02:27:50 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 8bit
+Subject: [1/2] arm64: arch_timer: Workaround for Allwinner A64 timer
+ instability
+From: Samuel Holland <samuel@sholland.org>
+X-Patchwork-Id: 10392891
+Message-Id: <20180511022751.9096-2-samuel@sholland.org>
+To: Maxime Ripard <maxime.ripard@bootlin.com>, Chen-Yu Tsai <wens@csie.org>, 
+ Catalin Marinas <catalin.marinas@arm.com>,
+ Will Deacon <will.deacon@arm.com>,
+ Daniel Lezcano <daniel.lezcano@linaro.org>,
+ Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <marc.zyngier@arm.com>
+Cc: linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org,
+ linux-arm-kernel@lists.infradead.org, Samuel Holland <samuel@sholland.org>
+Date: Thu, 10 May 2018 21:27:50 -0500
+
+The Allwinner A64 SoC is known [1] to have an unstable architectural
+timer, which manifests itself most obviously in the time jumping forward
+a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a
+timer frequency of 24 MHz, implying that the time went slightly backward
+(and this was interpreted by the kernel as it jumping forward and
+wrapping around past the epoch).
+
+Further investigation revealed instability in the low bits of CNTVCT at
+the point a high bit rolls over. This leads to power-of-two cycle
+forward and backward jumps. (Testing shows that forward jumps are about
+twice as likely as backward jumps.)
+
+Without trapping reads to CNTVCT, a userspace program is able to read it
+in a loop faster than it changes. A test program running on all 4 CPU
+cores that reported jumps larger than 100 ms was run for 13.6 hours and
+reported the following:
+
+ Count | Event
+-------+---------------------------
+  9940 | jumped backward      699ms
+   268 | jumped backward     1398ms
+     1 | jumped backward     2097ms
+ 16020 | jumped forward       175ms
+  6443 | jumped forward       699ms
+  2976 | jumped forward      1398ms
+     9 | jumped forward    356516ms
+     9 | jumped forward    357215ms
+     4 | jumped forward    714430ms
+     1 | jumped forward   3578440ms
+
+This works out to a jump larger than 100 ms about every 5.5 seconds on
+each CPU core.
+
+The largest jump (almost an hour!) was the following sequence of reads:
+      0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
+
+Note that the middle bits don't necessarily all read as all zeroes or
+all ones during the anomalous behavior; however the low 11 bits checked
+by the function in this patch have never been observed with any other
+value.
+
+Also note that smaller jumps are much more common, with the smallest
+backward jumps of 2048 cycles observed over 400 times per second on each
+core. (Of course, this is partially due to lower bits rolling over more
+frequently.) Any one of these could have caused the 95 year time skip.
+
+Similar anomalies were observed while reading CNTPCT (after patching the
+kernel to allow reads from userspace). However, the jumps are much less
+frequent, and only small jumps were observed. The same program as before
+(except now reading CNTPCT) observed after 72 hours:
+
+ Count | Event
+-------+---------------------------
+    17 | jumped backward      699ms
+    52 | jumped forward       175ms
+  2831 | jumped forward       699ms
+     5 | jumped forward      1398ms
+Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Tested-by: Andre Przywara <andre.przywara@arm.com>
+
+========================================================================
+
+Because the CPU can read the CNTPCT/CNTVCT registers faster than they
+change, performing two reads of the register and comparing the high bits
+(like other workarounds) is not a workable solution. And because the
+timer can jump both forward and backward, no pair of reads can
+distinguish a good value from a bad one. The only way to guarantee a
+good value from consecutive reads would be to read _three_ times, and
+take the middle value iff the three values are 1) individually unique
+and 2) increasing. This takes at minimum 3 cycles (125 ns), or more if
+an anomaly is detected.
+
+However, since there is a distinct pattern to the bad values, we can
+optimize the common case (2046/2048 of the time) to a single read by
+simply ignoring values that match the pattern. This still takes no more
+than 3 cycles in the worst case, and requires much less code.
+
+[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
+[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
+[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
+
+Signed-off-by: Samuel Holland <samuel@sholland.org>
+---
+ drivers/clocksource/Kconfig          | 11 ++++++++++
+ drivers/clocksource/arm_arch_timer.c | 39 ++++++++++++++++++++++++++++++++++++
+ 2 files changed, 50 insertions(+)
+
+diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
+index 8e8a09755d10..7a5d434dd30b 100644
+--- a/drivers/clocksource/Kconfig
++++ b/drivers/clocksource/Kconfig
+@@ -364,6 +364,17 @@ config ARM64_ERRATUM_858921
+ 	  The workaround will be dynamically enabled when an affected
+ 	  core is detected.
+ 
++config SUN50I_A64_UNSTABLE_TIMER
++	bool "Workaround for Allwinner A64 timer instability"
++	default y
++	depends on ARM_ARCH_TIMER && ARM64 && ARCH_SUNXI
++	select ARM_ARCH_TIMER_OOL_WORKAROUND
++	help
++	  This option enables a workaround for instability in the timer on
++	  the Allwinner A64 SoC. The workaround will only be active if the
++	  allwinner,sun50i-a64-unstable-timer property is found in the
++	  timer node.
++
+ config ARM_GLOBAL_TIMER
+ 	bool "Support for the ARM global timer" if COMPILE_TEST
+ 	select TIMER_OF if OF
+diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
+index 57cb2f00fc07..66ce13578c52 100644
+--- a/drivers/clocksource/arm_arch_timer.c
++++ b/drivers/clocksource/arm_arch_timer.c
+@@ -319,6 +319,36 @@ static u64 notrace arm64_858921_read_cntvct_el0(void)
+ }
+ #endif
+ 
++#ifdef CONFIG_SUN50I_A64_UNSTABLE_TIMER
++/*
++ * The low bits of each register can transiently read as all ones or all zeroes
++ * when bit 11 or greater rolls over. Since the value can jump both backward
++ * (7ff -> 000 -> 800) and forward (7ff -> fff -> 800), it is simplest to just
++ * ignore register values with all ones or zeros in the low bits.
++ */
++static u64 notrace sun50i_a64_read_cntpct_el0(void)
++{
++	u64 val;
++
++	do {
++		val = read_sysreg(cntpct_el0);
++	} while (((val + 1) & GENMASK(10, 0)) <= 1);
++
++	return val;
++}
++
++static u64 notrace sun50i_a64_read_cntvct_el0(void)
++{
++	u64 val;
++
++	do {
++		val = read_sysreg(cntvct_el0);
++	} while (((val + 1) & GENMASK(10, 0)) <= 1);
++
++	return val;
++}
++#endif
++
+ #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
+ DEFINE_PER_CPU(const struct arch_timer_erratum_workaround *, timer_unstable_counter_workaround);
+ EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
+@@ -408,6 +438,15 @@ static const struct arch_timer_erratum_workaround ool_workarounds[] = {
+ 		.read_cntvct_el0 = arm64_858921_read_cntvct_el0,
+ 	},
+ #endif
++#ifdef CONFIG_SUN50I_A64_UNSTABLE_TIMER
++	{
++		.match_type = ate_match_dt,
++		.id = "allwinner,sun50i-a64-unstable-timer",
++		.desc = "Allwinner A64 timer instability",
++		.read_cntpct_el0 = sun50i_a64_read_cntpct_el0,
++		.read_cntvct_el0 = sun50i_a64_read_cntvct_el0,
++	},
++#endif
+ };
+ 
+ typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *,

arm64-dts-allwinner-a64-Enable-A64-timer-workaround.patch

@@ -0,0 +1,38 @@
+From patchwork Fri May 11 02:27:51 2018
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [2/2] arm64: dts: allwinner: a64: Enable A64 timer workaround
+From: Samuel Holland <samuel@sholland.org>
+X-Patchwork-Id: 10392889
+Message-Id: <20180511022751.9096-3-samuel@sholland.org>
+To: Maxime Ripard <maxime.ripard@bootlin.com>, Chen-Yu Tsai <wens@csie.org>, 
+ Catalin Marinas <catalin.marinas@arm.com>,
+ Will Deacon <will.deacon@arm.com>,
+ Daniel Lezcano <daniel.lezcano@linaro.org>,
+ Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <marc.zyngier@arm.com>
+Cc: linux-sunxi@googlegroups.com, linux-kernel@vger.kernel.org,
+ linux-arm-kernel@lists.infradead.org, Samuel Holland <samuel@sholland.org>
+Date: Thu, 10 May 2018 21:27:51 -0500
+
+As instability in the architectural timer has been observed on multiple
+devices using this SoC, inluding the Pine64 and the Orange Pi Win,
+enable the workaround in the SoC's device tree.
+
+Signed-off-by: Samuel Holland <samuel@sholland.org>
+---
+ arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+index 1b2ef28c42bd..5202b76e9684 100644
+--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
++++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+@@ -152,6 +152,7 @@
+ 
+ 	timer {
+ 		compatible = "arm,armv8-timer";
++		allwinner,sun50i-a64-unstable-timer;
+ 		interrupts = <GIC_PPI 13
+ 			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ 			     <GIC_PPI 14

bcm2835-hwrng-Handle-deferred-clock-properly.patch

@@ -1,42 +0,0 @@
-From patchwork Mon Feb 12 20:11:36 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: hwrng: bcm2835: Handle deferred clock properly
-From: Stefan Wahren <stefan.wahren@i2se.com>
-X-Patchwork-Id: 10214385
-Message-Id: <1518466296-30161-1-git-send-email-stefan.wahren@i2se.com>
-To: Herbert Xu <herbert@gondor.apana.org.au>, Matt Mackall <mpm@selenic.com>
-Cc: Stefan Wahren <stefan.wahren@i2se.com>,
- Florian Fainelli <f.fainelli@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
- Scott Branden <sbranden@broadcom.com>, Jon Mason <jonmason@broadcom.com>, 
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
- Eric Anholt <eric@anholt.net>, 
- bcm-kernel-feedback-list@broadcom.com, linux-crypto@vger.kernel.org, 
- Ray Jui <rjui@broadcom.com>, linux-arm-kernel@lists.infradead.org
-Date: Mon, 12 Feb 2018 21:11:36 +0100
-
-In case the probe of the clock is deferred, we would assume it is
-optional. This is wrong, so defer the probe of this driver until
-the clock is available.
-
-Fixes: 791af4f4907a ("hwrng: bcm2835 - Manage an optional clock")
-Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
-Acked-by: Florian Fainelli <f.fainelli@gmail.com>
----
- drivers/char/hw_random/bcm2835-rng.c | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
-index 7a84cec..6767d96 100644
---- a/drivers/char/hw_random/bcm2835-rng.c
-+++ b/drivers/char/hw_random/bcm2835-rng.c
-@@ -163,6 +163,8 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
- 
- 	/* Clock is optional on most platforms */
- 	priv->clk = devm_clk_get(dev, NULL);
-+	if (IS_ERR(priv->clk) && PTR_ERR(priv->clk) == -EPROBE_DEFER)
-+		return -EPROBE_DEFER;
- 
- 	priv->rng.name = pdev->name;
- 	priv->rng.init = bcm2835_rng_init;

bcm2837-enable-pmu.patch

@@ -0,0 +1,31 @@
+From 69e52712002cb6768b894cde9620fb426fd8728d Mon Sep 17 00:00:00 2001
+From: Stefan Wahren <stefan.wahren@i2se.com>
+Date: Fri, 16 Mar 2018 21:49:37 +0100
+Subject: [PATCH] ARM: dts: bcm2837: Enable PMU on Raspberry Pi 3
+
+This enables the PMU (performance monitoring unit) on Raspberry Pi 3.
+In order to make it work on ARM and ARM64, we need to specify two
+compatible strings.
+
+Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
+---
+ arch/arm/boot/dts/bcm2837.dtsi | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi
+index 7704bb029605..1f5e5c782835 100644
+--- a/arch/arm/boot/dts/bcm2837.dtsi
++++ b/arch/arm/boot/dts/bcm2837.dtsi
+@@ -17,6 +17,12 @@
+ 		};
+ 	};
+ 
++	arm-pmu {
++		compatible = "arm,cortex-a53-pmu", "arm,cortex-a7-pmu";
++		interrupt-parent = <&local_intc>;
++		interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
++	};
++
+ 	timer {
+ 		compatible = "arm,armv7-timer";
+ 		interrupt-parent = <&local_intc>;

bcm283x-Fix-probing-of-bcm2835-i2s.patch

@@ -1,118 +0,0 @@
-From patchwork Fri Feb 16 10:55:33 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [V3, 1/2,
- RESEND] dt-bindings: bcm283x: Fix register ranges of bcm2835-i2s
-From: Stefan Wahren <stefan.wahren@i2se.com>
-X-Patchwork-Id: 10224429
-Message-Id: <1518778534-3328-2-git-send-email-stefan.wahren@i2se.com>
-To: Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
- Eric Anholt <eric@anholt.net>
-Cc: Stefan Wahren <stefan.wahren@i2se.com>, devicetree@vger.kernel.org,
- alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
- Mark Brown <broonie@kernel.org>, linux-rpi-kernel@lists.infradead.org,
- linux-arm-kernel@lists.infradead.org
-Date: Fri, 16 Feb 2018 11:55:33 +0100
-
-Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
-the bcm2835-i2s requires a clock as DT property. Unfortunately
-the necessary DT change has never been applied. While we are at it
-also fix the first PCM register range to cover the PCM_GRAY register.
-
-This patch only fixes the affected dt-bindings.
-
-Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
-Reviewed-by: Eric Anholt <eric@anholt.net>
-Reviewed-by: Rob Herring <robh@kernel.org>
----
- Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt   | 4 ++--
- Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt | 9 ++++-----
- 2 files changed, 6 insertions(+), 7 deletions(-)
-
-diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
-index baf9b34..b6a8cc0 100644
---- a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
-+++ b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
-@@ -74,8 +74,8 @@ Example:
- 
- bcm2835_i2s: i2s@7e203000 {
- 	compatible = "brcm,bcm2835-i2s";
--	reg = <	0x7e203000 0x20>,
--	      < 0x7e101098 0x02>;
-+	reg = <	0x7e203000 0x24>;
-+	clocks = <&clocks BCM2835_CLOCK_PCM>;
- 
- 	dmas = <&dma 2>,
- 	       <&dma 3>;
-diff --git a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
-index 65783de..7bb0362 100644
---- a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
-+++ b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
-@@ -2,9 +2,8 @@
- 
- Required properties:
- - compatible: "brcm,bcm2835-i2s"
--- reg: A list of base address and size entries:
--	* The first entry should cover the PCM registers
--	* The second entry should cover the PCM clock registers
-+- reg: Should contain PCM registers location and length.
-+- clocks: the (PCM) clock to use
- - dmas: List of DMA controller phandle and DMA request line ordered pairs.
- - dma-names: Identifier string for each DMA request line in the dmas property.
-   These strings correspond 1:1 with the ordered pairs in dmas.
-@@ -16,8 +15,8 @@ Example:
- 
- bcm2835_i2s: i2s@7e203000 {
- 	compatible = "brcm,bcm2835-i2s";
--	reg = <0x7e203000 0x20>,
--	      <0x7e101098 0x02>;
-+	reg = <0x7e203000 0x24>;
-+	clocks = <&clocks BCM2835_CLOCK_PCM>;
- 
- 	dmas = <&dma 2>,
- 	       <&dma 3>;
-From patchwork Fri Feb 16 10:55:34 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [V3,2/2,RESEND] ARM: dts: bcm283x: Fix probing of bcm2835-i2s
-From: Stefan Wahren <stefan.wahren@i2se.com>
-X-Patchwork-Id: 10224427
-Message-Id: <1518778534-3328-3-git-send-email-stefan.wahren@i2se.com>
-To: Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
- Eric Anholt <eric@anholt.net>
-Cc: Stefan Wahren <stefan.wahren@i2se.com>, devicetree@vger.kernel.org,
- alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
- Mark Brown <broonie@kernel.org>, linux-rpi-kernel@lists.infradead.org,
- linux-arm-kernel@lists.infradead.org
-Date: Fri, 16 Feb 2018 11:55:34 +0100
-
-Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
-the bcm2835-i2s requires a clock as DT property. Unfortunately
-the necessary DT change has never been applied. While we are at it
-also fix the first PCM register range to cover the PCM_GRAY register.
-
-Fixes: 517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
-Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
-Reviewed-by: Eric Anholt <eric@anholt.net>
-Tested-by: Matthias Reichl <hias@horus.com>
----
- arch/arm/boot/dts/bcm283x.dtsi | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
-index 013431e..e08203c 100644
---- a/arch/arm/boot/dts/bcm283x.dtsi
-+++ b/arch/arm/boot/dts/bcm283x.dtsi
-@@ -396,8 +396,8 @@
- 
- 		i2s: i2s@7e203000 {
- 			compatible = "brcm,bcm2835-i2s";
--			reg = <0x7e203000 0x20>,
--			      <0x7e101098 0x02>;
-+			reg = <0x7e203000 0x24>;
-+			clocks = <&clocks BCM2835_CLOCK_PCM>;
- 
- 			dmas = <&dma 2>,
- 			       <&dma 3>;

bcm283x-dma-mapping-skip-USB-devices-when-configuring-DMA-during-probe.patch

@@ -1,127 +0,0 @@
-From patchwork Thu Aug  3 15:52:08 2017
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v3] dma-mapping: skip USB devices when configuring DMA during probe
-From: Johan Hovold <johan@kernel.org>
-X-Patchwork-Id: 9879371
-Message-Id: <20170803155208.22165-1-johan@kernel.org>
-To: Christoph Hellwig <hch@lst.de>,
- Marek Szyprowski <m.szyprowski@samsung.com>,
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-Cc: =?UTF-8?q?Andreas=20F=C3=A4rber?= <afaerber@suse.de>,
- linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
- Alan Stern <stern@rowland.harvard.edu>, Johan Hovold <johan@kernel.org>,
- stable <stable@vger.kernel.org>, Robin Murphy <robin.murphy@arm.com>,
- Sricharan R <sricharan@codeaurora.org>,
- Stefan Wahren <stefan.wahren@i2se.com>
-Date: Thu,  3 Aug 2017 17:52:08 +0200
-
-USB devices use the DMA mask and offset of the controller, which have
-already been setup when a device is probed. Note that modifying the
-DMA mask of a USB device would change the mask for the controller (and
-all devices on the bus) as the mask is literally shared.
-
-Since commit 2bf698671205 ("USB: of: fix root-hub device-tree node
-handling"), of_dma_configure() would be called also for root hubs, which
-use the device node of the controller. A separate, long-standing bug
-that makes of_dma_configure() generate a 30-bit DMA mask from the RPI3's
-"dma-ranges" would thus set a broken mask also for the controller. This
-in turn prevents USB devices from enumerating when control transfers
-fail:
-
-	dwc2 3f980000.usb: Cannot do DMA to address 0x000000003a166a00
-
-Note that the aforementioned DMA-mask bug was benign for the HCD itself
-as the dwc2 driver overwrites the mask previously set by
-of_dma_configure() for the platform device in its probe callback. The
-mask would only later get corrupted when the root-hub child device was
-probed.
-
-Fix this, and similar future problems, by adding a flag to struct device
-which prevents driver core from calling dma_configure() during probe and
-making sure it is set for USB devices.
-
-Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices")
-Cc: stable <stable@vger.kernel.org>	# 4.12
-Cc: Robin Murphy <robin.murphy@arm.com>
-Cc: Sricharan R <sricharan@codeaurora.org>
-Cc: Stefan Wahren <stefan.wahren@i2se.com>
-Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
-Signed-off-by: Johan Hovold <johan@kernel.org>
----
-
-v3
- - add flag to struct device to prevent DMA configuration during probe instead
-   of checking for the USB bus type, which is not available when USB is built
-   as a module as noted by Alan
- - drop moderated rpi list from CC
-
-v2
- - amend commit message and point out that the long-standing 30-bit DMA-mask
-   bug was benign to the dwc2 HCD itself (Robin)
- - add and use a new dev_is_usb() helper (Robin)
-
-
- drivers/base/dma-mapping.c | 6 ++++++
- drivers/usb/core/usb.c     | 1 +
- include/linux/device.h     | 3 +++
- 3 files changed, 10 insertions(+)
-
-diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
-index b555ff9dd8fc..f9f703be0ad1 100644
---- a/drivers/base/dma-mapping.c
-+++ b/drivers/base/dma-mapping.c
-@@ -345,6 +345,9 @@ int dma_configure(struct device *dev)
- 	enum dev_dma_attr attr;
- 	int ret = 0;
- 
-+	if (dev->skip_dma_configure)
-+		return 0;
-+
- 	if (dev_is_pci(dev)) {
- 		bridge = pci_get_host_bridge_device(to_pci_dev(dev));
- 		dma_dev = bridge;
-@@ -369,6 +372,9 @@ int dma_configure(struct device *dev)
- 
- void dma_deconfigure(struct device *dev)
- {
-+	if (dev->skip_dma_configure)
-+		return;
-+
- 	of_dma_deconfigure(dev);
- 	acpi_dma_deconfigure(dev);
- }
-diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
-index 17681d5638ac..2a85d905b539 100644
---- a/drivers/usb/core/usb.c
-+++ b/drivers/usb/core/usb.c
-@@ -588,6 +588,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
- 	 * Note: calling dma_set_mask() on a USB device would set the
- 	 * mask for the entire HCD, so don't do that.
- 	 */
-+	dev->dev.skip_dma_configure = true;
- 	dev->dev.dma_mask = bus->sysdev->dma_mask;
- 	dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
- 	set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
-diff --git a/include/linux/device.h b/include/linux/device.h
-index 723cd54b94da..022cf258068b 100644
---- a/include/linux/device.h
-+++ b/include/linux/device.h
-@@ -877,6 +877,8 @@ struct dev_links_info {
-  * @offline:	Set after successful invocation of bus type's .offline().
-  * @of_node_reused: Set if the device-tree node is shared with an ancestor
-  *              device.
-+ * @skip_dma_configure: Set if driver core should not configure DMA for this
-+ *              device during probe.
-  *
-  * At the lowest level, every device in a Linux system is represented by an
-  * instance of struct device. The device structure contains the information
-@@ -965,6 +967,7 @@ struct device {
- 	bool			offline_disabled:1;
- 	bool			offline:1;
- 	bool			of_node_reused:1;
-+	bool			skip_dma_configure:1;
- };
- 
- static inline struct device *kobj_to_dev(struct kobject *kobj)

bcm283x-gpio-expander.patch

@@ -1,638 +0,0 @@
-From patchwork Tue Feb 20 12:19:31 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v5,1/5] ARM: bcm2835: sync firmware properties with downstream
-From: Baruch Siach <baruch@tkos.co.il>
-X-Patchwork-Id: 10229963
-Message-Id: <e7d1f1d0789f11d37957a8998bee23d035115aeb.1519128054.git.baruch@tkos.co.il>
-To: Linus Walleij <linus.walleij@linaro.org>,
- Dave Stevenson <dave.stevenson@raspberrypi.org>,
- Eric Anholt <eric@anholt.net>, Stefan Wahren <stefan.wahren@i2se.com>
-Cc: devicetree@vger.kernel.org, Baruch Siach <baruch@tkos.co.il>,
- linux-gpio@vger.kernel.org, Michael Zoran <mzoran@crowfest.net>,
- Rob Herring <robh+dt@kernel.org>, linux-rpi-kernel@lists.infradead.org,
- Frank Rowand <frowand.list@gmail.com>, linux-arm-kernel@lists.infradead.org
-Date: Tue, 20 Feb 2018 14:19:31 +0200
-
-Add latest firmware property tags from the latest Raspberry Pi downstream
-kernel. This is needed for the GPIO tags, so we can control the GPIO
-multiplexor lines.
-
-Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
-Signed-off-by: Baruch Siach <baruch@tkos.co.il>
----
-v4: No change
-
-v3: Add Stefan's ack
-
-v2: No change
----
- include/soc/bcm2835/raspberrypi-firmware.h | 18 ++++++++++++++++++
- 1 file changed, 18 insertions(+)
-
-diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
-index cb979ad90401..50df5b28d2c9 100644
---- a/include/soc/bcm2835/raspberrypi-firmware.h
-+++ b/include/soc/bcm2835/raspberrypi-firmware.h
-@@ -63,6 +63,7 @@ enum rpi_firmware_property_tag {
- 	RPI_FIRMWARE_GET_MIN_VOLTAGE =                        0x00030008,
- 	RPI_FIRMWARE_GET_TURBO =                              0x00030009,
- 	RPI_FIRMWARE_GET_MAX_TEMPERATURE =                    0x0003000a,
-+	RPI_FIRMWARE_GET_STC =                                0x0003000b,
- 	RPI_FIRMWARE_ALLOCATE_MEMORY =                        0x0003000c,
- 	RPI_FIRMWARE_LOCK_MEMORY =                            0x0003000d,
- 	RPI_FIRMWARE_UNLOCK_MEMORY =                          0x0003000e,
-@@ -72,12 +73,22 @@ enum rpi_firmware_property_tag {
- 	RPI_FIRMWARE_SET_ENABLE_QPU =                         0x00030012,
- 	RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE =       0x00030014,
- 	RPI_FIRMWARE_GET_EDID_BLOCK =                         0x00030020,
-+	RPI_FIRMWARE_GET_CUSTOMER_OTP =                       0x00030021,
- 	RPI_FIRMWARE_GET_DOMAIN_STATE =                       0x00030030,
- 	RPI_FIRMWARE_SET_CLOCK_STATE =                        0x00038001,
- 	RPI_FIRMWARE_SET_CLOCK_RATE =                         0x00038002,
- 	RPI_FIRMWARE_SET_VOLTAGE =                            0x00038003,
- 	RPI_FIRMWARE_SET_TURBO =                              0x00038009,
-+	RPI_FIRMWARE_SET_CUSTOMER_OTP =                       0x00038021,
- 	RPI_FIRMWARE_SET_DOMAIN_STATE =                       0x00038030,
-+	RPI_FIRMWARE_GET_GPIO_STATE =                         0x00030041,
-+	RPI_FIRMWARE_SET_GPIO_STATE =                         0x00038041,
-+	RPI_FIRMWARE_SET_SDHOST_CLOCK =                       0x00038042,
-+	RPI_FIRMWARE_GET_GPIO_CONFIG =                        0x00030043,
-+	RPI_FIRMWARE_SET_GPIO_CONFIG =                        0x00038043,
-+	RPI_FIRMWARE_GET_PERIPH_REG =                         0x00030045,
-+	RPI_FIRMWARE_SET_PERIPH_REG =                         0x00038045,
-+
- 
- 	/* Dispmanx TAGS */
- 	RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE =                   0x00040001,
-@@ -91,6 +102,8 @@ enum rpi_firmware_property_tag {
- 	RPI_FIRMWARE_FRAMEBUFFER_GET_VIRTUAL_OFFSET =         0x00040009,
- 	RPI_FIRMWARE_FRAMEBUFFER_GET_OVERSCAN =               0x0004000a,
- 	RPI_FIRMWARE_FRAMEBUFFER_GET_PALETTE =                0x0004000b,
-+	RPI_FIRMWARE_FRAMEBUFFER_GET_TOUCHBUF =               0x0004000f,
-+	RPI_FIRMWARE_FRAMEBUFFER_GET_GPIOVIRTBUF =            0x00040010,
- 	RPI_FIRMWARE_FRAMEBUFFER_RELEASE =                    0x00048001,
- 	RPI_FIRMWARE_FRAMEBUFFER_TEST_PHYSICAL_WIDTH_HEIGHT = 0x00044003,
- 	RPI_FIRMWARE_FRAMEBUFFER_TEST_VIRTUAL_WIDTH_HEIGHT =  0x00044004,
-@@ -100,6 +113,7 @@ enum rpi_firmware_property_tag {
- 	RPI_FIRMWARE_FRAMEBUFFER_TEST_VIRTUAL_OFFSET =        0x00044009,
- 	RPI_FIRMWARE_FRAMEBUFFER_TEST_OVERSCAN =              0x0004400a,
- 	RPI_FIRMWARE_FRAMEBUFFER_TEST_PALETTE =               0x0004400b,
-+	RPI_FIRMWARE_FRAMEBUFFER_TEST_VSYNC =                 0x0004400e,
- 	RPI_FIRMWARE_FRAMEBUFFER_SET_PHYSICAL_WIDTH_HEIGHT =  0x00048003,
- 	RPI_FIRMWARE_FRAMEBUFFER_SET_VIRTUAL_WIDTH_HEIGHT =   0x00048004,
- 	RPI_FIRMWARE_FRAMEBUFFER_SET_DEPTH =                  0x00048005,
-@@ -108,6 +122,10 @@ enum rpi_firmware_property_tag {
- 	RPI_FIRMWARE_FRAMEBUFFER_SET_VIRTUAL_OFFSET =         0x00048009,
- 	RPI_FIRMWARE_FRAMEBUFFER_SET_OVERSCAN =               0x0004800a,
- 	RPI_FIRMWARE_FRAMEBUFFER_SET_PALETTE =                0x0004800b,
-+	RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF =               0x0004801f,
-+	RPI_FIRMWARE_FRAMEBUFFER_SET_GPIOVIRTBUF =            0x00048020,
-+	RPI_FIRMWARE_FRAMEBUFFER_SET_VSYNC =                  0x0004800e,
-+	RPI_FIRMWARE_FRAMEBUFFER_SET_BACKLIGHT =              0x0004800f,
- 
- 	RPI_FIRMWARE_VCHIQ_INIT =                             0x00048010,
- 
-From patchwork Tue Feb 20 12:19:32 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v5,2/5] dt-bindings: gpio: add raspberry pi GPIO expander binding
-From: Baruch Siach <baruch@tkos.co.il>
-X-Patchwork-Id: 10229965
-Message-Id: <f400b48cbcd8a138c39d4e8f63d6c1f569090dcc.1519128054.git.baruch@tkos.co.il>
-To: Linus Walleij <linus.walleij@linaro.org>,
- Dave Stevenson <dave.stevenson@raspberrypi.org>,
- Eric Anholt <eric@anholt.net>, Stefan Wahren <stefan.wahren@i2se.com>
-Cc: devicetree@vger.kernel.org, Baruch Siach <baruch@tkos.co.il>,
- linux-gpio@vger.kernel.org, Michael Zoran <mzoran@crowfest.net>,
- Rob Herring <robh+dt@kernel.org>, linux-rpi-kernel@lists.infradead.org,
- Frank Rowand <frowand.list@gmail.com>, linux-arm-kernel@lists.infradead.org
-Date: Tue, 20 Feb 2018 14:19:32 +0200
-
-The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware over
-I2C. The firmware mailbox interface allows the ARM core to control the
-GPIO lines.
-
-Signed-off-by: Baruch Siach <baruch@tkos.co.il>
-Reviewed-by: Rob Herring <robh@kernel.org>
----
-v5:
-  * Remove the 'firmware' property
-  * Note that the gpio node is a child of the firmware node
-
-v4:
-  * Move the example gpio node under the firmware node
-  * Rename gpio node name to plain 'gpio'
-
-v3:
-  * Rename node name.
-
-v2:
-  * Rename compatible string to raspberrypi,firmware-gpio
----
- .../bindings/gpio/raspberrypi,firmware-gpio.txt    | 30 ++++++++++++++++++++++
- 1 file changed, 30 insertions(+)
- create mode 100644 Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
-
-diff --git a/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
-new file mode 100644
-index 000000000000..ce97265e23ba
---- /dev/null
-+++ b/Documentation/devicetree/bindings/gpio/raspberrypi,firmware-gpio.txt
-@@ -0,0 +1,30 @@
-+Raspberry Pi GPIO expander
-+
-+The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The
-+firmware exposes a mailbox interface that allows the ARM core to control the
-+GPIO lines on the expander.
-+
-+The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi
-+firmware node.
-+
-+Required properties:
-+
-+- compatible : Should be "raspberrypi,firmware-gpio"
-+- gpio-controller : Marks the device node as a gpio controller
-+- #gpio-cells : Should be two.  The first cell is the pin number, and
-+  the second cell is used to specify the gpio polarity:
-+  0 = active high
-+  1 = active low
-+
-+Example:
-+
-+firmware: firmware-rpi {
-+	compatible = "raspberrypi,bcm2835-firmware";
-+	mboxes = <&mailbox>;
-+
-+	expgpio: gpio {
-+		 compatible = "raspberrypi,firmware-gpio";
-+		 gpio-controller;
-+		 #gpio-cells = <2>;
-+	 };
-+};
-From patchwork Tue Feb 20 12:19:33 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v5,
- 3/5] gpio: raspberrypi-exp: Driver for RPi3 GPIO expander via mailbox
- service
-From: Baruch Siach <baruch@tkos.co.il>
-X-Patchwork-Id: 10229967
-Message-Id: <8c34f287ee72b340fa9d693aa0e304b25541c74c.1519128054.git.baruch@tkos.co.il>
-To: Linus Walleij <linus.walleij@linaro.org>,
- Dave Stevenson <dave.stevenson@raspberrypi.org>,
- Eric Anholt <eric@anholt.net>, Stefan Wahren <stefan.wahren@i2se.com>
-Cc: devicetree@vger.kernel.org, Baruch Siach <baruch@tkos.co.il>,
- linux-gpio@vger.kernel.org, Michael Zoran <mzoran@crowfest.net>,
- Rob Herring <robh+dt@kernel.org>, linux-rpi-kernel@lists.infradead.org,
- Frank Rowand <frowand.list@gmail.com>, linux-arm-kernel@lists.infradead.org
-Date: Tue, 20 Feb 2018 14:19:33 +0200
-
-From: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
-Pi3 and Compute Module 3 have a GPIO expander that the
-VPU communicates with.
-There is a mailbox service that now allows control of this
-expander, so add a kernel driver that can make use of it.
-
-Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
-Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-Signed-off-by: Baruch Siach <baruch@tkos.co.il>
----
-v5:
-  * Use the parent node to find the firmware
-
-v4:
-  * Don't set the .owner driver field
-  * Add Stefan's review tag
-
-v3:
-  * Tweak Kconfig driver prompt
-  * Make GPIO_RASPBERRYPI_EXP tristate
-  * Make COMPILE_TEST independent of RASPBERRYPI_FIRMWARE
-  * Remove redundant DMA header
-  * Use less code lines for dev_err()
-  * Check rpi_exp_gpio_get_polarity() return value
-  * Remove redundant platform_set_drvdata() call
-
-v2:
-  * Rename driver to gpio-raspberrypi-exp
-  * Populate the gpiochip parent device pointer
-  * Use macro for the mailbox base GPIO number
-  * Drop linux/gpio.h and GPIOF_DIR_*
-  * Check and print firmware error value
-  * Use devm_gpiochip_add_data(); drop .remove
-  * A few more minor tweaks
----
- drivers/gpio/Kconfig                |   9 ++
- drivers/gpio/Makefile               |   1 +
- drivers/gpio/gpio-raspberrypi-exp.c | 252 ++++++++++++++++++++++++++++++++++++
- 3 files changed, 262 insertions(+)
- create mode 100644 drivers/gpio/gpio-raspberrypi-exp.c
-
-diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
-index 8dbb2280538d..fd0562a37f68 100644
---- a/drivers/gpio/Kconfig
-+++ b/drivers/gpio/Kconfig
-@@ -122,6 +122,15 @@ config GPIO_ATH79
- 	  Select this option to enable GPIO driver for
- 	  Atheros AR71XX/AR724X/AR913X SoC devices.
- 
-+config GPIO_RASPBERRYPI_EXP
-+	tristate "Raspberry Pi 3 GPIO Expander"
-+	default RASPBERRYPI_FIRMWARE
-+	depends on OF_GPIO
-+	depends on (ARCH_BCM2835 && RASPBERRYPI_FIRMWARE) || COMPILE_TEST
-+	help
-+	  Turn on GPIO support for the expander on Raspberry Pi 3 boards, using
-+	  the firmware mailbox to communicate with VideoCore on BCM283x chips.
-+
- config GPIO_BCM_KONA
- 	bool "Broadcom Kona GPIO"
- 	depends on OF_GPIO && (ARCH_BCM_MOBILE || COMPILE_TEST)
-diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
-index cccb0d40846c..76dc0a02bd56 100644
---- a/drivers/gpio/Makefile
-+++ b/drivers/gpio/Makefile
-@@ -32,6 +32,7 @@ obj-$(CONFIG_GPIO_AMDPT)	+= gpio-amdpt.o
- obj-$(CONFIG_GPIO_ARIZONA)	+= gpio-arizona.o
- obj-$(CONFIG_GPIO_ATH79)	+= gpio-ath79.o
- obj-$(CONFIG_GPIO_ASPEED)	+= gpio-aspeed.o
-+obj-$(CONFIG_GPIO_RASPBERRYPI_EXP)	+= gpio-raspberrypi-exp.o
- obj-$(CONFIG_GPIO_BCM_KONA)	+= gpio-bcm-kona.o
- obj-$(CONFIG_GPIO_BD9571MWV)	+= gpio-bd9571mwv.o
- obj-$(CONFIG_GPIO_BRCMSTB)	+= gpio-brcmstb.o
-diff --git a/drivers/gpio/gpio-raspberrypi-exp.c b/drivers/gpio/gpio-raspberrypi-exp.c
-new file mode 100644
-index 000000000000..d6d36d537e37
---- /dev/null
-+++ b/drivers/gpio/gpio-raspberrypi-exp.c
-@@ -0,0 +1,252 @@
-+// SPDX-License-Identifier: GPL-2.0+
-+/*
-+ *  Raspberry Pi 3 expander GPIO driver
-+ *
-+ *  Uses the firmware mailbox service to communicate with the
-+ *  GPIO expander on the VPU.
-+ *
-+ *  Copyright (C) 2017 Raspberry Pi Trading Ltd.
-+ */
-+
-+#include <linux/err.h>
-+#include <linux/gpio/driver.h>
-+#include <linux/module.h>
-+#include <linux/platform_device.h>
-+#include <soc/bcm2835/raspberrypi-firmware.h>
-+
-+#define MODULE_NAME "raspberrypi-exp-gpio"
-+#define NUM_GPIO 8
-+
-+#define RPI_EXP_GPIO_BASE	128
-+
-+#define RPI_EXP_GPIO_DIR_IN	0
-+#define RPI_EXP_GPIO_DIR_OUT	1
-+
-+struct rpi_exp_gpio {
-+	struct gpio_chip gc;
-+	struct rpi_firmware *fw;
-+};
-+
-+/* VC4 firmware mailbox interface data structures */
-+
-+struct gpio_set_config {
-+	u32 gpio;
-+	u32 direction;
-+	u32 polarity;
-+	u32 term_en;
-+	u32 term_pull_up;
-+	u32 state;
-+};
-+
-+struct gpio_get_config {
-+	u32 gpio;
-+	u32 direction;
-+	u32 polarity;
-+	u32 term_en;
-+	u32 term_pull_up;
-+};
-+
-+struct gpio_get_set_state {
-+	u32 gpio;
-+	u32 state;
-+};
-+
-+static int rpi_exp_gpio_get_polarity(struct gpio_chip *gc, unsigned int off)
-+{
-+	struct rpi_exp_gpio *gpio;
-+	struct gpio_get_config get;
-+	int ret;
-+
-+	gpio = gpiochip_get_data(gc);
-+
-+	get.gpio = off + RPI_EXP_GPIO_BASE;	/* GPIO to update */
-+
-+	ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
-+				    &get, sizeof(get));
-+	if (ret || get.gpio != 0) {
-+		dev_err(gc->parent, "Failed to get GPIO %u config (%d %x)\n",
-+			off, ret, get.gpio);
-+		return ret ? ret : -EIO;
-+	}
-+	return get.polarity;
-+}
-+
-+static int rpi_exp_gpio_dir_in(struct gpio_chip *gc, unsigned int off)
-+{
-+	struct rpi_exp_gpio *gpio;
-+	struct gpio_set_config set_in;
-+	int ret;
-+
-+	gpio = gpiochip_get_data(gc);
-+
-+	set_in.gpio = off + RPI_EXP_GPIO_BASE;	/* GPIO to update */
-+	set_in.direction = RPI_EXP_GPIO_DIR_IN;
-+	set_in.term_en = 0;		/* termination disabled */
-+	set_in.term_pull_up = 0;	/* n/a as termination disabled */
-+	set_in.state = 0;		/* n/a as configured as an input */
-+
-+	ret = rpi_exp_gpio_get_polarity(gc, off);
-+	if (ret < 0)
-+		return ret;
-+	set_in.polarity = ret;		/* Retain existing setting */
-+
-+	ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_CONFIG,
-+				    &set_in, sizeof(set_in));
-+	if (ret || set_in.gpio != 0) {
-+		dev_err(gc->parent, "Failed to set GPIO %u to input (%d %x)\n",
-+			off, ret, set_in.gpio);
-+		return ret ? ret : -EIO;
-+	}
-+	return 0;
-+}
-+
-+static int rpi_exp_gpio_dir_out(struct gpio_chip *gc, unsigned int off, int val)
-+{
-+	struct rpi_exp_gpio *gpio;
-+	struct gpio_set_config set_out;
-+	int ret;
-+
-+	gpio = gpiochip_get_data(gc);
-+
-+	set_out.gpio = off + RPI_EXP_GPIO_BASE;	/* GPIO to update */
-+	set_out.direction = RPI_EXP_GPIO_DIR_OUT;
-+	set_out.term_en = 0;		/* n/a as an output */
-+	set_out.term_pull_up = 0;	/* n/a as termination disabled */
-+	set_out.state = val;		/* Output state */
-+
-+	ret = rpi_exp_gpio_get_polarity(gc, off);
-+	if (ret < 0)
-+		return ret;
-+	set_out.polarity = ret;		/* Retain existing setting */
-+
-+	ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_CONFIG,
-+				    &set_out, sizeof(set_out));
-+	if (ret || set_out.gpio != 0) {
-+		dev_err(gc->parent, "Failed to set GPIO %u to output (%d %x)\n",
-+			off, ret, set_out.gpio);
-+		return ret ? ret : -EIO;
-+	}
-+	return 0;
-+}
-+
-+static int rpi_exp_gpio_get_direction(struct gpio_chip *gc, unsigned int off)
-+{
-+	struct rpi_exp_gpio *gpio;
-+	struct gpio_get_config get;
-+	int ret;
-+
-+	gpio = gpiochip_get_data(gc);
-+
-+	get.gpio = off + RPI_EXP_GPIO_BASE;	/* GPIO to update */
-+
-+	ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_CONFIG,
-+				    &get, sizeof(get));
-+	if (ret || get.gpio != 0) {
-+		dev_err(gc->parent,
-+			"Failed to get GPIO %u config (%d %x)\n", off, ret,
-+			get.gpio);
-+		return ret ? ret : -EIO;
-+	}
-+	return !get.direction;
-+}
-+
-+static int rpi_exp_gpio_get(struct gpio_chip *gc, unsigned int off)
-+{
-+	struct rpi_exp_gpio *gpio;
-+	struct gpio_get_set_state get;
-+	int ret;
-+
-+	gpio = gpiochip_get_data(gc);
-+
-+	get.gpio = off + RPI_EXP_GPIO_BASE;	/* GPIO to update */
-+	get.state = 0;		/* storage for returned value */
-+
-+	ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_GET_GPIO_STATE,
-+					 &get, sizeof(get));
-+	if (ret || get.gpio != 0) {
-+		dev_err(gc->parent,
-+			"Failed to get GPIO %u state (%d %x)\n", off, ret,
-+			get.gpio);
-+		return ret ? ret : -EIO;
-+	}
-+	return !!get.state;
-+}
-+
-+static void rpi_exp_gpio_set(struct gpio_chip *gc, unsigned int off, int val)
-+{
-+	struct rpi_exp_gpio *gpio;
-+	struct gpio_get_set_state set;
-+	int ret;
-+
-+	gpio = gpiochip_get_data(gc);
-+
-+	set.gpio = off + RPI_EXP_GPIO_BASE;	/* GPIO to update */
-+	set.state = val;	/* Output state */
-+
-+	ret = rpi_firmware_property(gpio->fw, RPI_FIRMWARE_SET_GPIO_STATE,
-+					 &set, sizeof(set));
-+	if (ret || set.gpio != 0)
-+		dev_err(gc->parent,
-+			"Failed to set GPIO %u state (%d %x)\n", off, ret,
-+			set.gpio);
-+}
-+
-+static int rpi_exp_gpio_probe(struct platform_device *pdev)
-+{
-+	struct device *dev = &pdev->dev;
-+	struct device_node *np = dev->of_node;
-+	struct device_node *fw_node;
-+	struct rpi_firmware *fw;
-+	struct rpi_exp_gpio *rpi_gpio;
-+
-+	fw_node = of_get_parent(np);
-+	if (!fw_node) {
-+		dev_err(dev, "Missing firmware node\n");
-+		return -ENOENT;
-+	}
-+
-+	fw = rpi_firmware_get(fw_node);
-+	if (!fw)
-+		return -EPROBE_DEFER;
-+
-+	rpi_gpio = devm_kzalloc(dev, sizeof(*rpi_gpio), GFP_KERNEL);
-+	if (!rpi_gpio)
-+		return -ENOMEM;
-+
-+	rpi_gpio->fw = fw;
-+	rpi_gpio->gc.parent = dev;
-+	rpi_gpio->gc.label = MODULE_NAME;
-+	rpi_gpio->gc.owner = THIS_MODULE;
-+	rpi_gpio->gc.of_node = np;
-+	rpi_gpio->gc.base = -1;
-+	rpi_gpio->gc.ngpio = NUM_GPIO;
-+
-+	rpi_gpio->gc.direction_input = rpi_exp_gpio_dir_in;
-+	rpi_gpio->gc.direction_output = rpi_exp_gpio_dir_out;
-+	rpi_gpio->gc.get_direction = rpi_exp_gpio_get_direction;
-+	rpi_gpio->gc.get = rpi_exp_gpio_get;
-+	rpi_gpio->gc.set = rpi_exp_gpio_set;
-+	rpi_gpio->gc.can_sleep = true;
-+
-+	return devm_gpiochip_add_data(dev, &rpi_gpio->gc, rpi_gpio);
-+}
-+
-+static const struct of_device_id rpi_exp_gpio_ids[] = {
-+	{ .compatible = "raspberrypi,firmware-gpio" },
-+	{ }
-+};
-+MODULE_DEVICE_TABLE(of, rpi_exp_gpio_ids);
-+
-+static struct platform_driver rpi_exp_gpio_driver = {
-+	.driver	= {
-+		.name		= MODULE_NAME,
-+		.of_match_table	= of_match_ptr(rpi_exp_gpio_ids),
-+	},
-+	.probe	= rpi_exp_gpio_probe,
-+};
-+module_platform_driver(rpi_exp_gpio_driver);
-+
-+MODULE_LICENSE("GPL");
-+MODULE_AUTHOR("Dave Stevenson <dave.stevenson@raspberrypi.org>");
-+MODULE_DESCRIPTION("Raspberry Pi 3 expander GPIO driver");
-+MODULE_ALIAS("platform:rpi-exp-gpio");
-From patchwork Tue Feb 20 12:19:34 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v5,4/5] ARM: dts: bcm2835: make the firmware node into a bus
-From: Baruch Siach <baruch@tkos.co.il>
-X-Patchwork-Id: 10229961
-Message-Id: <43f9082a6835df6d7bcd3e16d79db687c52826d2.1519128054.git.baruch@tkos.co.il>
-To: Linus Walleij <linus.walleij@linaro.org>,
- Dave Stevenson <dave.stevenson@raspberrypi.org>,
- Eric Anholt <eric@anholt.net>, Stefan Wahren <stefan.wahren@i2se.com>
-Cc: devicetree@vger.kernel.org, Baruch Siach <baruch@tkos.co.il>,
- linux-gpio@vger.kernel.org, Michael Zoran <mzoran@crowfest.net>,
- Rob Herring <robh+dt@kernel.org>, linux-rpi-kernel@lists.infradead.org,
- Frank Rowand <frowand.list@gmail.com>, linux-arm-kernel@lists.infradead.org
-Date: Tue, 20 Feb 2018 14:19:34 +0200
-
-This allows adding devices for which the firmware exposes control interface
-via the mailbox. An example of such device is the GPIO expander.
-
-Signed-off-by: Baruch Siach <baruch@tkos.co.il>
-Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
----
-v4: New patch in this series
----
- arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
-diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
-index e36c392a2b8f..0198bd46ef7c 100644
---- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
-+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
-@@ -18,7 +18,9 @@
- 
- 	soc {
- 		firmware: firmware {
--			compatible = "raspberrypi,bcm2835-firmware";
-+			compatible = "raspberrypi,bcm2835-firmware", "simple-bus";
-+			#address-cells = <0>;
-+			#size-cells = <0>;
- 			mboxes = <&mailbox>;
- 		};
- 
-From patchwork Tue Feb 20 12:19:35 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v5,5/5] ARM: dts: bcm2837-rpi-3-b: add GPIO expander
-From: Baruch Siach <baruch@tkos.co.il>
-X-Patchwork-Id: 10229995
-Message-Id: <a6d59692dc4847e0b1639a26542e28c95ad5240f.1519128054.git.baruch@tkos.co.il>
-To: Linus Walleij <linus.walleij@linaro.org>,
- Dave Stevenson <dave.stevenson@raspberrypi.org>,
- Eric Anholt <eric@anholt.net>, Stefan Wahren <stefan.wahren@i2se.com>
-Cc: devicetree@vger.kernel.org, Baruch Siach <baruch@tkos.co.il>,
- linux-gpio@vger.kernel.org, Michael Zoran <mzoran@crowfest.net>,
- Rob Herring <robh+dt@kernel.org>, linux-rpi-kernel@lists.infradead.org,
- Frank Rowand <frowand.list@gmail.com>, linux-arm-kernel@lists.infradead.org
-Date: Tue, 20 Feb 2018 14:19:35 +0200
-
-Add a description of the RPi3 GPIO expander that the VC4 firmware controls.
-
-Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
-Signed-off-by: Baruch Siach <baruch@tkos.co.il>
-Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
----
-v5:
-  * Drop the 'firmware' property
-
-v4:
-  * Move the gpio node under the firmware node
-  * Rename the gpio node to plain 'gpio'
-  * Add Stefan's ack
-
-v3:
-  * List GPIO names one per line.
-
-v2:
-  * Move GPIO expander node out of the soc container
-  * Rename compatible string
-  * Add gpio-line-names property
----
- arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 17 +++++++++++++++++
- 1 file changed, 17 insertions(+)
-
-diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
-index 3e4ed7c5b0b3..0b31d995a066 100644
---- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
-+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
-@@ -25,6 +25,23 @@
- 	};
- };
- 
-+&firmware {
-+	expgpio: gpio {
-+		compatible = "raspberrypi,firmware-gpio";
-+		gpio-controller;
-+		#gpio-cells = <2>;
-+		gpio-line-names = "BT_ON",
-+				  "WL_ON",
-+				  "STATUS_LED",
-+				  "LAN_RUN",
-+				  "HPD_N",
-+				  "CAM_GPIO0",
-+				  "CAM_GPIO1",
-+				  "PWR_LOW_N";
-+		status = "okay";
-+	};
-+};
-+
- /* uart0 communicates with the BT module */
- &uart0 {
- 	pinctrl-names = "default";

configs/build_configs.sh

@@ -11,6 +11,8 @@ SCRIPT="$(readlink -f $0)"
 OUTPUT_DIR="$PWD"
 SCRIPT_DIR="$(dirname $SCRIPT)"
 
+LANG=en_US.UTF-8
+
 # to handle this script being a symlink
 cd $SCRIPT_DIR
 

configs/fedora/debug/CONFIG_ARM_PTDUMP

@@ -0,0 +1 @@
+CONFIG_ARM_PTDUMP=y

configs/fedora/debug/CONFIG_ARM_PTDUMP_DEBUGFS

@@ -0,0 +1 @@
+CONFIG_ARM_PTDUMP_DEBUGFS=y

configs/fedora/debug/CONFIG_DEBUG_RWSEMS

@@ -0,0 +1 @@
+CONFIG_DEBUG_RWSEMS=y

configs/fedora/debug/CONFIG_DEBUG_WW_MUTEX_SLOWPATH

@@ -0,0 +1 @@
+CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y

configs/fedora/debug/CONFIG_XFS_WARN

@@ -0,0 +1 @@
+CONFIG_XFS_WARN=y

configs/fedora/generic/CONFIG_ACPI_TAD

@@ -0,0 +1 @@
+CONFIG_ACPI_TAD=m

configs/fedora/generic/CONFIG_AD5272

@@ -0,0 +1 @@
+CONFIG_AD5272=m

configs/fedora/generic/CONFIG_AD5686_SPI

@@ -0,0 +1 @@
+# CONFIG_AD5686_SPI is not set

configs/fedora/generic/CONFIG_AD5696_I2C

@@ -0,0 +1 @@
+# CONFIG_AD5696_I2C is not set

configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE

@@ -0,0 +1 @@
+CONFIG_ALTERA_PR_IP_CORE=m

configs/fedora/generic/CONFIG_ALTERA_PR_IP_CORE_PLAT=n

@@ -0,0 +1 @@
+CONFIG_ALTERA_PR_IP_CORE_PLAT=m

configs/fedora/generic/CONFIG_ARCH_DAVINCI

@@ -0,0 +1 @@
+# CONFIG_ARCH_DAVINCI is not set

configs/fedora/generic/CONFIG_ARCH_DOVE

@@ -0,0 +1 @@
+# CONFIG_ARCH_DOVE is not set

configs/fedora/generic/CONFIG_ARCH_EBSA110

@@ -0,0 +1 @@
+# CONFIG_ARCH_EBSA110 is not set

configs/fedora/generic/CONFIG_ARCH_EP93XX

@@ -0,0 +1 @@
+# CONFIG_ARCH_EP93XX is not set

configs/fedora/generic/CONFIG_ARCH_FOOTBRIDGE

@@ -0,0 +1 @@
+# CONFIG_ARCH_FOOTBRIDGE is not set

configs/fedora/generic/CONFIG_ARCH_IOP13XX

@@ -0,0 +1 @@
+# CONFIG_ARCH_IOP13XX is not set

configs/fedora/generic/CONFIG_ARCH_IOP32X

@@ -0,0 +1 @@
+# CONFIG_ARCH_IOP32X is not set

configs/fedora/generic/CONFIG_ARCH_IOP33X

@@ -0,0 +1 @@
+# CONFIG_ARCH_IOP33X is not set

configs/fedora/generic/CONFIG_ARCH_IXP4XX

@@ -0,0 +1 @@
+# CONFIG_ARCH_IXP4XX is not set

configs/fedora/generic/CONFIG_ARCH_KS8695

@@ -0,0 +1 @@
+# CONFIG_ARCH_KS8695 is not set

configs/fedora/generic/CONFIG_ARCH_LPC32XX

@@ -0,0 +1 @@
+# CONFIG_ARCH_LPC32XX is not set

configs/fedora/generic/CONFIG_ARCH_MULTIPLATFORM

@@ -0,0 +1 @@
+CONFIG_ARCH_MULTIPLATFORM=y

configs/fedora/generic/CONFIG_ARCH_NETX

@@ -0,0 +1 @@
+# CONFIG_ARCH_NETX is not set

configs/fedora/generic/CONFIG_ARCH_OMAP1

@@ -0,0 +1 @@
+# CONFIG_ARCH_OMAP1 is not set

configs/fedora/generic/CONFIG_ARCH_PXA

@@ -0,0 +1 @@
+# CONFIG_ARCH_PXA is not set

configs/fedora/generic/CONFIG_ARCH_RPC

@@ -0,0 +1 @@
+# CONFIG_ARCH_RPC is not set

configs/fedora/generic/CONFIG_ARCH_S3C24XX

@@ -0,0 +1 @@
+# CONFIG_ARCH_S3C24XX is not set

configs/fedora/generic/CONFIG_ARCH_SA1100

@@ -0,0 +1 @@
+# CONFIG_ARCH_SA1100 is not set

configs/fedora/generic/CONFIG_ARCH_W90X900

@@ -0,0 +1 @@
+# CONFIG_ARCH_W90X900 is not set

configs/fedora/generic/CONFIG_ASIX_PHY

@@ -0,0 +1 @@
+# CONFIG_ASIX_PHY is not set

configs/fedora/generic/CONFIG_ATH10K_SNOC

@@ -0,0 +1 @@
+# CONFIG_ATH10K_SNOC is not set

configs/fedora/generic/CONFIG_AUTOFS_FS

@@ -0,0 +1 @@
+CONFIG_AUTOFS_FS=y

configs/fedora/generic/CONFIG_B43_BUSES_BCMA

@@ -0,0 +1 @@
+# CONFIG_B43_BUSES_BCMA is not set

configs/fedora/generic/CONFIG_B43_BUSES_BCMA_AND_SSB

@@ -0,0 +1 @@
+CONFIG_B43_BUSES_BCMA_AND_SSB=y

configs/fedora/generic/CONFIG_B43_BUSES_SSB

@@ -0,0 +1 @@
+# CONFIG_B43_BUSES_SSB is not set

configs/fedora/generic/CONFIG_BPFILTER

@@ -0,0 +1 @@
+# CONFIG_BPFILTER is not set

configs/fedora/generic/CONFIG_BRANCH_PROFILE_NONE

@@ -0,0 +1 @@
+CONFIG_BRANCH_PROFILE_NONE=y

configs/fedora/generic/CONFIG_BUILD_ID_SALT

@@ -0,0 +1 @@
+CONFIG_BUILD_ID_SALT=0x12345678

configs/fedora/generic/CONFIG_BUILD_SALT

@@ -0,0 +1 @@
+CONFIG_BUILD_SALT=""

configs/fedora/generic/CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE

@@ -0,0 +1 @@
+CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y

configs/fedora/generic/CONFIG_CC_STACKPROTECTOR_AUTO

@@ -0,0 +1 @@
+# CONFIG_CC_STACKPROTECTOR_AUTO is not set

configs/fedora/generic/CONFIG_CC_STACKPROTECTOR_NONE

@@ -0,0 +1 @@
+# CONFIG_CC_STACKPROTECTOR_NONE is not set

configs/fedora/generic/CONFIG_CC_STACKPROTECTOR_REGULAR

@@ -0,0 +1 @@
+# CONFIG_CC_STACKPROTECTOR_REGULAR is not set

configs/fedora/generic/CONFIG_CC_STACKPROTECTOR_STRONG

@@ -0,0 +1 @@
+# CONFIG_CC_STACKPROTECTOR_STRONG is not set

configs/fedora/generic/CONFIG_CEC_PIN_ERROR_INJ

@@ -0,0 +1 @@
+# CONFIG_CEC_PIN_ERROR_INJ is not set

configs/fedora/generic/CONFIG_CELL_CPU

@@ -0,0 +1 @@
+# CONFIG_CELL_CPU is not set

configs/fedora/generic/CONFIG_CHROMEOS_TBMC

@@ -0,0 +1 @@
+# CONFIG_CHROMEOS_TBMC is not set

configs/fedora/generic/CONFIG_COMMON_CLK_SI544

@@ -0,0 +1 @@
+CONFIG_COMMON_CLK_SI544=m

configs/fedora/generic/CONFIG_CONSOLE_LOGLEVEL_QUIET

@@ -0,0 +1 @@
+CONFIG_CONSOLE_LOGLEVEL_QUIET=3

configs/fedora/generic/CONFIG_CPU_BIG_ENDIAN

@@ -0,0 +1 @@
+# CONFIG_CPU_BIG_ENDIAN is not set

configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE

@@ -0,0 +1 @@
+# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set

configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE

@@ -0,0 +1 @@
+# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set

configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE

@@ -0,0 +1 @@
+# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set

configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL

@@ -0,0 +1 @@
+# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set

configs/fedora/generic/CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE

@@ -0,0 +1 @@
+# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set

configs/fedora/generic/CONFIG_CRC32_BIT

@@ -0,0 +1 @@
+# CONFIG_CRC32_BIT is not set

configs/fedora/generic/CONFIG_CRC32_SARWATE

@@ -0,0 +1 @@
+# CONFIG_CRC32_SARWATE is not set

configs/fedora/generic/CONFIG_CRC32_SLICEBY4

@@ -0,0 +1 @@
+# CONFIG_CRC32_SLICEBY4 is not set

configs/fedora/generic/CONFIG_CRC32_SLICEBY8

@@ -0,0 +1 @@
+CONFIG_CRC32_SLICEBY8=y

configs/fedora/generic/CONFIG_CRYPTO_842

@@ -1 +1 @@
-CONFIG_CRYPTO_842=m
+CONFIG_CRYPTO_842=y

configs/fedora/generic/CONFIG_CRYPTO_AEGIS128

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_AEGIS128 is not set

configs/fedora/generic/CONFIG_CRYPTO_AEGIS128L

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_AEGIS128L is not set

configs/fedora/generic/CONFIG_CRYPTO_AEGIS128L_AESNI_SSE2

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_AEGIS128L_AESNI_SSE2 is not set

configs/fedora/generic/CONFIG_CRYPTO_AEGIS128_AESNI_SSE2

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_AEGIS128_AESNI_SSE2 is not set

configs/fedora/generic/CONFIG_CRYPTO_AEGIS256

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_AEGIS256 is not set

configs/fedora/generic/CONFIG_CRYPTO_AEGIS256_AESNI_SSE2

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_AEGIS256_AESNI_SSE2 is not set

configs/fedora/generic/CONFIG_CRYPTO_CFB

@@ -0,0 +1 @@
+CONFIG_CRYPTO_CFB=m

configs/fedora/generic/CONFIG_CRYPTO_DEFLATE

@@ -1 +1 @@
-CONFIG_CRYPTO_DEFLATE=m
+CONFIG_CRYPTO_DEFLATE=y

configs/fedora/generic/CONFIG_CRYPTO_DEV_CHELSIO_TLS

@@ -0,0 +1 @@
+CONFIG_CRYPTO_DEV_CHELSIO_TLS=m

configs/fedora/generic/CONFIG_CRYPTO_MORUS1280

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_MORUS1280 is not set

configs/fedora/generic/CONFIG_CRYPTO_MORUS1280_AVX2

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_MORUS1280_AVX2 is not set

configs/fedora/generic/CONFIG_CRYPTO_MORUS1280_SSE2

@@ -0,0 +1 @@
+# CONFIG_CRYPTO_MORUS1280_SSE2 is not set