--- /dev/null
+From ce938231bd3b1d7af3cbd8836f084801090470e1 Mon Sep 17 00:00:00 2001
+From: "Daniel F. Dickinson" <cshored@thecshore.com>
+Date: Sat, 22 Dec 2018 01:09:13 -0500
+Subject: ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom
+
+From: Daniel F. Dickinson <cshored@thecshore.com>
+
+commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream.
+
+ath9k_of_init() function[0] was initially written on the assumption that
+if someone had an explicit ath9k OF node that "there must be something
+wrong, why would someone add an OF node if everything is fine"[1]
+(Quoting Martin Blumenstingl <martin.blumenstingl@googlemail.com>)
+
+"it turns out it's not that simple. with your requirements I'm now aware
+of two use-cases where the current code in ath9k_of_init() doesn't work
+without modifications"[1]
+
+The "your requirements" Martin speaks of is the result of the fact that I
+have a device (PowerCloud Systems CR5000) has some kind of default - not
+unique mac address - set and requires to set the correct MAC address via
+mac-address devicetree property, however:
+
+"some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom"
+should not be set (your use-case). in this case AH_USE_EEPROM should be
+set (which is the default when there is no OF node)"[1]
+
+The other use case is:
+
+the firmware on some PowerMac G5 seems to add a OF node for the ath9k
+card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP
+should be unset (which is the default when there is no OF node). see [3]
+
+After this patch to ath9k_of_init() the new behavior will be:
+
+ if there's no OF node then everything is the same as before
+ if there's an empty OF node then ath9k will use the hardware EEPROM
+ (before ath9k would fail to initialize because no EEPROM data was
+ provided by userspace)
+ if there's an OF node with only a MAC address then ath9k will use
+ the MAC address and the hardware EEPROM (see the case above)
+ with "qca,no-eeprom" EEPROM data from userspace will be requested.
+ the behavior here will not change
+[1]
+
+Martin provides additional background on EEPROM swapping[1].
+
+Thanks to Christian Lamparter <chunkeey@gmail.com> for all his help on
+troubleshooting this issue and the basis for this patch.
+
+[0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615
+[1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
+[2]https://github.com/openwrt/openwrt/pull/1613
+[3]https://patchwork.kernel.org/patch/10241731/
+
+Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node")
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Signed-off-by: Daniel F. Dickinson <cshored@thecshore.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Cc: Christian Lamparter <chunkeey@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/ath/ath9k/init.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath9k/init.c
++++ b/drivers/net/wireless/ath/ath9k/init.c
+@@ -580,15 +580,15 @@ static int ath9k_of_init(struct ath_soft
+ ret = ath9k_eeprom_request(sc, eeprom_name);
+ if (ret)
+ return ret;
++
++ ah->ah_flags &= ~AH_USE_EEPROM;
++ ah->ah_flags |= AH_NO_EEP_SWAP;
+ }
+
+ mac = of_get_mac_address(np);
+ if (mac)
+ ether_addr_copy(common->macaddr, mac);
+
+- ah->ah_flags &= ~AH_USE_EEPROM;
+- ah->ah_flags |= AH_NO_EEP_SWAP;
+-
+ return 0;
+ }
+
--- /dev/null
+From 376991db4b6464e906d699ef07681e2ffa8ab08c Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Thu, 7 Feb 2019 20:36:53 +0100
+Subject: driver core: Postpone DMA tear-down until after devres release
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit 376991db4b6464e906d699ef07681e2ffa8ab08c upstream.
+
+When unbinding the (IOMMU-enabled) R-Car SATA device on Salvator-XS
+(R-Car H3 ES2.0), in preparation of rebinding against vfio-platform for
+device pass-through for virtualization:
+
+ echo ee300000.sata > /sys/bus/platform/drivers/sata_rcar/unbind
+
+the kernel crashes with:
+
+ Unable to handle kernel paging request at virtual address ffffffbf029ffffc
+ Mem abort info:
+ ESR = 0x96000006
+ Exception class = DABT (current EL), IL = 32 bits
+ SET = 0, FnV = 0
+ EA = 0, S1PTW = 0
+ Data abort info:
+ ISV = 0, ISS = 0x00000006
+ CM = 0, WnR = 0
+ swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000007e8c586c
+ [ffffffbf029ffffc] pgd=000000073bfc6003, pud=000000073bfc6003, pmd=0000000000000000
+ Internal error: Oops: 96000006 [#1] SMP
+ Modules linked in:
+ CPU: 0 PID: 1098 Comm: bash Not tainted 5.0.0-rc5-salvator-x-00452-g37596f884f4318ef #287
+ Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
+ pstate: 60400005 (nZCv daif +PAN -UAO)
+ pc : __free_pages+0x8/0x58
+ lr : __dma_direct_free_pages+0x50/0x5c
+ sp : ffffff801268baa0
+ x29: ffffff801268baa0 x28: 0000000000000000
+ x27: ffffffc6f9c60bf0 x26: ffffffc6f9c60bf0
+ x25: ffffffc6f9c60810 x24: 0000000000000000
+ x23: 00000000fffff000 x22: ffffff8012145000
+ x21: 0000000000000800 x20: ffffffbf029fffc8
+ x19: 0000000000000000 x18: ffffffc6f86c42c8
+ x17: 0000000000000000 x16: 0000000000000070
+ x15: 0000000000000003 x14: 0000000000000000
+ x13: ffffff801103d7f8 x12: 0000000000000028
+ x11: ffffff8011117604 x10: 0000000000009ad8
+ x9 : ffffff80110126d0 x8 : ffffffc6f7563000
+ x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000018
+ x5 : ffffff8011cf3cc8 x4 : 0000000000004000
+ x3 : 0000000000080000 x2 : 0000000000000001
+ x1 : 0000000000000000 x0 : ffffffbf029fffc8
+ Process bash (pid: 1098, stack limit = 0x00000000c38e3e32)
+ Call trace:
+ __free_pages+0x8/0x58
+ __dma_direct_free_pages+0x50/0x5c
+ arch_dma_free+0x1c/0x98
+ dma_direct_free+0x14/0x24
+ dma_free_attrs+0x9c/0xdc
+ dmam_release+0x18/0x20
+ release_nodes+0x25c/0x28c
+ devres_release_all+0x48/0x4c
+ device_release_driver_internal+0x184/0x1f0
+ device_release_driver+0x14/0x1c
+ unbind_store+0x70/0xb8
+ drv_attr_store+0x24/0x34
+ sysfs_kf_write+0x4c/0x64
+ kernfs_fop_write+0x154/0x1c4
+ __vfs_write+0x34/0x164
+ vfs_write+0xb4/0x16c
+ ksys_write+0x5c/0xbc
+ __arm64_sys_write+0x14/0x1c
+ el0_svc_common+0x98/0x114
+ el0_svc_handler+0x1c/0x24
+ el0_svc+0x8/0xc
+ Code: d51b4234 17fffffa a9bf7bfd 910003fd (b9403404)
+ ---[ end trace 8c564cdd3a1a840f ]---
+
+While I've bisected this to commit e8e683ae9a736407 ("iommu/of: Fix
+probe-deferral"), and reverting that commit on post-v5.0-rc4 kernels
+does fix the problem, this turned out to be a red herring.
+
+On arm64, arch_teardown_dma_ops() resets dev->dma_ops to NULL.
+Hence if a driver has used a managed DMA allocation API, the allocated
+DMA memory will be freed using the direct DMA ops, while it may have
+been allocated using a custom DMA ops (iommu_dma_ops in this case).
+
+Fix this by reversing the order of the calls to devres_release_all() and
+arch_teardown_dma_ops().
+
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Acked-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+[rm: backport for 4.12-4.19 - kernels before 5.0 will not see
+ the crash above, but may get silent memory corruption instead]
+Signed-off-by: Robin Murphy <robin.murphy@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/dd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/base/dd.c
++++ b/drivers/base/dd.c
+@@ -850,9 +850,9 @@ static void __device_release_driver(stru
+ drv->remove(dev);
+
+ device_links_driver_cleanup(dev);
+- dma_deconfigure(dev);
+
+ devres_release_all(dev);
++ dma_deconfigure(dev);
+ dev->driver = NULL;
+ dev_set_drvdata(dev, NULL);
+ if (dev->pm_domain && dev->pm_domain->dismiss)
--- /dev/null
+From 605b0487f0bc1ae9963bf52ece0f5c8055186f81 Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher <agruenba@redhat.com>
+Date: Wed, 6 Mar 2019 15:41:57 +0100
+Subject: gfs2: Fix missed wakeups in find_insert_glock
+
+From: Andreas Gruenbacher <agruenba@redhat.com>
+
+commit 605b0487f0bc1ae9963bf52ece0f5c8055186f81 upstream.
+
+Mark Syms has reported seeing tasks that are stuck waiting in
+find_insert_glock. It turns out that struct lm_lockname contains four padding
+bytes on 64-bit architectures that function glock_waitqueue doesn't skip when
+hashing the glock name. As a result, we can end up waking up the wrong
+waitqueue, and the waiting tasks may be stuck forever.
+
+Fix that by using ht_parms.key_len instead of sizeof(struct lm_lockname) for
+the key length.
+
+Reported-by: Mark Syms <mark.syms@citrix.com>
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/gfs2/glock.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/gfs2/glock.c
++++ b/fs/gfs2/glock.c
+@@ -107,7 +107,7 @@ static int glock_wake_function(wait_queu
+
+ static wait_queue_head_t *glock_waitqueue(struct lm_lockname *name)
+ {
+- u32 hash = jhash2((u32 *)name, sizeof(*name) / 4, 0);
++ u32 hash = jhash2((u32 *)name, ht_parms.key_len / 4, 0);
+
+ return glock_wait_table + hash_32(hash, GLOCK_WAIT_TABLE_BITS);
+ }
arm-dts-exynos-add-minimal-clkout-parameters-to-exynos3250-pmu.patch
drm-disable-uncached-dma-optimization-for-arm-and-ar.patch
arm-8781-1-fix-thumb-2-syscall-return-for-binutils-2.patch
+gfs2-fix-missed-wakeups-in-find_insert_glock.patch
+ath9k-avoid-of-no-eeprom-quirks-without-qca-no-eeprom.patch
+driver-core-postpone-dma-tear-down-until-after-devres-release.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
