From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5FE7AE9272B for ; Thu, 5 Oct 2023 19:23:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) id 3BFFFC433C8; Thu, 5 Oct 2023 19:23:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99D63C433C7; Thu, 5 Oct 2023 19:23:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1696533805; bh=mEC4GCPFke5BHEMWLbxQgvP7fQIPlgzksDjsQnxScS8=; h=Date:From:To:List-Id:Cc:Subject:References:In-Reply-To:From; b=DjI8Frt+YkYm54tzjnBb1KFjBfpXU6PXPmmZtKSjuVjwYSNPiyvTGynp4hA8tTxFz Vey859gxJ/zzg1Q7s+SIHHbOFkZFbDdqiHkX0AJbrW+rI5WQFxAxxQtMj+NOZpt1fP 6Nz647Q+482Gkqk26jF+MQotdB0tnlu8iCRIFFTc= Date: Thu, 5 Oct 2023 21:23:22 +0200 From: Greg KH To: Krzysztof Kozlowski List-Id: Cc: William McVicker , Peter Griffin , robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com, conor+dt@kernel.org, sboyd@kernel.org, tomasz.figa@gmail.com, s.nawrocki@samsung.com, linus.walleij@linaro.org, wim@linux-watchdog.org, linux@roeck-us.net, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, olof@lixom.net, cw00.choi@samsung.com, tudor.ambarus@linaro.org, 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, linux-gpio@vger.kernel.org, linux-watchdog@vger.kernel.org, kernel-team@google.com Subject: Re: [PATCH 18/21] arm64: dts: google: Add initial Google gs101 SoC support Message-ID: <2023100513-mashing-scrubber-ea59@gregkh> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99419159-cab0-4c79-a4a0-12229bfad3c0@linaro.org> On Thu, Oct 05, 2023 at 09:18:48PM +0200, Krzysztof Kozlowski wrote: > >> I'd like to bring up this thread and discuss the option of not introducing > >> another ARCH_* config: > >> > >> https://lore.kernel.org/all/20200306103652.GA3634389@kroah.com/ > > > > I agree, PLEASE don't add platform config options as that makes it > > impossible to make a unified kernel image that works for more than one > > platform at the same time. > > There is no single problem in making unified image as we were doing > since beginning of ARM64. The ARCH_* is not a obstacle for this. Then why are the ARCH_* options needed at all? What does this help out with? > >> I especially don't like the "depends on ARCH_EXYNOS" because that forces one to > >> include all the other Exynos drivers that ARCH_EXYNOS selects that Google > >> Tensor SoCs don't need. Can we consider using SOC_GOOGLE instead and for all > >> drivers that actually depend on the SoC hardware, we can just add "depends on > >> SOC_GOOGLE"? > > > > Why do any of this at all? It should not be needed. > > > >> The idea is that drivers should be tied to hardware -- not a specific vendor. > > > > And drivers should be auto-loaded. > > > > All of these drivers are not vendor-specific at all, they are based on > > the same IP blocks as others, so that is how they should be unified. > > They are vendor specific. All of them are specifically for Exynos > hardwre, because this is Exynos. We call it Google GS/Tensor SoC just > for fancy convenience, but this just Exynos. Ok, then why is this ARCH_ option needed if these IP blocks really are from something else and are part of other drivers? confused, greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BCAD7E9272B for ; Thu, 5 Oct 2023 19:24:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=527bkiUM/Wi9dnfIAXkMXINcovjPIS68KKDKtMund4I=; b=T3GJeFIW4dJlgW CeYJEy1LQlmpk38kpg8fX1JNQHBOIJBmdT/KJD6fZ9th89gg7m/Di4FViQI6o8ChlTthb86ZTRSaH F8Uf5Beuq5i67kh1Vqa2z7kXilSJxXVX/4CXKqralVKJwbzSOQIxBk+9VZa0Ga24U9YQLDOyLOLWi 5YrCouDVFBl5/3WZZVPv5pDUniqnVIf0IzFCcu/q4pavmVF2XwH5a9nG3gWzweAq0F23CJx/qjvyW k3++Z46b2HRR/496/T1FWorOE2eWbLaKfSgqW2kXlQ83iOVkMvmEaCLtm0n3oNyH26Ebba7ms7CzO 3/gIaCxv5+zVbsProEvA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qoTwY-004MYv-1K; Thu, 05 Oct 2023 19:23:30 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qoTwV-004MXu-29 for linux-arm-kernel@lists.infradead.org; Thu, 05 Oct 2023 19:23:29 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id BF9D2B82686; Thu, 5 Oct 2023 19:23:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99D63C433C7; Thu, 5 Oct 2023 19:23:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1696533805; bh=mEC4GCPFke5BHEMWLbxQgvP7fQIPlgzksDjsQnxScS8=; h=Date:From:To:List-Id:Cc:Subject:References:In-Reply-To:From; b=DjI8Frt+YkYm54tzjnBb1KFjBfpXU6PXPmmZtKSjuVjwYSNPiyvTGynp4hA8tTxFz Vey859gxJ/zzg1Q7s+SIHHbOFkZFbDdqiHkX0AJbrW+rI5WQFxAxxQtMj+NOZpt1fP 6Nz647Q+482Gkqk26jF+MQotdB0tnlu8iCRIFFTc= Date: Thu, 5 Oct 2023 21:23:22 +0200 From: Greg KH To: Krzysztof Kozlowski Cc: William McVicker , Peter Griffin , robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com, conor+dt@kernel.org, sboyd@kernel.org, tomasz.figa@gmail.com, s.nawrocki@samsung.com, linus.walleij@linaro.org, wim@linux-watchdog.org, linux@roeck-us.net, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, olof@lixom.net, cw00.choi@samsung.com, tudor.ambarus@linaro.org, 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, linux-gpio@vger.kernel.org, linux-watchdog@vger.kernel.org, kernel-team@google.com Subject: Re: [PATCH 18/21] arm64: dts: google: Add initial Google gs101 SoC support Message-ID: <2023100513-mashing-scrubber-ea59@gregkh> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <99419159-cab0-4c79-a4a0-12229bfad3c0@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231005_122327_854377_EB995A14 X-CRM114-Status: GOOD ( 24.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Oct 05, 2023 at 09:18:48PM +0200, Krzysztof Kozlowski wrote: > >> I'd like to bring up this thread and discuss the option of not introducing > >> another ARCH_* config: > >> > >> https://lore.kernel.org/all/20200306103652.GA3634389@kroah.com/ > > > > I agree, PLEASE don't add platform config options as that makes it > > impossible to make a unified kernel image that works for more than one > > platform at the same time. > > There is no single problem in making unified image as we were doing > since beginning of ARM64. The ARCH_* is not a obstacle for this. Then why are the ARCH_* options needed at all? What does this help out with? > >> I especially don't like the "depends on ARCH_EXYNOS" because that forces one to > >> include all the other Exynos drivers that ARCH_EXYNOS selects that Google > >> Tensor SoCs don't need. Can we consider using SOC_GOOGLE instead and for all > >> drivers that actually depend on the SoC hardware, we can just add "depends on > >> SOC_GOOGLE"? > > > > Why do any of this at all? It should not be needed. > > > >> The idea is that drivers should be tied to hardware -- not a specific vendor. > > > > And drivers should be auto-loaded. > > > > All of these drivers are not vendor-specific at all, they are based on > > the same IP blocks as others, so that is how they should be unified. > > They are vendor specific. All of them are specifically for Exynos > hardwre, because this is Exynos. We call it Google GS/Tensor SoC just > for fancy convenience, but this just Exynos. Ok, then why is this ARCH_ option needed if these IP blocks really are from something else and are part of other drivers? confused, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel