June 2018 - Linux-stable-mirror

panic at boot time with kernel >= 4.9.98 - uninitialized system_wq in early interrupt

by Max Asbock

We have been seeing kernel panics on certain systems with the 4.9.x stable kernel, where x >= 98. We captured the following panic message: [ 6.252000] BUG: unable to handle kernel NULL pointer dereference at 0000000000000102 [ 6.261222] IP: [<ffffffff810a8ea2>] __queue_work+0x32/0x430 [ 6.267826] PGD 0 [ 6.269951] [ 6.271887] Oops: 0000 [#1] SMP [ 6.275576] Modules linked in: [ 6.279264] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.100 #1 [ 6.296760] task: ffffffff81c114c0 task.stack: ffffffff81c00000 [ 6.303564] RIP: 0010:[<ffffffff810a8ea2>] [<ffffffff810a8ea2>] __queue_work+0x32/0x430 [ 6.312997] RSP: 0000:ffff897a40403d98 EFLAGS: 00010046 [ 6.319120] RAX: 0000000000000082 RBX: 0000000000000046 RCX: 0000000000000000 [ 6.327282] RDX: ffffffff81d02300 RSI: 0000000000000000 RDI: 0000000000002000 [ 6.335443] RBP: ffff897a40403dd0 R08: 00000000d431dd4b R09: 0000000000000000 [ 6.343606] R10: ffff897a40403e08 R11: ffffffff8227615c R12: ffffffff81d02300 [ 6.351766] R13: 0000000000002000 R14: 0000000000000000 R15: ffffffff81a88ffd [ 6.359930] FS: 0000000000000000(0000) GS:ffff897a40400000(0000) knlGS:0000000000000000 [ 6.369274] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.375883] CR2: 0000000000000102 CR3: 0000000001c08000 CR4: 0000000000040630 [ 6.384045] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6.392206] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 6.400366] Stack: [ 6.402801] 0000001000000000 0000200040403e08 0000000000000046 0000000000000002 [ 6.411723] ffffffff82275f40 ffff897a40403e08 ffffffff81a88ffd ffff897a40403de8 [ 6.420638] ffffffff810a9677 ffffffff82275f88 ffff897a40403e78 ffffffff8148dff4 [ 6.429554] Call Trace: [ 6.432473] <IRQ> [ 6.434698] [<ffffffff810a9677>] queue_work_on+0x27/0x40 [ 6.441121] [<ffffffff8148dff4>] crng_reseed+0x154/0x260 [ 6.447343] [<ffffffff8148e334>] credit_entropy_bits+0x234/0x2a0 [ 6.454343] [<ffffffff8148e77b>] ? add_interrupt_randomness+0x1bb/0x220 [ 6.462020] [<ffffffff8148e77b>] add_interrupt_randomness+0x1bb/0x220 [ 6.469506] [<ffffffff810ef8f0>] handle_irq_event_percpu+0x40/0x80 [ 6.476698] [<ffffffff810ef96b>] handle_irq_event+0x3b/0x60 [ 6.483211] [<ffffffff810f2e7f>] handle_level_irq+0x8f/0x110 [ 6.489823] [<ffffffff81030fd5>] handle_irq+0xb5/0x140 [ 6.495854] [<ffffffff81096651>] ? _local_bh_enable+0x21/0x50 [ 6.502562] [<ffffffff81038ab5>] ? __exit_idle+0x5/0x30 [ 6.508689] [<ffffffff817250cd>] do_IRQ+0x4d/0xe0 [ 6.514232] [<ffffffff81722ba0>] common_interrupt+0xa0/0xa0 [ 6.520744] <EOI> [ 6.522968] [<ffffffff81ddeb08>] ? vfs_caches_init+0xe1/0xe3 [ 6.529779] [<ffffffff81da212e>] start_kernel+0x451/0x4c8 [ 6.536096] [<ffffffff81da1acb>] ? set_init_arg+0x55/0x55 [ 6.542415] [<ffffffff81da1120>] ? early_idt_handler_array+0x120/0x120 [ 6.549995] [<ffffffff81da15d6>] x86_64_start_reservations+0x2a/0x2c [ 6.557381] [<ffffffff81da1714>] x86_64_start_kernel+0x13c/0x15f [ 6.564378] Code: 89 e5 41 57 41 56 49 89 f6 41 55 41 89 fd 41 54 49 89 d4 53 48 83 ec 10 89 7d d4 ff 14 25 80 86 c3 81 f6 c4 02 0f 85 1f 03 00 00 <41> f6 86 02 01 00 00 01 0f 85 b2 02 00 00 49 c7 c7 78 69 01 00 [ 6.591500] RIP [<ffffffff810a8ea2>] __queue_work+0x32/0x430 [ 6.598197] RSP <ffff897a40403d98> [ 6.602281] CR2: 0000000000000102 The NULL pointer dereference happens because the second argument to __queue_work is 0. The second argument is a struct workqueue_struct, specifically system_wq. This shows that an interrupt happened before the system_wq was initialized. We believe the problem was introduced with this commit: $ git show c3ff2da5cef05676d490fa9057b2dceb5e48cdb9 commit c3ff2da5cef05676d490fa9057b2dceb5e48cdb9 Author: Theodore Ts'o <tytso(a)mit.edu> Date: Mon Apr 23 18:51:28 2018 -0400 random: fix possible sleeping allocation from irq context commit 6c1e851c4edc13a43adb3ea4044e3fc8f43ccf7d upstream. We can do a sleeping allocation from an irq context when CONFIG_NUMA is enabled. Fix this by initializing the NUMA crng instances in a workqueue. Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot+9de458f6a5e713ee8c1a(a)syzkaller.appspotmail.com Fixes: 8ef35c866f8862df ("random: set up the NUMA crng instances...") Cc: stable(a)vger.kernel.org Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/char/random.c b/drivers/char/random.c index b979173..dbfb3e69 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -820,7 +820,7 @@ static int crng_fast_load(const char *cp, size_t len) } #ifdef CONFIG_NUMA -static void numa_crng_init(void) +static void do_numa_crng_init(struct work_struct *work) { int i; struct crng_state *crng; @@ -841,6 +841,13 @@ static void numa_crng_init(void) kfree(pool); } } + +static DECLARE_WORK(numa_crng_init_work, do_numa_crng_init); + +static void numa_crng_init(void) +{ + schedule_work(&numa_crng_init_work); +} #else static void numa_crng_init(void) {} #endif Apparently we can't count on system_wq being initialized when schedule_work is called in numa_crng_init from an early interrupt. I don't understand the underlying code enough to propose a fix right away. thanks, Max

6 years, 8 months

2
3
0 0

[PATCH] x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec()

by Dan Williams

Mark notes that gcc optimization passes have the potential to elide necessary invocations of this instruction sequence, so include an optimization barrier. > I think that either way, we have a potential problem if the compiler > generates a branch dependent on the result of validate_index_nospec(). > > In that case, we could end up with codegen approximating: > > bool safe = false; > > if (idx < bound) { > idx = array_index_nospec(idx, bound); > safe = true; > } > > // this branch can be mispredicted > if (safe) { > foo = array[idx]; > } > > ... and thus we lose the nospec protection. I see GCC do this at -O0, but so far I haven't tricked it into doing this at -O1 or above. Regardless, I worry this is fragile -- GCC *can* generate code as per the above, even if it's unlikely to. Cc: <stable(a)vger.kernel.org> Fixes: babdde2698d4 ("x86: Implement array_index_mask_nospec") Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Ingo Molnar <mingo(a)kernel.org> Reported-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- arch/x86/include/asm/barrier.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h index 042b5e892ed1..41f7435c84a7 100644 --- a/arch/x86/include/asm/barrier.h +++ b/arch/x86/include/asm/barrier.h @@ -38,10 +38,11 @@ static inline unsigned long array_index_mask_nospec(unsigned long index, { unsigned long mask; - asm ("cmp %1,%2; sbb %0,%0;" + asm volatile ("cmp %1,%2; sbb %0,%0;" :"=r" (mask) :"g"(size),"r" (index) :"cc"); + barrier(); return mask; }

6 years, 8 months

4
4
0 0

[PATCH v2 2/2] iommu/vt-d: fix dev iotlb pfsid use

by Jacob Pan

PFSID should be used in the invalidation descriptor for flushing device IOTLBs on SRIOV VFs. Signed-off-by: Jacob Pan <jacob.jun.pan(a)linux.intel.com> Cc: stable(a)vger.kernel.org Cc: "Ashok Raj" <ashok.raj(a)intel.com> Cc: "Lu Baolu" <baolu.lu(a)linux.intel.com> --- drivers/iommu/dmar.c | 6 +++--- drivers/iommu/intel-iommu.c | 17 ++++++++++++++++- include/linux/intel-iommu.h | 5 ++--- 3 files changed, 21 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c index 460bed4..7852678 100644 --- a/drivers/iommu/dmar.c +++ b/drivers/iommu/dmar.c @@ -1339,8 +1339,8 @@ void qi_flush_iotlb(struct intel_iommu *iommu, u16 did, u64 addr, qi_submit_sync(&desc, iommu); } -void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 qdep, - u64 addr, unsigned mask) +void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 pfsid, + u16 qdep, u64 addr, unsigned mask) { struct qi_desc desc; @@ -1355,7 +1355,7 @@ void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 qdep, qdep = 0; desc.low = QI_DEV_IOTLB_SID(sid) | QI_DEV_IOTLB_QDEP(qdep) | - QI_DIOTLB_TYPE; + QI_DIOTLB_TYPE | QI_DEV_IOTLB_PFSID(pfsid); qi_submit_sync(&desc, iommu); } diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 3d77d61..8b533cc 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -1503,6 +1503,20 @@ static void iommu_enable_dev_iotlb(struct device_domain_info *info) return; pdev = to_pci_dev(info->dev); + /* For IOMMU that supports device IOTLB throttling (DIT), we assign + * PFSID to the invalidation desc of a VF such that IOMMU HW can gauge + * queue depth at PF level. If DIT is not set, PFSID will be treated as + * reserved, which should be set to 0. + */ + if (!ecap_dit(info->iommu->ecap)) + info->pfsid = 0; + else { + struct pci_dev *pf_pdev; + + /* pdev will be returned if device is not a vf */ + pf_pdev = pci_physfn(pdev); + info->pfsid = PCI_DEVID(pf_pdev->bus->number, pf_pdev->devfn); + } #ifdef CONFIG_INTEL_IOMMU_SVM /* The PCIe spec, in its wisdom, declares that the behaviour of @@ -1568,7 +1582,8 @@ static void iommu_flush_dev_iotlb(struct dmar_domain *domain, sid = info->bus << 8 | info->devfn; qdep = info->ats_qdep; - qi_flush_dev_iotlb(info->iommu, sid, qdep, addr, mask); + qi_flush_dev_iotlb(info->iommu, sid, info->pfsid, + qdep, addr, mask); } spin_unlock_irqrestore(&device_domain_lock, flags); } diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h index af1c05f..7fd9fbae 100644 --- a/include/linux/intel-iommu.h +++ b/include/linux/intel-iommu.h @@ -456,9 +456,8 @@ extern void qi_flush_context(struct intel_iommu *iommu, u16 did, u16 sid, u8 fm, u64 type); extern void qi_flush_iotlb(struct intel_iommu *iommu, u16 did, u64 addr, unsigned int size_order, u64 type); -extern void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 qdep, - u64 addr, unsigned mask); - +extern void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 pfsid, + u16 qdep, u64 addr, unsigned mask); extern int qi_submit_sync(struct qi_desc *desc, struct intel_iommu *iommu); extern int dmar_ir_support(void); -- 2.7.4

6 years, 8 months

1
0
0 0

[PATCH 4.16.y] netfilter: nf_flow_table: attach dst to skbs

by Jason A. Donenfeld

commit 2a79fd3908acd88e6cb0e620c314d7b1fee56a02 upstream. Some drivers, such as vxlan and wireguard, use the skb's dst in order to determine things like PMTU. They therefore loose functionality when flow offloading is enabled. So, we ensure the skb has it before xmit'ing it in the offloading path. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- net/ipv4/netfilter/nf_flow_table_ipv4.c | 5 +++-- net/ipv6/netfilter/nf_flow_table_ipv6.c | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv4/netfilter/nf_flow_table_ipv4.c b/net/ipv4/netfilter/nf_flow_table_ipv4.c index 0cd46bffa469..fc3923932eda 100644 --- a/net/ipv4/netfilter/nf_flow_table_ipv4.c +++ b/net/ipv4/netfilter/nf_flow_table_ipv4.c @@ -213,7 +213,7 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb, enum flow_offload_tuple_dir dir; struct flow_offload *flow; struct net_device *outdev; - const struct rtable *rt; + struct rtable *rt; struct iphdr *iph; __be32 nexthop; @@ -234,7 +234,7 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb, dir = tuplehash->tuple.dir; flow = container_of(tuplehash, struct flow_offload, tuplehash[dir]); - rt = (const struct rtable *)flow->tuplehash[dir].tuple.dst_cache; + rt = (struct rtable *)flow->tuplehash[dir].tuple.dst_cache; if (unlikely(nf_flow_exceeds_mtu(skb, rt))) return NF_ACCEPT; @@ -251,6 +251,7 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb, skb->dev = outdev; nexthop = rt_nexthop(rt, flow->tuplehash[!dir].tuple.src_v4.s_addr); + skb_dst_set_noref(skb, &rt->dst); neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb); return NF_STOLEN; diff --git a/net/ipv6/netfilter/nf_flow_table_ipv6.c b/net/ipv6/netfilter/nf_flow_table_ipv6.c index 207cb35569b1..2d6652146bba 100644 --- a/net/ipv6/netfilter/nf_flow_table_ipv6.c +++ b/net/ipv6/netfilter/nf_flow_table_ipv6.c @@ -243,6 +243,7 @@ nf_flow_offload_ipv6_hook(void *priv, struct sk_buff *skb, skb->dev = outdev; nexthop = rt6_nexthop(rt, &flow->tuplehash[!dir].tuple.src_v6); + skb_dst_set_noref(skb, &rt->dst); neigh_xmit(NEIGH_ND_TABLE, outdev, nexthop, skb); return NF_STOLEN; -- 2.17.1

6 years, 8 months

2
1
0 0

[PATCH v4.17.y] netfilter: nf_flow_table: attach dst to skbs

by Jason A. Donenfeld

commit 2a79fd3908acd88e6cb0e620c314d7b1fee56a02 upstream. Some drivers, such as vxlan and wireguard, use the skb's dst in order to determine things like PMTU. They therefore loose functionality when flow offloading is enabled. So, we ensure the skb has it before xmit'ing it in the offloading path. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- net/ipv4/netfilter/nf_flow_table_ipv4.c | 5 +++-- net/ipv6/netfilter/nf_flow_table_ipv6.c | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv4/netfilter/nf_flow_table_ipv4.c b/net/ipv4/netfilter/nf_flow_table_ipv4.c index 0cd46bffa469..fc3923932eda 100644 --- a/net/ipv4/netfilter/nf_flow_table_ipv4.c +++ b/net/ipv4/netfilter/nf_flow_table_ipv4.c @@ -213,7 +213,7 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb, enum flow_offload_tuple_dir dir; struct flow_offload *flow; struct net_device *outdev; - const struct rtable *rt; + struct rtable *rt; struct iphdr *iph; __be32 nexthop; @@ -234,7 +234,7 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb, dir = tuplehash->tuple.dir; flow = container_of(tuplehash, struct flow_offload, tuplehash[dir]); - rt = (const struct rtable *)flow->tuplehash[dir].tuple.dst_cache; + rt = (struct rtable *)flow->tuplehash[dir].tuple.dst_cache; if (unlikely(nf_flow_exceeds_mtu(skb, rt))) return NF_ACCEPT; @@ -251,6 +251,7 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb, skb->dev = outdev; nexthop = rt_nexthop(rt, flow->tuplehash[!dir].tuple.src_v4.s_addr); + skb_dst_set_noref(skb, &rt->dst); neigh_xmit(NEIGH_ARP_TABLE, outdev, &nexthop, skb); return NF_STOLEN; diff --git a/net/ipv6/netfilter/nf_flow_table_ipv6.c b/net/ipv6/netfilter/nf_flow_table_ipv6.c index 207cb35569b1..2d6652146bba 100644 --- a/net/ipv6/netfilter/nf_flow_table_ipv6.c +++ b/net/ipv6/netfilter/nf_flow_table_ipv6.c @@ -243,6 +243,7 @@ nf_flow_offload_ipv6_hook(void *priv, struct sk_buff *skb, skb->dev = outdev; nexthop = rt6_nexthop(rt, &flow->tuplehash[!dir].tuple.src_v6); + skb_dst_set_noref(skb, &rt->dst); neigh_xmit(NEIGH_ND_TABLE, outdev, nexthop, skb); return NF_STOLEN; -- 2.17.1

6 years, 8 months

1
0
0 0

[PATCH v3 0/2] Fixes for v4.4

by Jarkko Sakkinen

Chris Chiu (1): tpm: self test failure should not cause suspend to fail Enric Balletbo i Serra (1): tpm: do not suspend/resume if power stays on drivers/char/tpm/tpm-chip.c | 12 ++++++++++++ drivers/char/tpm/tpm-interface.c | 7 +++++++ drivers/char/tpm/tpm.h | 1 + 3 files changed, 20 insertions(+) -- v3: use CONFIG_OF flag v2: moved the check from tpm_of.c to tpm-chip.c as in v4.4 chip is unreachable otherwise. I did compilation test now with BuildRoot for power arch. 2.17.0

6 years, 8 months

2
5
0 0

Please add e2731e55884f2138a252b0a to 4.14 and 4.9

by David Sterba

Hi, please add the commit e2731e55884f2138a252b0a3d7b24d57e49c3c59 ("btrfs: define SUPER_FLAG_METADUMP_V2") to the 4.14.x and 4.9.x stable trees. The patch allows to mount an image dump of v2 format on < 4.15 kernels that are still in use for the btrfs-progs testsuite. The image mount is part of some tests that fail but otherwise are ok. The patch can be cleanly applied on top of current 4.14 and 4.9 branches, fails on 4.4 and older but I'm interested namely in 4.14. Thanks.

6 years, 8 months

2
1
0 0

[PATCH] KVM: VMX: Expose SSBD properly to guests.

by Konrad Rzeszutek Wilk

The X86_FEATURE_SSBD is an synthetic CPU feature - that is it bit location has no relevance to the real CPUID 0x7.EBX[31] bit position. For that we need the new CPU feature name. Fixes: 52817587e706 ("x86/cpufeatures: Disentangle SSBD enumeration") CC: Paolo Bonzini <pbonzini(a)redhat.com> Cc: "Radim Krčmář" <rkrcmar(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: stable(a)vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> --- arch/x86/kvm/cpuid.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index ced851169730..598461e24be3 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -407,8 +407,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, /* cpuid 7.0.edx*/ const u32 kvm_cpuid_7_0_edx_x86_features = - F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) | F(SSBD) | - F(ARCH_CAPABILITIES); + F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) | + F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES); /* all calls to cpuid_count() should be made on the same cpu */ get_cpu(); -- 2.13.4

6 years, 8 months

3
2
0 0

[PATCH] Input: xpad - Add usb-ids for the XBOX360 controller built into the GPD win 2

by Hans de Goede

The GPD win 2 x86 portable game computer comes with a builtin XBOX360 controller with a vid:pid of 0079:18d4. Add support for this controller. BugLink: https://www.reddit.com/r/gpdwin/comments/8l5vn8/gpd_win_2_gamepad_in_linux/ Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/input/joystick/xpad.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c index 06e9650b3b30..c4f119a6e9d7 100644 --- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -123,6 +123,7 @@ static const struct xpad_device { u8 mapping; u8 xtype; } xpad_device[] = { + { 0x0079, 0x18d4, "GPD WIN 2", 0, XTYPE_XBOX360 }, { 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX }, -- 2.17.1

6 years, 8 months

2
1
0 0

[PATCH] Input: goodix - Add "GDIX1002" ACPI HID

by Hans de Goede

Some newer devices with a goodix touchscreen use GDIX1002 as ACPI HID rather then GDIX1001. These devices work fine with the goodix driver as is. This commit adds the new "GDIX1002" ACPI HID to make the touchscreen work on these devices. Buglink: https://www.reddit.com/r/gpdwin/comments/8lwy8n/gpd_win_2_linux_touchscreen… Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/input/touchscreen/goodix.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c index 9736c83dd418..f2d9c2c41885 100644 --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -933,6 +933,7 @@ MODULE_DEVICE_TABLE(i2c, goodix_ts_id); #ifdef CONFIG_ACPI static const struct acpi_device_id goodix_acpi_match[] = { { "GDIX1001", 0 }, + { "GDIX1002", 0 }, { } }; MODULE_DEVICE_TABLE(acpi, goodix_acpi_match); -- 2.17.1

6 years, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2018