]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 4.19
authorSasha Levin <sashal@kernel.org>
Fri, 17 Jul 2020 12:56:00 +0000 (08:56 -0400)
committerSasha Levin <sashal@kernel.org>
Fri, 17 Jul 2020 12:56:00 +0000 (08:56 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-4.19/arm64-alternatives-use-subsections-for-replacement-s.patch [new file with mode: 0644]
queue-4.19/drm-exynos-fix-ref-count-leak-in-mic_pre_enable.patch [new file with mode: 0644]
queue-4.19/drm-msm-fix-potential-memleak-in-error-branch.patch [new file with mode: 0644]
queue-4.19/gfs2-read-only-mounts-should-grab-the-sd_freeze_gl-g.patch [new file with mode: 0644]
queue-4.19/i2c-eg20t-load-module-automatically-if-id-matches.patch [new file with mode: 0644]
queue-4.19/m68k-mm-fix-node-memblock-init.patch [new file with mode: 0644]
queue-4.19/m68k-nommu-register-start-of-the-memory-with-membloc.patch [new file with mode: 0644]
queue-4.19/series
queue-4.19/tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch [new file with mode: 0644]

diff --git a/queue-4.19/arm64-alternatives-use-subsections-for-replacement-s.patch b/queue-4.19/arm64-alternatives-use-subsections-for-replacement-s.patch
new file mode 100644 (file)
index 0000000..29b582d
--- /dev/null
@@ -0,0 +1,136 @@
+From 308cc751eea576a3e4b50e2cad3d16e39e000faf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 30 Jun 2020 10:19:21 +0200
+Subject: arm64/alternatives: use subsections for replacement sequences
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+[ Upstream commit f7b93d42945cc71e1346dd5ae07c59061d56745e ]
+
+When building very large kernels, the logic that emits replacement
+sequences for alternatives fails when relative branches are present
+in the code that is emitted into the .altinstr_replacement section
+and patched in at the original site and fixed up. The reason is that
+the linker will insert veneers if relative branches go out of range,
+and due to the relative distance of the .altinstr_replacement from
+the .text section where its branch targets usually live, veneers
+may be emitted at the end of the .altinstr_replacement section, with
+the relative branches in the sequence pointed at the veneers instead
+of the actual target.
+
+The alternatives patching logic will attempt to fix up the branch to
+point to its original target, which will be the veneer in this case,
+but given that the patch site is likely to be far away as well, it
+will be out of range and so patching will fail. There are other cases
+where these veneers are problematic, e.g., when the target of the
+branch is in .text while the patch site is in .init.text, in which
+case putting the replacement sequence inside .text may not help either.
+
+So let's use subsections to emit the replacement code as closely as
+possible to the patch site, to ensure that veneers are only likely to
+be emitted if they are required at the patch site as well, in which
+case they will be in range for the replacement sequence both before
+and after it is transported to the patch site.
+
+This will prevent alternative sequences in non-init code from being
+released from memory after boot, but this is tolerable given that the
+entire section is only 512 KB on an allyesconfig build (which weighs in
+at 500+ MB for the entire Image). Also, note that modules today carry
+the replacement sequences in non-init sections as well, and any of
+those that target init code will be emitted into init sections after
+this change.
+
+This fixes an early crash when booting an allyesconfig kernel on a
+system where any of the alternatives sequences containing relative
+branches are activated at boot (e.g., ARM64_HAS_PAN on TX2)
+
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
+Cc: James Morse <james.morse@arm.com>
+Cc: Andre Przywara <andre.przywara@arm.com>
+Cc: Dave P Martin <dave.martin@arm.com>
+Link: https://lore.kernel.org/r/20200630081921.13443-1-ardb@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/include/asm/alternative.h | 16 ++++++++--------
+ arch/arm64/kernel/vmlinux.lds.S      |  3 ---
+ 2 files changed, 8 insertions(+), 11 deletions(-)
+
+diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
+index 1a7ba3de70793..849d891c60a81 100644
+--- a/arch/arm64/include/asm/alternative.h
++++ b/arch/arm64/include/asm/alternative.h
+@@ -73,11 +73,11 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
+       ".pushsection .altinstructions,\"a\"\n"                         \
+       ALTINSTR_ENTRY(feature)                                         \
+       ".popsection\n"                                                 \
+-      ".pushsection .altinstr_replacement, \"a\"\n"                   \
++      ".subsection 1\n"                                               \
+       "663:\n\t"                                                      \
+       newinstr "\n"                                                   \
+       "664:\n\t"                                                      \
+-      ".popsection\n\t"                                               \
++      ".previous\n\t"                                                 \
+       ".org   . - (664b-663b) + (662b-661b)\n\t"                      \
+       ".org   . - (662b-661b) + (664b-663b)\n"                        \
+       ".endif\n"
+@@ -117,9 +117,9 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
+ 662:  .pushsection .altinstructions, "a"
+       altinstruction_entry 661b, 663f, \cap, 662b-661b, 664f-663f
+       .popsection
+-      .pushsection .altinstr_replacement, "ax"
++      .subsection 1
+ 663:  \insn2
+-664:  .popsection
++664:  .previous
+       .org    . - (664b-663b) + (662b-661b)
+       .org    . - (662b-661b) + (664b-663b)
+       .endif
+@@ -160,7 +160,7 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
+       .pushsection .altinstructions, "a"
+       altinstruction_entry 663f, 661f, \cap, 664f-663f, 662f-661f
+       .popsection
+-      .pushsection .altinstr_replacement, "ax"
++      .subsection 1
+       .align 2        /* So GAS knows label 661 is suitably aligned */
+ 661:
+ .endm
+@@ -179,9 +179,9 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
+ .macro alternative_else
+ 662:
+       .if .Lasm_alt_mode==0
+-      .pushsection .altinstr_replacement, "ax"
++      .subsection 1
+       .else
+-      .popsection
++      .previous
+       .endif
+ 663:
+ .endm
+@@ -192,7 +192,7 @@ static inline void apply_alternatives_module(void *start, size_t length) { }
+ .macro alternative_endif
+ 664:
+       .if .Lasm_alt_mode==0
+-      .popsection
++      .previous
+       .endif
+       .org    . - (664b-663b) + (662b-661b)
+       .org    . - (662b-661b) + (664b-663b)
+diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
+index 74e469f8a8507..d6050c6e65bc1 100644
+--- a/arch/arm64/kernel/vmlinux.lds.S
++++ b/arch/arm64/kernel/vmlinux.lds.S
+@@ -154,9 +154,6 @@ SECTIONS
+               *(.altinstructions)
+               __alt_instructions_end = .;
+       }
+-      .altinstr_replacement : {
+-              *(.altinstr_replacement)
+-      }
+       . = ALIGN(PAGE_SIZE);
+       __inittext_end = .;
+-- 
+2.25.1
+
diff --git a/queue-4.19/drm-exynos-fix-ref-count-leak-in-mic_pre_enable.patch b/queue-4.19/drm-exynos-fix-ref-count-leak-in-mic_pre_enable.patch
new file mode 100644 (file)
index 0000000..818181c
--- /dev/null
@@ -0,0 +1,39 @@
+From d79cddeecd121ce1dfed77f1a1eaaa2e1d3b43a9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Jun 2020 00:49:28 -0500
+Subject: drm/exynos: fix ref count leak in mic_pre_enable
+
+From: Navid Emamdoost <navid.emamdoost@gmail.com>
+
+[ Upstream commit d4f5a095daf0d25f0b385e1ef26338608433a4c5 ]
+
+in mic_pre_enable, pm_runtime_get_sync is called which
+increments the counter even in case of failure, leading to incorrect
+ref count. In case of failure, decrement the ref count before returning.
+
+Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
+Signed-off-by: Inki Dae <inki.dae@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/exynos/exynos_drm_mic.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
+index 2fd299a58297e..cd5530bbfe2e6 100644
+--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
++++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
+@@ -267,8 +267,10 @@ static void mic_pre_enable(struct drm_bridge *bridge)
+               goto unlock;
+       ret = pm_runtime_get_sync(mic->dev);
+-      if (ret < 0)
++      if (ret < 0) {
++              pm_runtime_put_noidle(mic->dev);
+               goto unlock;
++      }
+       mic_set_path(mic, 1);
+-- 
+2.25.1
+
diff --git a/queue-4.19/drm-msm-fix-potential-memleak-in-error-branch.patch b/queue-4.19/drm-msm-fix-potential-memleak-in-error-branch.patch
new file mode 100644 (file)
index 0000000..512c51c
--- /dev/null
@@ -0,0 +1,41 @@
+From 418c89021144dacb14fa1b7d4682bd772cb3287b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 12 Jun 2020 09:23:49 +0800
+Subject: drm/msm: fix potential memleak in error branch
+
+From: Bernard Zhao <bernard@vivo.com>
+
+[ Upstream commit 177d3819633cd520e3f95df541a04644aab4c657 ]
+
+In function msm_submitqueue_create, the queue is a local
+variable, in return -EINVAL branch, queue didn`t add to ctx`s
+list yet, and also didn`t kfree, this maybe bring in potential
+memleak.
+
+Signed-off-by: Bernard Zhao <bernard@vivo.com>
+[trivial commit msg fixup]
+Signed-off-by: Rob Clark <robdclark@chromium.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c b/drivers/gpu/drm/msm/msm_submitqueue.c
+index 5115f75b5b7f3..325da440264a3 100644
+--- a/drivers/gpu/drm/msm/msm_submitqueue.c
++++ b/drivers/gpu/drm/msm/msm_submitqueue.c
+@@ -78,8 +78,10 @@ int msm_submitqueue_create(struct drm_device *drm, struct msm_file_private *ctx,
+       queue->flags = flags;
+       if (priv->gpu) {
+-              if (prio >= priv->gpu->nr_rings)
++              if (prio >= priv->gpu->nr_rings) {
++                      kfree(queue);
+                       return -EINVAL;
++              }
+               queue->prio = prio;
+       }
+-- 
+2.25.1
+
diff --git a/queue-4.19/gfs2-read-only-mounts-should-grab-the-sd_freeze_gl-g.patch b/queue-4.19/gfs2-read-only-mounts-should-grab-the-sd_freeze_gl-g.patch
new file mode 100644 (file)
index 0000000..90b08d7
--- /dev/null
@@ -0,0 +1,51 @@
+From e51da74ec4db21e98e769cf0007268c1dd7e3a2b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 25 Jun 2020 13:30:18 -0500
+Subject: gfs2: read-only mounts should grab the sd_freeze_gl glock
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+[ Upstream commit b780cc615ba4795a7ef0e93b19424828a5ad456a ]
+
+Before this patch, only read-write mounts would grab the freeze
+glock in read-only mode, as part of gfs2_make_fs_rw. So the freeze
+glock was never initialized. That meant requests to freeze, which
+request the glock in EX, were granted without any state transition.
+That meant you could mount a gfs2 file system, which is currently
+frozen on a different cluster node, in read-only mode.
+
+This patch makes read-only mounts lock the freeze glock in SH mode,
+which will block for file systems that are frozen on another node.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/ops_fstype.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
+index ed77b10bdfb53..9448c8461e576 100644
+--- a/fs/gfs2/ops_fstype.c
++++ b/fs/gfs2/ops_fstype.c
+@@ -1160,7 +1160,17 @@ static int fill_super(struct super_block *sb, struct gfs2_args *args, int silent
+               goto fail_per_node;
+       }
+-      if (!sb_rdonly(sb)) {
++      if (sb_rdonly(sb)) {
++              struct gfs2_holder freeze_gh;
++
++              error = gfs2_glock_nq_init(sdp->sd_freeze_gl, LM_ST_SHARED,
++                                         GL_EXACT, &freeze_gh);
++              if (error) {
++                      fs_err(sdp, "can't make FS RO: %d\n", error);
++                      goto fail_per_node;
++              }
++              gfs2_glock_dq_uninit(&freeze_gh);
++      } else {
+               error = gfs2_make_fs_rw(sdp);
+               if (error) {
+                       fs_err(sdp, "can't make FS RW: %d\n", error);
+-- 
+2.25.1
+
diff --git a/queue-4.19/i2c-eg20t-load-module-automatically-if-id-matches.patch b/queue-4.19/i2c-eg20t-load-module-automatically-if-id-matches.patch
new file mode 100644 (file)
index 0000000..22d3d21
--- /dev/null
@@ -0,0 +1,35 @@
+From 7d2248f77e191a6888688b31e8489ee70698cf46 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 2 Jul 2020 13:15:27 +0300
+Subject: i2c: eg20t: Load module automatically if ID matches
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+[ Upstream commit 5f90786b31fb7d1e199a8999d46c4e3aea672e11 ]
+
+The driver can't be loaded automatically because it misses
+module alias to be provided. Add corresponding MODULE_DEVICE_TABLE()
+call to the driver.
+
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-eg20t.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/i2c/busses/i2c-eg20t.c b/drivers/i2c/busses/i2c-eg20t.c
+index 231675b10376a..44025507b8f7b 100644
+--- a/drivers/i2c/busses/i2c-eg20t.c
++++ b/drivers/i2c/busses/i2c-eg20t.c
+@@ -188,6 +188,7 @@ static const struct pci_device_id pch_pcidev_id[] = {
+       { PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_I2C), 1, },
+       {0,}
+ };
++MODULE_DEVICE_TABLE(pci, pch_pcidev_id);
+ static irqreturn_t pch_i2c_handler(int irq, void *pData);
+-- 
+2.25.1
+
diff --git a/queue-4.19/m68k-mm-fix-node-memblock-init.patch b/queue-4.19/m68k-mm-fix-node-memblock-init.patch
new file mode 100644 (file)
index 0000000..1620150
--- /dev/null
@@ -0,0 +1,39 @@
+From 445e81a243b5d6917d96c60798aab1dd33931b2f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Jun 2020 09:53:41 +0300
+Subject: m68k: mm: fix node memblock init
+
+From: Angelo Dureghello <angelo.dureghello@timesys.com>
+
+[ Upstream commit c43e55796dd4d13f4855971a4d7970ce2cd94db4 ]
+
+After pulling 5.7.0 (linux-next merge), mcf5441x mmu boot was
+hanging silently.
+
+memblock_add() seems not appropriate, since using MAX_NUMNODES
+as node id, while memblock_add_node() sets up memory for node id 0.
+
+Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
+Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
+Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/m68k/mm/mcfmmu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
+index f5453d944ff5e..c5e26222979ad 100644
+--- a/arch/m68k/mm/mcfmmu.c
++++ b/arch/m68k/mm/mcfmmu.c
+@@ -160,7 +160,7 @@ void __init cf_bootmem_alloc(void)
+       m68k_memory[0].addr = _rambase;
+       m68k_memory[0].size = _ramend - _rambase;
+-      memblock_add(m68k_memory[0].addr, m68k_memory[0].size);
++      memblock_add_node(m68k_memory[0].addr, m68k_memory[0].size, 0);
+       /* compute total pages in system */
+       num_pages = PFN_DOWN(_ramend - _rambase);
+-- 
+2.25.1
+
diff --git a/queue-4.19/m68k-nommu-register-start-of-the-memory-with-membloc.patch b/queue-4.19/m68k-nommu-register-start-of-the-memory-with-membloc.patch
new file mode 100644 (file)
index 0000000..5279ccd
--- /dev/null
@@ -0,0 +1,63 @@
+From e00a1b98589e34f2fccdaa7955c3bba444c6b511 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 17 Jun 2020 09:53:40 +0300
+Subject: m68k: nommu: register start of the memory with memblock
+
+From: Mike Rapoport <rppt@linux.ibm.com>
+
+[ Upstream commit d63bd8c81d8ab64db506ffde569cc8ff197516e2 ]
+
+The m68k nommu setup code didn't register the beginning of the physical
+memory with memblock because it was anyway occupied by the kernel. However,
+commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
+zone sizes") changed zones initialization to use memblock.memory to detect
+the zone extents and this caused inconsistency between zone PFNs and the
+actual PFNs:
+
+BUG: Bad page state in process swapper  pfn:20165
+page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0()
+raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000
+page dumped because: nonzero mapcount
+CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1
+Stack from 404c9ebc:
+        404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4
+        00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21
+        00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000
+        00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001
+        400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04
+        41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff
+Call Trace:
+        [<40088470>] 0x40088470
+ [<40088504>] 0x40088504
+ [<40088a12>] 0x40088a12
+ [<402ca000>] 0x402ca000
+ [<400a0934>] 0x400a0934
+
+Adjust the memory registration with memblock to include the beginning of
+the physical memory and make sure that the area occupied by the kernel is
+marked as reserved.
+
+Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
+Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/m68k/kernel/setup_no.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
+index cfd5475bfc315..4625acc1e7c4d 100644
+--- a/arch/m68k/kernel/setup_no.c
++++ b/arch/m68k/kernel/setup_no.c
+@@ -140,7 +140,8 @@ void __init setup_arch(char **cmdline_p)
+       pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
+                __bss_stop, memory_start, memory_start, memory_end);
+-      memblock_add(memory_start, memory_end - memory_start);
++      memblock_add(_rambase, memory_end - _rambase);
++      memblock_reserve(_rambase, memory_start - _rambase);
+       /* Keep a copy of command line */
+       *cmdline_p = &command_line[0];
+-- 
+2.25.1
+
index a4f155641cc92de37c8340b17a3575f4c2ea1e1c..14d450e8df384b8af140f2c3201297bc857b4777 100644 (file)
@@ -18,3 +18,11 @@ cgroup-fix-sock_cgroup_data-on-big-endian.patch
 sched-consistently-handle-layer3-header-accesses-in-the-presence-of-vlans.patch
 vlan-consolidate-vlan-parsing-code-and-limit-max-parsing-depth.patch
 
+drm-msm-fix-potential-memleak-in-error-branch.patch
+drm-exynos-fix-ref-count-leak-in-mic_pre_enable.patch
+m68k-nommu-register-start-of-the-memory-with-membloc.patch
+m68k-mm-fix-node-memblock-init.patch
+arm64-alternatives-use-subsections-for-replacement-s.patch
+tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch
+gfs2-read-only-mounts-should-grab-the-sd_freeze_gl-g.patch
+i2c-eg20t-load-module-automatically-if-id-matches.patch
diff --git a/queue-4.19/tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch b/queue-4.19/tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch
new file mode 100644 (file)
index 0000000..c94854b
--- /dev/null
@@ -0,0 +1,42 @@
+From d9b80aad50e56be23923cf197956884356e12889 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 13 Jun 2020 17:18:33 +0300
+Subject: tpm_tis: extra chip->ops check on error path in tpm_tis_core_init
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+[ Upstream commit ccf6fb858e17a8f8a914a1c6444d277cfedfeae6 ]
+
+Found by smatch:
+drivers/char/tpm/tpm_tis_core.c:1088 tpm_tis_core_init() warn:
+ variable dereferenced before check 'chip->ops' (see line 979)
+
+'chip->ops' is assigned in the beginning of function
+in tpmm_chip_alloc->tpm_chip_alloc
+and is used before first possible goto to error path.
+
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/char/tpm/tpm_tis_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
+index 5d8f8f018984d..280d60cba1f8c 100644
+--- a/drivers/char/tpm/tpm_tis_core.c
++++ b/drivers/char/tpm/tpm_tis_core.c
+@@ -1007,7 +1007,7 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
+       return 0;
+ out_err:
+-      if ((chip->ops != NULL) && (chip->ops->clk_enable != NULL))
++      if (chip->ops->clk_enable != NULL)
+               chip->ops->clk_enable(chip, false);
+       tpm_tis_remove(chip);
+-- 
+2.25.1
+