Hi Shawn,

Am Freitag, den 14.12.2018, 09:12 +0800 schrieb Shawn Guo:

On Thu, Dec 13, 2018 at 02:51:50PM +0000, Abel Vesa wrote:
...

quoted

quoted

quoted

diff --git a/arch/arm64/Kconfig.platforms

b/arch/arm64/Kconfig.platforms
index 7e1545a..318dbb9 100644

--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms

@@ -148,14 +148,6 @@ config ARCH_MXC

quoted

quoted

quoted

quoted

 	  This enables support for the ARMv8 based SoCs in the
 	  NXP i.MX family.

 
-config SOC_IMX8MQ

quoted

quoted

quoted

quoted

-	bool "i.MX8MQ support"
-	depends on ARCH_MXC
-	select ARM64_ERRATUM_843419
-	select ARM64_ERRATUM_845719
-	help
-	  This enables support for the i.MX8MQ SoC.

-

NACK on this one. Having a single place where stuff that is absolutely
critical for proper SoC operation can be selected is very useful and
avoids hard to debug issues due to slightly wrong configs in the long
run.

As mentioned in the cover letter, please ignore this patch set entirely.
The ARCH_MXC is actually used on arm32 too, so it won't work.

I'm working on a patchset that will add the Kconfig into 
drivers/clk/imx/ and in it will add CLK_IMX8MQ. That will
fix the clock dependency since the CLK_IMX8MQ will depend on
ARCH_MXC and ARM64. I believe the CLK_IMX8QXP will follow
the same pattern.

As for the SOC_IMX8MQ, all the other vendors have one single
config for all the arm64 platforms. TBH, to control every SoC
independently it's a little bit of an overkill.

Lucas,

We are still waiting for further comments from Olof [1].  But it sounds
like SoC specific option is not welcomed on ARM64.

While I personally would prefer to keep the SoC options, I see that we
need to align with the judgment of the arm-soc maintainers.

But at the very least we should keep the select for vital system
workarounds. They need to move to the arch Kconfig symbol in that case
and might select stuff that isn't needed on each of the i.MX8 SoCs. But
better enabling more workaround and drivers than necessary than having
hard to debug system failures in the future.

Regards,
Lucas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel