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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0EE8E92FCF for ; Thu, 5 Oct 2023 23:22:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229866AbjJEXW2 (ORCPT ); Thu, 5 Oct 2023 19:22:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229731AbjJEXUw (ORCPT ); Thu, 5 Oct 2023 19:20:52 -0400 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 14728271F for ; Thu, 5 Oct 2023 16:20:01 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1c6185cafb3so36975ad.1 for ; Thu, 05 Oct 2023 16:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696548000; x=1697152800; 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=g9+/T8jL1FueuqbJWbDBnW4JHhnHC6qNQT3btWThJAA=; b=v+UouYNuHRJZLn6qa9pJlSug21LceqYMP5xJLBs9AV3PUI6CY9ziCJvFykObqwWyZI 93HL2qRPazgPcjnAqexgNvuIaSVfnlvgzFDZscbBOeCwL2y26LlCy7Fc501aHKwe/bIU xzBXd8VCKDpYeict0m6yZtkzqiobtvwhJrnc18eD0QPziGC0YVN5ykkAYcklcpcnlqNl eu0rKyhDl5cuZKlyNCsN8pq+JtkEV8u49VyWRqAeOI7MUuSxjrHO0/XqvTFSqxKeEFfz V4PV2sV92v40eI0by02BJttTmjFBd+K6BPQ4oV5brWXrSmtrdnitnLQylHgXN5gBFwhg qK2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696548000; x=1697152800; 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=g9+/T8jL1FueuqbJWbDBnW4JHhnHC6qNQT3btWThJAA=; b=g7c296/5UvFSBBIWNNwofJFTFOXhoDD5QOff/zyYQsdii4hGbZ+o/oIpckl/HLPj3i c6rUrRbo/pZCTSIDjV/gS0SGAMq/7fuMa8aRRe4nD4GOHF7JTsIAmMkatmkjKceU72g5 8EYrK8CY6LifP9+iTEs38h60mQRH4P9kMPYjSt/I+vR4b34nsu/XsBkHDkgT61BonfPi 1HbhQddA8TEbleZpTMCtqsUrNTe7dfVyy5bvYAcHc8tyWdaqHABCEe33sTRXNba/UpiH M9nCaqWnsVQSxLeqigA45bc5U4iDAYy+WuDFv1cl8yPQXD7Irnw/90gMvldVT1N1l0s+ yX4g== X-Gm-Message-State: AOJu0YzBwfxFCYZy07jq1R+RwlhnMFA5h+XXhPb4f02zOsy+UHKn9ql2 JugXZY5XVphbL6WXyhnltR7a3g== X-Google-Smtp-Source: AGHT+IG6SUbZdWjUlwVKgWGyn2h7w47kdQ+sEw89YZgLkBjRn4vrO6PiIxtJlw/+S61vF8DHpPNtxw== X-Received: by 2002:a17:902:d506:b0:1c4:4470:bfa7 with SMTP id b6-20020a170902d50600b001c44470bfa7mr232458plg.29.1696548000224; Thu, 05 Oct 2023 16:20:00 -0700 (PDT) Received: from google.com (13.65.82.34.bc.googleusercontent.com. [34.82.65.13]) by smtp.gmail.com with ESMTPSA id rm10-20020a17090b3eca00b0026d214a2b33sm4130541pjb.7.2023.10.05.16.19.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 16:19:59 -0700 (PDT) Date: Thu, 5 Oct 2023 16:19:56 -0700 From: William McVicker To: Krzysztof Kozlowski Cc: Greg KH , 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@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On 10/05/2023, Krzysztof Kozlowski wrote: > On 05/10/2023 21:23, Greg KH wrote: > > 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? > > It helps all the people and distros who do not want to build/package > drivers or modules for unrelated hardware or architectures. > > Let's take Samsung Exynos UART driver. It will never, 100% never, work > on x86, x86_64. There is no single need to package it for kernels build > for these products. It will not work on nVidia Tegra ARM64, Qualcomm > ARM64 SoC, so if you do not want to run on Exynos, then you do no select > ARCH_EXYNOS and have significantly smaller image. > > Now, there is no problem to have one kernel for nVidia Tegra + Qualcomm > + Samsung Exynos with everything you need. The ARCH_EXYNOS or SOC_EXYNOS > or SOC_GOOGLE serves only the purpose to allow distros and people > customize build for specific hardware. > > It does not limit anyone on anything. I'm glad you brought up Exynos UART because this is where one of the limitations is introduced. For example, if you want to modularize out all the vendor specific drivers from the core kernel to create a common arm64 kernel binary that works on all ARM64 devices, you will not be able to build in the early console UART drivers without enabling the respective ARCH_* configs. 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. I understand that ARCH_* configs are used to selectively pick which device tree blobs are built, but forcing developers to pick all or nothing is where I have a problem. Regards, Will > > > > > > >>>> 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? > > For the same reason above, because if I want to build kernel for > Qualcomm, I want to drop easily anything not related. If I want to build > kernel without I2C, I disable I2C bus which effectively disables all > drivers which work on I2C. If I want to build kernel without Exynos, I > disable ARCH_EXYNOS which effectively disables entire Exynos hardware. > > Think of SoC as a bus or interface. > > Best regards, > Krzysztof > 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 8C2EAE92FC9 for ; Thu, 5 Oct 2023 23:20:42 +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=uviZKqxgNruZbd8QrUC5JfNI8WPoPikmY+GOQDwTbdc=; b=La9ZefztAJhfMt wAOGWCyXnGSBZZHan02XxNuOEPiLVR8vYUZatMPuGU4Z9tdw5Hsx18TqJXbcmozXZfW+7z9FgG6hi HTg5pmBYXKgYJbz+s4SnTQHpW4B0DvhSr2gHNZkMmn5udxBh3GQ3UuXeg1TcGx+IOHRMBIvvXIL0q IWRlngdq5wmp7yE0G97FErcv0gXea4YBkg1XqxO+HN3yWVO7cnPZl5Fkw9ArzxuIn8p5DN5cSKyD9 9RFY47TbQq0O8qOu2x1HMDFKlf2m2AdOPXjwY9xdOLDZ4PUHHoyucEwuqBz9ePSqXG45+CYkECpS1 zRBCwqQKTUqOO6C3n0UA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qoXdV-004bhE-0L; Thu, 05 Oct 2023 23:20:05 +0000 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qoXdR-004bgb-2W for linux-arm-kernel@lists.infradead.org; Thu, 05 Oct 2023 23:20:03 +0000 Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1c6185cafb3so36985ad.1 for ; Thu, 05 Oct 2023 16:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696548000; x=1697152800; darn=lists.infradead.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=g9+/T8jL1FueuqbJWbDBnW4JHhnHC6qNQT3btWThJAA=; b=wYcn8QkAKXsAFnmxQfNITm58mPPIKpa9lk8+mXwXmKfR8t476ynOHgATVkA/+AwP6T UIeAQC+visAZNcIEYbV+X7TVE904dL0rM0ciDo+gbatm1GB2J+m2Tg+8ShLT0IrsAbGB Ir2wfSTQe7+MEuPSJ/0Rz73ACIV7dm1YL7nMIuJa+PubXlpA10N4ROh5vQX3kV0OwIWr ViFHHtLFQ5g5XgbfUBkTaISkdIOgJt3xaWgQdBdTRu8t9EFmp/aFKeB/kmiirQxnxXdC g704CWPykXQBlmIDuaSiQY1SVGE75h+PnueDqm8IM+fpftZLk7ip+vzJb6e+aEDmBY4c OJoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696548000; x=1697152800; 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=g9+/T8jL1FueuqbJWbDBnW4JHhnHC6qNQT3btWThJAA=; b=W7nGGBwWpqWcTrnLitZfXKqMFrPM4nLrB456yDwSi6r8rDPBbcA1jUa0Kf0/qnYQ48 pFaYR1VwDzo/fdZ1s24oUf6A/uRer6TClU8QpSCw59TsoxdclCjmw7LyT0pJdd9DQk/o Mot/Uf59qBMhkaYqk88m0wIBScwT0P0nfARPc6E3b5HubE1ExUqUNa2gdJjfjuyhQoRs wXBS2c5MM0snitlhjUMdCyrt68eVcm5kfXRMoiv3z97Z1DrWwR/yTT2vlZjG+ppvdGCN h+rc1nkyWTUNninwwFyHQujtyO2F8i7+eAaU62AiFLzhwnK5aNqhXYWAC4Sa62AA0TIa YQzw== X-Gm-Message-State: AOJu0YwoSQW8vb1kYUIE8xkofqxVT4KOqz8JKOgHpK/9w5lr8f8+HqfU sxivx1xyB3bz9qn9gSbQe2d1Dw== X-Google-Smtp-Source: AGHT+IG6SUbZdWjUlwVKgWGyn2h7w47kdQ+sEw89YZgLkBjRn4vrO6PiIxtJlw/+S61vF8DHpPNtxw== X-Received: by 2002:a17:902:d506:b0:1c4:4470:bfa7 with SMTP id b6-20020a170902d50600b001c44470bfa7mr232458plg.29.1696548000224; Thu, 05 Oct 2023 16:20:00 -0700 (PDT) Received: from google.com (13.65.82.34.bc.googleusercontent.com. [34.82.65.13]) by smtp.gmail.com with ESMTPSA id rm10-20020a17090b3eca00b0026d214a2b33sm4130541pjb.7.2023.10.05.16.19.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 16:19:59 -0700 (PDT) Date: Thu, 5 Oct 2023 16:19:56 -0700 From: William McVicker To: Krzysztof Kozlowski Cc: Greg KH , 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@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231005_162001_825142_955E7D24 X-CRM114-Status: GOOD ( 40.02 ) 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 10/05/2023, Krzysztof Kozlowski wrote: > On 05/10/2023 21:23, Greg KH wrote: > > 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? > > It helps all the people and distros who do not want to build/package > drivers or modules for unrelated hardware or architectures. > > Let's take Samsung Exynos UART driver. It will never, 100% never, work > on x86, x86_64. There is no single need to package it for kernels build > for these products. It will not work on nVidia Tegra ARM64, Qualcomm > ARM64 SoC, so if you do not want to run on Exynos, then you do no select > ARCH_EXYNOS and have significantly smaller image. > > Now, there is no problem to have one kernel for nVidia Tegra + Qualcomm > + Samsung Exynos with everything you need. The ARCH_EXYNOS or SOC_EXYNOS > or SOC_GOOGLE serves only the purpose to allow distros and people > customize build for specific hardware. > > It does not limit anyone on anything. I'm glad you brought up Exynos UART because this is where one of the limitations is introduced. For example, if you want to modularize out all the vendor specific drivers from the core kernel to create a common arm64 kernel binary that works on all ARM64 devices, you will not be able to build in the early console UART drivers without enabling the respective ARCH_* configs. 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. I understand that ARCH_* configs are used to selectively pick which device tree blobs are built, but forcing developers to pick all or nothing is where I have a problem. Regards, Will > > > > > > >>>> 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? > > For the same reason above, because if I want to build kernel for > Qualcomm, I want to drop easily anything not related. If I want to build > kernel without I2C, I disable I2C bus which effectively disables all > drivers which work on I2C. If I want to build kernel without Exynos, I > disable ARCH_EXYNOS which effectively disables entire Exynos hardware. > > Think of SoC as a bus or interface. > > Best regards, > Krzysztof > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel