Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp948767rwb; Tue, 27 Sep 2022 06:41:03 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4CdwDwaKH/wyufdmldNrcN++VbI8p8YOKhaWPLcg9fM78rxfeaUoZ0QyRzqFsqKWs096LR X-Received: by 2002:a17:903:1245:b0:178:9234:3768 with SMTP id u5-20020a170903124500b0017892343768mr27371748plh.146.1664286063433; Tue, 27 Sep 2022 06:41:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664286063; cv=none; d=google.com; s=arc-20160816; b=dfuA6DdZ3G5N6Kjug/qDhkKUhhKRHCNGzzR3euMYUhIzugqXQmByHWKFeqKp5/RJm0 aHRzx8AJfUVlbS/PgzLIEy+4HqZjL+hW6SSA39xwYvVcPozZSd4O9/0scQsnzqT/1FWR mcwwHiFtslZL5+gxlK6fs17cuyVBkHC8CeZJMIXEVOxyphSqDD5AMXuURyRnKaelg5r2 bApMw3Nfa6a5//4Gt1ju/fhT0xVggHwmniCN19SnGw4nx1uYdQJ6AyG8nmLds6y876s0 Q+x4LR+YoEHkjkmOzShm9FBZtTrTAxGmpfKY1Lu3btH4ovIbaloSGboAzXcznkKIeVqD h2XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=gpkfqV9LqaqtIXYV9NVkyE+oRu91BA6o1ZPDjZ4np/Q=; b=q8grF4/+sYVI5KUb3zfO2ApvtZrTY/A74w61FWrJXo0pGz/h9KHhHWR9375YWOpKCe NaaDMylq+nf42/ucWAciWgyUXNUHYtPr12JCYvpFnEbkW+QiN9stWxPyY5xqqb32mx7t wTty4wEKl0nNdR0UMNd6/yxeMp5uTxmATRA3gLjkAuZP5l5W6afEgZn7aG2cn2VNXiqu 8YQOq691vlIN08R2gfKMG4PDUuMGjBV4gyFpahaMRnWO+zGSFZG7Ogd0iVf/AVf+5hg2 tuS7SlY6ttLB0fYsiHuKEJwK/0Kt4l2K0fsL1bg/QAjX0rrTf5EXHmmhYDOVuUN0HIpJ qoIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W3xA2sj8; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n15-20020a63a50f000000b0043c8ce929bbsi1954017pgf.95.2022.09.27.06.40.51; Tue, 27 Sep 2022 06:41:03 -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=@intel.com header.s=Intel header.b=W3xA2sj8; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231725AbiI0M3w (ORCPT + 99 others); Tue, 27 Sep 2022 08:29:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231881AbiI0M27 (ORCPT ); Tue, 27 Sep 2022 08:28:59 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 309CD12888D; Tue, 27 Sep 2022 05:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664281642; x=1695817642; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=V4TS9Qc3Cqv4yBjI7kNikCjjWn3L2ESGLMtkevk0BkA=; b=W3xA2sj8rx/B/NOy7czvduDKD3/CIu5d444WQCaffua5e0kBeTYd/Cki 4z5Ss01xJK1005VLHvhrqocpcIbL2DqKtD06opkie7VctdlJa3048PcB9 5veXgReqIrjg5ZIGC7hvxiISACSNmXhKSiXoKgPZv30/X1upDVdO4SNhH lHcv6VPAnhQ7HFf3sF2gR2SrGGdoAVS/Kt+omj+dHZsk0B3L0o3TMR58m +H3Uj3rDR2gbKPkYNgKXDh43c6gzzBSP3isPWXS580NsMP3WPr3s/QbjB dq/NHMWbjS5pXoClESHYtXySdYAM1ijACtS+5qhB+3yCWYU0Bc8xHttzg w==; X-IronPort-AV: E=McAfee;i="6500,9779,10482"; a="288453311" X-IronPort-AV: E=Sophos;i="5.93,349,1654585200"; d="scan'208";a="288453311" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2022 05:27:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10482"; a="654708104" X-IronPort-AV: E=Sophos;i="5.93,349,1654585200"; d="scan'208";a="654708104" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga001.jf.intel.com with ESMTP; 27 Sep 2022 05:27:19 -0700 Received: by black.fi.intel.com (Postfix, from userid 1001) id 6493C7C; Tue, 27 Sep 2022 15:27:38 +0300 (EEST) Date: Tue, 27 Sep 2022 15:27:38 +0300 From: Mika Westerberg To: Rajat Khandelwal Cc: andreas.noever@gmail.com, michael.jamet@intel.com, YehezkelShB@gmail.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] thunderbolt: Add wake on connect/disconnect on USB4 ports Message-ID: References: <20220928115230.2031934-1-rajat.khandelwal@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220928115230.2031934-1-rajat.khandelwal@intel.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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 Hi, On Wed, Sep 28, 2022 at 05:22:30PM +0530, Rajat Khandelwal wrote: > Wake on connect/disconnect is only supported while runtime suspend > for now, which is obviously necessary. Its also not inherently > desired for the system to wakeup on thunderbolt hot events. > However, we can still make user in control of waking up the system > in the events of hot plug/unplug. > This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs > attribute and only enables wakes on connect/disconnect to the > respective port when 'wakeup' is set to 'enabled'. The attribute > is set to 'disabled' by default. > > Signed-off-by: Rajat Khandelwal > --- > > Significant changes and reasons: > 1. 'if (!port->cap_usb4)' is added under the loop in > 'usb4_switch_check_wakes' function since the checks later are > explicitly targeted to the USB4 port configuration capability. > 'if (!tb_port_has_remote(port))' is removed because events now can > be connection/disconnection along with USB4 events. Thus, a wake > on connection can be triggered by user on the USB4 port (initially > no remote). > 2. Verified runtime wakeup. It works absolutely fine. > 3. Wakeup count has to be increased in the 'wakeup_count' attribute > under usb4_port/power, thus requiring another pm_wakeup_event. > > Fixes in v4: Have you sent this patch previously upstream? I don't think so. So the version number should be v1 (or ignored) and this changelog is not needed either. Also in future it is good to have link here to the previous versions of the patch. I think all this is explained in https://docs.kernel.org/process/index.html.