Message ID | 20240219195807.517742-2-sakari.ailus@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-71932-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp84092dyc; Mon, 19 Feb 2024 15:05:34 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWBVAyksGdEw0O8uiRrL3KQsiUHWVrzNcv8VFFtbGoQCUyOVaxW39R/ll/eu+hyA1keBJbWblBOgLZPMTXNiw7U+B/XtA== X-Google-Smtp-Source: AGHT+IGxBhvlAy5LEhe6PiZfHm/PgiUpi4anot6jSbU0P7IoQrJNqI9FC3IeFoiVV6/ldKyVtajB X-Received: by 2002:a05:6808:3209:b0:3c0:354b:1559 with SMTP id cb9-20020a056808320900b003c0354b1559mr20168722oib.53.1708383933538; Mon, 19 Feb 2024 15:05:33 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708383933; cv=pass; d=google.com; s=arc-20160816; b=Yd0TP+zkfU07TD77t0+gCtoj6etTNBdyHZp+RAceG6U7vJQwifm/C3lN4f0FFBbf+t lJgwqliKaq/4Sr/S9cRGEwiMnBnVxtGPGwAh6huavb4moF9iQO4IecGR9RzGyEx6EA4r cjnwIkODkhKjPCMiTrkqT8Gqu0zQxfrQw3NjPuvwjH5DSLlEXC+I3F3Mv3eRdRdovcnk NPtYEDIUJpEsOwDhMPW3Iimdb3aincxAsf0s8f0PUb17RlmHv7+cO0E8LHo1CG5P73zh VGHtPxoYLJP+FS3xo3rLDAVxwwPiEKNtUWLA6H0zC01ely1Oi7VU7JaEc8iej02jsmLT famw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=s4DzhaKf0vAIXchiqvP1x0OqPxipS/FnE8nIaEoxUKA=; fh=LOynIoGsIcCMdPC1QzzjJynRZ/faW1WIR3/UfREgjqw=; b=DT0l/ujGwwPmKwAQJ2P7+iIRd4uQCcv5G8OfjmQE9nPoLjpm8Gg48uUzJ6eZtjGTzz QJgS97blwyDeds9sBFC2taIYT9dhCwwjq8rP1NgpaonZ9Grtn4CZCOtF4MOsiQB7Bqjx SY8vXv0paVu3IBP5RRbzvDqMFF4xqwl7OFAn/U5YuDeuZUxG3K0L3AWvI6GomQeH9jHB 0FzARpGYFDEr4tKpFb/V93ReXB7oAXKNbvap0PIaCAyhXueKzB0UbRzmlU2Y2xgVHpX0 1pLetL/T3tpMp+Ot8eX/tepXsx3FUyKTK84UJbo+5mxFZJyUVkvJdAUEz7O25a2x2UZ8 NO+g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=h36kLlcW; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-71932-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-71932-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id y18-20020a05620a44d200b00787389cfc39si8521405qkp.735.2024.02.19.15.05.33 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Feb 2024 15:05:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-71932-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=h36kLlcW; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-71932-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-71932-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 020481C2387A for <ouuuleilei@gmail.com>; Mon, 19 Feb 2024 20:00:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6A6DC5380C; Mon, 19 Feb 2024 19:58:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="h36kLlcW" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34F2451033 for <linux-kernel@vger.kernel.org>; Mon, 19 Feb 2024 19:58:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708372699; cv=none; b=eNxv+LJR1iUxqapVgr5+vO3EdQM/FSUw3sG4RJ3CRbq9RBkg2PdXPHDgL66Gn5uemNWnS0mYF5uv00oawQXUZGPSsb1kCi6Tk9/QMEhNtfx4fRzrG/RO3qUXjMWVOobV2f/YbouJWCKfnzdSlfCmrGILUX0ruJ5cMvIQ4PRWcBw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708372699; c=relaxed/simple; bh=TquE1dW+qm+nVtngnRKRNtP2lZTiAhrMZ6Ch/QG2DI4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rQtbnXSOQybKUj6K2A57OAiFQ6fF4xFUAiBUeWrpjRHVzvwiWCi+3DhOjp3wix2ZnB3xiXqdkxjVpqHKnp53QjARKfYBzmqj0UdnO4jKQiSB94vmmSca5ukag3YCdsXg9PgTs6c6xP80sU4OlMkrm5nK9w0PFGEGSIcP6b+W4Xg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=h36kLlcW; arc=none smtp.client-ip=198.175.65.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708372698; x=1739908698; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TquE1dW+qm+nVtngnRKRNtP2lZTiAhrMZ6Ch/QG2DI4=; b=h36kLlcWT41Km2bnHbnqIMtkxibn6hWt5bUK+lgwpv6gr0woKlY5XHqu 4q1fE/qYTAy8tBnmtNDFX07/cbHtvLNEi/BjL3fc3JwpGs3R91LlUsSFm kJZtaSFUlEzzmJw/cd6Y9MhyfVp0dx0n1PuBl15hKa+Y0KSVHOOMZ8KkH 0CLPmiXvFe7x7exa57/TTWRdclapNwT9SXdr/TUXkfdPv+7zDAR1XE95N zOABs5e4HnWJvezLgTzXoBXxuXTF+4hY8NlL4F9CEeTdII6S6sONYG71X BJvMLIxDxymIk7QXFdUXa6BXCel4mEtW2jCzj9l91z6JqpEEeNDa9cCFP Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10989"; a="19893439" X-IronPort-AV: E=Sophos;i="6.06,170,1705392000"; d="scan'208";a="19893439" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 11:58:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,170,1705392000"; d="scan'208";a="9239476" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 11:58:14 -0800 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 1BC0611F855; Mon, 19 Feb 2024 21:58:08 +0200 (EET) From: Sakari Ailus <sakari.ailus@linux.intel.com> To: linux-kernel@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com>, Tomas Winkler <tomas.winkler@intel.com>, Wentong Wu <wentong.wu@intel.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Subject: [PATCH v2 1/3] mei: vsc: Call wake_up() in the threaded IRQ handler Date: Mon, 19 Feb 2024 21:58:05 +0200 Message-Id: <20240219195807.517742-2-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240219195807.517742-1-sakari.ailus@linux.intel.com> References: <20240219195807.517742-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791370391616813434 X-GMAIL-MSGID: 1791370391616813434 |
Series |
MEI VSC fixes and cleanups
|
|
Commit Message
Sakari Ailus
Feb. 19, 2024, 7:58 p.m. UTC
The hard IRQ handler vsc_tp_irq() is called with a raw spinlock taken.
wake_up() acquires a spinlock, a sleeping lock on PREEMPT_RT. This leads
to sleeping in atomic context.
Move the wake_up() call to the threaded IRQ handler vsc_tp_thread_isr()
where it can be safely called.
Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/misc/mei/vsc-tp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
> From: Sakari Ailus <sakari.ailus@linux.intel.com> > > The hard IRQ handler vsc_tp_irq() is called with a raw spinlock taken. > wake_up() acquires a spinlock, a sleeping lock on PREEMPT_RT. Does this mean we can't use wake_up() in isr? BR, Wentong > This leads to sleeping in atomic context. > > Move the wake_up() call to the threaded IRQ handler vsc_tp_thread_isr() > where it can be safely called. > > Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > drivers/misc/mei/vsc-tp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c index > 6f4a4be6ccb5..2b69ada9349e 100644 > --- a/drivers/misc/mei/vsc-tp.c > +++ b/drivers/misc/mei/vsc-tp.c > @@ -416,8 +416,6 @@ static irqreturn_t vsc_tp_isr(int irq, void *data) > > atomic_inc(&tp->assert_cnt); > > - wake_up(&tp->xfer_wait); > - > return IRQ_WAKE_THREAD; > } > > @@ -425,6 +423,8 @@ static irqreturn_t vsc_tp_thread_isr(int irq, void > *data) { > struct vsc_tp *tp = data; > > + wake_up(&tp->xfer_wait); > + > if (tp->event_notify) > tp->event_notify(tp->event_notify_context); > > -- > 2.39.2
Hi Wentong, On Thu, Feb 22, 2024 at 03:26:18AM +0000, Wu, Wentong wrote: > > From: Sakari Ailus <sakari.ailus@linux.intel.com> > > > > The hard IRQ handler vsc_tp_irq() is called with a raw spinlock taken. > > wake_up() acquires a spinlock, a sleeping lock on PREEMPT_RT. > > Does this mean we can't use wake_up() in isr? Good question. A lot of callers currently do. In this case, handle_edge_irq() takes the raw spinlock and acquiring the wake queue spinlock in wake_up() leads to sleeping IRQs disabled (see below). I don't think there's any harm in moving the wake_up() to the threaded handler. -------8<--------------------------- [ 54.216989] ============================= [ 54.218458] [ BUG: Invalid wait context ] [ 54.219913] 6.8.0-rc2+ #1972 Not tainted [ 54.221493] ----------------------------- [ 54.223165] swapper/4/0 is trying to lock: [ 54.224756] ffff888112d04688 (&tp->xfer_wait){....}-{3:3}, at: __wake_up_common_lock+0x25/0x60 [ 54.226426] other info that might help us debug this: [ 54.228189] context-{2:2} [ 54.229817] no locks held by swapper/4/0. [ 54.231453] stack backtrace: [ 54.233078] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.8.0-rc2+ #1972 [ 54.234720] Hardware name: Dell Inc. XPS 9315/0WWXF6, BIOS 1.3.0 08/16/2022 [ 54.236361] Call Trace: [ 54.237983] <IRQ> [ 54.239594] dump_stack_lvl+0x6a/0x9f [ 54.241147] __lock_acquire+0x43e/0x11fb [ 54.242704] ? mark_lock+0x96/0x34d [ 54.244212] ? check_chain_key+0xe5/0x132 [ 54.245759] ? __wake_up_common_lock+0x25/0x60 [ 54.247312] lock_acquire+0x128/0x27c [ 54.248848] ? __wake_up_common_lock+0x25/0x60 [ 54.250384] _raw_spin_lock_irqsave+0x3e/0x51 [ 54.251922] ? __wake_up_common_lock+0x25/0x60 [ 54.253524] __wake_up_common_lock+0x25/0x60 [ 54.255049] vsc_tp_isr+0x1e/0x28 [mei_vsc_hw] [ 54.256569] __handle_irq_event_percpu+0xb4/0x1aa [ 54.258054] handle_irq_event_percpu+0xf/0x32 [ 54.259550] handle_irq_event+0x34/0x53 [ 54.260982] handle_edge_irq+0xb0/0xcf [ 54.262440] handle_irq_desc+0x39/0x43 [ 54.263898] intel_gpio_irq+0x105/0x15a [ 54.265348] __handle_irq_event_percpu+0xb4/0x1aa [ 54.266792] handle_irq_event_percpu+0xf/0x32 [ 54.268244] handle_irq_event+0x34/0x53 [ 54.269634] handle_fasteoi_irq+0xa5/0x131 [ 54.271018] __common_interrupt+0xdc/0xeb [ 54.272392] common_interrupt+0x96/0xc1 [ 54.273754] </IRQ> [ 54.275109] <TASK> [ 54.276391] asm_common_interrupt+0x22/0x40 [ 54.277733] RIP: 0010:cpuidle_enter_state+0x171/0x253 [ 54.279071] Code: 8b 73 04 83 cf ff 49 89 c6 e8 62 fe df ff 31 ff e8 65 29 79 ff 45 84 ff 74 07 31 ff e8 0d c3 7f ff e8 fc 91 85 ff fb 45 85 e4 <0f> 88 ba 00 00 00 48 8b 04 24 49 63 cc 48 6b d1 68 49 29 c6 48 89 [ 54.280496] RSP: 0018:ffffc900001a7e88 EFLAGS: 00000202 [ 54.281935] RAX: 0000000000000004 RBX: ffffe8ffffa310c0 RCX: 000000000000001f [ 54.283382] RDX: 0000000c9f7cf88f RSI: ffffffff82103e63 RDI: ffffffff8209b592 [ 54.284828] RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000001 [ 54.286274] R10: 0000000001151268 R11: 0000000000000020 R12: 0000000000000004 [ 54.287699] R13: ffffffff8266fec0 R14: 0000000c9f7cf88f R15: 0000000000000000 [ 54.289127] ? cpuidle_enter_state+0x16d/0x253 [ 54.290564] cpuidle_enter+0x2a/0x38 [ 54.291987] do_idle+0x190/0x204 [ 54.293394] cpu_startup_entry+0x2a/0x2c [ 54.294797] start_secondary+0x12d/0x12d [ 54.296198] secondary_startup_64_no_verify+0x15e/0x16b [ 54.297595] </TASK> -------8<--------------------------- > > BR, > Wentong > > > This leads to sleeping in atomic context. > > > > Move the wake_up() call to the threaded IRQ handler vsc_tp_thread_isr() > > where it can be safely called. > > > > Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > --- > > drivers/misc/mei/vsc-tp.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c index > > 6f4a4be6ccb5..2b69ada9349e 100644 > > --- a/drivers/misc/mei/vsc-tp.c > > +++ b/drivers/misc/mei/vsc-tp.c > > @@ -416,8 +416,6 @@ static irqreturn_t vsc_tp_isr(int irq, void *data) > > > > atomic_inc(&tp->assert_cnt); > > > > - wake_up(&tp->xfer_wait); > > - > > return IRQ_WAKE_THREAD; > > } > > > > @@ -425,6 +423,8 @@ static irqreturn_t vsc_tp_thread_isr(int irq, void > > *data) { > > struct vsc_tp *tp = data; > > > > + wake_up(&tp->xfer_wait); > > + > > if (tp->event_notify) > > tp->event_notify(tp->event_notify_context); > >
> -----Original Message----- > From: Sakari Ailus <sakari.ailus@linux.intel.com> > > The hard IRQ handler vsc_tp_irq() is called with a raw spinlock taken. > wake_up() acquires a spinlock, a sleeping lock on PREEMPT_RT. This leads to > sleeping in atomic context. > > Move the wake_up() call to the threaded IRQ handler vsc_tp_thread_isr() > where it can be safely called. > > Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Tested-and-Reviewed-by: Wentong Wu <wentong.wu@intel.com> > --- > drivers/misc/mei/vsc-tp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c index > 6f4a4be6ccb5..2b69ada9349e 100644 > --- a/drivers/misc/mei/vsc-tp.c > +++ b/drivers/misc/mei/vsc-tp.c > @@ -416,8 +416,6 @@ static irqreturn_t vsc_tp_isr(int irq, void *data) > > atomic_inc(&tp->assert_cnt); > > - wake_up(&tp->xfer_wait); > - > return IRQ_WAKE_THREAD; > } > > @@ -425,6 +423,8 @@ static irqreturn_t vsc_tp_thread_isr(int irq, void > *data) { > struct vsc_tp *tp = data; > > + wake_up(&tp->xfer_wait); > + > if (tp->event_notify) > tp->event_notify(tp->event_notify_context); > > -- > 2.39.2
Hi Wentong, On Wed, Feb 28, 2024 at 08:19:04AM +0000, Wu, Wentong wrote: > > -----Original Message----- > > From: Sakari Ailus <sakari.ailus@linux.intel.com> > > > > The hard IRQ handler vsc_tp_irq() is called with a raw spinlock taken. > > wake_up() acquires a spinlock, a sleeping lock on PREEMPT_RT. This leads to > > sleeping in atomic context. > > > > Move the wake_up() call to the threaded IRQ handler vsc_tp_thread_isr() > > where it can be safely called. > > > > Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > Tested-and-Reviewed-by: Wentong Wu <wentong.wu@intel.com> Thanks! I dug a little bit deeper and it seems the lockdep warning this patch fixes is something we can safely ignore, see <URL:https://wiki.archlinux.org/title/Realtime_kernel_patchset#How_does_the_realtime_patch_work>. My apologies for the noise. The two other patches in the set are still unaffected by this.
On Thu, Feb 22, 2024, at 12:46, Sakari Ailus wrote: > Hi Wentong, > > On Thu, Feb 22, 2024 at 03:26:18AM +0000, Wu, Wentong wrote: >> > From: Sakari Ailus <sakari.ailus@linux.intel.com> >> > >> > The hard IRQ handler vsc_tp_irq() is called with a raw spinlock taken. >> > wake_up() acquires a spinlock, a sleeping lock on PREEMPT_RT. >> >> Does this mean we can't use wake_up() in isr? > > Good question. A lot of callers currently do. If driver has a traditional (non-threaded) handler, it should always work fine: on non-PREEMPT_RT it can take the spinlock and on PREEMPT_RT it automatically turns into a threaded handler that can still call it. > In this case, handle_edge_irq() takes the raw spinlock and acquiring the > wake queue spinlock in wake_up() leads to sleeping IRQs disabled (see > below). > > I don't think there's any harm in moving the wake_up() to the threaded > handler. It causes an extra bit of latency for the non-PREEMPT_RT case because you now always have to go through two task switches. This is probably fine if you don't care about latency. You can probably replace the open-coded completion (wait queue head plus atomic) with a normal 'struct completion' and call complete() in the isr instead. This one seems to only take a raw spinlock already. Arnd
diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c index 6f4a4be6ccb5..2b69ada9349e 100644 --- a/drivers/misc/mei/vsc-tp.c +++ b/drivers/misc/mei/vsc-tp.c @@ -416,8 +416,6 @@ static irqreturn_t vsc_tp_isr(int irq, void *data) atomic_inc(&tp->assert_cnt); - wake_up(&tp->xfer_wait); - return IRQ_WAKE_THREAD; } @@ -425,6 +423,8 @@ static irqreturn_t vsc_tp_thread_isr(int irq, void *data) { struct vsc_tp *tp = data; + wake_up(&tp->xfer_wait); + if (tp->event_notify) tp->event_notify(tp->event_notify_context);