On Mon, Oct 15, 2018 at 09:03:04AM +0000, A.s. Dong wrote:

quoted

-----Original Message-----
From: Sascha Hauer [mailto:s.hauer@pengutronix.de]
Sent: Monday, October 15, 2018 4:28 PM
To: A.s. Dong <aisheng.dong@nxp.com>
Cc: linux-arm-kernel@lists.infradead.org; Mark Rutland
[off-list ref]; dongas86@gmail.com; devicetree@vger.kernel.org;
catalin.marinas@arm.com; will.deacon@arm.com; robh+dt@kernel.org;
dl-linux-imx [off-list ref]; kernel@pengutronix.de; Fabio Estevam
[off-list ref]; shawnguo@kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp support

On Mon, Oct 15, 2018 at 08:08:31AM +0000, A.s. Dong wrote:

quoted

quoted

quoted

+		imx8qx-pm {
+			compatible = "fsl,scu-pd";

I missed this earlier, but there should be a i.MX8qp specific
compatible as the SCU API might change for future SoCs.

We still do not see that requirement up till now. Not sure if it would
be possible in the future. I see low possibilities.
SCU IPC is designed to be generic to all MX8 SCU firmwares.

And i.MX9? i.MX10?

MX8DM MX8DXP

I was not talking about existing SoCs, I was talking about future SoCs.

quoted

quoted

Even it changes, SCU firmware version control may helps.

It's not the first time that the position of the version field changes with a
newer version.

I understand your worry. 
Up till now all SCU firmware based SoCs are all using one generic IPC driver internally.
And I have not heard a possible changing in the future.
I double checked the SCU firmware implementation that the IPC
Is deigned to be platform independent. So it's less to be changed.
So I wonder if this could be over worried.
Even it is changed, (quite less probility), we still can user version
To distinguish them, just like arm,scpi , arm,scmi. Right?

You can still add and use a generic compatible, but does it hurt when
you add a SoC specific one that you *can* use should you have to?

quoted

quoted

quoted

quoted

+			compatible = "fsl,imx7ulp-lpuart";
+			compatible = "fsl,imx7ulp-lpi2c";
+			compatible = "fsl,imx7d-usdhc";

All these lack the most specific imx8qp compatible.

Adding them requires binding doc update as well.
S I suppose they could be added later when the QXP specific features
are really supported by the drivers.
Do you think it's okay?

Newer Kernels should work with older device trees, so once you roll out these
compatibles it's too late already.

The backwards compatible string is used to guarantee a basic function.
Even we add qxp specific compatible string later, it still can work with
backwards function. So I'm not quite get what the real problem is.
And this is the initial support that we don't expect the full features
with such an early device tree, right?

By not adding a SoC compatible you lose the possibility to add a SoC
specific fixup without changing the device tree or you have to work with
quirks like:

https://elixir.bootlin.com/linux/latest/source/drivers/clocksource/timer-imx-gpt.c#L521

or

https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi-imx.c#L1182

So far we have added new compatibles with each new SoC type for good
reasons, so why should we change this?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |