December 2017 - Linux-stable-mirror

[Linux-stable-mirror] Patch "ath9k: fix tx99 potential info leak" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath9k: fix tx99 potential info leak to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath9k-fix-tx99-potential-info-leak.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:29:00 CET 2017 From: Miaoqing Pan <miaoqing(a)codeaurora.org> Date: Wed, 27 Sep 2017 09:13:34 +0800 Subject: ath9k: fix tx99 potential info leak From: Miaoqing Pan <miaoqing(a)codeaurora.org> [ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ] When the user sets count to zero the string buffer would remain completely uninitialized which causes the kernel to parse its own stack data, potentially leading to an info leak. In addition to that, the string might be not terminated properly when the user data does not contain a 0-terminator. Signed-off-by: Miaoqing Pan <miaoqing(a)codeaurora.org> Reviewed-by: Christoph Böhmwalder <christoph(a)boehmwalder.at> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath9k/tx99.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/wireless/ath/ath9k/tx99.c +++ b/drivers/net/wireless/ath/ath9k/tx99.c @@ -179,6 +179,9 @@ static ssize_t write_file_tx99(struct fi ssize_t len; int r; + if (count < 1) + return -EINVAL; + if (sc->cur_chan->nvifs > 1) return -EOPNOTSUPP; @@ -186,6 +189,8 @@ static ssize_t write_file_tx99(struct fi if (copy_from_user(buf, user_buf, len)) return -EFAULT; + buf[len] = '\0'; + if (strtobool(buf, &start)) return -EINVAL; Patches currently in stable-queue which might be from miaoqing(a)codeaurora.org are queue-4.14/ath9k-fix-tx99-potential-info-leak.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: fix core PCI suspend when WoWLAN is supported but disabled" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: fix core PCI suspend when WoWLAN is supported but disabled to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:29:00 CET 2017 From: Brian Norris <briannorris(a)chromium.org> Date: Wed, 4 Oct 2017 12:22:55 +0300 Subject: ath10k: fix core PCI suspend when WoWLAN is supported but disabled From: Brian Norris <briannorris(a)chromium.org> [ Upstream commit 96378bd2c6cda5f04d0f6da2cd35d4670a982c38 ] For devices where the FW supports WoWLAN but user-space has not configured it, we don't do any PCI-specific suspend/resume operations, because mac80211 doesn't call drv_suspend() when !wowlan. This has particularly bad effects for some platforms, because we don't stop the power-save timer, and if this timer goes off after the PCI controller has suspended the link, Bad Things will happen. Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops") got some of this right, in that it understood there was a problem on non-WoWLAN firmware. But it forgot the $subject case. Fix this by moving all the PCI driver suspend/resume logic exclusively into the driver PM hooks. This shouldn't affect WoWLAN support much (this just gets executed later on). I would just as well kill the entirety of ath10k_hif_suspend(), as it's not even implemented on the USB or SDIO drivers. I expect that we don't need the callback, except to return "supported" (i.e., 0) or "not supported" (i.e., -EOPNOTSUPP). Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops") Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving") Signed-off-by: Brian Norris <briannorris(a)chromium.org> Cc: Ryan Hsu <ryanhsu(a)qti.qualcomm.com> Cc: Kalle Valo <kvalo(a)qca.qualcomm.com> Cc: Michal Kazior <michal.kazior(a)tieto.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/pci.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -2581,6 +2581,12 @@ void ath10k_pci_hif_power_down(struct at static int ath10k_pci_hif_suspend(struct ath10k *ar) { + /* Nothing to do; the important stuff is in the driver suspend. */ + return 0; +} + +static int ath10k_pci_suspend(struct ath10k *ar) +{ /* The grace timer can still be counting down and ar->ps_awake be true. * It is known that the device may be asleep after resuming regardless * of the SoC powersave state before suspending. Hence make sure the @@ -2593,6 +2599,12 @@ static int ath10k_pci_hif_suspend(struct static int ath10k_pci_hif_resume(struct ath10k *ar) { + /* Nothing to do; the important stuff is in the driver resume. */ + return 0; +} + +static int ath10k_pci_resume(struct ath10k *ar) +{ struct ath10k_pci *ar_pci = ath10k_pci_priv(ar); struct pci_dev *pdev = ar_pci->pdev; u32 val; @@ -3401,11 +3413,7 @@ static __maybe_unused int ath10k_pci_pm_ struct ath10k *ar = dev_get_drvdata(dev); int ret; - if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT, - ar->running_fw->fw_file.fw_features)) - return 0; - - ret = ath10k_hif_suspend(ar); + ret = ath10k_pci_suspend(ar); if (ret) ath10k_warn(ar, "failed to suspend hif: %d\n", ret); @@ -3417,11 +3425,7 @@ static __maybe_unused int ath10k_pci_pm_ struct ath10k *ar = dev_get_drvdata(dev); int ret; - if (test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT, - ar->running_fw->fw_file.fw_features)) - return 0; - - ret = ath10k_hif_resume(ar); + ret = ath10k_pci_resume(ar); if (ret) ath10k_warn(ar, "failed to resume hif: %d\n", ret); Patches currently in stable-queue which might be from briannorris(a)chromium.org are queue-4.14/ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch queue-4.14/ath10k-fix-build-errors-with-config_pm.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: fix build errors with !CONFIG_PM" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: fix build errors with !CONFIG_PM to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath10k-fix-build-errors-with-config_pm.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:29:00 CET 2017 From: Brian Norris <briannorris(a)chromium.org> Date: Thu, 19 Oct 2017 11:45:19 -0700 Subject: ath10k: fix build errors with !CONFIG_PM From: Brian Norris <briannorris(a)chromium.org> [ Upstream commit 20665a9076d48e9abd9a2db13d307f58f7ef6647 ] Build errors have been reported with CONFIG_PM=n: drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit declaration of function 'ath10k_pci_suspend' [-Werror=implicit-function-declaration] drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit declaration of function 'ath10k_pci_resume' [-Werror=implicit-function-declaration] These are caused by the combination of the following two commits: 6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused") 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but disabled") Both build fine on their own. But now that ath10k_pci_pm_{suspend,resume}() is compiled unconditionally, we should also compile ath10k_pci_{suspend,resume}() unconditionally. And drop the #ifdef around ath10k_pci_hif_{suspend,resume}() too; they are trivial (empty), so we're not saving much space by compiling them out. And the alternatives would be to sprinkle more __maybe_unused, or spread the #ifdef's further. Build tested with the following combinations: CONFIG_PM=y && CONFIG_PM_SLEEP=y CONFIG_PM=y && CONFIG_PM_SLEEP=n CONFIG_PM=n Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but disabled") Fixes: 096ad2a15fd8 ("Merge branch 'ath-next'") Signed-off-by: Brian Norris <briannorris(a)chromium.org> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/pci.c | 5 ----- 1 file changed, 5 deletions(-) --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -2577,8 +2577,6 @@ void ath10k_pci_hif_power_down(struct at */ } -#ifdef CONFIG_PM - static int ath10k_pci_hif_suspend(struct ath10k *ar) { /* Nothing to do; the important stuff is in the driver suspend. */ @@ -2627,7 +2625,6 @@ static int ath10k_pci_resume(struct ath1 return ret; } -#endif static bool ath10k_pci_validate_cal(void *data, size_t size) { @@ -2782,10 +2779,8 @@ static const struct ath10k_hif_ops ath10 .power_down = ath10k_pci_hif_power_down, .read32 = ath10k_pci_read32, .write32 = ath10k_pci_write32, -#ifdef CONFIG_PM .suspend = ath10k_pci_hif_suspend, .resume = ath10k_pci_hif_resume, -#endif .fetch_cal_eeprom = ath10k_pci_hif_fetch_cal_eeprom, }; Patches currently in stable-queue which might be from briannorris(a)chromium.org are queue-4.14/ath10k-fix-core-pci-suspend-when-wowlan-is-supported-but-disabled.patch queue-4.14/ath10k-fix-build-errors-with-config_pm.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:28:59 CET 2017 From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Date: Wed, 1 Nov 2017 07:16:58 +0000 Subject: ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> [ Upstream commit 21781e87881f9c420871b1d1f3f29d4cd7bffb10 ] SSI parent mod might be NULL. ssi_parent_mod() needs to care about it. Otherwise, it uses negative shift. This patch fixes it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/sh/rcar/ssi.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/sound/soc/sh/rcar/ssi.c +++ b/sound/soc/sh/rcar/ssi.c @@ -198,10 +198,15 @@ static u32 rsnd_ssi_run_mods(struct rsnd { struct rsnd_mod *ssi_mod = rsnd_io_to_mod_ssi(io); struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io); + u32 mods; - return rsnd_ssi_multi_slaves_runtime(io) | - 1 << rsnd_mod_id(ssi_mod) | - 1 << rsnd_mod_id(ssi_parent_mod); + mods = rsnd_ssi_multi_slaves_runtime(io) | + 1 << rsnd_mod_id(ssi_mod); + + if (ssi_parent_mod) + mods |= 1 << rsnd_mod_id(ssi_parent_mod); + + return mods; } u32 rsnd_ssi_multi_slaves_runtime(struct rsnd_dai_stream *io) Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are queue-4.14/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch queue-4.14/asoc-rsnd-rsnd_ssi_run_mods-needs-to-care-ssi_parent_mod.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-intel-skylake-fix-uuid_module-memory-leak-in-failure-case.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:28:59 CET 2017 From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com> Date: Tue, 7 Nov 2017 16:16:19 +0530 Subject: ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case From: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com> [ Upstream commit f8e066521192c7debe59127d90abbe2773577e25 ] In the loop that adds the uuid_module to the uuid_list list, allocated memory is not properly freed in the error path free uuid_list whenever any of the memory allocation in the loop fails to avoid memory leak. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya(a)intel.com> Signed-off-by: Guneshwor Singh <guneshwor.o.singh(a)intel.com> Acked-By: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/skylake/skl-sst-utils.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) --- a/sound/soc/intel/skylake/skl-sst-utils.c +++ b/sound/soc/intel/skylake/skl-sst-utils.c @@ -251,6 +251,7 @@ int snd_skl_parse_uuids(struct sst_dsp * struct uuid_module *module; struct firmware stripped_fw; unsigned int safe_file; + int ret = 0; /* Get the FW pointer to derive ADSP header */ stripped_fw.data = fw->data; @@ -299,8 +300,10 @@ int snd_skl_parse_uuids(struct sst_dsp * for (i = 0; i < num_entry; i++, mod_entry++) { module = kzalloc(sizeof(*module), GFP_KERNEL); - if (!module) - return -ENOMEM; + if (!module) { + ret = -ENOMEM; + goto free_uuid_list; + } uuid_bin = (uuid_le *)mod_entry->uuid.id; memcpy(&module->uuid, uuid_bin, sizeof(module->uuid)); @@ -311,8 +314,8 @@ int snd_skl_parse_uuids(struct sst_dsp * size = sizeof(int) * mod_entry->instance_max_count; module->instance_id = devm_kzalloc(ctx->dev, size, GFP_KERNEL); if (!module->instance_id) { - kfree(module); - return -ENOMEM; + ret = -ENOMEM; + goto free_uuid_list; } list_add_tail(&module->list, &skl->uuid_list); @@ -323,6 +326,10 @@ int snd_skl_parse_uuids(struct sst_dsp * } return 0; + +free_uuid_list: + skl_freeup_uuid_list(skl); + return ret; } void skl_freeup_uuid_list(struct skl_sst *ctx) Patches currently in stable-queue which might be from pankaj.laxminarayan.bharadiya(a)intel.com are queue-4.14/asoc-intel-skylake-fix-uuid_module-memory-leak-in-failure-case.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:28:59 CET 2017 From: Nick Desaulniers <ndesaulniers(a)google.com> Date: Fri, 27 Oct 2017 09:33:41 -0700 Subject: arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27 From: Nick Desaulniers <ndesaulniers(a)google.com> [ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ] Upon upgrading to binutils 2.27, we found that our lz4 and gzip compressed kernel images were significantly larger, resulting is 10ms boot time regressions. As noted by Rahul: "aarch64 binaries uses RELA relocations, where each relocation entry includes an addend value. This is similar to x86_64. On x86_64, the addend values are also stored at the relocation offset for relative relocations. This is an optimization: in the case where code does not need to be relocated, the loader can simply skip processing relative relocations. In binutils-2.25, both bfd and gold linkers did this for x86_64, but only the gold linker did this for aarch64. The kernel build here is using the bfd linker, which stored zeroes at the relocation offsets for relative relocations. Since a set of zeroes compresses better than a set of non-zero addend values, this behavior was resulting in much better lz4 compression. The bfd linker in binutils-2.27 is now storing the actual addend values at the relocation offsets. The behavior is now consistent with what it does for x86_64 and what gold linker does for both architectures. The change happened in this upstream commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=1f56df9d0d5ad8980… Since a bunch of zeroes got replaced by non-zero addend values, we see the side effect of lz4 compressed image being a bit bigger. To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs" flag can be used: $ LDFLAGS="--no-apply-dynamic-relocs" make With this flag, the compressed image size is back to what it was with binutils-2.25. If the kernel is using ASLR, there aren't additional runtime costs to --no-apply-dynamic-relocs, as the relocations will need to be applied again anyway after the kernel is relocated to a random address. If the kernel is not using ASLR, then presumably the current default behavior of the linker is better. Since the static linker performed the dynamic relocs, and the kernel is not moved to a different address at load time, it can skip applying the relocations all over again." Some measurements: $ ld -v GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117 ^ $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb $ ld -v GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315 ^ pre patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb post patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb By Siqi's measurement w/ gzip: binutils 2.27 with this patch (with --no-apply-dynamic-relocs): Image 41535488 Image.gz 13404067 binutils 2.27 without this patch (without --no-apply-dynamic-relocs): Image 41535488 Image.gz 14125516 Any compression scheme should be able to get better results from the longer runs of zeros, not just GZIP and LZ4. 10ms boot time savings isn't anything to get excited about, but users of arm64+compression+bfd-2.27 should not have to pay a penalty for no runtime improvement. Reported-by: Gopinath Elanchezhian <gelanchezhian(a)google.com> Reported-by: Sindhuri Pentyala <spentyala(a)google.com> Reported-by: Wei Wang <wvw(a)google.com> Suggested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Suggested-by: Rahul Chaudhry <rahulchaudhry(a)google.com> Suggested-by: Siqi Lin <siqilin(a)google.com> Suggested-by: Stephen Hines <srhines(a)google.com> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [will: added comment to Makefile] Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/Makefile | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -14,8 +14,12 @@ LDFLAGS_vmlinux :=-p --no-undefined -X CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET) GZFLAGS :=-9 -ifneq ($(CONFIG_RELOCATABLE),) -LDFLAGS_vmlinux += -pie -shared -Bsymbolic +ifeq ($(CONFIG_RELOCATABLE), y) +# Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour +# for relative relocs, since this leads to better Image compression +# with the relocation offsets always being zero. +LDFLAGS_vmlinux += -pie -shared -Bsymbolic \ + $(call ld-option, --no-apply-dynamic-relocs) endif ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) Patches currently in stable-queue which might be from ndesaulniers(a)google.com are queue-4.14/arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-dts-meson-gxbb-odroidc2-fix-usb1-power-supply.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:28:59 CET 2017 From: Neil Armstrong <narmstrong(a)baylibre.com> Date: Thu, 19 Oct 2017 12:31:09 +0200 Subject: ARM64: dts: meson-gxbb-odroidc2: fix usb1 power supply From: Neil Armstrong <narmstrong(a)baylibre.com> [ Upstream commit e841ec956e539f4002f5e9fe9f9e904dcca12d5d ] Looking at the schematics, the USB Power Supply is shared between the two USB interfaces, If the usb0 fails to initialize, the second one won't have power. Fixes: 5a0803bd5ae2 ("ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes") Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts @@ -301,6 +301,7 @@ &usb1_phy { status = "okay"; + phy-supply = <&usb_otg_pwr>; }; &usb0 { Patches currently in stable-queue which might be from narmstrong(a)baylibre.com are queue-4.14/arm64-dts-meson-gxbb-odroidc2-fix-usb1-power-supply.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "arm-ccn: perf: Prevent module unload while PMU is in use" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm-ccn: perf: Prevent module unload while PMU is in use to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 13:28:59 CET 2017 From: Suzuki K Poulose <suzuki.poulose(a)arm.com> Date: Fri, 3 Nov 2017 11:45:18 +0000 Subject: arm-ccn: perf: Prevent module unload while PMU is in use From: Suzuki K Poulose <suzuki.poulose(a)arm.com> [ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ] When the PMU driver is built as a module, the perf expects the pmu->module to be valid, so that the driver is prevented from being unloaded while it is in use. Fix the CCN pmu driver to fill in this field. Fixes: a33b0daab73a0 ("bus: ARM CCN PMU driver") Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1280,6 +1280,7 @@ static int arm_ccn_pmu_init(struct arm_c /* Perf driver registration */ ccn->dt.pmu = (struct pmu) { + .module = THIS_MODULE, .attr_groups = arm_ccn_pmu_attr_groups, .task_ctx_nr = perf_invalid_context, .event_init = arm_ccn_pmu_event_init, Patches currently in stable-queue which might be from suzuki.poulose(a)arm.com are queue-4.14/arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "usb: add helper to extract bits 12:11 of wMaxPacketSize" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: add helper to extract bits 12:11 of wMaxPacketSize to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-add-helper-to-extract-bits-12-11-of-wmaxpacketsize.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 541b6fe63023f3059cf85d47ff2767a3e42a8e44 Mon Sep 17 00:00:00 2001 From: Felipe Balbi <felipe.balbi(a)linux.intel.com> Date: Mon, 26 Sep 2016 10:51:18 +0300 Subject: usb: add helper to extract bits 12:11 of wMaxPacketSize From: Felipe Balbi <felipe.balbi(a)linux.intel.com> commit 541b6fe63023f3059cf85d47ff2767a3e42a8e44 upstream. According to USB Specification 2.0 table 9-4, wMaxPacketSize is a bitfield. Endpoint's maxpacket is laid out in bits 10:0. For high-speed, high-bandwidth isochronous endpoints, bits 12:11 contain a multiplier to tell us how many transactions we want to try per uframe. This means that if we want an isochronous endpoint to issue 3 transfers of 1024 bytes per uframe, wMaxPacketSize should contain the value: 1024 | (2 << 11) or 5120 (0x1400). In order to make Host and Peripheral controller drivers' life easier, we're adding a helper which returns bits 12:11. Note that no care is made WRT to checking endpoint type and gadget's speed. That's left for drivers to handle. Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/uapi/linux/usb/ch9.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) --- a/include/uapi/linux/usb/ch9.h +++ b/include/uapi/linux/usb/ch9.h @@ -423,6 +423,11 @@ struct usb_endpoint_descriptor { #define USB_ENDPOINT_XFER_INT 3 #define USB_ENDPOINT_MAX_ADJUSTABLE 0x80 +#define USB_EP_MAXP_MULT_SHIFT 11 +#define USB_EP_MAXP_MULT_MASK (3 << USB_EP_MAXP_MULT_SHIFT) +#define USB_EP_MAXP_MULT(m) \ + (((m) & USB_EP_MAXP_MULT_MASK) >> USB_EP_MAXP_MULT_SHIFT) + /* The USB 3.0 spec redefines bits 5:4 of bmAttributes as interrupt ep type. */ #define USB_ENDPOINT_INTRTYPE 0x30 #define USB_ENDPOINT_INTR_PERIODIC (0 << 4) @@ -630,6 +635,20 @@ static inline int usb_endpoint_maxp(cons return __le16_to_cpu(epd->wMaxPacketSize); } +/** + * usb_endpoint_maxp_mult - get endpoint's transactional opportunities + * @epd: endpoint to be checked + * + * Return @epd's wMaxPacketSize[12:11] + 1 + */ +static inline int +usb_endpoint_maxp_mult(const struct usb_endpoint_descriptor *epd) +{ + int maxp = __le16_to_cpu(epd->wMaxPacketSize); + + return USB_EP_MAXP_MULT(maxp) + 1; +} + static inline int usb_endpoint_interrupt_type( const struct usb_endpoint_descriptor *epd) { Patches currently in stable-queue which might be from felipe.balbi(a)linux.intel.com are queue-4.9/usb-add-helper-to-extract-bits-12-11-of-wmaxpacketsize.patch

7 years

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] ovl: fix overlay: warning prefix

by Amir Goldstein

On Wed, Nov 22, 2017 at 8:27 PM, Amir Goldstein <amir73il(a)gmail.com> wrote: > Conform two stray warning messages to the standard overlayfs: prefix. > > Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> > --- Greg, Upstream commit ("da2e6b7eeda8 ovl: fix overlay: warning prefix") was not marked for stable, because it is not a bug fix per-se. Nevertheless, it may be useful to apply it to stable kernels to keep overlayfs bug reports/analysis consistent. The first hunk fixes (#v4.10): a6c606551141 ovl: redirect on rename-dir The second hunk fixes (#v4.14): b5efccbe0a12 ovl: constant d_ino across copy up For your consideration. If you wish, I can send a patch for v4.10 with just the first hunk. Thanks, Amir.

7 years

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2017