Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp310101pxb; Mon, 25 Oct 2021 08:44:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztomY+/K5vJETvk9LOhQN111j+LQgPqvoODM4BOJsr3chUJvGl88emXOtpbuytF1u6oNE2 X-Received: by 2002:a63:6fc9:: with SMTP id k192mr14301808pgc.49.1635176669221; Mon, 25 Oct 2021 08:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635176669; cv=none; d=google.com; s=arc-20160816; b=GeDaUG+YMAcVkDFO2CNk9y40d3p6qt0IztcsMZC0T2ErXCoG9CRBft0mMzeL0fjT1W WGdYc/m9qoy1o4ZJK9M0taYamiSNn1vODpQevkHpNIyxTPvizeeklrQXkPhanuMNJDC6 hDD881/pqhTLYHARSOF3qle92h2CC/9OSMsQ7T50wJEIrmVRq896KlTcmBAFHs0tYqbK STfxVFI2M3RQzpjOEUDVOQya6ZK5gDusuLO9caTUVILeUnalr3wevaHAVylpJ6nzeOEq ysKWwhZbGacHdw8V+5mtbSywWklH/m99MMgD7YdGHgLibGeUscoyNXgUgUx1Us85OZ8s y7VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=RHGVKjaPOqlDvxa5KtQZFBp41k947U9ARi5AJGZWOlI=; b=gAs97+DVqoECwzqWzx9blo9bslXLeHMHslF23Ki9s6s2pNgYrAGDIJwy3rKTlfzMaN 3n1BnVJxNPZh3xzI2pXcQgsDPq3ZJ+1fXnUZNdac9E4JNbQxQNWhSQEoYCCL1UPDEVi/ j7rhROe/G19CMmghbnZ46xVj7onZaoYR0oaj5qBWQRuaf97joASBwp5Mhs8KwFmsRimA 2L1XDkZTmA5DNNNBPXNm+g5eDiPRARpQq3zY2uwpemnn9l14OYK0UgCIeh8tKoHBDAVX /T0YSMWSmMmRMpkHLW8Nvztd/VQXgxSZvZhMMNRj8a5euwgFGOqKOnIg3hLOef8//+8Z yY4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uriQqWR7; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m22si22557567pff.308.2021.10.25.08.44.15; Mon, 25 Oct 2021 08:44:29 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uriQqWR7; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232685AbhJYPnH (ORCPT + 99 others); Mon, 25 Oct 2021 11:43:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:58656 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232673AbhJYPnG (ORCPT ); Mon, 25 Oct 2021 11:43:06 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2E63460F70; Mon, 25 Oct 2021 15:40:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635176444; bh=/EA1ZAMyLcB3Pv54GqH5FxuPnB3C0lNTVGdITSn85WM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uriQqWR79lkskbj36qK2x7YgxWLdQu3mGve8sf+/u4KBLMU4hcJihVdVNhhYg3yW7 uF6AzBPtz95P39yXY5UrzPDmk8MIS9V8YL83MpDHn/nmkHg2Xp1FbBORDoTx/noSs7 W8ugzkPVPVOwy9N2rSSTh4zFicqP/aHaLQOybu8ffl8o0bQZ+7WPknVyu45papGtcb 4qQiY60OdAwk2MUYEGB0IWO5k24/TBHsCL2mpzEtCc3oE+2RedrR+OA5fuSb2jePbg cAX+43MRjU7MkXo0pDuPTzsfX8K3MA7zKOM9vcNzIz1FogAWM6ven+QnLXpw/ResKE 5lJvYsgE4oGAQ== Received: by mail-ed1-f44.google.com with SMTP id z20so1148409edc.13; Mon, 25 Oct 2021 08:40:44 -0700 (PDT) X-Gm-Message-State: AOAM532YFsXYApd7pvM5FMSnDTzQwgNt4wgab8TIPtiPh2aAkDXatYVv /ziPb5KtUd9IJiQ0g1m91y88fXTnXg2vtL3GUA== X-Received: by 2002:a17:907:869e:: with SMTP id qa30mr12516665ejc.320.1635176393733; Mon, 25 Oct 2021 08:39:53 -0700 (PDT) MIME-Version: 1.0 References: <20211023144252.z7ou2l2tvm6cvtf7@pali> In-Reply-To: <20211023144252.z7ou2l2tvm6cvtf7@pali> From: Rob Herring Date: Mon, 25 Oct 2021 10:39:42 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Change PCI DTS scheme for port/link specific properties To: =?UTF-8?Q?Pali_Roh=C3=A1r?= Cc: Mauro Carvalho Chehab , Bjorn Helgaas , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , =?UTF-8?B?TWFyZWsgQmVow7pu?= , Matthew Wilcox , Alex Williamson , PCI , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 23, 2021 at 9:43 AM Pali Roh=C3=A1r wrote: > > Hello Rob! > > I think that the current DT scheme for PCI buses and devices defined in > Linux kernel tree has wrong definitions of port/link specific properties: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/D= ocumentation/devicetree/bindings/pci/pci.txt > > Port or link specific properties are at least: max-link-speed, > reset-gpios and supports-clkreq. And are currently defined as properties > of host bridges. pci-bus.yaml in dtschema is what matters now and it's a bit more flexible. > Host Bridge contains one or more PCIe Root Ports (each represented as > PCI Bridge device) and to each PCIe Root Port can be connected exactly > one PCIe Upstream device. > > PCIe Upstream device can be either endpoint PCIe card or it can be also > PCIe switch is consists of exactly one Upstream Port (represented as PCI > Bridge device) and then one or more Downstream Port devices (each > represent as PCI Bridge device). To each Downstream Port can be > connected again exactly one PCIe Upstream device. > > Port or link specific properties (e.g. max-link-speed, reset-gpios and > supports-clkreq) define "the PCIe link" between the Root/Downstream > device and Endpoint/Upstream device. And it is basically Root/Downstream > device which configures the port or link. So I think that these > properties should not be in Host Bridge DTS node, but rather in DTS node > which represents Root Port (or Downstream Port in case of PCIe switches). I tend to agree, but that ship has sailed because we don't tend to have a RP node in DT. Most host bridges also tend to be a single RP. In those cases, the properties come from whatever node we have. Certainly if there are multiple RPs on the host bridge bus (bus 0), then we need multiple child nodes for the RPs. IIRC, some host bindings do this already. > Mauro wrote in another email, that he has PCIe topology with > single-root-port host bridge to which is connected multi-port PCIe > switch and he needs to control reset-gpios of devices connected to > downstream ports of PCIe switch. I did a lot of work on that to get it right in terms of having the right nodes matching the bus hierarchy and resets distributed in the nodes. > > Current pci.txt DT scheme is fully unsuitable for this kind of setup as > basically PCIe switch is completely independent device of host bridge > and so host bridge really should not define in its node properties which > do not belong to host bridge itself. > > Rob, what do you think, how to solve this issue? > > I would suggest to define that max-link-speed, reset-gpios and > supports-clkreq properties should be in node for Root Port and > Downstream Port devices and not in host bridge nodes. > > So DTS for PCIe controller which has 2 root ports where to first root > port is connected PCIe switch with 2 cards and to second root port is > connected just endpoint card: > > pcie-host-bridge { > compatible =3D "vendor-controller-string"; /* e.g. designware, et= c... */ > > pcie-root-port-1@0,0 { pcie@0,0 and 'device_type =3D "pci"' are needed to indicate this is a bridge node and apply the schema. > reg =3D <0x00000000 0 0 0 0>; /* root port at device 0 */ > reset-gpios =3D ...; /* resets card connected to root-por= t-1 which is pcie-switch-1-upstream-port */ > max-link-speed =3D <3> /* link between root-port-1 and sw= itch is GEN3 */ > > pcie-switch-1-upstream-port@0,0 { > reg =3D ...; /* upstream port at device 0 */ > > pcie-switch-1-downstream-port-1@X,0 { > reg =3D ...; /* downstream port 1 at swit= ch specific address */ > reset-gpios =3D ...; /* resets card conne= cted to switch's port 1 */ > max-link-speed =3D <1> /* link between th= is port and card is GEN1 */ > > /* optional node for endpoint card */ > /* pcie-card@0,0 { ... }; */ > }; > > pcie-switch-1-downstream-port-2@Y,0 { > reg =3D ...; /* downstream port 2 at swit= ch specific address */ > reset-gpios =3D ...; /* resets card conne= cted to switch's port 2 */ > max-link-speed =3D <1> /* link between th= is port and card is GEN1 */ > > /* optional node for endpoint card */ > /* pcie-card@0,0 { ... }; */ > }; > }; > }; > > pcie-root-port-2@1,0 { > reg =3D <0x00000800 0 0 0 0>; /* root port at device 1 */ > reset-gpios =3D ...; /* resets card connected to root-por= t-2 */ > max-link-speed =3D <2> /* link between root-port-2 and ca= rd below is just GEN2 */ > > /* optional node for endpoint card */ > /* pcie-card@0,0 { ... }; */ > }; > }; > > Any opinion?