--- /dev/null
+From ac8616e4c81dded650dfade49a7da283565d37ce Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@csie.org>
+Date: Tue, 14 Feb 2017 11:35:22 +0800
+Subject: clk: sunxi-ng: mp: Adjust parent rate for pre-dividers
+
+From: Chen-Yu Tsai <wens@csie.org>
+
+commit ac8616e4c81dded650dfade49a7da283565d37ce upstream.
+
+The MP style clocks support an mux with pre-dividers. While the driver
+correctly accounted for them in the .determine_rate callback, it did
+not in the .recalc_rate and .set_rate callbacks.
+
+This means when calculating the factors in the .set_rate callback, they
+would be off by a factor of the active pre-divider. Same goes for
+reading back the clock rate after it is set.
+
+Fixes: 2ab836db5097 ("clk: sunxi-ng: Add M-P factor clock support")
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/sunxi-ng/ccu_mp.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/clk/sunxi-ng/ccu_mp.c
++++ b/drivers/clk/sunxi-ng/ccu_mp.c
+@@ -85,6 +85,10 @@ static unsigned long ccu_mp_recalc_rate(
+ unsigned int m, p;
+ u32 reg;
+
++ /* Adjust parent_rate according to pre-dividers */
++ ccu_mux_helper_adjust_parent_for_prediv(&cmp->common, &cmp->mux,
++ -1, &parent_rate);
++
+ reg = readl(cmp->common.base + cmp->common.reg);
+
+ m = reg >> cmp->m.shift;
+@@ -114,6 +118,10 @@ static int ccu_mp_set_rate(struct clk_hw
+ unsigned int m, p;
+ u32 reg;
+
++ /* Adjust parent_rate according to pre-dividers */
++ ccu_mux_helper_adjust_parent_for_prediv(&cmp->common, &cmp->mux,
++ -1, &parent_rate);
++
+ max_m = cmp->m.max ?: 1 << cmp->m.width;
+ max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
+
--- /dev/null
+From 9ad0bb39fce319d7b92c17d306ed0a9f70a02e7d Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@csie.org>
+Date: Tue, 14 Feb 2017 10:23:32 +0800
+Subject: clk: sunxi-ng: sun6i: Fix enable bit offset for hdmi-ddc module clock
+
+From: Chen-Yu Tsai <wens@csie.org>
+
+commit 9ad0bb39fce319d7b92c17d306ed0a9f70a02e7d upstream.
+
+The enable bit offset for the hdmi-ddc module clock is wrong. It is
+pointing to the main hdmi module clock enable bit.
+
+Reported-by: Bob Ham <rah@settrans.net>
+Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
++++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+@@ -608,7 +608,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_cl
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
+
+-static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(31), 0);
++static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(30), 0);
+
+ static SUNXI_CCU_GATE(ps_clk, "ps", "lcd1-ch1", 0x140, BIT(31), 0);
+
--- /dev/null
+From 7c468447f40645fbf2a033dfdaa92b1957130d50 Mon Sep 17 00:00:00 2001
+From: Gary R Hook <ghook@amd.com>
+Date: Fri, 10 Mar 2017 12:28:18 -0600
+Subject: crypto: ccp - Assign DMA commands to the channel's CCP
+
+From: Gary R Hook <ghook@amd.com>
+
+commit 7c468447f40645fbf2a033dfdaa92b1957130d50 upstream.
+
+The CCP driver generally uses a round-robin approach when
+assigning operations to available CCPs. For the DMA engine,
+however, the DMA mappings of the SGs are associated with a
+specific CCP. When an IOMMU is enabled, the IOMMU is
+programmed based on this specific device.
+
+If the DMA operations are not performed by that specific
+CCP then addressing errors and I/O page faults will occur.
+
+Update the CCP driver to allow a specific CCP device to be
+requested for an operation and use this in the DMA engine
+support.
+
+Signed-off-by: Gary R Hook <gary.hook@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/ccp/ccp-dev.c | 5 ++++-
+ drivers/crypto/ccp/ccp-dmaengine.c | 1 +
+ include/linux/ccp.h | 2 +-
+ 3 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/crypto/ccp/ccp-dev.c
++++ b/drivers/crypto/ccp/ccp-dev.c
+@@ -283,11 +283,14 @@ EXPORT_SYMBOL_GPL(ccp_version);
+ */
+ int ccp_enqueue_cmd(struct ccp_cmd *cmd)
+ {
+- struct ccp_device *ccp = ccp_get_device();
++ struct ccp_device *ccp;
+ unsigned long flags;
+ unsigned int i;
+ int ret;
+
++ /* Some commands might need to be sent to a specific device */
++ ccp = cmd->ccp ? cmd->ccp : ccp_get_device();
++
+ if (!ccp)
+ return -ENODEV;
+
+--- a/drivers/crypto/ccp/ccp-dmaengine.c
++++ b/drivers/crypto/ccp/ccp-dmaengine.c
+@@ -390,6 +390,7 @@ static struct ccp_dma_desc *ccp_create_d
+ goto err;
+
+ ccp_cmd = &cmd->ccp_cmd;
++ ccp_cmd->ccp = chan->ccp;
+ ccp_pt = &ccp_cmd->u.passthru_nomap;
+ ccp_cmd->flags = CCP_CMD_MAY_BACKLOG;
+ ccp_cmd->flags |= CCP_CMD_PASSTHRU_NO_DMA_MAP;
+--- a/include/linux/ccp.h
++++ b/include/linux/ccp.h
+@@ -556,7 +556,7 @@ enum ccp_engine {
+ * struct ccp_cmd - CPP operation request
+ * @entry: list element (ccp driver use only)
+ * @work: work element used for callbacks (ccp driver use only)
+- * @ccp: CCP device to be run on (ccp driver use only)
++ * @ccp: CCP device to be run on
+ * @ret: operation return code (ccp driver use only)
+ * @flags: cmd processing flags
+ * @engine: CCP operation to perform
--- /dev/null
+From 69db7009318758769d625b023402161c750f7876 Mon Sep 17 00:00:00 2001
+From: Prarit Bhargava <prarit@redhat.com>
+Date: Tue, 14 Mar 2017 07:36:01 -0400
+Subject: hwrng: amd - Revert managed API changes
+
+From: Prarit Bhargava <prarit@redhat.com>
+
+commit 69db7009318758769d625b023402161c750f7876 upstream.
+
+After commit 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"), the
+amd-rng driver uses devres with pci_dev->dev to keep track of resources,
+but does not actually register a PCI driver. This results in the
+following issues:
+
+1. The message
+
+WARNING: CPU: 2 PID: 621 at drivers/base/dd.c:349 driver_probe_device+0x38c
+
+is output when the i2c_amd756 driver loads and attempts to register a PCI
+driver. The PCI & device subsystems assume that no resources have been
+registered for the device, and the WARN_ON() triggers since amd-rng has
+already do so.
+
+2. The driver leaks memory because the driver does not attach to a
+device. The driver only uses the PCI device as a reference. devm_*()
+functions will release resources on driver detach, which the amd-rng
+driver will never do. As a result,
+
+3. The driver cannot be reloaded because there is always a use of the
+ioport and region after the first load of the driver.
+
+Revert the changes made by 31b2a73c9c5f ("hwrng: amd - Migrate to managed
+API").
+
+Signed-off-by: Prarit Bhargava <prarit@redhat.com>
+Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API").
+Cc: Matt Mackall <mpm@selenic.com>
+Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
+Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
+Cc: Wei Yongjun <weiyongjun1@huawei.com>
+Cc: linux-crypto@vger.kernel.org
+Cc: linux-geode@lists.infradead.org
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/hw_random/amd-rng.c | 42 +++++++++++++++++++++++++++++++--------
+ 1 file changed, 34 insertions(+), 8 deletions(-)
+
+--- a/drivers/char/hw_random/amd-rng.c
++++ b/drivers/char/hw_random/amd-rng.c
+@@ -55,6 +55,7 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
+ struct amd768_priv {
+ void __iomem *iobase;
+ struct pci_dev *pcidev;
++ u32 pmbase;
+ };
+
+ static int amd_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+@@ -148,33 +149,58 @@ found:
+ if (pmbase == 0)
+ return -EIO;
+
+- priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
++ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+- if (!devm_request_region(&pdev->dev, pmbase + PMBASE_OFFSET,
+- PMBASE_SIZE, DRV_NAME)) {
++ if (!request_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE, DRV_NAME)) {
+ dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
+ pmbase + 0xF0);
+- return -EBUSY;
++ err = -EBUSY;
++ goto out;
+ }
+
+- priv->iobase = devm_ioport_map(&pdev->dev, pmbase + PMBASE_OFFSET,
+- PMBASE_SIZE);
++ priv->iobase = ioport_map(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+ if (!priv->iobase) {
+ pr_err(DRV_NAME "Cannot map ioport\n");
+- return -ENOMEM;
++ err = -EINVAL;
++ goto err_iomap;
+ }
+
+ amd_rng.priv = (unsigned long)priv;
++ priv->pmbase = pmbase;
+ priv->pcidev = pdev;
+
+ pr_info(DRV_NAME " detected\n");
+- return devm_hwrng_register(&pdev->dev, &amd_rng);
++ err = hwrng_register(&amd_rng);
++ if (err) {
++ pr_err(DRV_NAME " registering failed (%d)\n", err);
++ goto err_hwrng;
++ }
++ return 0;
++
++err_hwrng:
++ ioport_unmap(priv->iobase);
++err_iomap:
++ release_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
++out:
++ kfree(priv);
++ return err;
+ }
+
+ static void __exit mod_exit(void)
+ {
++ struct amd768_priv *priv;
++
++ priv = (struct amd768_priv *)amd_rng.priv;
++
++ hwrng_unregister(&amd_rng);
++
++ ioport_unmap(priv->iobase);
++
++ release_region(priv->pmbase + PMBASE_OFFSET, PMBASE_SIZE);
++
++ kfree(priv);
+ }
+
+ module_init(mod_init);
--- /dev/null
+From 8c75704ebcac2ffa31ee7bcc359baf701b52bf00 Mon Sep 17 00:00:00 2001
+From: Prarit Bhargava <prarit@redhat.com>
+Date: Tue, 14 Mar 2017 07:36:02 -0400
+Subject: hwrng: geode - Revert managed API changes
+
+From: Prarit Bhargava <prarit@redhat.com>
+
+commit 8c75704ebcac2ffa31ee7bcc359baf701b52bf00 upstream.
+
+After commit e9afc746299d ("hwrng: geode - Use linux/io.h instead of
+asm/io.h") the geode-rng driver uses devres with pci_dev->dev to keep
+track of resources, but does not actually register a PCI driver. This
+results in the following issues:
+
+1. The driver leaks memory because the driver does not attach to a
+device. The driver only uses the PCI device as a reference. devm_*()
+functions will release resources on driver detach, which the geode-rng
+driver will never do. As a result,
+
+2. The driver cannot be reloaded because there is always a use of the
+ioport and region after the first load of the driver.
+
+Revert the changes made by e9afc746299d ("hwrng: geode - Use linux/io.h
+instead of asm/io.h").
+
+Signed-off-by: Prarit Bhargava <prarit@redhat.com>
+Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API")
+Cc: Matt Mackall <mpm@selenic.com>
+Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
+Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
+Cc: Wei Yongjun <weiyongjun1@huawei.com>
+Cc: linux-crypto@vger.kernel.org
+Cc: linux-geode@lists.infradead.org
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/hw_random/geode-rng.c | 50 +++++++++++++++++++++++++------------
+ 1 file changed, 35 insertions(+), 15 deletions(-)
+
+--- a/drivers/char/hw_random/geode-rng.c
++++ b/drivers/char/hw_random/geode-rng.c
+@@ -31,6 +31,9 @@
+ #include <linux/module.h>
+ #include <linux/pci.h>
+
++
++#define PFX KBUILD_MODNAME ": "
++
+ #define GEODE_RNG_DATA_REG 0x50
+ #define GEODE_RNG_STATUS_REG 0x54
+
+@@ -82,6 +85,7 @@ static struct hwrng geode_rng = {
+
+ static int __init mod_init(void)
+ {
++ int err = -ENODEV;
+ struct pci_dev *pdev = NULL;
+ const struct pci_device_id *ent;
+ void __iomem *mem;
+@@ -89,27 +93,43 @@ static int __init mod_init(void)
+
+ for_each_pci_dev(pdev) {
+ ent = pci_match_id(pci_tbl, pdev);
+- if (ent) {
+- rng_base = pci_resource_start(pdev, 0);
+- if (rng_base == 0)
+- return -ENODEV;
+-
+- mem = devm_ioremap(&pdev->dev, rng_base, 0x58);
+- if (!mem)
+- return -ENOMEM;
+- geode_rng.priv = (unsigned long)mem;
+-
+- pr_info("AMD Geode RNG detected\n");
+- return devm_hwrng_register(&pdev->dev, &geode_rng);
+- }
++ if (ent)
++ goto found;
+ }
+-
+ /* Device not found. */
+- return -ENODEV;
++ goto out;
++
++found:
++ rng_base = pci_resource_start(pdev, 0);
++ if (rng_base == 0)
++ goto out;
++ err = -ENOMEM;
++ mem = ioremap(rng_base, 0x58);
++ if (!mem)
++ goto out;
++ geode_rng.priv = (unsigned long)mem;
++
++ pr_info("AMD Geode RNG detected\n");
++ err = hwrng_register(&geode_rng);
++ if (err) {
++ pr_err(PFX "RNG registering failed (%d)\n",
++ err);
++ goto err_unmap;
++ }
++out:
++ return err;
++
++err_unmap:
++ iounmap(mem);
++ goto out;
+ }
+
+ static void __exit mod_exit(void)
+ {
++ void __iomem *mem = (void __iomem *)geode_rng.priv;
++
++ hwrng_unregister(&geode_rng);
++ iounmap(mem);
+ }
+
+ module_init(mod_init);
--- /dev/null
+From 5003ae1e735e6bfe4679d9bed6846274f322e77e Mon Sep 17 00:00:00 2001
+From: Koos Vriezen <koos.vriezen@gmail.com>
+Date: Wed, 1 Mar 2017 21:02:50 +0100
+Subject: iommu/vt-d: Fix NULL pointer dereference in device_to_iommu
+
+From: Koos Vriezen <koos.vriezen@gmail.com>
+
+commit 5003ae1e735e6bfe4679d9bed6846274f322e77e upstream.
+
+The function device_to_iommu() in the Intel VT-d driver
+lacks a NULL-ptr check, resulting in this oops at boot on
+some platforms:
+
+ BUG: unable to handle kernel NULL pointer dereference at 00000000000007ab
+ IP: [<ffffffff8132234a>] device_to_iommu+0x11a/0x1a0
+ PGD 0
+
+ [...]
+
+ Call Trace:
+ ? find_or_alloc_domain.constprop.29+0x1a/0x300
+ ? dw_dma_probe+0x561/0x580 [dw_dmac_core]
+ ? __get_valid_domain_for_dev+0x39/0x120
+ ? __intel_map_single+0x138/0x180
+ ? intel_alloc_coherent+0xb6/0x120
+ ? sst_hsw_dsp_init+0x173/0x420 [snd_soc_sst_haswell_pcm]
+ ? mutex_lock+0x9/0x30
+ ? kernfs_add_one+0xdb/0x130
+ ? devres_add+0x19/0x60
+ ? hsw_pcm_dev_probe+0x46/0xd0 [snd_soc_sst_haswell_pcm]
+ ? platform_drv_probe+0x30/0x90
+ ? driver_probe_device+0x1ed/0x2b0
+ ? __driver_attach+0x8f/0xa0
+ ? driver_probe_device+0x2b0/0x2b0
+ ? bus_for_each_dev+0x55/0x90
+ ? bus_add_driver+0x110/0x210
+ ? 0xffffffffa11ea000
+ ? driver_register+0x52/0xc0
+ ? 0xffffffffa11ea000
+ ? do_one_initcall+0x32/0x130
+ ? free_vmap_area_noflush+0x37/0x70
+ ? kmem_cache_alloc+0x88/0xd0
+ ? do_init_module+0x51/0x1c4
+ ? load_module+0x1ee9/0x2430
+ ? show_taint+0x20/0x20
+ ? kernel_read_file+0xfd/0x190
+ ? SyS_finit_module+0xa3/0xb0
+ ? do_syscall_64+0x4a/0xb0
+ ? entry_SYSCALL64_slow_path+0x25/0x25
+ Code: 78 ff ff ff 4d 85 c0 74 ee 49 8b 5a 10 0f b6 9b e0 00 00 00 41 38 98 e0 00 00 00 77 da 0f b6 eb 49 39 a8 88 00 00 00 72 ce eb 8f <41> f6 82 ab 07 00 00 04 0f 85 76 ff ff ff 0f b6 4d 08 88 0e 49
+ RIP [<ffffffff8132234a>] device_to_iommu+0x11a/0x1a0
+ RSP <ffffc90001457a78>
+ CR2: 00000000000007ab
+ ---[ end trace 16f974b6d58d0aad ]---
+
+Add the missing pointer check.
+
+Fixes: 1c387188c60f53b338c20eee32db055dfe022a9b ("iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions")
+Signed-off-by: Koos Vriezen <koos.vriezen@gmail.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/intel-iommu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iommu/intel-iommu.c
++++ b/drivers/iommu/intel-iommu.c
+@@ -915,7 +915,7 @@ static struct intel_iommu *device_to_iom
+ * which we used for the IOMMU lookup. Strictly speaking
+ * we could do this for all PCI devices; we only need to
+ * get the BDF# from the scope table for ACPI matches. */
+- if (pdev->is_virtfn)
++ if (pdev && pdev->is_virtfn)
+ goto got_pdev;
+
+ *bus = drhd->devices[i].bus;
--- /dev/null
+From e2ebfb2142acefecc2496e71360f50d25726040b Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 20 Mar 2017 19:50:29 +0200
+Subject: mmc: sdhci: Do not disable interrupts while waiting for clock
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit e2ebfb2142acefecc2496e71360f50d25726040b upstream.
+
+Disabling interrupts for even a millisecond can cause problems for some
+devices. That can happen when sdhci changes clock frequency because it
+waits for the clock to become stable under a spin lock.
+
+The spin lock is not necessary here. Anything that is racing with changes
+to the I/O state is already broken. The mmc core already provides
+synchronization via "claiming" the host.
+
+Although the spin lock probably should be removed from the code paths that
+lead to this point, such a patch would touch too much code to be suitable
+for stable trees. Consequently, for this patch, just drop the spin lock
+while waiting.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci.c
++++ b/drivers/mmc/host/sdhci.c
+@@ -1371,7 +1371,9 @@ void sdhci_set_clock(struct sdhci_host *
+ return;
+ }
+ timeout--;
+- mdelay(1);
++ spin_unlock_irq(&host->lock);
++ usleep_range(900, 1100);
++ spin_lock_irq(&host->lock);
+ }
+
+ clk |= SDHCI_CLOCK_CARD_EN;
--- /dev/null
+From 16681037e75ce08f2980ac5dbb03414429c7a55d Mon Sep 17 00:00:00 2001
+From: Anssi Hannula <anssi.hannula@bitwise.fi>
+Date: Mon, 13 Feb 2017 14:06:10 +0200
+Subject: mmc: sdhci-of-arasan: fix incorrect timeout clock
+
+From: Anssi Hannula <anssi.hannula@bitwise.fi>
+
+commit 16681037e75ce08f2980ac5dbb03414429c7a55d upstream.
+
+sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 <<
+(13 + divisor)).
+
+However, the divisor is not some Arasan-specific value, but instead is
+just the Data Timeout Counter Value from the SDHCI Timeout Control
+Register.
+
+Applying it here like this is wrong as the sdhci driver already takes
+that value into account when calculating timeouts, and in fact it *sets*
+that register value based on how long a timeout is wanted.
+
+Additionally, sdhci core interprets the .get_timeout_clock callback
+return value as if it were read from hardware registers, i.e. the unit
+should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit.
+This bit is set at least on the tested Zynq-7000 SoC.
+
+With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in
+too high a timeout clock rate being reported, causing the core to use
+longer-than-needed timeouts. Additionally, on a partitioned MMC
+(therefore having erase_group_def bit set) mmc_calc_max_discard()
+disables discard support as it looks like controller does not support
+the long timeouts needed for that.
+
+Do not apply the extra divisor and return the timeout clock in the
+expected unit.
+
+Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR
+eMMC card.
+
+Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
+Fixes: e3ec3a3d11ad ("mmc: arasan: Add driver for Arasan SDHCI")
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-of-arasan.c | 14 +++++---------
+ 1 file changed, 5 insertions(+), 9 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-of-arasan.c
++++ b/drivers/mmc/host/sdhci-of-arasan.c
+@@ -28,13 +28,9 @@
+ #include "sdhci-pltfm.h"
+ #include <linux/of.h>
+
+-#define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
+ #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
+
+ #define VENDOR_ENHANCED_STROBE BIT(0)
+-#define CLK_CTRL_TIMEOUT_SHIFT 16
+-#define CLK_CTRL_TIMEOUT_MASK (0xf << CLK_CTRL_TIMEOUT_SHIFT)
+-#define CLK_CTRL_TIMEOUT_MIN_EXP 13
+
+ #define PHY_CLK_TOO_SLOW_HZ 400000
+
+@@ -163,15 +159,15 @@ static int sdhci_arasan_syscon_write(str
+
+ static unsigned int sdhci_arasan_get_timeout_clock(struct sdhci_host *host)
+ {
+- u32 div;
+ unsigned long freq;
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+- div = readl(host->ioaddr + SDHCI_ARASAN_CLK_CTRL_OFFSET);
+- div = (div & CLK_CTRL_TIMEOUT_MASK) >> CLK_CTRL_TIMEOUT_SHIFT;
++ /* SDHCI timeout clock is in kHz */
++ freq = DIV_ROUND_UP(clk_get_rate(pltfm_host->clk), 1000);
+
+- freq = clk_get_rate(pltfm_host->clk);
+- freq /= 1 << (CLK_CTRL_TIMEOUT_MIN_EXP + div);
++ /* or in MHz */
++ if (host->caps & SDHCI_TIMEOUT_CLK_UNIT)
++ freq = DIV_ROUND_UP(freq, 1000);
+
+ return freq;
+ }
--- /dev/null
+From 2ce0c7b65505e0d915e99389cced45b478dc935d Mon Sep 17 00:00:00 2001
+From: Romain Izard <romain.izard.pro@gmail.com>
+Date: Thu, 9 Mar 2017 16:18:20 +0100
+Subject: mmc: sdhci-of-at91: Support external regulators
+
+From: Romain Izard <romain.izard.pro@gmail.com>
+
+commit 2ce0c7b65505e0d915e99389cced45b478dc935d upstream.
+
+The SDHCI controller in the SAMA5D2 chip requires a valid voltage set
+in the power control register, otherwise commands will fail with a
+timeout error.
+
+When using the regulator framework to specify the regulator used by the
+mmc device, the voltage is not configured, and it is not possible to use
+the connected device.
+
+Implement a custom 'set_power' function for this specific hardware, that
+configures the voltage in the register in all cases.
+
+Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
+Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-of-at91.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-of-at91.c
++++ b/drivers/mmc/host/sdhci-of-at91.c
+@@ -85,11 +85,30 @@ static void sdhci_at91_set_clock(struct
+ sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
+ }
+
++/*
++ * In this specific implementation of the SDHCI controller, the power register
++ * needs to have a valid voltage set even when the power supply is managed by
++ * an external regulator.
++ */
++static void sdhci_at91_set_power(struct sdhci_host *host, unsigned char mode,
++ unsigned short vdd)
++{
++ if (!IS_ERR(host->mmc->supply.vmmc)) {
++ struct mmc_host *mmc = host->mmc;
++
++ spin_unlock_irq(&host->lock);
++ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
++ spin_lock_irq(&host->lock);
++ }
++ sdhci_set_power_noreg(host, mode, vdd);
++}
++
+ static const struct sdhci_ops sdhci_at91_sama5d2_ops = {
+ .set_clock = sdhci_at91_set_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .reset = sdhci_reset,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
++ .set_power = sdhci_at91_set_power,
+ };
+
+ static const struct sdhci_pltfm_data soc_data_sama5d2 = {
--- /dev/null
+From 027fb89e61054b4aedd962adb3e2003dec78a716 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 20 Mar 2017 19:50:30 +0200
+Subject: mmc: sdhci-pci: Do not disable interrupts in sdhci_intel_set_power
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 027fb89e61054b4aedd962adb3e2003dec78a716 upstream.
+
+Disabling interrupts for even a millisecond can cause problems for some
+devices. That can happen when Intel host controllers wait for the present
+state to propagate.
+
+The spin lock is not necessary here. Anything that is racing with changes
+to the I/O state is already broken. The mmc core already provides
+synchronization via "claiming" the host.
+
+Although the spin lock probably should be removed from the code paths that
+lead to this point, such a patch would touch too much code to be suitable
+for stable trees. Consequently, for this patch, just drop the spin lock
+while waiting.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Tested-by: Ludovic Desroches <ludovic.desroches@microchip.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-pci-core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-pci-core.c
++++ b/drivers/mmc/host/sdhci-pci-core.c
+@@ -412,6 +412,8 @@ static void sdhci_intel_set_power(struct
+ if (mode == MMC_POWER_OFF)
+ return;
+
++ spin_unlock_irq(&host->lock);
++
+ /*
+ * Bus power might not enable after D3 -> D0 transition due to the
+ * present state not yet having propagated. Retry for up to 2ms.
+@@ -424,6 +426,8 @@ static void sdhci_intel_set_power(struct
+ reg |= SDHCI_POWER_ON;
+ sdhci_writeb(host, reg, SDHCI_POWER_CONTROL);
+ }
++
++ spin_lock_irq(&host->lock);
+ }
+
+ static const struct sdhci_ops sdhci_intel_byt_ops = {
--- /dev/null
+From 4e841d3eb9294ce4137fdb5d0a88f1bceab9c212 Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Fri, 10 Mar 2017 17:39:21 -0800
+Subject: mwifiex: pcie: don't leak DMA buffers when removing
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit 4e841d3eb9294ce4137fdb5d0a88f1bceab9c212 upstream.
+
+When PCIe FLR support was added, much of the remove/release code for
+PCIe was migrated to ->down_dev(), but ->down_dev() is never called for
+device removal. Let's refactor the cleanup to be done in both cases.
+
+Also, drop the comments above mwifiex_cleanup_pcie(), because they were
+clearly wrong, and it's better to have clear and obvious code than to
+detail the code steps in comments anyway.
+
+Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/marvell/mwifiex/pcie.c | 41 +++++++++++++---------------
+ 1 file changed, 20 insertions(+), 21 deletions(-)
+
+--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
++++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
+@@ -2700,6 +2700,21 @@ static void mwifiex_pcie_device_dump(str
+ schedule_work(&pcie_work);
+ }
+
++static void mwifiex_pcie_free_buffers(struct mwifiex_adapter *adapter)
++{
++ struct pcie_service_card *card = adapter->card;
++ const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
++
++ if (reg->sleep_cookie)
++ mwifiex_pcie_delete_sleep_cookie_buf(adapter);
++
++ mwifiex_pcie_delete_cmdrsp_buf(adapter);
++ mwifiex_pcie_delete_evtbd_ring(adapter);
++ mwifiex_pcie_delete_rxbd_ring(adapter);
++ mwifiex_pcie_delete_txbd_ring(adapter);
++ card->cmdrsp_buf = NULL;
++}
++
+ /*
+ * This function initializes the PCI-E host memory space, WCB rings, etc.
+ *
+@@ -2812,13 +2827,6 @@ err_enable_dev:
+
+ /*
+ * This function cleans up the allocated card buffers.
+- *
+- * The following are freed by this function -
+- * - TXBD ring buffers
+- * - RXBD ring buffers
+- * - Event BD ring buffers
+- * - Command response ring buffer
+- * - Sleep cookie buffer
+ */
+ static void mwifiex_pcie_cleanup(struct mwifiex_adapter *adapter)
+ {
+@@ -2834,6 +2842,8 @@ static void mwifiex_pcie_cleanup(struct
+ "Failed to write driver not-ready signature\n");
+ }
+
++ mwifiex_pcie_free_buffers(adapter);
++
+ if (pdev) {
+ pci_iounmap(pdev, card->pci_mmap);
+ pci_iounmap(pdev, card->pci_mmap1);
+@@ -3080,10 +3090,7 @@ err_cre_txbd:
+ pci_iounmap(pdev, card->pci_mmap1);
+ }
+
+-/* This function cleans up the PCI-E host memory space.
+- * Some code is extracted from mwifiex_unregister_dev()
+- *
+- */
++/* This function cleans up the PCI-E host memory space. */
+ static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
+ {
+ struct pcie_service_card *card = adapter->card;
+@@ -3095,16 +3102,8 @@ static void mwifiex_pcie_down_dev(struct
+ adapter->seq_num = 0;
+ adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K;
+
+- if (card) {
+- if (reg->sleep_cookie)
+- mwifiex_pcie_delete_sleep_cookie_buf(adapter);
+-
+- mwifiex_pcie_delete_cmdrsp_buf(adapter);
+- mwifiex_pcie_delete_evtbd_ring(adapter);
+- mwifiex_pcie_delete_rxbd_ring(adapter);
+- mwifiex_pcie_delete_txbd_ring(adapter);
+- card->cmdrsp_buf = NULL;
+- }
++ if (card)
++ mwifiex_pcie_free_buffers(adapter);
+
+ return;
+ }
ext4-mark-inode-dirty-after-converting-inline-directory.patch
ext4-lock-the-xattr-block-before-checksuming-it.patch
powerpc-64s-fix-idle-wakeup-potential-to-clobber-registers.patch
+mmc-sdhci-of-at91-support-external-regulators.patch
+mmc-sdhci-of-arasan-fix-incorrect-timeout-clock.patch
+mmc-sdhci-do-not-disable-interrupts-while-waiting-for-clock.patch
+mmc-sdhci-pci-do-not-disable-interrupts-in-sdhci_intel_set_power.patch
+hwrng-amd-revert-managed-api-changes.patch
+hwrng-geode-revert-managed-api-changes.patch
+clk-sunxi-ng-sun6i-fix-enable-bit-offset-for-hdmi-ddc-module-clock.patch
+clk-sunxi-ng-mp-adjust-parent-rate-for-pre-dividers.patch
+mwifiex-pcie-don-t-leak-dma-buffers-when-removing.patch
+crypto-ccp-assign-dma-commands-to-the-channel-s-ccp.patch
+xen-acpi-upload-pm-state-from-init-domain-to-xen.patch
+iommu-vt-d-fix-null-pointer-dereference-in-device_to_iommu.patch
--- /dev/null
+From 1914f0cd203c941bba72f9452c8290324f1ef3dc Mon Sep 17 00:00:00 2001
+From: Ankur Arora <ankur.a.arora@oracle.com>
+Date: Tue, 21 Mar 2017 15:43:38 -0700
+Subject: xen/acpi: upload PM state from init-domain to Xen
+
+From: Ankur Arora <ankur.a.arora@oracle.com>
+
+commit 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.
+
+This was broken in commit cd979883b9ed ("xen/acpi-processor:
+fix enabling interrupts on syscore_resume"). do_suspend (from
+xen/manage.c) and thus xen_resume_notifier never get called on
+the initial-domain at resume (it is if running as guest.)
+
+The rationale for the breaking change was that upload_pm_data()
+potentially does blocking work in syscore_resume(). This patch
+addresses the original issue by scheduling upload_pm_data() to
+execute in workqueue context.
+
+Cc: Stanislaw Gruszka <sgruszka@redhat.com>
+Based-on-patch-by: Konrad Wilk <konrad.wilk@oracle.com>
+Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/xen-acpi-processor.c | 34 ++++++++++++++++++++++++++--------
+ 1 file changed, 26 insertions(+), 8 deletions(-)
+
+--- a/drivers/xen/xen-acpi-processor.c
++++ b/drivers/xen/xen-acpi-processor.c
+@@ -27,10 +27,10 @@
+ #include <linux/init.h>
+ #include <linux/module.h>
+ #include <linux/types.h>
++#include <linux/syscore_ops.h>
+ #include <linux/acpi.h>
+ #include <acpi/processor.h>
+ #include <xen/xen.h>
+-#include <xen/xen-ops.h>
+ #include <xen/interface/platform.h>
+ #include <asm/xen/hypercall.h>
+
+@@ -466,15 +466,33 @@ static int xen_upload_processor_pm_data(
+ return rc;
+ }
+
+-static int xen_acpi_processor_resume(struct notifier_block *nb,
+- unsigned long action, void *data)
++static void xen_acpi_processor_resume_worker(struct work_struct *dummy)
+ {
++ int rc;
++
+ bitmap_zero(acpi_ids_done, nr_acpi_bits);
+- return xen_upload_processor_pm_data();
++
++ rc = xen_upload_processor_pm_data();
++ if (rc != 0)
++ pr_info("ACPI data upload failed, error = %d\n", rc);
++}
++
++static void xen_acpi_processor_resume(void)
++{
++ static DECLARE_WORK(wq, xen_acpi_processor_resume_worker);
++
++ /*
++ * xen_upload_processor_pm_data() calls non-atomic code.
++ * However, the context for xen_acpi_processor_resume is syscore
++ * with only the boot CPU online and in an atomic context.
++ *
++ * So defer the upload for some point safer.
++ */
++ schedule_work(&wq);
+ }
+
+-struct notifier_block xen_acpi_processor_resume_nb = {
+- .notifier_call = xen_acpi_processor_resume,
++static struct syscore_ops xap_syscore_ops = {
++ .resume = xen_acpi_processor_resume,
+ };
+
+ static int __init xen_acpi_processor_init(void)
+@@ -527,7 +545,7 @@ static int __init xen_acpi_processor_ini
+ if (rc)
+ goto err_unregister;
+
+- xen_resume_notifier_register(&xen_acpi_processor_resume_nb);
++ register_syscore_ops(&xap_syscore_ops);
+
+ return 0;
+ err_unregister:
+@@ -544,7 +562,7 @@ static void __exit xen_acpi_processor_ex
+ {
+ int i;
+
+- xen_resume_notifier_unregister(&xen_acpi_processor_resume_nb);
++ unregister_syscore_ops(&xap_syscore_ops);
+ kfree(acpi_ids_done);
+ kfree(acpi_id_present);
+ kfree(acpi_id_cst_present);