Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp922672pxb; Wed, 27 Oct 2021 15:17:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxhoJnOepoaq5vGlIkWIAiQQbak3O+Prjjlbi2LQpahvNo33i1djLjEcJ/J2gP2nrjayNpo X-Received: by 2002:a17:902:bd98:b0:13f:9ae7:54d1 with SMTP id q24-20020a170902bd9800b0013f9ae754d1mr242712pls.15.1635373033368; Wed, 27 Oct 2021 15:17:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635373033; cv=none; d=google.com; s=arc-20160816; b=i8PTMHPe3aLqxY2lEQNgCNlMc1NDbB82d7P/KzWXHJInDJT1cVfB7LpfEI5/I+MQvi Qq5jr73C11RmzkxS9t57HdM+FtMpYmvr28JePdsmWGI4Hw0CULuU5b7VQsgJHOUN3q6k B6L8SNCfmwUTjyJXmqLhY19WLdu+Qpnc+fCdktxR7rVuuHlGSpGQdQ0JPRMZX+U/5IXR rbVIPrdacA1jruXy+cPHxw39vbsLcet6wB9tW4P9BBRzKEGZC3ksS4DY8QUlvEICI6UC faeNUwq0xI+1y+jtFmFYqNdGSUTCGAd3E8vdGr6P/e48MWYohqJUQ57Nb0kpTSGHIq+L sf8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=oXhNHb05MCO6YZn1A/AKAzrQpjgdWMMnnUW0Vvxi8Zc=; b=zzG4/rztld2PxPES70j7+C3/atEqBtgKqDuJ0PBDQf49NgAv7eR4I4fPLk4aKFuEZB OiqZ/AX7GOiMHhruFTIwgY19P3O3u1Oe89fUfmMTtcPcdPCX+E7sOs/t7UWZ6TfX+msP 55+k1Y0yD8n+Is2Q5TY67F8F+83e/5TCVuvNl/sjg7tZCCPOK6IpWJjgNjUpSHYZ0eYE kGWneUXZ2UZrynNyc0GRjCWycTGqkrXJH+Cl1Dh3/IWGVf8iT6tjTKoEgHlTnesjPcqU fLd4sjcCRgOQPP/wha3gXTvW61efH2AlZg+cN1O+/7P7NHEswgohJ3dvYE9xYI/fuXCe jHNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=r1PDHPT+; 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 r19si1981204pgj.102.2021.10.27.15.17.01; Wed, 27 Oct 2021 15:17:13 -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=r1PDHPT+; 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 S231897AbhJ0Vk1 (ORCPT + 99 others); Wed, 27 Oct 2021 17:40:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:41594 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232045AbhJ0VkX (ORCPT ); Wed, 27 Oct 2021 17:40:23 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5303360D42; Wed, 27 Oct 2021 21:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635370677; bh=vLiIfNu/LBHkvASsSz6r5IhCi/TCTkMibmd4RzIo5SE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r1PDHPT+08Enf9PlduEp8ddfwQUMPja4rCnQKhPSOgmlm1EBbTUZRDB3IcbDeQjP1 qfigBf9vX5z/PCnvL5NMx7JaDpA63Ru8oo5ESUJ9Hk1hJZgJgqFcVnLPp7uEmmV/R7 +muYlfp9JcaP3f7Dtw2KJPYdvgoYFWXhuu8EHx5LNC98kZ0d2+qaTVMPNEDSo3SNuG HaB4gcSEn9/xy39dY5ng1qZ8MoR8snl1al+ntiz9XVbbHqXzHbkIWq3f7274Zwf98F MEOMKAp9H5oRspDIr6IDipytX89HIZbwAOitIyRC6BIBavrdAE8ctAN2tCcc7XcNHu CyMezx2VSVCTg== Received: by pali.im (Postfix) id 0B651894; Wed, 27 Oct 2021 23:37:54 +0200 (CEST) Date: Wed, 27 Oct 2021 23:37:54 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Bjorn Helgaas Cc: Jim Quinlan , Rob Herring , Jim Quinlan , "open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS" , Nicolas Saenz Julienne , Mark Brown , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , Florian Fainelli , Bjorn Helgaas , Saenz Julienne , "moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list Subject: Re: [PATCH v5 1/6] dt-bindings: PCI: Add bindings for Brcmstb EP voltage regulators Message-ID: <20211027213754.bnswkijrqinackgt@pali> References: <20211027165857.GA229979@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211027165857.GA229979@bhelgaas> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 27 October 2021 11:58:57 Bjorn Helgaas wrote: > On Tue, Oct 26, 2021 at 05:27:32PM -0400, Jim Quinlan wrote: > > > I don't think it matters but our PCIe controllers only have a single > > root port. > > Just to kibitz, and I don't know anything about the DT binding under > discussion here, but I would prefer if DTs and drivers did not have > the "single root port" assumption baked deeply in them. +1 Please look also at my proposal for similar/same issue: https://lore.kernel.org/linux-pci/20211023144252.z7ou2l2tvm6cvtf7@pali/t/#u > I expect some controllers to support multiple root ports, and it would > be really nice if the DTs and drivers all had similar structures with > the single-root-port controllers just being the N=1 case. > > For example, some drivers put their per-root port stuff in > *_add_pcie_port() functions, which I think is a nice way to do it > because it leaves the door open for calling *_add_pcie_port() in a > loop. > > Ironically, the only driver I see that looks like it currently > supports multiple root ports is pci-mvebu.c, and it doesn't have an > _add_pcie_port() function. Ironically, pci-mvebu.c is doing it wrong because HW has basically N fully independent HW host bridges and pci-mvebu.c driver is registering one kernel virtual host bridge device and is merging root ports of all host bridges into this one "virtual" bus which belongs to that kernel virtual host bridge... Plus root ports are also "virtual" because they are broken in HW. So correctly pci-mvebu.c should have been split into separate host bridge DTS nodes, but due to backward compatibility it is not possible. > Having this sort of consistent structure and naming across drivers is > a huge help for ongoing maintenance. > > Bjorn +1 That is why I sent that my proposal. Defining this as a common way for (new) drivers would really helps a lot all maintenance.