linux-kernel - Re: [PATCH v5 2/2] PCI: microchip: rework reg region handing to support using either instance 1 or 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241106-eats-anthology-657e2238e271@spud>
Date: Wed, 6 Nov 2024 16:26:02 +0000
From: Conor Dooley <conor@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: linux-pci@...r.kernel.org, Conor Dooley <conor.dooley@...rochip.com>,
	Daire McNamara <daire.mcnamara@...rochip.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v5 2/2] PCI: microchip: rework reg region handing to
 support using either instance 1 or 2

On Tue, Nov 05, 2024 at 11:18:28AM -0600, Bjorn Helgaas wrote:
> On Mon, Nov 04, 2024 at 11:18:43AM +0000, Conor Dooley wrote:
> > On Fri, Nov 01, 2024 at 02:51:29PM -0500, Bjorn Helgaas wrote:
> > > On Wed, Aug 14, 2024 at 09:08:42AM +0100, Conor Dooley wrote:
> > > > From: Conor Dooley <conor.dooley@...rochip.com>
> > > > 
> > > > The PCI host controller on PolarFire SoC has multiple "instances", each
> > > > with their own bridge and ctrl address spaces. The original binding has
> > > > an "apb" register region, and it is expected to be set to the base
> > > > address of the host controllers register space. Defines in the driver
> > > > were used to compute the addresses of the bridge and ctrl address ranges
> > > > corresponding to instance1. Some customers want to use instance0 however
> > > > and that requires changing the defines in the driver, which is clearly
> > > > not a portable solution.
> > > 
> > > The subject mentions "instance 1 or 2".
> > > 
> > > This paragraph implies adding support for "instance0" ("customers want
> > > to use instance0").
> > > 
> > > The DT patch suggests that we're adding support for "instance2"
> > > ("customers want to use instance2").
> > > 
> > > Both patches suggest that the existing support is for "instance 1".
> > > 
> > > Maybe what's being added is "instance 2", and this commit log should
> > > s/instance0/instance 2/ ?  And probably s/instance1/instance 1/ so the
> > > style is consistent?
> > 
> > Hmm no, it would be s/instance1/instance 2/ & s/instance0/instance 1/.
> > The indices are 1-based, not 0-based.
> > 
> > > Is this a "pick one or the other but not both" situation, or does this
> > > device support two independent PCIe controllers?
> > > 
> > > I first thought this driver supported a single PCIe controller, and
> > > you were adding support for a second independent controller.
> > 
> > I don't know if they are fully independent (Daire would have to confirm)
> > but as far as the driver in linux is concerned they are. As far as I
> > know, you could operate both instances at the same time, but I've not
> > heard of any customer that is actually doing that nor tested it myself.
> > Operating both instances would require another node in the devicetree,
> > which should work fine given the private data structs are allocated at
> > runtime. I think the config space is shared.
> > 
> > > But the fact that you say "the [singular] host controller on
> > > PolarFire", and you're not changing mc_host_probe() to call
> > > pci_host_common_probe() more than once makes me think there is only a
> > > single PCIe controller, and for some reason you can choose to operate
> > > it using either register set 1 or register set 2.
> > 
> > The wording I've used mostly stems from conversations with Daire. We've
> > kinda been saying that there's a single controller with two root port
> > instances. 
> 
> If these are two separate Root Ports, can we call them "Root Ports"
> instead of "instances"?  Common terminology makes for common
> understanding.

Sure.

> > Each root port instance is connected to different IOs,
> > they're more than just different registers for accessing the same thing.
> 
> Sounds like some customers use Root Port 1 and others use Root Port 2,
> maybe based on things like which pins are more convenient to route.

Aye, the user that motivated the patchset uses a very small package and
was not able to use root port 1 for that reason.

> I would very much like to reword these commit logs using as much
> standard PCIe terminology as possible.  Most of these native PCIe
> controller drivers have Root Complex and Root Port concepts all mixed
> together, and anything we can do to standardize them will be a
> benefit.

I can do that tomorrow.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)