On Mon, Oct 15, 2018 at 09:03:04AM +0000, A.s. Dong wrote: > > -----Original Message----- > > From: Sascha Hauer [mailto:s.hauer@xxxxxxxxxxxxxx] > > Sent: Monday, October 15, 2018 4:28 PM > > To: A.s. Dong <aisheng.dong@xxxxxxx> > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Mark Rutland > > <mark.rutland@xxxxxxx>; dongas86@xxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; > > catalin.marinas@xxxxxxx; will.deacon@xxxxxxx; robh+dt@xxxxxxxxxx; > > dl-linux-imx <linux-imx@xxxxxxx>; kernel@xxxxxxxxxxxxxx; Fabio Estevam > > <fabio.estevam@xxxxxxx>; shawnguo@xxxxxxxxxx > > 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: > > > > > + 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. > > > > 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? > > > > > > > > > + 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 |
