From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF78128E0A for ; Fri, 6 Oct 2023 16:34:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="1cH8qcBL" Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 331BCCF for ; Fri, 6 Oct 2023 09:33:57 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1c6185cafb3so166695ad.1 for ; Fri, 06 Oct 2023 09:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696610036; x=1697214836; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hTvdrZFmq0hYxp77EcKvOnGpN0oCW3xY/AiFjsTxtTU=; b=1cH8qcBLbYdVmyJgImfP4kPooyszqdpDDthXV10khKxOsscBnVV3NVbQKLvLbvxpMO fHuFzPq8TQdY/uGy/u2NON+aYcSKUcYAazbz3YZ3KSDLDm3GSD+rP2mR8S8Glbt07Kb0 7A5a49SYPvi9/b1g50QgirZreJsXES4IRiUp0GEzEw66wp/Q7G6GfLEvcSRoOy8cDMVC oyvq+1tJ8NU9qKSqigDolMELM0AEmHqdWsJAzcy5mV6TCdzukP5Yv9SxTHQrT9llVCzj jaIwVe6yRVaJa8K3mrN8ZYfIVvFLcTSx/Q9Q5rbHIQ8W4JqZ87/ZOzBiqlJK+ngA/TgG Ghog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696610036; x=1697214836; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hTvdrZFmq0hYxp77EcKvOnGpN0oCW3xY/AiFjsTxtTU=; b=jjKES0M5f5GHPZoBX9uj6y9+pX149uDhNaWFNgr9+Wyom2Ws0xL1fNquDLVcSBkfnV 6j8TqsmiVdXJSRxh9TjgqzvSMugGFR7aOnGfOEynggpJGXgFqE8FZokDQ1ASmwIk0dQN hyZjUIPGzjXCMNSWMYoFEBmb2HGFRZ8YFnOyohEAsXXeTwvCBmVknllbHPdGjjNCimOJ H/2jia16YIM3pVB9fvwz17kpgc6yaWdn7MYGCizl2hKApAHiHzm02FZm0bXBYPFMiMl+ 5cV1ij4lYbggYMwljeh4QqJU+ZRqqsrjdwO30Y5V3iLcWiooU1jGaxiS92AyAFnlteQ/ 61zQ== X-Gm-Message-State: AOJu0YwXlTXroTKQ0TFY4Tm/2P8z2d2mv1ZfxyljXva0F7AlZKWMQQfv VWC+MxW1+Q9D8RoCvPCUWCg/Kg== X-Google-Smtp-Source: AGHT+IHgejsiy4SZfD/kIaiCo2p5a5GHbtVsqXoNRUJ/kjAOpzjKyLWuXfdo9k7lkUWRMBwV75Nd+w== X-Received: by 2002:a17:902:e805:b0:1c7:3224:913a with SMTP id u5-20020a170902e80500b001c73224913amr382708plg.27.1696610036323; Fri, 06 Oct 2023 09:33:56 -0700 (PDT) Received: from google.com (13.65.82.34.bc.googleusercontent.com. [34.82.65.13]) by smtp.gmail.com with ESMTPSA id l4-20020a170902eb0400b001b9d7c8f44dsm4113036plb.182.2023.10.06.09.33.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Oct 2023 09:33:55 -0700 (PDT) Date: Fri, 6 Oct 2023 09:33:51 -0700 From: William McVicker To: Arnd Bergmann Cc: Krzysztof Kozlowski , Greg Kroah-Hartman , Peter Griffin , Rob Herring , krzysztof.kozlowski+dt@linaro.org, Michael Turquette , Conor Dooley , Stephen Boyd , Tomasz Figa , Sylwester Nawrocki , Linus Walleij , Wim Van Sebroeck , Guenter Roeck , Catalin Marinas , Will Deacon , Olof Johansson , Chanwoo Choi , Tudor Ambarus , andre.draszik@linaro.org, semen.protsenko@linaro.org, soc@kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, "open list:GPIO SUBSYSTEM" , linux-watchdog@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 18/21] arm64: dts: google: Add initial Google gs101 SoC support Message-ID: References: <20231005155618.700312-1-peter.griffin@linaro.org> <20231005155618.700312-19-peter.griffin@linaro.org> <2023100520-cleaver-sinless-fbae@gregkh> <99419159-cab0-4c79-a4a0-12229bfad3c0@linaro.org> <2023100513-mashing-scrubber-ea59@gregkh> <44816879-a3a7-4bd0-bb20-19a645107b4b@linaro.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-15.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,HK_RANDOM_ENVFROM,HK_RANDOM_FROM, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On 10/06/2023, Arnd Bergmann wrote: > On Fri, Oct 6, 2023, at 08:06, Krzysztof Kozlowski wrote: > > On 06/10/2023 01:19, William McVicker wrote: > >> On 10/05/2023, Krzysztof Kozlowski wrote: > >>> On 05/10/2023 21:23, Greg KH wrote: > >> > >> Being able to include SERIAL_SAMSUNG and SERIAL_MSM without all the vendor> specific drivers that ARCH_EXYNOS and ARCH_QCOM select is very > > valuable for > >> debugging early boot issues. > > > > Really? How related? The drivers are independent. You describe some > > out-of-tree development process which we never needed for upstream work. > > And we did here quite a lot of upstream, specially if you look at ARCH_QCOM. > > Right: in general, all drivers are independent of the platform > besides the typical 'depends on ARCH_FOO || COMPILE_TEST' dependency, > but I think it's worth mentioning the known exceptions, so Greg and > Will can take that fight to the respective places rather than > discussing it in the platform submission: > > - Some subsystems are considered 'special' and the maintainers > prefer the drivers to be automatically selected based on the > ARCH_* settings instead of having user-visible options. This is > traditionally true for large chunks of drivers/irqchip, > drivers/clocksource and drivers/pinctrl, though it has gotten > better over time on all of them. > > - Some older 32-bit platforms are still not as modular as we'd > like them to be, especially the StrongARM (ARMv4) platforms that > require a custom kernel build, and some of ARMv4T and ARMv5 > boards that are still missing DT support. These tend to require > drivers they directly link to from board code, so disabling > the drivers would cause a link failure until this gets > cleaned up. > > - A couple of drivers are force-enabled based on the ARCH_* > options because booting without these drivers would risk > permanent damage to hardware, e.g. in overtemp or overcurrent > scenarios. > > - ACPI based platforms require the PCI host bridge driver to > be built-in rather than a loadable module because ACPI > needs to probe PCI devices during early boot. > > - Some subsystems (notably drivers/gpu/, but others as well) > have an excessive number of 'select' statements, so you > end up surprise-enabling a number of additional drivers > and subsystems by enabling certain less important platform > specific drivers. > > Arnd So if the argument is that the existing upstream Exynos platforms are required to have these drivers built-in to the kernel to boot: COMMON_CLK_SAMSUNG CLKSRC_EXYNOS_MCT EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS EXYNOS_PMU PINCTRL PINCTRL_EXYNOS PM_GENERIC_DOMAINS if PM SOC_SAMSUNG ...then that is understandable and we can work to fix that. My last question then is -- why do we need a new ARCH_GOOGLE_TENSOR config in the platform Kconfig? For example, I don't really like this: diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig index 76a494e95027..4c8f173c4dec 100644 --- a/drivers/clk/samsung/Kconfig +++ b/drivers/clk/samsung/Kconfig @@ -13,6 +13,7 @@ config COMMON_CLK_SAMSUNG select EXYNOS_5420_COMMON_CLK if ARM && SOC_EXYNOS5420 select EXYNOS_ARM64_COMMON_CLK if ARM64 && ARCH_EXYNOS select TESLA_FSD_COMMON_CLK if ARM64 && ARCH_TESLA_FSD + select GOOGLE_GS101_COMMON_CLK if ARM64 && ARCH_GOOGLE_TENSOR What happens when we have GOOGLE_GS101_COMMON_CLK, GOOGLE_GS201_COMMON_CLK, and so on? How are we going to pick the right driver when we have a generic ARCH_GOOGLE_TENSOR config? Ideally, we should have one Exynos clock driver that can detect what hardware is running (using the DT) to determine what it needs to do. If you really want to compile out the other vendor's clock drivers using some configs, then we should do that with SOC_GS101, SOC_GS201, SOC_TESLA_FSD configs (not ideal though). With that approach, we could drop the platform ARCH_GOOGLE_TENSOR config and create an SOC_GS101 config that can be used for things like the COMMON_CLK_SAMSUNG driver (for now) and building the GS101 dtb. Let me know your thoughts. Thanks, Will