The patch below does not apply to the 5.2-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 740f05f30a8c49ec63668055d28feedd906d3c50 Mon Sep 17 00:00:00 2001
From: Sven Schnelle <svens(a)stackframe.org>
Date: Tue, 23 Jul 2019 22:37:54 +0200
Subject: [PATCH] parisc: fix race condition in patching code
Assume the following ftrace code sequence that was patched in earlier by
ftrace_make_call():
PAGE A:
ffc: addr of ftrace_caller()
PAGE B:
000: 0x6fc10080 /* stw,ma r1,40(sp) */
004: 0x48213fd1 /* ldw -18(r1),r1 */
008: 0xe820c002 /* bv,n r0(r1) */
00c: 0xe83f1fdf /* b,l,n .-c,r1 */
When a Code sequences that is to be patched spans a page break, we might
have already cleared the part on the PAGE A. If an interrupt is coming in
during the remap of the fixed mapping to PAGE B, it might execute the
patched function with only parts of the FTRACE code cleared. To prevent
this, clear the jump to our mini trampoline first, and clear the remaining
parts after this. This might also happen when patch_text() patches a
function that it calls during remap.
Signed-off-by: Sven Schnelle <svens(a)stackframe.org>
Cc: <stable(a)vger.kernel.org> # 5.2+
Signed-off-by: Helge Deller <deller(a)gmx.de>
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index d784ccdd8fef..b6fb30f2e4bf 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -181,8 +181,9 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
for (i = 0; i < ARRAY_SIZE(insn); i++)
insn[i] = INSN_NOP;
+ __patch_text((void *)rec->ip, INSN_NOP);
__patch_text_multiple((void *)rec->ip + 4 - sizeof(insn),
- insn, sizeof(insn));
+ insn, sizeof(insn)-4);
return 0;
}
#endif
From: Suganath Prabu S <suganath-prabu.subramani(a)broadcom.com>
Although SAS3 & SAS3.5 IT HBA controllers support
64-bit DMA addressing, as per hardware design,
if DMA able range contains all 64-bits set (0xFFFFFFFF-FFFFFFFF) then
it results in a firmware fault.
e.g. SGE's start address is 0xFFFFFFFF-FFFF000 and
data length is 0x1000 bytes. when HBA tries to DMA the data
at 0xFFFFFFFF-FFFFFFFF location then HBA will
fault the firmware.
Fix:
Driver will set 63-bit DMA mask to ensure the above address
will not be used.
Cc: <stable(a)vger.kernel.org> # 4.4.186, # 4.9.186
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani(a)broadcom.com>
---
Note:
This Patch is for stable kernel 4.4.186 and 4.9.186.
Original patch is applied to 5.3/scsi-fixes.
commit ID: df9a606184bfdb5ae3ca9d226184e9489f5c24f7
drivers/scsi/mpt3sas/mpt3sas_base.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 9b53672..7af7a08 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1686,9 +1686,11 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev)
{
struct sysinfo s;
u64 consistent_dma_mask;
+ /* Set 63 bit DMA mask for all SAS3 and SAS35 controllers */
+ int dma_mask = (ioc->hba_mpi_version_belonged > MPI2_VERSION) ? 63 : 64;
if (ioc->dma_mask)
- consistent_dma_mask = DMA_BIT_MASK(64);
+ consistent_dma_mask = DMA_BIT_MASK(dma_mask);
else
consistent_dma_mask = DMA_BIT_MASK(32);
@@ -1696,11 +1698,11 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev)
const uint64_t required_mask =
dma_get_required_mask(&pdev->dev);
if ((required_mask > DMA_BIT_MASK(32)) &&
- !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
+ !pci_set_dma_mask(pdev, DMA_BIT_MASK(dma_mask)) &&
!pci_set_consistent_dma_mask(pdev, consistent_dma_mask)) {
ioc->base_add_sg_single = &_base_add_sg_single_64;
ioc->sge_size = sizeof(Mpi2SGESimple64_t);
- ioc->dma_mask = 64;
+ ioc->dma_mask = dma_mask;
goto out;
}
}
@@ -1726,7 +1728,7 @@ static int
_base_change_consistent_dma_mask(struct MPT3SAS_ADAPTER *ioc,
struct pci_dev *pdev)
{
- if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+ if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(ioc->dma_mask))) {
if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32)))
return -ENODEV;
}
@@ -3325,7 +3327,7 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc, int sleep_flag)
total_sz += sz;
} while (ioc->rdpq_array_enable && (++i < ioc->reply_queue_count));
- if (ioc->dma_mask == 64) {
+ if (ioc->dma_mask > 32) {
if (_base_change_consistent_dma_mask(ioc, ioc->pdev) != 0) {
pr_warn(MPT3SAS_FMT
"no suitable consistent DMA mask for %s\n",
--
2.16.3
Hi Greg,
> -----Original Message-----
> From: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com>
> Sent: Thursday, February 14, 2019 6:08 PM
> To: linux-snps-arc(a)lists.infradead.org; Vineet Gupta <vgupta(a)synopsys.com>
> Cc: linux-kernel(a)vger.kernel.org; Alexey Brodkin <abrodkin(a)synopsys.com>; Corentin Labbe
> <clabbe(a)baylibre.com>; khilman(a)baylibre.com; Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com>
> Subject: [PATCH v2 2/2] ARC: enable uboot support unconditionally
>
> After reworking U-boot args handling code and adding paranoid
> arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and
> enable uboot support unconditionally.
>
> For JTAG case we can assume that core registers will come up
> reset value of 0 or in worst case we rely on user passing
> '-on=clear_regs' to Metaware debugger.
>
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com>
May we have this one back-ported to linux-4.19.y?
It was initially applied to Linus' tree during 5.0 development
cycle [1] but was never back-ported.
Now w/o that patch in KernelCI we see boot failure on ARC HSDK
board [2] as opposed to normally working later kernel versions.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
[2] https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfi…
Below is that same patch but rebased on linux-4.19 as in its pristine
form it won't apply due to offset of one of hunks.
-Alexey
------------------------------------>8--------------------------------
>From 3e565355f6a2d1a82bc9ecd47a46d1fa3c0cd2c1 Mon Sep 17 00:00:00 2001
From: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com>
Date: Thu, 14 Feb 2019 18:07:45 +0300
Subject: [PATCH] ARC: enable uboot support unconditionally
After reworking U-boot args handling code and adding paranoid
arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and
enable uboot support unconditionally.
For JTAG case we can assume that core registers will come up
reset value of 0 or in worst case we rely on user passing
'-on=clear_regs' to Metaware debugger.
Cc: stable(a)vger.kernel.org
Tested-by: Corentin LABBE <clabbe(a)baylibre.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com>
Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com>
---
arch/arc/Kconfig | 13 -------------
arch/arc/configs/nps_defconfig | 1 -
arch/arc/configs/vdk_hs38_defconfig | 1 -
arch/arc/configs/vdk_hs38_smp_defconfig | 2 --
arch/arc/kernel/head.S | 2 --
arch/arc/kernel/setup.c | 2 --
6 files changed, 21 deletions(-)
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 85eb7fc2e241..97b45fe8f0c2 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -199,7 +199,6 @@ config NR_CPUS
config ARC_SMP_HALT_ON_RESET
bool "Enable Halt-on-reset boot mode"
- default y if ARC_UBOOT_SUPPORT
help
In SMP configuration cores can be configured as Halt-on-reset
or they could all start at same time. For Halt-on-reset, non
@@ -538,18 +537,6 @@ config ARC_DBG_TLB_PARANOIA
endif
-config ARC_UBOOT_SUPPORT
- bool "Support uboot arg Handling"
- default n
- help
- ARC Linux by default checks for uboot provided args as pointers to
- external cmdline or DTB. This however breaks in absence of uboot,
- when booting from Metaware debugger directly, as the registers are
- not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus
- registers look like uboot args to kernel which then chokes.
- So only enable the uboot arg checking/processing if users are sure
- of uboot being in play.
-
config ARC_BUILTIN_DTB_NAME
string "Built in DTB"
help
diff --git a/arch/arc/configs/nps_defconfig b/arch/arc/configs/nps_defconfig
index 6e84060e7c90..621f59407d76 100644
--- a/arch/arc/configs/nps_defconfig
+++ b/arch/arc/configs/nps_defconfig
@@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5
# CONFIG_ARC_HAS_LLSC is not set
CONFIG_ARC_KVADDR_SIZE=402
CONFIG_ARC_EMUL_UNALIGNED=y
-CONFIG_ARC_UBOOT_SUPPORT=y
CONFIG_PREEMPT=y
CONFIG_NET=y
CONFIG_UNIX=y
diff --git a/arch/arc/configs/vdk_hs38_defconfig b/arch/arc/configs/vdk_hs38_defconfig
index 1e59a2e9c602..e447ace6fa1c 100644
--- a/arch/arc/configs/vdk_hs38_defconfig
+++ b/arch/arc/configs/vdk_hs38_defconfig
@@ -13,7 +13,6 @@ CONFIG_PARTITION_ADVANCED=y
CONFIG_ARC_PLAT_AXS10X=y
CONFIG_AXS103=y
CONFIG_ISA_ARCV2=y
-CONFIG_ARC_UBOOT_SUPPORT=y
CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38"
CONFIG_PREEMPT=y
CONFIG_NET=y
diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig b/arch/arc/configs/vdk_hs38_smp_defconfig
index b5c3f6c54b03..c82cdb10aaf4 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -15,8 +15,6 @@ CONFIG_AXS103=y
CONFIG_ISA_ARCV2=y
CONFIG_SMP=y
# CONFIG_ARC_TIMERS_64BIT is not set
-# CONFIG_ARC_SMP_HALT_ON_RESET is not set
-CONFIG_ARC_UBOOT_SUPPORT=y
CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38_smp"
CONFIG_PREEMPT=y
CONFIG_NET=y
diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S
index 208bf2c9e7b0..a72bbda2f7aa 100644
--- a/arch/arc/kernel/head.S
+++ b/arch/arc/kernel/head.S
@@ -100,7 +100,6 @@ ENTRY(stext)
st.ab 0, [r5, 4]
1:
-#ifdef CONFIG_ARC_UBOOT_SUPPORT
; Uboot - kernel ABI
; r0 = [0] No uboot interaction, [1] cmdline in r2, [2] DTB in r2
; r1 = magic number (always zero as of now)
@@ -109,7 +108,6 @@ ENTRY(stext)
st r0, [@uboot_tag]
st r1, [@uboot_magic]
st r2, [@uboot_arg]
-#endif
; setup "current" tsk and optionally cache it in dedicated r25
mov r9, @init_task
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index a1218937abd6..89c97dcfa360 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -493,7 +493,6 @@ void __init handle_uboot_args(void)
bool use_embedded_dtb = true;
bool append_cmdline = false;
-#ifdef CONFIG_ARC_UBOOT_SUPPORT
/* check that we know this tag */
if (uboot_tag != UBOOT_TAG_NONE &&
uboot_tag != UBOOT_TAG_CMDLINE &&
@@ -525,7 +524,6 @@ void __init handle_uboot_args(void)
append_cmdline = true;
ignore_uboot_args:
-#endif
if (use_embedded_dtb) {
machine_desc = setup_machine_fdt(__dtb_start);
--
2.16.2
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 25e5ef302c24a6fead369c0cfe88c073d7b97ca8 Mon Sep 17 00:00:00 2001
From: Jean Delvare <jdelvare(a)suse.de>
Date: Sun, 28 Jul 2019 18:41:38 +0200
Subject: [PATCH] eeprom: at24: make spd world-readable again
The integration of the at24 driver into the nvmem framework broke the
world-readability of spd EEPROMs. Fix it.
Signed-off-by: Jean Delvare <jdelvare(a)suse.de>
Cc: stable(a)vger.kernel.org
Fixes: 57d155506dd5 ("eeprom: at24: extend driver to plug into the NVMEM framework")
Cc: Andrew Lunn <andrew(a)lunn.ch>
Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Bartosz Golaszewski <brgl(a)bgdev.pl>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 35bf2477693d..518945b2f737 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -685,7 +685,7 @@ static int at24_probe(struct i2c_client *client)
nvmem_config.name = dev_name(dev);
nvmem_config.dev = dev;
nvmem_config.read_only = !writable;
- nvmem_config.root_only = true;
+ nvmem_config.root_only = !(flags & AT24_FLAG_IRUGO);
nvmem_config.owner = THIS_MODULE;
nvmem_config.compat = true;
nvmem_config.base_dev = dev;
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 95eef14cdad150fed43147bcd4f29eea3d0a3f03 Mon Sep 17 00:00:00 2001
From: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com>
Date: Mon, 10 Jun 2019 11:19:14 +0300
Subject: [PATCH] drm/i915/perf: fix ICL perf register offsets
We got the wrong offsets (could they have changed?). New values were
computed off an error state by looking up the register offset in the
context image as written by the HW.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com>
Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL")
Cc: <stable(a)vger.kernel.org> # v4.18+
Acked-by: Kenneth Graunke <kenneth(a)whitecape.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610081914.25428-1-lionel…
(cherry picked from commit 8dcfdfb4501012a8d36d2157dc73925715f2befb)
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a700c5c3d167..1ae06a1b6749 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3477,9 +3477,13 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.enable_metric_set = gen8_enable_metric_set;
dev_priv->perf.oa.ops.disable_metric_set = gen10_disable_metric_set;
- dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
- dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
-
+ if (IS_GEN(dev_priv, 10)) {
+ dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
+ dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
+ } else {
+ dev_priv->perf.oa.ctx_oactxctrl_offset = 0x124;
+ dev_priv->perf.oa.ctx_flexeu0_offset = 0x78e;
+ }
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
}
}
On Sat, 2019-07-20 at 12:23 +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.2.1, v5.1.18, v4.19.59, v4.14.133, v4.9.185, v4.4.185.
>
> v5.2.1: Build OK!
> v5.1.18: Build OK!
> v4.19.59: Build OK!
> v4.14.133: Build OK!
> v4.9.185: Failed to apply! Possible dependencies:
> 1f3706508395 ("iwlwifi: mvm: support unification of INIT and RT images")
> 42ce76d615e7 ("iwlwifi: mvm: spin off SAR profile selection function")
> 6996490501ed ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table")
> 7fe90e0e3d60 ("iwlwifi: mvm: refactor geo init")
> a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table")
> c386dacb4ed6 ("iwlwifi: mvm: refactor SAR init to prepare for dynamic SAR")
>
> v4.4.185: Failed to apply! Possible dependencies:
> 13555e8ba2f4 ("iwlwifi: mvm: add 9000-series RX API")
> 1a616dd2f171 ("iwlwifi: dump prph registers in a common place for all transports")
> 2f89a5d7d377 ("iwlwifi: mvm: move fw-dbg code to separate file")
> 321c2104f2f1 ("iwlwifi: mvm: Support setting continuous recording debug mode")
> 39bdb17ebb5b ("iwlwifi: update host command messages to new format")
> 42ce76d615e7 ("iwlwifi: mvm: spin off SAR profile selection function")
> 43413a975d06 ("iwlwifi: mvm: support rss queues configuration command")
> 4707fde5cdef ("iwlwifi: mvm: use build-time assertion for fw trigger ID")
> 6c4fbcbc1c95 ("iwlwifi: add support for 12K Receive Buffers")
> 854d773e4ab5 ("iwlwifi: mvm: improve RSS configuration")
> 92fe83430b89 ("iwlwifi: uninline iwl_trans_send_cmd")
> 9e7dce286595 ("iwlwifi: mvm: allow to limit the A-MSDU from debugfs")
> da2830acf15a ("iwlwifi: mvm: read SAR BIOS table from ACPI")
> dcbb4746286a ("iwlwifi: trans: support a callback for ASYNC commands")
> dd4d3161d0f2 ("iwlwifi: mvm: fix RSS key sizing")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
Hi Sasha,
In this specific case, the patch does not have to be applied on 4.9 and
4.4. What is the right way to handle these cases? Should I simply
ignore them, so they won't go into those kernels by default or do you
want me to follow up somehow and let you know that those kernels can be
ignore?
--
Cheers,
Luca.