Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1846987imu; Fri, 14 Dec 2018 01:23:31 -0800 (PST) X-Google-Smtp-Source: AFSGD/UJzl8ZQvPFK5pgBJJhS6ac7X7qUJQxVmCjBOLDnqYOmxXSgjCpYDoZ4V/4zkQsN//P7XSM X-Received: by 2002:a17:902:8ec8:: with SMTP id x8mr2188119plo.210.1544779411172; Fri, 14 Dec 2018 01:23:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544779411; cv=none; d=google.com; s=arc-20160816; b=eWRLwOX7d+qd5YHlcTXWWsM0wL9avJF/FvsyMP7x82L2q4ZHJlLS9OdESkhFZlIQq4 tVIHi6pdFMzM/be/aQ2JuTk/tnZq009WSAv3aw1ljiV9r/j1nVR5QxEl+8QAASQ20GPY iKWaLEkCb2y74diYhkmWutnLRrpMDsOHQNtdPw2pxh8u4Exl3mmrs4t7p6BPqkdMUQ0l rrbZi6HyPxzwlSo/IZRsMvGU8v33O7OHOj/S+Jlt7bfbJebJ2yRvVRT8jWvadNGLgTzi zyumFLP342A8IhN8usg4gGRPM+hN/C04zTdbiWStX4gcs6/DZgCGhUg7buU5etrB5NA0 xebQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=Y+suvELe5+KZIoER9Ny8jWkXSXV+y95BZHpWyNRagcI=; b=zEuNdCZPz9LpYWW+C9gts7UapaY+gvFyRGglyU3Z5kCBGeGK1fnXXxQphXdcDHL5SD Q6f+tF2+1zvuJ1os0Fsrv9ExZtcpNnWpZECSrj7g05WbVvS89X97z1kxeyPCjcnMWrwl 46zqvBv/C3QtPRnxGF1Lp0/bWk5d8F+P8uXXfReTdHGzW9R7fjdzoP02QGEray650PgB r26p3G8RHW8nusI2fVGSNCN/scQKkxLSm1Ax5xLKDAwoFjFJbQB9p6iO5V9B9+H/SSdH ilXM0Wq2gyOJp9uu4/wup03fkuUpegQNZz7P1tGf+62PSri24K03aU92MFCBJL7QNWfb x2Lg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u186si3518098pgd.131.2018.12.14.01.23.15; Fri, 14 Dec 2018 01:23:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728260AbeLNJWW (ORCPT + 99 others); Fri, 14 Dec 2018 04:22:22 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:53765 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726423AbeLNJWW (ORCPT ); Fri, 14 Dec 2018 04:22:22 -0500 Received: from kresse.hi.pengutronix.de ([2001:67c:670:100:1d::2a]) by metis.ext.pengutronix.de with esmtp (Exim 4.89) (envelope-from ) id 1gXjfg-00007T-GT; Fri, 14 Dec 2018 10:22:12 +0100 Message-ID: <1544779331.3137.36.camel@pengutronix.de> Subject: Re: [PATCH 1/3] arm64: Remove CONFIG_SOC_IMX8MQ and use ARCH_MXC instead From: Lucas Stach To: Shawn Guo , Abel Vesa Cc: Stephen Boyd , Aisheng Dong , "linux-clk@vger.kernel.org" , Pengutronix Kernel Team , Olof Johansson , "linux-arm-kernel@lists.infradead.org" , Linux Kernel Mailing List , dl-linux-imx , Rob Herring , Will Deacon , Fabio Estevam Date: Fri, 14 Dec 2018 10:22:11 +0100 In-Reply-To: <20181214011207.GB13243@dragon> References: <1544707047-4417-1-git-send-email-abel.vesa@nxp.com> <1544707047-4417-2-git-send-email-abel.vesa@nxp.com> <1544711727.3137.32.camel@pengutronix.de> <20181213145149.6hyyhi6hxdzvikl4@fsr-ub1664-175> <20181214011207.GB13243@dragon> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::2a X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > ... > > > > 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 > > > > > > > >     This enables support for the ARMv8 based SoCs in the > > > > > > > >     NXP i.MX family. > > > >   > > > > -config SOC_IMX8MQ > > > > > > > > - 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