--- /dev/null
+From 60b89f1928af80b546b5c3fd8714a62f6f4b8844 Mon Sep 17 00:00:00 2001
+From: Nicolas Ferre <nicolas.ferre@microchip.com>
+Date: Tue, 14 Mar 2017 09:38:04 +0100
+Subject: ARM: at91: pm: cpu_idle: switch DDR to power-down mode
+
+From: Nicolas Ferre <nicolas.ferre@microchip.com>
+
+commit 60b89f1928af80b546b5c3fd8714a62f6f4b8844 upstream.
+
+On some DDR controllers, compatible with the sama5d3 one,
+the sequence to enter/exit/re-enter the self-refresh mode adds
+more constrains than what is currently written in the at91_idle
+driver. An actual access to the DDR chip is needed between exit
+and re-enter of this mode which is somehow difficult to implement.
+This sequence can completely hang the SoC. It is particularly
+experienced on parts which embed a L2 cache if the code run
+between IDLE calls fits in it...
+
+Moreover, as the intention is to enter and exit pretty rapidly
+from IDLE, the power-down mode is a good candidate.
+
+So now we use power-down instead of self-refresh. As we can
+simplify the code for sama5d3 compatible DDR controllers,
+we instantiate a new sama5d3_ddr_standby() function.
+
+Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Fixes: 017b5522d5e3 ("ARM: at91: Add new binding for sama5d3-ddramc")
+Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-at91/pm.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/mach-at91/pm.c
++++ b/arch/arm/mach-at91/pm.c
+@@ -286,6 +286,22 @@ static void at91_ddr_standby(void)
+ at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
+ }
+
++static void sama5d3_ddr_standby(void)
++{
++ u32 lpr0;
++ u32 saved_lpr0;
++
++ saved_lpr0 = at91_ramc_read(0, AT91_DDRSDRC_LPR);
++ lpr0 = saved_lpr0 & ~AT91_DDRSDRC_LPCB;
++ lpr0 |= AT91_DDRSDRC_LPCB_POWER_DOWN;
++
++ at91_ramc_write(0, AT91_DDRSDRC_LPR, lpr0);
++
++ cpu_do_idle();
++
++ at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr0);
++}
++
+ /* We manage both DDRAM/SDRAM controllers, we need more than one value to
+ * remember.
+ */
+@@ -320,7 +336,7 @@ static const struct of_device_id const r
+ { .compatible = "atmel,at91rm9200-sdramc", .data = at91rm9200_standby },
+ { .compatible = "atmel,at91sam9260-sdramc", .data = at91sam9_sdram_standby },
+ { .compatible = "atmel,at91sam9g45-ddramc", .data = at91_ddr_standby },
+- { .compatible = "atmel,sama5d3-ddramc", .data = at91_ddr_standby },
++ { .compatible = "atmel,sama5d3-ddramc", .data = sama5d3_ddr_standby },
+ { /*sentinel*/ }
+ };
+
--- /dev/null
+From b1708b72a0959a032cd2eebb77fa9086ea3e0c84 Mon Sep 17 00:00:00 2001
+From: Nicolas Ferre <nicolas.ferre@atmel.com>
+Date: Tue, 26 Jan 2016 17:30:18 +0100
+Subject: ARM: dts: at91: sama5d2: add dma properties to UART nodes
+
+From: Nicolas Ferre <nicolas.ferre@atmel.com>
+
+commit b1708b72a0959a032cd2eebb77fa9086ea3e0c84 upstream.
+
+The dmas/dma-names properties are added to the UART nodes. Note that additional
+properties are needed to enable them at the board level: check bindings for
+details.
+
+Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
+Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/sama5d2.dtsi | 35 +++++++++++++++++++++++++++++++++++
+ 1 file changed, 35 insertions(+)
+
+--- a/arch/arm/boot/dts/sama5d2.dtsi
++++ b/arch/arm/boot/dts/sama5d2.dtsi
+@@ -856,6 +856,13 @@
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xf801c000 0x100>;
+ interrupts = <24 IRQ_TYPE_LEVEL_HIGH 7>;
++ dmas = <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(35))>,
++ <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(36))>;
++ dma-names = "tx", "rx";
+ clocks = <&uart0_clk>;
+ clock-names = "usart";
+ status = "disabled";
+@@ -865,6 +872,13 @@
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xf8020000 0x100>;
+ interrupts = <25 IRQ_TYPE_LEVEL_HIGH 7>;
++ dmas = <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(37))>,
++ <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(38))>;
++ dma-names = "tx", "rx";
+ clocks = <&uart1_clk>;
+ clock-names = "usart";
+ status = "disabled";
+@@ -874,6 +888,13 @@
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xf8024000 0x100>;
+ interrupts = <26 IRQ_TYPE_LEVEL_HIGH 7>;
++ dmas = <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(39))>,
++ <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(40))>;
++ dma-names = "tx", "rx";
+ clocks = <&uart2_clk>;
+ clock-names = "usart";
+ status = "disabled";
+@@ -985,6 +1006,13 @@
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfc008000 0x100>;
+ interrupts = <27 IRQ_TYPE_LEVEL_HIGH 7>;
++ dmas = <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(41))>,
++ <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(42))>;
++ dma-names = "tx", "rx";
+ clocks = <&uart3_clk>;
+ clock-names = "usart";
+ status = "disabled";
+@@ -993,6 +1021,13 @@
+ uart4: serial@fc00c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfc00c000 0x100>;
++ dmas = <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(43))>,
++ <&dma0
++ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
++ AT91_XDMAC_DT_PERID(44))>;
++ dma-names = "tx", "rx";
+ interrupts = <28 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <&uart4_clk>;
+ clock-names = "usart";
--- /dev/null
+From ff010472fb75670cb5c08671e820eeea3af59c87 Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Tue, 21 Mar 2017 11:36:06 +0530
+Subject: cpufreq: Restore policy min/max limits on CPU online
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+commit ff010472fb75670cb5c08671e820eeea3af59c87 upstream.
+
+On CPU online the cpufreq core restores the previous governor (or
+the previous "policy" setting for ->setpolicy drivers), but it does
+not restore the min/max limits at the same time, which is confusing,
+inconsistent and real pain for users who set the limits and then
+suspend/resume the system (using full suspend), in which case the
+limits are reset on all CPUs except for the boot one.
+
+Fix this by making cpufreq_online() restore the limits when an inactive
+policy is brought online.
+
+The commit log and patch are inspired from Rafael's earlier work.
+
+Reported-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/cpufreq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/cpufreq/cpufreq.c
++++ b/drivers/cpufreq/cpufreq.c
+@@ -1186,6 +1186,9 @@ static int cpufreq_online(unsigned int c
+ for_each_cpu(j, policy->related_cpus)
+ per_cpu(cpufreq_cpu_data, j) = policy;
+ write_unlock_irqrestore(&cpufreq_driver_lock, flags);
++ } else {
++ policy->min = policy->user_policy.min;
++ policy->max = policy->user_policy.max;
+ }
+
+ if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
--- /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
+@@ -908,7 +908,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 633ee407b9d15a75ac9740ba9d3338815e1fcb95 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Tue, 21 Mar 2017 13:44:28 +0100
+Subject: libceph: force GFP_NOIO for socket allocations
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit 633ee407b9d15a75ac9740ba9d3338815e1fcb95 upstream.
+
+sock_alloc_inode() allocates socket+inode and socket_wq with
+GFP_KERNEL, which is not allowed on the writeback path:
+
+ Workqueue: ceph-msgr con_work [libceph]
+ ffff8810871cb018 0000000000000046 0000000000000000 ffff881085d40000
+ 0000000000012b00 ffff881025cad428 ffff8810871cbfd8 0000000000012b00
+ ffff880102fc1000 ffff881085d40000 ffff8810871cb038 ffff8810871cb148
+ Call Trace:
+ [<ffffffff816dd629>] schedule+0x29/0x70
+ [<ffffffff816e066d>] schedule_timeout+0x1bd/0x200
+ [<ffffffff81093ffc>] ? ttwu_do_wakeup+0x2c/0x120
+ [<ffffffff81094266>] ? ttwu_do_activate.constprop.135+0x66/0x70
+ [<ffffffff816deb5f>] wait_for_completion+0xbf/0x180
+ [<ffffffff81097cd0>] ? try_to_wake_up+0x390/0x390
+ [<ffffffff81086335>] flush_work+0x165/0x250
+ [<ffffffff81082940>] ? worker_detach_from_pool+0xd0/0xd0
+ [<ffffffffa03b65b1>] xlog_cil_force_lsn+0x81/0x200 [xfs]
+ [<ffffffff816d6b42>] ? __slab_free+0xee/0x234
+ [<ffffffffa03b4b1d>] _xfs_log_force_lsn+0x4d/0x2c0 [xfs]
+ [<ffffffff811adc1e>] ? lookup_page_cgroup_used+0xe/0x30
+ [<ffffffffa039a723>] ? xfs_reclaim_inode+0xa3/0x330 [xfs]
+ [<ffffffffa03b4dcf>] xfs_log_force_lsn+0x3f/0xf0 [xfs]
+ [<ffffffffa039a723>] ? xfs_reclaim_inode+0xa3/0x330 [xfs]
+ [<ffffffffa03a62c6>] xfs_iunpin_wait+0xc6/0x1a0 [xfs]
+ [<ffffffff810aa250>] ? wake_atomic_t_function+0x40/0x40
+ [<ffffffffa039a723>] xfs_reclaim_inode+0xa3/0x330 [xfs]
+ [<ffffffffa039ac07>] xfs_reclaim_inodes_ag+0x257/0x3d0 [xfs]
+ [<ffffffffa039bb13>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
+ [<ffffffffa03ab745>] xfs_fs_free_cached_objects+0x15/0x20 [xfs]
+ [<ffffffff811c0c18>] super_cache_scan+0x178/0x180
+ [<ffffffff8115912e>] shrink_slab_node+0x14e/0x340
+ [<ffffffff811afc3b>] ? mem_cgroup_iter+0x16b/0x450
+ [<ffffffff8115af70>] shrink_slab+0x100/0x140
+ [<ffffffff8115e425>] do_try_to_free_pages+0x335/0x490
+ [<ffffffff8115e7f9>] try_to_free_pages+0xb9/0x1f0
+ [<ffffffff816d56e4>] ? __alloc_pages_direct_compact+0x69/0x1be
+ [<ffffffff81150cba>] __alloc_pages_nodemask+0x69a/0xb40
+ [<ffffffff8119743e>] alloc_pages_current+0x9e/0x110
+ [<ffffffff811a0ac5>] new_slab+0x2c5/0x390
+ [<ffffffff816d71c4>] __slab_alloc+0x33b/0x459
+ [<ffffffff815b906d>] ? sock_alloc_inode+0x2d/0xd0
+ [<ffffffff8164bda1>] ? inet_sendmsg+0x71/0xc0
+ [<ffffffff815b906d>] ? sock_alloc_inode+0x2d/0xd0
+ [<ffffffff811a21f2>] kmem_cache_alloc+0x1a2/0x1b0
+ [<ffffffff815b906d>] sock_alloc_inode+0x2d/0xd0
+ [<ffffffff811d8566>] alloc_inode+0x26/0xa0
+ [<ffffffff811da04a>] new_inode_pseudo+0x1a/0x70
+ [<ffffffff815b933e>] sock_alloc+0x1e/0x80
+ [<ffffffff815ba855>] __sock_create+0x95/0x220
+ [<ffffffff815baa04>] sock_create_kern+0x24/0x30
+ [<ffffffffa04794d9>] con_work+0xef9/0x2050 [libceph]
+ [<ffffffffa04aa9ec>] ? rbd_img_request_submit+0x4c/0x60 [rbd]
+ [<ffffffff81084c19>] process_one_work+0x159/0x4f0
+ [<ffffffff8108561b>] worker_thread+0x11b/0x530
+ [<ffffffff81085500>] ? create_worker+0x1d0/0x1d0
+ [<ffffffff8108b6f9>] kthread+0xc9/0xe0
+ [<ffffffff8108b630>] ? flush_kthread_worker+0x90/0x90
+ [<ffffffff816e1b98>] ret_from_fork+0x58/0x90
+ [<ffffffff8108b630>] ? flush_kthread_worker+0x90/0x90
+
+Use memalloc_noio_{save,restore}() to temporarily force GFP_NOIO here.
+
+Link: http://tracker.ceph.com/issues/19309
+Reported-by: Sergey Jerusalimov <wintchester@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Reviewed-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/ceph/messenger.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/net/ceph/messenger.c
++++ b/net/ceph/messenger.c
+@@ -7,6 +7,7 @@
+ #include <linux/kthread.h>
+ #include <linux/net.h>
+ #include <linux/nsproxy.h>
++#include <linux/sched.h>
+ #include <linux/slab.h>
+ #include <linux/socket.h>
+ #include <linux/string.h>
+@@ -478,11 +479,16 @@ static int ceph_tcp_connect(struct ceph_
+ {
+ struct sockaddr_storage *paddr = &con->peer_addr.in_addr;
+ struct socket *sock;
++ unsigned int noio_flag;
+ int ret;
+
+ BUG_ON(con->sock);
++
++ /* sock_create_kern() allocates with GFP_KERNEL */
++ noio_flag = memalloc_noio_save();
+ ret = sock_create_kern(read_pnet(&con->msgr->net), paddr->ss_family,
+ SOCK_STREAM, IPPROTO_TCP, &sock);
++ memalloc_noio_restore(noio_flag);
+ if (ret)
+ return ret;
+ sock->sk->sk_allocation = GFP_NOFS;
--- /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
+@@ -1274,7 +1274,9 @@ clock_set:
+ return;
+ }
+ timeout--;
+- mdelay(1);
++ spin_unlock_irq(&host->lock);
++ usleep_range(900, 1100);
++ spin_lock_irq(&host->lock);
+ }
+
+ clk |= SDHCI_CLOCK_CARD_EN;
iio-hid-sensor-trigger-change-get-poll-value-function-order-to-avoid-sensor-properties-losing-after-resume-from-s3.patch
parport-fix-attempt-to-write-duplicate-procfiles.patch
ext4-mark-inode-dirty-after-converting-inline-directory.patch
+mmc-sdhci-do-not-disable-interrupts-while-waiting-for-clock.patch
+xen-acpi-upload-pm-state-from-init-domain-to-xen.patch
+iommu-vt-d-fix-null-pointer-dereference-in-device_to_iommu.patch
+arm-at91-pm-cpu_idle-switch-ddr-to-power-down-mode.patch
+arm-dts-at91-sama5d2-add-dma-properties-to-uart-nodes.patch
+cpufreq-restore-policy-min-max-limits-on-cpu-online.patch
+libceph-force-gfp_noio-for-socket-allocations.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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
