From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C66CC433FE for ; Tue, 8 Feb 2022 06:33:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347453AbiBHGd0 (ORCPT ); Tue, 8 Feb 2022 01:33:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229847AbiBHGdZ (ORCPT ); Tue, 8 Feb 2022 01:33:25 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E13D1C0401EF; Mon, 7 Feb 2022 22:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644302004; x=1675838004; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9jg7rs/9d9B2nZhgpl+jOoQzcAvvsYwCDrq5DLE+r60=; b=Geegj7pnVulhFAmm5CS0w+FTCNVhuMKXMNEvUkrFnG+SiAM5Vz4QVFI5 N8L57if67/zDsm1IECxqUu2RTULMC+U9mvBnqi29sDIFZpUwGha9cQM0B T/Mvg0+g9sFudSGSGfJ3OCcXCI+JF2i5WHgyzppBCTej0anoUfawCDXio cu1n+EXbD78JDMLK4/Nx2/subrnb5G7xdlQjSUcwVVHO5ysJ8PG4A7neM /b40PL/QyGLR24pl1P5XM10ZHIycJ+IpPqPYy6c+jlYjLKjr9/vy2p3HK 5FS0LeW00Wd7a9kR6K/9y+3R/fS3nAPfJZbvkJ1W9w9J538fjtneoKCby A==; X-IronPort-AV: E=McAfee;i="6200,9189,10251"; a="312181870" X-IronPort-AV: E=Sophos;i="5.88,351,1635231600"; d="scan'208";a="312181870" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Feb 2022 22:33:24 -0800 X-IronPort-AV: E=Sophos;i="5.88,351,1635231600"; d="scan'208";a="484704520" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.162]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Feb 2022 22:33:21 -0800 Received: by lahna (sSMTP sendmail emulation); Tue, 08 Feb 2022 08:33:18 +0200 Date: Tue, 8 Feb 2022 08:33:18 +0200 From: Mika Westerberg To: Lukas Wunner Cc: "Deucher, Alexander" , "Limonciello, Mario" , Bjorn Helgaas , Andreas Noever , "open list:PCI SUBSYSTEM" , "open list:THUNDERBOLT DRIVER" , Michael Jamet , Yehezkel Bernat Subject: Re: [PATCH 0/2] Mark USB4 controllers as is_thunderbolt Message-ID: References: <20220204182820.130339-1-mario.limonciello@amd.com> <20220207174703.GA25761@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220207174703.GA25761@wunner.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Hi, On Mon, Feb 07, 2022 at 06:47:03PM +0100, Lukas Wunner wrote: > On Mon, Feb 07, 2022 at 03:52:13PM +0000, Deucher, Alexander wrote: > > > From: Mika Westerberg > > > The other option is to look for ACPI companion (ACPI_COMPANION()) of the > > > device. AFAICT dGPUs don't have one (as the BIOS does not know in advance > > > what will be connected to the hotplug ports) whereas internal does typically > > > have one. > > > > Yeah, this is probably the right way to do this. > > No, that doesn't work. At least Apple represents the first few devices > in the Thunderbolt daisy-chain in the ACPI namespace, so IIUC you'd find > an ACPI companion for those but not for the remainder of the daisy-chain. > This is from a 2019/2020 MacBookPro16,1: > > $ grep 'Device ' acpidump/mbp161/ssdt6.dsl > Device (UPSB) > Device (DSB0) > Device (NHI0) > Device (DSB1) > Device (UPS0) > Device (DSB0) > Device (DEV0) > Device (DSB3) > Device (UPS0) > Device (DSB0) > Device (DEV0) > Device (DSB3) > Device (DEV0) > ... > > There's a *reason* why I introduced the is_thunderbolt flag, > there is no other reliable way to detect externally attached devices. In case of dGPU, the thing (I think) that is needed is whether there is some sort of power resource attached to the root port that allows powering it down or so. That can still be done without is_thunderbolt flag using the current ACPI functions. [ IMHO we should get rid of that flag completely, or rename it to some more generic like "removable" (following USB, perhaps moving to driver core) that allows drivers to check if the device is soldered on the motherboard or hanging off of some hotpluggable port. ]