March 2019 - Linux-stable-mirror

by Arnd Bergmann

clang points out with hundreds of warnings that the bitrev macros have a problem with constant input: drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization [-Werror,-Wuninitialized] u8 crc = bitrev8(data->val_status & 0x0F); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8' __constant_bitrev8(__x) : \ ~~~~~~~~~~~~~~~~~~~^~~~ include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8' u8 __x = x; \ ~~~ ^ Both the bitrev and the __constant_bitrev macros use an internal variable named __x, which goes horribly wrong when passing one to the other. The obvious fix is to rename one of the variables, so this adds an extra '_'. It seems we got away with this because - there are only a few drivers using bitrev macros - usually there are no constant arguments to those - when they are constant, they tend to be either 0 or (unsigned)-1 (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and give the correct result by pure chance. In fact, the only driver that I could find that gets different results with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver for fairly rare hardware (adding the maintainer to Cc for testing). Cc: Zhao Qiang <qiang.zhao(a)nxp.com> Cc: Yalin Wang <yalin.wang(a)sonymobile.com> Cc: stable(a)vger.kernel.org Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- include/linux/bitrev.h | 46 +++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h index 50fb0dee23e8..d35b8ec1c485 100644 --- a/include/linux/bitrev.h +++ b/include/linux/bitrev.h @@ -34,41 +34,41 @@ static inline u32 __bitrev32(u32 x) #define __constant_bitrev32(x) \ ({ \ - u32 __x = x; \ - __x = (__x >> 16) | (__x << 16); \ - __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = (___x >> 16) | (___x << 16); \ + ___x = ((___x & (u32)0xFF00FF00UL) >> 8) | ((___x & (u32)0x00FF00FFUL) << 8); \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev16(x) \ ({ \ - u16 __x = x; \ - __x = (__x >> 8) | (__x << 8); \ - __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \ - __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \ - __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \ - __x; \ + u16 ___x = x; \ + ___x = (___x >> 8) | (___x << 8); \ + ___x = ((___x & (u16)0xF0F0U) >> 4) | ((___x & (u16)0x0F0FU) << 4); \ + ___x = ((___x & (u16)0xCCCCU) >> 2) | ((___x & (u16)0x3333U) << 2); \ + ___x = ((___x & (u16)0xAAAAU) >> 1) | ((___x & (u16)0x5555U) << 1); \ + ___x; \ }) #define __constant_bitrev8x4(x) \ ({ \ - u32 __x = x; \ - __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \ - __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \ - __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \ - __x; \ + u32 ___x = x; \ + ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \ + ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \ + ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \ + ___x; \ }) #define __constant_bitrev8(x) \ ({ \ - u8 __x = x; \ - __x = (__x >> 4) | (__x << 4); \ - __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \ - __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \ - __x; \ + u8 ___x = x; \ + ___x = (___x >> 4) | (___x << 4); \ + ___x = ((___x & (u8)0xCCU) >> 2) | ((___x & (u8)0x33U) << 2); \ + ___x = ((___x & (u8)0xAAU) >> 1) | ((___x & (u8)0x55U) << 1); \ + ___x; \ }) #define bitrev32(x) \ -- 2.20.0

5 years, 9 months

2
1
0 0

"HID: sony: Update device ids" Patch breaks bluetooth connectivity on 4.4.x

by Souhrid Nandi

Commit in question: https://lkml.org/lkml/2018/9/27/647 Device tested on: OnePlus 5 Android Version: 9, Pie Kernel Version: 4.4.177 (Personal Kernel) This patch seems to break Bluetooth connectivity for DualShock 4 controllers on 4.4. Reverting it fixes the issue, reported and confirmed by one of my users. I've confirmed that this happens on other devices of the same kernel version (4.4.y) - Redmi Note 5 Pro and other OnePlus 5/5T's for kernels that have this commit.

5 years, 9 months

2
1
0 0

Re: [PATCH] mm: Fix modifying of page protection by insert_pfn()

by Jan Kara

On Mon 25-03-19 00:38:20, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: b2770da64254 mm: add vm_insert_mixed_mkwrite(). > > The bot has tested the following trees: v5.0.3, v4.19.30, v4.14.107. > > v5.0.3: Build OK! > v4.19.30: Failed to apply! Possible dependencies: > f2c57d91b0d9 ("mm: Fix warning in insert_pfn()") > > v4.14.107: Failed to apply! Possible dependencies: > f2c57d91b0d9 ("mm: Fix warning in insert_pfn()") > > > How should we proceed with this patch? I'd say apply also f2c57d91b0d9 to both trees. Nice automation BTW :). Honza -- Jan Kara <jack(a)suse.com> SUSE Labs, CR

5 years, 9 months

1
0
0 0

[PATCH] ASoC: intel: Fix crash at suspend/resume after failed codec registration

by Guenter Roeck

If codec registration fails after the ASoC Intel SST driver has been probed, the kernel will Oops and crash at suspend/resume. general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 2811 Comm: cat Tainted: G W 4.19.30 #15 Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014 RIP: 0010:snd_soc_suspend+0x5a/0xd21 Code: 03 80 3c 10 00 49 89 d7 74 0b 48 89 df e8 71 72 c4 fe 4c 89 fa 48 8b 03 48 89 45 d0 48 8d 98 a0 01 00 00 48 89 d8 48 c1 e8 03 <8a> 04 10 84 c0 0f 85 85 0c 00 00 80 3b 00 0f 84 6b 0c 00 00 48 8b RSP: 0018:ffff888035407750 EFLAGS: 00010202 RAX: 0000000000000034 RBX: 00000000000001a0 RCX: 0000000000000000 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88805c417098 RBP: ffff8880354077b0 R08: dffffc0000000000 R09: ffffed100b975718 R10: 0000000000000001 R11: ffffffff949ea4a3 R12: 1ffff1100b975746 R13: dffffc0000000000 R14: ffff88805cba4588 R15: dffffc0000000000 FS: 0000794a78e91b80(0000) GS:ffff888068d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007bd5283ccf58 CR3: 000000004b7aa000 CR4: 00000000001006e0 Call Trace: ? dpm_complete+0x67b/0x67b ? i915_gem_suspend+0x14d/0x1ad sst_soc_prepare+0x91/0x1dd ? sst_be_hw_params+0x7e/0x7e dpm_prepare+0x39a/0x88b dpm_suspend_start+0x13/0x9d suspend_devices_and_enter+0x18f/0xbd7 ? arch_suspend_enable_irqs+0x11/0x11 ? printk+0xd9/0x12d ? lock_release+0x95f/0x95f ? log_buf_vmcoreinfo_setup+0x131/0x131 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? __pm_pr_dbg+0x186/0x190 ? pm_notifier_call_chain+0x39/0x39 ? suspend_test+0x9d/0x9d pm_suspend+0x2f4/0x728 ? trace_suspend_resume+0x3da/0x3da ? lock_release+0x95f/0x95f ? kernfs_fop_write+0x19f/0x32d state_store+0xd8/0x147 ? sysfs_kf_read+0x155/0x155 kernfs_fop_write+0x23e/0x32d __vfs_write+0x108/0x608 ? vfs_read+0x2e9/0x2e9 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? debug_smp_processor_id+0x10/0x10 ? selinux_file_permission+0x1c5/0x3c8 ? rcu_sync_lockdep_assert+0x6a/0xad ? __sb_start_write+0x129/0x2ac vfs_write+0x1aa/0x434 ksys_write+0xfe/0x1be ? __ia32_sys_read+0x82/0x82 do_syscall_64+0xcd/0x120 entry_SYSCALL_64_after_hwframe+0x49/0xbe In the observed situation, the problem is seen because the codec driver failed to probe due to a hardware problem. max98090 i2c-193C9890:00: Failed to read device revision: -1 max98090 i2c-193C9890:00: ASoC: failed to probe component -1 cht-bsw-max98090 cht-bsw-max98090: ASoC: failed to instantiate card -1 cht-bsw-max98090 cht-bsw-max98090: snd_soc_register_card failed -1 cht-bsw-max98090: probe of cht-bsw-max98090 failed with error -1 The problem is similar to the problem solved with commit 2fc995a87f2e ("ASoC: intel: Fix crash at suspend/resume without card registration"), but codec registration fails at a later point. At that time, the pointer checked with the above mentioned commit is already set, but it is not cleared if the device is subsequently removed. Adding a remove function to clear the pointer fixes the problem. Cc: stable(a)vger.kernel.org Cc: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> Cc: Curtis Malainey <cujomalainey(a)chromium.org> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index 08cea5b5cda9..0e8b1c5eec88 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -706,9 +706,17 @@ static int sst_soc_probe(struct snd_soc_component *component) return sst_dsp_init_v2_dpcm(component); } +static void sst_soc_remove(struct snd_soc_component *component) +{ + struct sst_data *drv = dev_get_drvdata(component->dev); + + drv->soc_card = NULL; +} + static const struct snd_soc_component_driver sst_soc_platform_drv = { .name = DRV_NAME, .probe = sst_soc_probe, + .remove = sst_soc_remove, .ops = &sst_platform_ops, .compr_ops = &sst_platform_compr_ops, .pcm_new = sst_pcm_new, -- 2.7.4

5 years, 9 months

3
9
0 0

[PATCH] KEYS: trusted: defer execution of TPM-specific code until key instantiate

by Roberto Sassu

Commit 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()") changed the tpm_chip argument of every TPM function from NULL to a pointer that is retrieved at module initialization time. Unlike before this patch, the trusted module cannot be loaded if no TPM is available. Unfortunately, this causes a dependency problem because the encrypted key type requires the 'key_type_trusted' symbol when CONFIG_TRUSTED_KEYS is defined. This patch fixes the issue by deferring the execution of TPM-specific code until a new trusted key is instantiated: init_tpm(), to obtain a tpm_chip pointer; init_digests(), introduced by commit 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()"), to get random bytes from the TPM to lock a PCR. Cc: stable(a)vger.kernel.org Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()") Reported-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> --- security/keys/trusted.c | 89 +++++++++++++++++++++++------------------ 1 file changed, 50 insertions(+), 39 deletions(-) diff --git a/security/keys/trusted.c b/security/keys/trusted.c index ecec672d3a77..c5162ca9c944 100644 --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -946,6 +946,44 @@ static struct trusted_key_payload *trusted_payload_alloc(struct key *key) return p; } +static int init_tpm(void) +{ + if (chip) + return 0; + + chip = tpm_default_chip(); + if (!chip) + return -ENODEV; + + return 0; +} + +static int init_digests(void) +{ + u8 digest[TPM_MAX_DIGEST_SIZE]; + int ret; + int i; + + if (digests) + return 0; + + ret = tpm_get_random(chip, digest, TPM_MAX_DIGEST_SIZE); + if (ret < 0) + return ret; + if (ret < TPM_MAX_DIGEST_SIZE) + return -EFAULT; + + digests = kcalloc(chip->nr_allocated_banks, sizeof(*digests), + GFP_KERNEL); + if (!digests) + return -ENOMEM; + + for (i = 0; i < chip->nr_allocated_banks; i++) + memcpy(digests[i].digest, digest, TPM_MAX_DIGEST_SIZE); + + return 0; +} + /* * trusted_instantiate - create a new trusted key * @@ -967,6 +1005,14 @@ static int trusted_instantiate(struct key *key, size_t key_len; int tpm2; + ret = init_tpm(); + if (ret < 0) + return ret; + + ret = init_digests(); + if (ret < 0) + return ret; + tpm2 = tpm_is_tpm2(chip); if (tpm2 < 0) return tpm2; @@ -1218,58 +1264,23 @@ static int __init trusted_shash_alloc(void) return ret; } -static int __init init_digests(void) -{ - u8 digest[TPM_MAX_DIGEST_SIZE]; - int ret; - int i; - - ret = tpm_get_random(chip, digest, TPM_MAX_DIGEST_SIZE); - if (ret < 0) - return ret; - if (ret < TPM_MAX_DIGEST_SIZE) - return -EFAULT; - - digests = kcalloc(chip->nr_allocated_banks, sizeof(*digests), - GFP_KERNEL); - if (!digests) - return -ENOMEM; - - for (i = 0; i < chip->nr_allocated_banks; i++) - memcpy(digests[i].digest, digest, TPM_MAX_DIGEST_SIZE); - - return 0; -} - static int __init init_trusted(void) { int ret; - chip = tpm_default_chip(); - if (!chip) - return -ENOENT; - ret = init_digests(); - if (ret < 0) - goto err_put; ret = trusted_shash_alloc(); if (ret < 0) - goto err_free; + return ret; ret = register_key_type(&key_type_trusted); if (ret < 0) - goto err_release; - return 0; -err_release: - trusted_shash_release(); -err_free: - kfree(digests); -err_put: - put_device(&chip->dev); + trusted_shash_release(); return ret; } static void __exit cleanup_trusted(void) { - put_device(&chip->dev); + if (chip) + put_device(&chip->dev); kfree(digests); trusted_shash_release(); unregister_key_type(&key_type_trusted); -- 2.17.1

5 years, 9 months

3
2
0 0

Re: [PATCH] Makefile: Add '-fno-builtin-bcmp' to CLANG_FLAGS

by Nathan Chancellor

On Mon, Mar 25, 2019 at 12:38:33AM +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.0.3, v4.19.30, v4.14.107, v4.9.164, v4.4.176, v3.18.136. > > v5.0.3: Build OK! > v4.19.30: Build OK! > v4.14.107: Build OK! > v4.9.164: Build OK! > v4.4.176: Failed to apply! Possible dependencies: > 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") > dbe27a002ef8 ("kbuild: add -no-integrated-as Clang option unconditionally") > > v3.18.136: Failed to apply! Possible dependencies: > 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") > 35288e30ebca ("Kbuild: fix file name in comment about extra gcc checks") > 5631d9c42985 ("kbuild: Fix clang detection") > 665d92e38f65 ("kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion") > 785f11aa595b ("kbuild: Add better clang cross build support") > 92d6cf2dab83 ("powerpc: Don't use -mno-strict-align on clang") > a37c45cd82e6 ("kbuild: clang: add -no-integrated-as to KBUILD_[AC]FLAGS") > ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before incl. arch Makefile") > bb3f38c3c5b7 ("kbuild: clang: fix build failures with sparse check") > bfb38988c51e ("kbuild: clang: Disable 'address-of-packed-member' warning") > dd33c03b18b3 ("kbuild: fix cc-ifversion macro") > e79c8385c878 ("powerpc: Don't do gcc version checks if we're building with clang") > ee4eb20dbce9 ("Makefile: Fix detection of clang when cross-compiling") > ef8c4ed9db80 ("kbuild: allow to use GCC toolchain not in Clang search path") > > > How should we proceed with this patch? > > -- > Thanks, > Sasha Hi Sasha, This patch will not be picked up, Nick's patch is a much better fix, which should apply cleanly to all stable branches after it makes it into mainline. https://lore.kernel.org/lkml/20190313211335.165605-1-ndesaulniers@google.co… Thanks for letting us know! Nathan

5 years, 9 months

1
0
0 0

Re: [PATCH for-rc 2/5] IB/hfi1: Failed to drain send queue when QP is put into error state

by Jason Gunthorpe

On Mon, Mar 25, 2019 at 12:38:23AM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: 2e2ba09e48b7 IB/rdmavt, IB/hfi1: Create device > dependent s_flags. This patch hasn't even been accepted to any trees yet. Why are you looking at it? Jason

5 years, 9 months

1
0
0 0

[PATCH 2/2] cpufreq: intel_pstate: Also use cppc nominal_perf for base_frequency

by Srinivas Pandruvada

ACPI specifications stat that if the "Guaranteed Performance Register" is not implemented, OSPM assumes guaranteed performance is always equal to nominal performance. So for invalid and unimplemented guaranteed performance register, use nominal performance as guaranteed performance. This change will fallback to nominal_perf when guranteed_perf is invalid. If nominal_perf is also invalid, then fallback to existing implementation, which is to read from HWP Capabilities MSR. Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency attribute") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: 4.20+ <stable(a)vger.kernel.org> # 4.20+ --- drivers/cpufreq/intel_pstate.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 7b4b0a7ac68b..e16dea241c55 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -385,6 +385,9 @@ static int intel_pstate_get_cppc_guranteed(int cpu) if (ret) return ret; + if (!cppc_perf.guaranteed_perf) + return cppc_perf.nominal_perf; + return cppc_perf.guaranteed_perf; } -- 2.17.2

5 years, 9 months

2
1
0 0

[PATCH 1/2] ACPI / CPPC: Fix processing for guaranteed performance

by Srinivas Pandruvada

As per ACPI specification "Guaranteed Performance Register" is a "Buffer" field. It can't be "Integer" field. So treat "Integer" type as invalid and ignore "Guaranteed Performance Register". Also save one cpc_read() call, when "Guaranteed Performance Register" is not present, which means register defined as: "Register(SystemMemory, 0, 0, 0, 0)". Fixes: 29523f095397 ("ACPI / CPPC: Add support for guaranteed performance") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: 4.20+ <stable(a)vger.kernel.org> # 4.20+ --- drivers/acpi/cppc_acpi.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 1b207fca1420..3f6c290e06af 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -1150,8 +1150,14 @@ int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps) cpc_read(cpunum, nominal_reg, &nom); perf_caps->nominal_perf = nom; - cpc_read(cpunum, guaranteed_reg, &guaranteed); - perf_caps->guaranteed_perf = guaranteed; + if (guaranteed_reg->type == ACPI_TYPE_INTEGER || + (guaranteed_reg->type == ACPI_TYPE_BUFFER && + IS_NULL_REG(&guaranteed_reg->cpc_entry.reg))) { + perf_caps->guaranteed_perf = 0; + } else { + cpc_read(cpunum, guaranteed_reg, &guaranteed); + perf_caps->guaranteed_perf = guaranteed; + } cpc_read(cpunum, lowest_non_linear_reg, &min_nonlinear); perf_caps->lowest_nonlinear_perf = min_nonlinear; -- 2.17.2

5 years, 9 months

2
1
0 0

Re: [PATCH v2] iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE

by Stanislaw Gruszka

On Mon, Mar 25, 2019 at 12:38:21AM +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.0.3, v4.19.30, v4.14.107, v4.9.164, v4.4.176, v3.18.136. > > v5.0.3: Build OK! > v4.19.30: Build OK! > v4.14.107: Build OK! > v4.9.164: Build OK! > v4.4.176: Failed to apply! Possible dependencies: <snip> > v3.18.136: Failed to apply! Possible dependencies: <snip> > How should we proceed with this patch? I've haven't looked into 4.4 and 3.18 amd_iommu code, but not counting comment, patch is one-liner, so should be trivial to backport it manually. Stanislaw

5 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2019