Received-SPF: pass (google.com: domain of linux-kernel+bounces-50656-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 2 Feb 2024 17:22:07 -0500
From: Frank Li <Frank.li@nxp.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: 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, robh@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: <Zb1rD4WK5D0ckKos@lizhi-Precision-Tower-5810>
References: <20240119171122.3057511-6-Frank.Li@nxp.com>
 <20240202215431.GA728556@bhelgaas>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240202215431.GA728556@bhelgaas>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?zaYkygNxKWEqfAhxlytI5dfJe0MdEq5vI0HIrzWHDvd3wcwrrcK8Gu1uVowV?=
 =?us-ascii?Q?+0nn/c1cgubf56/YqwtzPu6qfWjmtVpCCVCKWoJTnKX4ZkWrTb0bqyjPnxFD?=
 =?us-ascii?Q?Lwue+djxbdcgzhegNfpx/OQgaWMHHyS7Qebm+7otMu4xXu4MvhQU2XPiy1yU?=
 =?us-ascii?Q?YOlt15vEnlxyol77Si1ZMq22uCGNcAjlGcUwOzMJt49k1YEcoJf0QuYRAZLz?=
 =?us-ascii?Q?0P3qM3NMVQZDFHeIORALMKRafGV5dOOaZtLky1u96BoUVcPtRDCGZioBfHam?=
 =?us-ascii?Q?eSU88Am1j64XmtK3jUUolv36BtoRChQCldj7NKZuV3rztbf60EXeomlaECuP?=
 =?us-ascii?Q?YqFbohb9p2DmErFU4J+W5XcFYLsg6rKyUPzybETm7tuYsc/NJ/IjwAE6puHI?=
 =?us-ascii?Q?jCJD097REyitomU+d88ovsepT8gEdKwR2T0cI8wgPEWy3AZc7eFwlc2SUzBA?=
 =?us-ascii?Q?8KLhg8mb+ecM7aCgq2c0VFufS3oGQbehsb6GBcSToNdn13BydhFB7bxIgmM/?=
 =?us-ascii?Q?5IBT7bo1lyuhaSkrcjAIoMH9o7Cl9IgVY6ShZpYx8fecfEBnDOyq+kRm0b6M?=
 =?us-ascii?Q?ET4XEg9SAsXLnxIDQjEZnV5osSDFJ1zs+D/6vn+Epy1faAomkuS3tcTW6NNT?=
 =?us-ascii?Q?l++3Zw5f6pzePd8FOsvDZqtvj+1gmD1sZQSReX1eE/SKjXtafAAKDVxtSb9H?=
 =?us-ascii?Q?QACqSWFG5IypgM7gFk6bSweOMC+ZeRsrplqJW0COXBWPQ2N7xm/BnOtXiyuN?=
 =?us-ascii?Q?mL6WivsB2RUqdYZrzv6LaxPDI4sTJfNy+brArrKpfSq/H4uqf4mrm1hBpF7Z?=
 =?us-ascii?Q?JnoEo2GgydrgTIKapNT2Gwo4hjKf2ye47s2FyM2+UNGZmuCy46zmZ/xQHlCT?=
 =?us-ascii?Q?06wmm5v3i2bE0MpXLt1SL/aJaqtiYcweZqiENS9M8J1OuMP2g1KMXROoJ5o9?=
 =?us-ascii?Q?sRhtBMu57pxeSkQWprnFf9wntONX1wgdKouGaNmq3iPiVI0fwrMDIkzOwd+/?=
 =?us-ascii?Q?QQaiA7rq91a8DLxkrtPAuvBmm3/svk93Q0TdtlZ+FYGUwXP3hDp/959/nFaR?=
 =?us-ascii?Q?AJsg1v5aRF2v7jwpALEXy6H6irkP4a8E4crWQmnEbNsdcpXLdIntyDgypE5U?=
 =?us-ascii?Q?mkJu7q8NsAwDEQMjLYmI3RVtgFx3B5k9Fs8cuQOXwsnPpMLPunF+pjqL8VU3?=
 =?us-ascii?Q?FMyD2tVUu6Hh0JOGFTNyXyZNC/m9r2BjdB1VtTG+S+yydCJtYtRam/vRU4Qu?=
 =?us-ascii?Q?SVyi/ZdelZ8BqNTHYc6HubhtFFCWiJaaUNowZEfElylRg0sej8Xw+0Ik/0CW?=
 =?us-ascii?Q?L/pazNKSUDgr4K6hzPkBtmzkd1DXG82qNe3rps0+Ogs00L4MHjqtUlNYUJeq?=
 =?us-ascii?Q?zUMTWFJen+Zp2JEoHxKLSmrRaeSW3fV5kID0RpGkm2RZz4mcFDLNbeOoD9Zq?=
 =?us-ascii?Q?vqA0fThhdZOKjVc5HV2Cz1MibOLS//EB77Nx+JcVPRZN5beU3OqtykqAoSaG?=
 =?us-ascii?Q?siOBiCW8J1uy6tnuSwqQajbfHtcWeEBvVW6IHbdAieI1u1zxXeczXa2F87jA?=
 =?us-ascii?Q?n/5NQLxHPQBgMLF8DDA=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 411d930e-7ced-4ba4-1ac2-08dc243d6ab8
X-MS-Exchange-CrossTenant-AuthSource: PAXPR04MB9642.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2024 22:22:18.3205
 (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: +N7ohEbJIPXC+dLSbZQzPrx0+xjZb6q3+rnwpMpkAGhH5iHIXkyjTlfcXhd+Ay126gILqaJc25JYb/o4fAYIbQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR04MB6823

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/

https://lore.kernel.org/imx/20231217175158.GF6748@thinkpad/

> 
> 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.

> 
> That doesn't seem related to "linux,pci-domain" at all.

I added comments about
/* Using linux,pci-domain as PCI slot id */

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