Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp1858875ybh; Sun, 4 Aug 2019 11:26:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqwL3d9KzhLgW6ukpTxAL6Iw8BFedqgnDmxToL8VsAZF58TeAL2cXwjbyVKhd8IbGPK5tFbJ X-Received: by 2002:a17:902:6b0c:: with SMTP id o12mr38024654plk.113.1564943198653; Sun, 04 Aug 2019 11:26:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564943198; cv=none; d=google.com; s=arc-20160816; b=PF0gjlBGIlaHQPJH3gI01+sUD30iL8NCHO5M6i+zr1vNbOFMu1hTqavM5PGXeXpl5L pKuf2FRYF7MayzGBabLK1pZBM0rz2GIT5XbiIKZG1+pD6HFvI+ZIsPeFYKPCPaTsnrqy hw+XayRtNlPIellZyNJIMJyXkvZu5w56MwU2dcbZEnjshkl9BXZujN3ZMRav7FDeMgbp g/18hOAU7DJAGNw5h1xQw+bv6XcdGLYs6QSPZPinr4uOyM6YaClS/Nqv+hxAlXVgqn6t Nmw1YbhrHTQ6goiVRl767KqMQCxrPcFxAR6TUwFeWWDqeuZ3cnPnFrah4rKeMxbTvgMn KZFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=x1noeLykc1iUI5EGF/BOS1eDa5MtJWQJuTh0hxmDttc=; b=mhJ5xj9/mvrow3kU5kgCQgfWVQ+gUgmciVsH/ax/pQCrEQil8n8GPBYS8+9LVPUS/b vPCGh0hjV1wxeOAdQulDldpBbc7sQdBoJAGAwl0YlNbjUEIYvL1Apid/Ol0c1+ueQuIO bfey4ygqK52EdFz57lVmOQop3vLbTaIPFD3wFMV82GK5QOrJGJQslP//xKUemyu+foML hmQXDLRO0MZLaVm4zEKIng8vw73QtK33FVRtOPfvwpa0VPCgt7Keqllg8W5nJs7d6MmI seRP60JKh62+z6ozKzoSBiT9zREUz6mMv/gIoP9PP8+GgHtpb4ysfFSmzk3bFgy+3rB2 uIXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9si4233556pll.333.2019.08.04.11.26.11; Sun, 04 Aug 2019 11:26:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726536AbfHDSZN (ORCPT + 99 others); Sun, 4 Aug 2019 14:25:13 -0400 Received: from bmailout3.hostsharing.net ([176.9.242.62]:33583 "EHLO bmailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726392AbfHDSZN (ORCPT ); Sun, 4 Aug 2019 14:25:13 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id 9A43A100D9411; Sun, 4 Aug 2019 20:25:10 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 4C6EE1213E; Sun, 4 Aug 2019 20:25:10 +0200 (CEST) Date: Sun, 4 Aug 2019 20:25:10 +0200 From: Lukas Wunner To: Mika Westerberg Cc: linux-kernel@vger.kernel.org, Andreas Noever , Michael Jamet , Yehezkel Bernat , "Rafael J . Wysocki" , Len Brown , Mario.Limonciello@dell.com, Anthony Wong , linux-acpi@vger.kernel.org Subject: Re: [PATCH 7/8] thunderbolt: Add support for Intel Ice Lake Message-ID: <20190804182510.m7tlftyc73sp6bjs@wunner.de> References: <20190705095800.43534-1-mika.westerberg@linux.intel.com> <20190705095800.43534-8-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190705095800.43534-8-mika.westerberg@linux.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 05, 2019 at 12:57:59PM +0300, Mika Westerberg wrote: > @@ -891,16 +1020,23 @@ static int nhi_resume_noirq(struct device *dev) > { > struct pci_dev *pdev = to_pci_dev(dev); > struct tb *tb = pci_get_drvdata(pdev); > + int ret; > + > + ret = nhi_power_up(tb->nhi); Some general thoughts: You're enabling Force Power during the resume_noirq phase of the NHI. If TBT devices were already connected before system sleep, the PCI core walks down the hierarchy during resume_noirq, puts each device into D0 and restores config space. For this to work, the NHI must have set up tunnels to attached devices. But it can hardly do that until Force Power is enabled. Yet I cannot see any provision here which causes the hotplug bridges to wait for the NHI to finish its resume_noirq phase. Don't you need that? On Macs we have quirk_apple_wait_for_thunderbolt() to resolve this issue. And a commit has been rotting on my development branch for years which replaces quirk_apple_wait_for_thunderbolt() with device links: https://github.com/l1k/linux/commit/8cbb1d589660 Also, you recently posted a patch stating that on Ice Lake, the NHI and hotplug bridges share an ACPI Power Resource: https://patchwork.kernel.org/patch/11015233/ How does that relate to the Force Power and Go2Sx dance implemented in the present patch? Does the ACPI Power Resource toggle the same Force Power and Go2Sx registers as this patch here? Or is that an additional power management mechanism? If Force Power is off on the NHI, are the hotplug bridges' config and mmio spaces accessible? All of this should be documented in code comments or at least the commit message. There's a quirk for Macs with Cactus Ridge to perform a Go2Sx dance during the suspend_noirq phase, quirk_apple_poweroff_thunderbolt(). Can this be reimplemented using the infrastructure you're adding in this patch? On Macs with Thunderbolt 1 and 2, there are ACPI methods to toggle Force Power in the NHI's namespace. However disabling Force Power not only cuts power to the NHI but also to the integrated PCIe switch. For this reason, I've implemented power management on these Macs using a struct dev_pm_domain which is assigned to the upstream bridge of the integrated PCIe switch. That way, power isn't cut until the Thunderbolt controller's top-most device in the hierarchy is runtime suspended: https://github.com/l1k/linux/commit/4db7f0b1f5c9 I'm wondering if it would make sense to similarly assign a dev_pm_domain to the NHI on Ice Lake. One thing that bothers me a bit with the present patch is that nhi.c is cluttered up with code specific to Ice Lake. That doesn't seem sustainable going forward as I expect we'll have to add plenty of other quirks once USB4 chipsets become available. Ideally the file should contain only (or mostly) generic code and quirks should be contained in separate files which need not be compiled in on unrelated arches. That's why in the above-linked commit to add Apple-specific power management, I put all the code in a pm_apple.c and nhi.c only calls tb_pm_apple_init() / _fini(), which become empty inline stubs if CONFIG_ACPI or CONFIG_PM isn't enabled. > --- a/drivers/thunderbolt/nhi.c > +++ b/drivers/thunderbolt/nhi.c > @@ -38,6 +40,60 @@ > #define MSIX_MAX_VECS 16 > > #define NHI_MAILBOX_TIMEOUT 500 /* ms */ > +#define LC_MAILBOX_TIMEOUT 500 /* ms */ > + > +enum lc_mailbox_cmd { > + LC_GO2SX = 0x02, > + LC_GO2SX_NO_WAKE = 0x03, > + LC_PREPARE_FOR_RESET = 0x21, > +}; Shouldn't these live together with the other LC macros in tb_regs.h? > + ret = device_for_each_child(&tb->root_switch->dev, NULL, > + nhi_device_connected); > + if (!ret) { > + lc_mailbox_cmd(tb->nhi, LC_PREPARE_FOR_RESET); > + ret = lc_mailbox_cmd_complete(tb->nhi, > + LC_MAILBOX_TIMEOUT); > + if (ret) > + return ret; > + > + return nhi_power_down(tb->nhi); > + } > + > + return 0; > +} Why not: if (ret) return 0; and that way reduce the indentation of the code in your if-block by 1 tab? Thanks, Lukas