Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp5957rwb; Fri, 16 Sep 2022 23:04:38 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6GeCJxTQ69ZK91T4C1iUJn2rUyICvXx3FnIsCQhDm20wA8c0f+EpwQTxHQwdrpVKrnMkL4 X-Received: by 2002:a17:907:2c67:b0:77d:740a:e9b1 with SMTP id ib7-20020a1709072c6700b0077d740ae9b1mr5642175ejc.614.1663394678724; Fri, 16 Sep 2022 23:04:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663394678; cv=none; d=google.com; s=arc-20160816; b=y4+a5fkCpRpqD7bap58Dme7bWdoX/FEtzZoPNKGP8tHtEa0ZYqHH82wBFkuWNuZj1K yeQyq7fEUQO1ySXf0vhse/Og1aIgMiU+2KXKpOVHvzqMPD4CaJVaABo5PE7PLwgZdtjq xQKzaHyk4/lcU6mOszJaS5zG6W6TZQWNe+RxMQvz4RE3VT4i3iAqnu5QW8WpdRKjb30s XrIPVrN2qcZszdKV7Abw3BEawmEijx0omj12MTZTGP69HuEVLVmC6/3i2uQ7kek7w2md UJhLR0WhN6EbOFpXC5sEMRKRikGZq2YwajX/sq41PGdA00tgUcXndllfqSAIxRXP+rwp 8jhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature:dkim-signature; bh=7Yp3zTHMwctw9hXJnmux/FcPbXl+5o9mxLXbEWDRw/E=; b=aOBr+lIzYTV7FkHWPf2lcfiH4ohI2J6qqEGATDDeByK6uAgEIB/l63Asnv/pMWT+4l g28AQ5rCDIYU7cQGrog+7VJ+p1q+KI35ut4mIFNnW7m2plHHUvJF0TcZ0+DUZMOTLfow 9TgQJfF9IhcXca2VN7aT8I7HKSkiOrU1lUM2LjBLuSirBb6NtqSyym6YFWdCCY97BQhy v9Gvosds+5MUI2MrkgQ+rLWVkIfPyGzEvQXKUst55YLY6HBS6+TQPHf0SR5ssNYE4nQB ZmQF65qmqbvsMVx38RqkpagB/p70dHJp4sqtdL/K4wGDJhelw/ZmaM0JPOdPCQwjsajh 2ksQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=sfzONBFh; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=TJcvE7UN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c25-20020a170906155900b00779a69067afsi15589527ejd.830.2022.09.16.23.04.08; Fri, 16 Sep 2022 23:04:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=sfzONBFh; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=TJcvE7UN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229492AbiIQFvm (ORCPT + 99 others); Sat, 17 Sep 2022 01:51:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229528AbiIQFv2 (ORCPT ); Sat, 17 Sep 2022 01:51:28 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B7DD52466 for ; Fri, 16 Sep 2022 22:51:26 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7EDD8348BA; Sat, 17 Sep 2022 05:51:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1663393885; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7Yp3zTHMwctw9hXJnmux/FcPbXl+5o9mxLXbEWDRw/E=; b=sfzONBFhT/8Xu68WgwfyjXWpt953h6ozCteLdk8wVylY9nt1kMrs7YEbh0i0GTMHFyWCgA HuDMSYfvYcwi4UCoHaNcpqBMrIS6JAStR7LERdgYvoHj37whYUyFqUVpmSiCKtDmSwuG3s 8CdhrfipUfw4+N0xf7rpsZcgrHGrnQ0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1663393885; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7Yp3zTHMwctw9hXJnmux/FcPbXl+5o9mxLXbEWDRw/E=; b=TJcvE7UN01MU0DvI5CZEZzTaTvvm7n+WArzkEoO8g44PUiMEs7Sj8F6Tt/BhqKiC5Qp5Yj oa6F4poRJuAJZRBQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3458213A7F; Sat, 17 Sep 2022 05:51:25 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id TA/uC11gJWPkdQAAMHmgww (envelope-from ); Sat, 17 Sep 2022 05:51:25 +0000 Date: Sat, 17 Sep 2022 07:51:24 +0200 Message-ID: <87k062r1k3.wl-tiwai@suse.de> From: Takashi Iwai To: "Arava, Jairaj" Cc: Takashi Iwai , Pshou , "linux-kernel@vger.kernel.org" , "Nujella, Sathyanarayana" , "Prabhu, Swarna" , "Afzal, Naeem M" , "Hsu, Shui-Wen" , "Perati, RK" , "Mandri, Padmashree" , Kailang Subject: Re: Sarien/Dorset device: After system resumed from suspend, 3.5m jack is still shown as detected when unplugged during suspend In-Reply-To: References: <874jx7vdhs.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 16 Sep 2022 21:50:51 +0200, Arava, Jairaj wrote: > > Hi Takashi, > > This discussion is regarding the bug https://bugzilla.kernel.org/show_bug.cgi?id=215297. Did you read the comment 17? You haven't analyzed yet properly what was going wrong. > As we know https://lore.kernel.org/alsa-devel/20210310112809.9215-3-tiwai@suse.de/ is causing the 3.5mm headset jack detection issue during system suspend resume. So after reverting this patch the issue is not seen since the unsol event is handled without this patch. > > Since we see in https://elixir.bootlin.com/linux/latest/source/sound/pci/hda/patch_realtek.c#L992 the codec driver has snd_hda_jack_unsol_event as the unsol event handler. Hence after reverting your patch, from https://elixir.bootlin.com/linux/latest/source/sound/pci/hda/hda_bind.c#L56 the driver is calling https://elixir.bootlin.com/linux/latest/source/sound/pci/hda/hda_jack.c#L713 to handle the unsolv event. > > Based on above observance, seems snd_hda_jack_unsol_event is mandatory for the intel platform Realtek codec driver to handle such unsolv enets. Hence, @Pshou added the PM flag check as the patch was tested by Nvidia. If the hardware can't detect the jack at the resume by some reason, that must be the cause, and not because it doesn't handle the unsol event during the suspend. Please try to debug more deeply at first. thanks, Takashi > > Thanks, > Jai > -----Original Message----- > From: Takashi Iwai > Sent: Friday, September 16, 2022 3:08 AM > To: Pshou > Cc: linux-kernel@vger.kernel.org; Takashi Iwai ; Arava, Jairaj ; Nujella, Sathyanarayana ; Prabhu, Swarna ; Afzal, Naeem M ; Hsu, Shui-Wen ; Perati, RK ; Mandri, Padmashree ; Kailang > Subject: Re: Sarien/Dorset device: After system resumed from suspend, 3.5m jack is still shown as detected when unplugged during suspend > > On Fri, 16 Sep 2022 07:34:38 +0200, > Pshou wrote: > > > > > > Hi Takashi Iwai: > > > > Can you help me update this PATCH file? > > > > Check if ignore unsol events duing system suspend/resume and NVIDIA > > chip in hda_codec_unsol_event(). > > > > Signed-off-by:PeiSen Hou > > > > Signed-off-by: Jairaj Arava > > > > diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c > > > > index 1a868dd9dc4b..75560ff6eb83 100644 > > > > --- a/sound/pci/hda/hda_bind.c > > > > +++ b/sound/pci/hda/hda_bind.c > > > > @@ -50,7 +50,8 @@ static void hda_codec_unsol_event(struct hdac_device > > *dev, unsigned int ev) > > > > /* ignore unsol events during system suspend/resume */ > > > > if (codec->core.dev.power.power_state.event != PM_EVENT_ON) > > > > - return; > > > > + if (codec->core.vendor_id == PCI_VENDOR_ID_NVIDIA) > > > > + return; > > > > if (codec->patch_ops.unsol_event) > > > > codec->patch_ops.unsol_event(codec, ev); > > Hmm, this doesn't look safe. We also want to avoid the unsol event handling during the PM state transition, too. So, if any, this should be allowed only at PM_EVENT_SUSPEND or PM_EVENT_HIBERNATE. > > Also, checking the codec vendor ID here is no good way. We may add a new flag for the special behavior (either allowing the unsol handling or prohibiting). > > But, from your patch, I don't see any reason *why* this has to be changed in that way. Could you give more backgrounds? > > > thanks, > > Takashi >