Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp2070212rbb; Tue, 27 Feb 2024 09:39:23 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCX4CpMf/A5hjO/+Ln8Hno1z3Q2MpCYy6ec9PhPreMk8PpzRQYQ21j/KlVtmzqWfSYedSVStjbgB0G3HJKf3ZaqyQYuoDUK3/jqof/vLzQ== X-Google-Smtp-Source: AGHT+IFHsXP10h+vciBYlhVPT4Fj5i3LFaIU8lWge/ZdTBmoyQt9LRmdgoiRVwPi8Cn10TLAcbTS X-Received: by 2002:a9d:7998:0:b0:6e4:a450:a503 with SMTP id h24-20020a9d7998000000b006e4a450a503mr4938797otm.26.1709055563669; Tue, 27 Feb 2024 09:39:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709055563; cv=pass; d=google.com; s=arc-20160816; b=QhLcFvZGrzAxCxTcbWVbykocrGl6RzaAZEhO0u5fKH7zYRpF4nkOX7yp3c5eEqw50D xCpAk9Mb+d5JVHKqRnIixOmtroHE4tjjOs9gXFpl7+LtEu6LoSfNsu1m931xjXtutdAH 5eKdjCgQ6pAy8bwqKNS+MBeg5UJdNL7OQpnsrxBFCVn0TWiWg+xOA9unsNaCfkrrhMJA qwt3JVNnS7BupCStUqHO/Y9egGsRlWfLkbNfBeY46BdIryUw52l7zv5UZGy+x7k5asKC mAxb9NwddkJ45NgekTGku/7LkCZJce7DuQk/eEVQf8JO1sq6z9yVoctL3BPpI7Q+UlcF Yozw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:subject:cc:to:from:date:dkim-signature; bh=bKkf8uWfpEcbXXcrA8pAYGWoFKPSE1z347haE/xXLus=; fh=xfJuHMJtfkU7AgAsUUYBD7g1CbMZqeGaI18eLP6CMNU=; b=p8Uw+8AIl621wnOKK5J/cLGZ8T0qc5egCXlWkqV/DjH00h9FeNm2YDlMqFwM6B8DIn eJQb2neQdRBJtZ11cZkq5VKPYAaMIgl1tRe1q6uUPNRzACK8N/FhWu5iErXzYfZ53fWu jCH5nal/0uTOTeO5KBQ04BVnVIY0FbSJLQRNosM9jE6f3wxgVgffZWEK3wXtAKlkSCVU 0OVcd0mhd9C4Wsi2pj0qxsQ522NtMF2zfEI4C6ydUB8xGC5EX1w+cD1asWcUJd0xNsxU AqwTeLzT8JqtnU7E4VUOLruf605evWgR+ydnGRJnVNwCuHtMln+ESAW3rG9eTk9vUTKU NOJA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tP6sQLXi; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-83741-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-83741-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id y3-20020a63e243000000b005cee03a1bf9si5714404pgj.448.2024.02.27.09.39.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 09:39:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-83741-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tP6sQLXi; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-83741-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-83741-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 64386289BFC for ; Tue, 27 Feb 2024 17:38:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E2ACA4EB3B; Tue, 27 Feb 2024 17:37:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tP6sQLXi" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 843394E1BD; Tue, 27 Feb 2024 17:37:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709055427; cv=none; b=H4aAUVHU+wLCO2fwITlvFXrkApB9BlA5o3CGQMslztiW6PoItcd8a5QjHTzMVwOfw87/YxDb7peDCjInq5xBQtxbf1Hou+SLeUPbPEdiH991f0WUTVvbcmd2ZebWIkcDbnSLZDibyZfl3Ef0ILf67dwM2JbauPy97nS/Bgz/CMw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709055427; c=relaxed/simple; bh=kcCY13OTkGcMrsoVrg34boTcMN0rsdNg4ViQTr06L5Q=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=tIb0/fS3/VC46XRDV2Bc4h2NG0Ic6bGJHy39Sy24RMCuomSVMHWa/+uuk2lFSfhXmQ1Svg3dc0HTSMyDWwDoPZJhCetAgti4BAfUZHrq42QYNG6dBMBxGYCTaDCN+P6ERdofY9+xlaq4aHJwHgoW+OTXEU+A96eQnehtHiXTg08= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tP6sQLXi; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8FAEC433F1; Tue, 27 Feb 2024 17:37:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709055427; bh=kcCY13OTkGcMrsoVrg34boTcMN0rsdNg4ViQTr06L5Q=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=tP6sQLXiUAB6vXs63FdW15R7zXtYajub7uKs0w1bhnG5OICHxIBqsaYjeJEwkw7Lf cOx5CO204kQ80zCHEse2L+dXHQ8UkxKEEfTwOizDYa+vHkooesGEgIgUbSLRo1tJIW MNFDOpjp4YUd3Dd0HKDSIlH6Jm3wOn+h4ujerCiMNRD5Pp4T558/bQ12g197L2qmsQ vAHZ4B3M15fYeIQNODUPhWwe1FtekWFwX+V85PtFM1p+6bCvtJWE99IwAwXfDC4kiv v35fo086l5vid8yV9RkuuRFNXzLqXg2aI/6cU9PuBcXsZBCNdnTjCJXTfDeEQNQ7tV y13ZQPJzrEB7g== Date: Tue, 27 Feb 2024 11:37:05 -0600 From: Bjorn Helgaas To: Manivannan Sadhasivam Cc: Bjorn Helgaas , Bjorn Andersson , Konrad Dybcio , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Lukas Wunner , Mika Westerberg , quic_krichai@quicinc.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v3] PCI: Add D3 support for PCI bridges in DT based platforms Message-ID: <20240227173705.GA241732@bhelgaas> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240227170840.GR2587@thinkpad> On Tue, Feb 27, 2024 at 10:38:40PM +0530, Manivannan Sadhasivam wrote: > On Tue, Feb 27, 2024 at 10:25:35AM -0600, Bjorn Helgaas wrote: > > [...] > > > > Ok, I got the issue. TBH, I added the device tree property based on > > > the existing quirks for the ACPI devices. But none of the DT based > > > platforms I'm aware of (even the legacy Qcom MSM8996 chipset > > > released in early 2016) doesn't have any issue with D3hot. But I'm > > > just nervous to assume it is the case for all the DT based platforms > > > in the wild. > > > > > > But to proceed further, what is your preference? Should we ammend > > > the DT property to make it explicit that the propery only focuses on > > > the D3hot capability of the bridge and it works as per the spec > > > (PMCSR) or bite the bullet and enable D3hot for all the non-ACPI > > > platforms? > > > > > > We can add quirks for the bridges later on if we happen to receive > > > any bug report. > > > > I would assume all devices support D3hot via PMCSR per spec. We can > > add quirks if we discover something that doesn't. > > When you say "all devices", are you referring to bridges in DT > platforms or the bridges across all platforms? This patch is only concerned with DT, so that's what I'm commenting on here. I don't know how to untangle the question of ACPI systems. This patch affects platform_pci_bridge_d3(), so just based on the "platform" in the function name, I would expect it to be concerned with the D3cold case and whether the platform supports controlling main power. It looks like this patch says "we can put devices in D3cold if DT has 'supports-d3'". But I don't know how to make sense of that because that requires (a) platform hardware to control main power and (b) software that knows how to use that hardware. Wouldn't this require a little more DT description, like "regulator X controls main power for this bridge"? And then an OS would only be able to actually use D3cold if it knows how to *operate* the regulator, and it doesn't seem like DT could answer that. > > If we add annotations that "this device works correctly", we're > > digging a hole for ourselves because it's impossible to remove those > > annotations and they complicate all future maintenance. > > > > Bjorn > > -- > மணிவண்ணன் சதாசிவம்