Received-SPF: pass (google.com: domain of linux-kernel+bounces-50799-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 2 Feb 2024 20:01:05 -0500
From: Frank Li <Frank.li@nxp.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>, manivannan.sadhasivam@linaro.org,
	bhelgaas@google.com, conor+dt@kernel.org,
	devicetree@vger.kernel.org, festevam@gmail.com,
	hongxing.zhu@nxp.com, imx@lists.linux.dev, kernel@pengutronix.de,
	krzysztof.kozlowski+dt@linaro.org, krzysztof.kozlowski@linaro.org,
	kw@linux.com, l.stach@pengutronix.de,
	linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	lpieralisi@kernel.org, s.hauer@pengutronix.de, shawnguo@kernel.org
Subject: Re: [PATCH v9 05/16] PCI: imx6: Using "linux,pci-domain" as slot ID
Message-ID: <Zb2QUTenlj3kEeE/@lizhi-Precision-Tower-5810>
References: <Zb1rD4WK5D0ckKos@lizhi-Precision-Tower-5810>
 <20240202225116.GA732628@bhelgaas>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240202225116.GA732628@bhelgaas>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?WCpOIx0sbK6OuvKyNiEtdXsne0traF0FuElHqIFidf6GDA/QZnwWDSS2ES0T?=
 =?us-ascii?Q?8pvJWTH3iF7eQNSg3Vkb6y4ax60+zwjBulpzSvnl5kfbwRStlVsG4XueFkt4?=
 =?us-ascii?Q?uepNhi6gyChhuhUNYDYbKmT9eEPsM8c6OuiL/V6W1k5UqUkzAzTtxi/Q1h/y?=
 =?us-ascii?Q?1vqrKjQaJAA5Njc3zhlbblAbfZIQwLMUJOqk/X4xMQmMvu6S6GI1alY3DiOI?=
 =?us-ascii?Q?fI27Ja2cRHtQJvY16KKoM2rXROhNy7WMGCkAq0GiMB99DJ0iVPMPsuxmKTGz?=
 =?us-ascii?Q?RjpLlf87OOPm/tk/z+Yej7VmrSbm/McuDBwRJuhh9+f/UappZEhBC444toJa?=
 =?us-ascii?Q?mYsaWGF4if8FzvGPkYU7mr08eMPoKLkr4drj0GpppV2kNLhi3ziE+/PO3Rwg?=
 =?us-ascii?Q?zQdGabnnV0+AcXiVcC8r/ojCjg+kLCiVtzSDS3LHkKgytJSvpLeLvqQ8v0ep?=
 =?us-ascii?Q?3wV1nP1Fi3D9EK40XfQqZA6i8TXtsBrpUyvrnM1yRhK7nGoFRNyysC7pE0+C?=
 =?us-ascii?Q?0LOnyKGp2YNvMocjzRq+mzRYz/5rYiEfpnwjwc+usQKAeYVzxEXZSFIQlxMK?=
 =?us-ascii?Q?XTwVe2XcTyJNzFfHLFTc7tlI3xE/jY8G2dZUMUSW+iOV9x8Eua2wYFZU9GKp?=
 =?us-ascii?Q?vkGuj+BYat6pOm4MbLCWoe8Y6Kc7ckSOC/Dd5BEd0+uPYAeD3lmx4D2Urxsq?=
 =?us-ascii?Q?QSZ42Fkyn9nwkwLg8ySrvu8ebL0/nMJEYdEPHVkgQ/kOt0wA5V2YyiPJ41mb?=
 =?us-ascii?Q?wfTrCYgQmIWya0BcvC46yDHAF8NNa/DX4PKMIziyxEe775PdaD66Nr//2bPV?=
 =?us-ascii?Q?wIfJjLlb8ConMiMPfgCo6HwMHDNNQrLD4be5YrMCCQ/Vb0KOgTHdIaXMxS1h?=
 =?us-ascii?Q?gielOZuQPTgnfPtdeAH/1AV3WoXko8oI2rLKeNgDfWgf9YPpRV3ahPDVfXXq?=
 =?us-ascii?Q?64hoAmniOEWnNxyzvOTNuv4+267r2KiYuRgvASnu4Yfm3/G0d7sWCfwIqRlN?=
 =?us-ascii?Q?h6xo262ZLEv8qBem57t0k6SBybmx+VnSAcJdT8pqwoW+mN9R4USUoYJ6LBPW?=
 =?us-ascii?Q?yC8lt4DyOuuSnERioIyVVkdGk+2zbnhfW+IzVEX65rgchvNvUOm4GBeoPkA6?=
 =?us-ascii?Q?1TbfTRKyqKLO1dE7rta21Asc4DgO8h+Vb+Q7AbxaFRN6PlqTec8QX62Q6gBu?=
 =?us-ascii?Q?Ge9LaRCOhRm9JTG23LKplPTgh08qt7IX2SxpHQs4LSTD+nEO+95Fv+DZEG00?=
 =?us-ascii?Q?9ABTX1P2pAVc38GLpoutWo7FjZPM6jrEwP2usFVg2ArCkpDWgS76o7JhG75l?=
 =?us-ascii?Q?FOdvOVxloq2NpbrZ9/cm5suTRTlzCjHaLHicfFbsX7GcDZSota9ftJu80ob2?=
 =?us-ascii?Q?cY5h/XPI2jAopUWilDe5A0ZOr/eTXbHqSiTHOsHgsVJxxDv1Tt4WakRviL+c?=
 =?us-ascii?Q?ULVKEfJVkBy/6yRFCDz7HcJfTgPaycevdF996jDCZBRbTBtrk71uwEXaOx3N?=
 =?us-ascii?Q?kmVQIyIAjCMr/wCXiVGXJKDzWapt5x44rSconT8yBS0oiAtJLNPAvEt7lGOr?=
 =?us-ascii?Q?FvachEZkG/NAKEwX6uDKOt2NIAeOQdGo4SQBvRiA?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 716db753-3329-4f8e-01a8-08dc24539dc9
X-MS-Exchange-CrossTenant-AuthSource: PAXPR04MB9642.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2024 01:01:12.9007
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 29t9YhYD8OD4HwL1HL12KIK42/Fk2z0ewQO+2xmUueJHpVDk5ItIZ/oD8tl7wANmCXaF5i/SpRBF6VCXrANaoA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB9350

On Fri, Feb 02, 2024 at 04:51:16PM -0600, Bjorn Helgaas wrote:
> [Rob to to: line]
> 
> On Fri, Feb 02, 2024 at 05:22:07PM -0500, Frank Li wrote:
> > On Fri, Feb 02, 2024 at 03:54:31PM -0600, Bjorn Helgaas wrote:
> > > On Fri, Jan 19, 2024 at 12:11:11PM -0500, Frank Li wrote:
> > > > Avoid use get slot id by compared with register physical address. If there
> > > > are more than 2 slots, compared logic will become complex.
> > > > 
> > > > "linux,pci-domain" already exist at dts since commit:
> > > > 	commit (c0b70f05c87f3b arm64: dts: imx8mq: use_dt_domains for pci node).
> > > > 
> > > > So it is safe to remove compare basic address code:
> > > > 	...
> > > > 	if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR)
> > > > 		imx6_pcie->controller_id = 1;
> > > > 	...
> > > 
> > > I have no idea what this is telling me.  I guess you don't want to use
> > > IMX8MQ_PCIE2_BASE_ADDR to decide something?  That much sounds good:
> > > the *address* of some MMIO space doesn't tell us anything about the
> > > function of that space.
> > 
> > You are right. If there are more than two controller. The check logic
> > will be extremely complex.
> > 
> > There are some discussin at below thread about linux,pci-domain
> > https://lore.kernel.org/imx/20231206165953.GA717921@bhelgaas/
> 
> My response here was too low level, just about trivial syntactic and
> style issues.  I should have seen the larger issue at the time; sorry
> about that.
> 
> > https://lore.kernel.org/imx/20231217175158.GF6748@thinkpad/
> 
> That's a good response from Mani, but again not relevant to my point.
> 
> My point here is that "compatible" should tell the driver how to
> operate the device, i.e., the driver knows what registers are present
> and how they work.
> 
> If you have two variant devices that both implement a register that
> can be used to distinguish them, a single "compatible" string might be
> enough because the driver can use that register to tell the
> difference.
> 
> If the driver can't tell the difference by looking at the hardware
> itself, I think you need a separate "compatible" string for it.  Of
> course I'm far from a DT expert, so please correct this if necessary,
> Rob, et al.
> 
> > > I expect the "compatible" string to tell the driver what the
> > > programming model of the device is.
> > > 
> > > > +	/* Using linux,pci-domain as PCI slot id */
> > > > +	imx6_pcie->controller_id = of_get_pci_domain_nr(node);
> > > > +	/*
> > > > +	 * If there are no "linux,pci-domain" property specified in DT, then assume only one
> > > > +	 * controller is available.
> > > > +	 */
> > > > +	if (imx6_pcie->controller_id == -EINVAL)
> > > > +		imx6_pcie->controller_id = 0;
> > > > +	else if (imx6_pcie->controller_id < 0)
> > > > +		return dev_err_probe(dev, imx6_pcie->controller_id,
> > > > +				     "linux,pci-domain have wrong value\n");
> > > 
> > > Maybe I'm missing something here.  It looks like this driver uses
> > > controller_id to distinguish between hardware variants or maybe
> > > between two Root Ports (slots?) in the same SoC?
> > 
> > Yes!
> > 
> > >   imx6_pcie_grp_offset
> > >     return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
> > > 
> > >   imx6_pcie_configure_type
> > >     id = imx6_pcie->controller_id
> > >     if (!drvdata->mode_mask[id])         # <-- looks unsafe
> > 
> > I can add safe check here.
> > 
> > >       id = 0;
> > >     regmap_update_bits(drvdata->mode_off[id], ...)
> > > 
> > > (This "mode_mask[id]" looks like it will reference garbage if the DT
> > > supplies "linux,pci-domain = <2>".  A bogus DT shouldn't be able to
> > > cause a driver to misbehave like that.)
> > 
> > Suppose I can use dt-bind doc to force to 0,1 and safe check here.
> 
> Nope.  The driver must protect itself from garbage in the DT.
> 
> > > That doesn't seem related to "linux,pci-domain" at all.
> > 
> > I added comments about
> > /* Using linux,pci-domain as PCI slot id */
> 
> That doesn't make it related :)

Okay, linux,pci-domain is not good method for this. Anyways, previous
implement is wrong.

Let me skip it and think a better method to fix this problem later.

Frank 
> 
> > We may add new property about controller-id, but there already have common
> > one "linux,pci-domain", which value in upstreamed dts exactly match our
> > expection, I also found other platform use it as slot id in kernel tree.
> > 
> > Any way, we can continue discuss the better solution here. But I hope
> > it was not block whole 16 patches. we can skip this one firstly.
> > 
> > I still have more than 10 clean up patches my local tree.
> > 
> > > 
> > > Bjorn