Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2047675pxu; Tue, 24 Nov 2020 15:48:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJyevw36IqRxRbyeJJaKNSviMbcxepqoH8hKS/vN4+g7a+3xvqqLqeFIhufMi8CiOyAeiMqt X-Received: by 2002:a17:906:4982:: with SMTP id p2mr837839eju.416.1606261723165; Tue, 24 Nov 2020 15:48:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606261723; cv=none; d=google.com; s=arc-20160816; b=SZcLuXc4Gd74ot1pOOIx8rMwHh5VSy3ZwhgnCJ+kHF0upgnwRDxRK4Eqo25z117Bk1 BkINh/JBNz3ZCdGGUXrtHrDiFQipTbSH32YAK0GkVbnt3//eqcB5waE2hJ0bh5+9cfue VlqYSLldCf4H5OXocRtWJy5vJCefmgy0eHlATjshqkK/z1Ou0aViSHkThX7d/qAlX+Zd dIGv+6sajUlyOIXxR9PoqevqzsQzVeeo2GiyDK5g7/KWqRwWIj0+nBR9cKJuEJn4crPu cnFsPJ1t1ifMwcuckrs0OCAgYiiFcgf7vDef8tHB2iH0QPj11MVywTN+7A+Izl1PGKjz Ymgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=nVs7Pb8c8sJ5L+f5dmHx/bFvDyMgv5Qf07/x6oV14G0=; b=TO6SNEKnw8ffU7yE0A1Ww8bc8vlpjUETYMjrJ46YF2N5OUWJVCQi70CtROZJ/UAzIC i410YGpHMqgvKUlkAKmitS9/l/MJJFE4LpacKawYJlv/QW+/QzsWSu8SpKPVobU2OySM uN1UDU8UabjB7oDFLMVR53SPsaBJTBtGctt9gHU3Nl1kAS5BuFag1xhj8mXf6LwUFkhX xGUjCEKgfp3ODLe0KWnHx3hANmv+Pb5UQ5tlCOSF60ymBatGLVZi7oztTftcX+3xN6Xz HvaPwkHEqVVYMltD5TeZ2XEhGJxhHXtYY8arnvMvs4R7XeAxB5ER5xx/EcuVfjo/9MYd pmHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si272551ejf.167.2020.11.24.15.48.19; Tue, 24 Nov 2020 15:48:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390815AbgKXRcG convert rfc822-to-8bit (ORCPT + 99 others); Tue, 24 Nov 2020 12:32:06 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:33890 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728749AbgKXRcF (ORCPT ); Tue, 24 Nov 2020 12:32:05 -0500 Received: from mail-pf1-f200.google.com ([209.85.210.200]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1khcAd-00026Z-03 for linux-kernel@vger.kernel.org; Tue, 24 Nov 2020 17:32:03 +0000 Received: by mail-pf1-f200.google.com with SMTP id z28so16159173pfr.12 for ; Tue, 24 Nov 2020 09:32:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c59NXUKfsVeXI+YuJz0D1TteRrVfduhKNfg9Shm/UEo=; b=G3YnrGgBFnIYMFfM5a5L8PRWwuPELragFwDXOWyVQ04qruoikt9JM2+9WIRxFetKSi juaRn7Xb+pnp6EOmwPRn5qfKlPzXEJ62CNl2GGn7DllVz4Tz7YHJwCIEKp7p/zUWiO8p Nz1RFapRH+I6VwNbcSgfXqNUFdh9p7CkjWUsgt6Btj63u+LVBHcU9iGrDFPQshe8ZJtk Ncpt2zdnej9Jn3bsosmPfGn7cjrBKiVN6I1u6T0DoNORPodq9hpKNSghj0I7JFLP3gT7 gzFRLqORUel9k9A08GGPNRDhpVft0f+laiIp4s7uFfjLy95pbrHWBtDTgehgFw9AgIrC WqNA== X-Gm-Message-State: AOAM533VJ5crYBAEoxSVUc3ULayHdzi+iq6tYmp7xIaq/D6yUli/oE3s Z+NaMRxgQ1t5ZA6meqoHJGuO9ugcLHDJng22DquGlle+QVOLwSD5u2oHrBUMUol1qUvRRAWvyYl UhUBbUzQM0KsOTj4LTT1ltLHmNrtUT1mTGKX3oX2JKQ== X-Received: by 2002:a63:381:: with SMTP id 123mr4637082pgd.112.1606239121625; Tue, 24 Nov 2020 09:32:01 -0800 (PST) X-Received: by 2002:a63:381:: with SMTP id 123mr4637060pgd.112.1606239121217; Tue, 24 Nov 2020 09:32:01 -0800 (PST) Received: from [192.168.1.208] (220-133-187-190.HINET-IP.hinet.net. [220.133.187.190]) by smtp.gmail.com with ESMTPSA id c22sm15239170pfo.211.2020.11.24.09.31.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Nov 2020 09:32:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Subject: Re: [PATCH] ACPI: PM: Re-enable ACPI GPE if it's already enabled From: Kai-Heng Feng In-Reply-To: Date: Wed, 25 Nov 2020 01:31:56 +0800 Cc: Rafael Wysocki , Andy Shevchenko , Mika Westerberg , Hans de Goede , Bjorn Helgaas , ACPI Devel Maling List , Linux PCI , "Rafael J. Wysocki" , Len Brown , open list Content-Transfer-Encoding: 8BIT Message-Id: <90E54BA3-FC3A-4538-ACD0-4C4DDF570C7C@canonical.com> References: <20201124073619.771940-1-kai.heng.feng@canonical.com> To: "Rafael J. Wysocki" X-Mailer: Apple Mail (2.3654.20.0.2.21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Nov 24, 2020, at 22:00, Rafael J. Wysocki wrote: > > On Tue, Nov 24, 2020 at 8:36 AM Kai-Heng Feng > wrote: >> >> Dell Precision 5550 fails to detect Thunderbolt device hotplug events, >> once the Thunderbolt device and its root port are runtime-suspended to >> D3cold. >> >> While putting the entire hierarchy to D3cold, the root port ACPI GPE is >> enabled via acpi_pci_propagate_wakeup() when suspending Thunderbolt >> bridges/switches. So when putting the root port to D3cold as last step, >> ACPI GPE is untouched as it's already enabled. >> >> However, platform may need PCI devices to be in D3hot or PME enabled >> prior enabling GPE to make it work. > > What platforms and why. Dell Precision 5550. Its thunderbolt port can't detect newly plugged thunderbolt devices. > >> So re-enable ACPI GPE to address this. >> >> Signed-off-by: Kai-Heng Feng >> --- >> drivers/acpi/device_pm.c | 13 ++++++------- >> 1 file changed, 6 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c >> index 94d91c67aeae..dc25d9d204ae 100644 >> --- a/drivers/acpi/device_pm.c >> +++ b/drivers/acpi/device_pm.c >> @@ -757,11 +757,10 @@ static int __acpi_device_wakeup_enable(struct acpi_device *adev, >> >> mutex_lock(&acpi_wakeup_lock); >> >> - if (wakeup->enable_count >= max_count) >> - goto out; >> - >> - if (wakeup->enable_count > 0) >> - goto inc; >> + if (wakeup->enable_count > 0) { >> + acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number); >> + acpi_disable_wakeup_device_power(adev); >> + } > > An event occurring at this point may be lost after this patch. Yes, so this approach is not optimal. > > It looks like you are trying to work around a hardware issue. Windows doesn't have this issue. So I don't think it's hardware issue. > Can you > please describe that issue in detail? The GPE used by Thunderbolt root port, was previously enabled by Thunderbolt switches/bridges. So when the GPE is already enabled when Thunderbolt root port is suspended. However, the GPE needs to be enabled after root port is suspended, and that's the approach this patch takes. Is there any actual hardware benefits from acpi_pci_propagate_wakeup()? If there's no actual device benefits from it, we can remove it and only enable GPE for the root port. Otherwise we need to quirk off Thunderbolt bridges/switches, since their native PME just work without the need to enable root port GPE. Kai-Heng > >> >> error = acpi_enable_wakeup_device_power(adev, target_state); >> if (error) >> @@ -777,8 +776,8 @@ static int __acpi_device_wakeup_enable(struct acpi_device *adev, >> acpi_handle_debug(adev->handle, "GPE%2X enabled for wakeup\n", >> (unsigned int)wakeup->gpe_number); >> >> -inc: >> - wakeup->enable_count++; >> + if (wakeup->enable_count < max_count) >> + wakeup->enable_count++; >> >> out: >> mutex_unlock(&acpi_wakeup_lock); >> -- >> 2.29.2