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 X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EF87C43461 for ; Tue, 8 Sep 2020 09:56:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D742D21D7A for ; Tue, 8 Sep 2020 09:56:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eBAIq7MK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="TaxgCbh9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D742D21D7A Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=q8TcUvsKDopekJCzJF4aiykHTSKwn4dWOOo6MSZKR0M=; b=eBAIq7MK70CzpHuO0TsheiYdV tT5AeyZdpMvGhIc2Uypox+EwYkOkGXnYjhxSOFvpk1akMFF2D98Yu+Q30/PztCNYW0hRPxDXeMEjB PKzHZMDSVMDMA9V4k5qPX/axyugZkCPwL6GgJnUgigw+fqrmkHa2BxWfrxLqm3n9z+uMzywJbwwpp nWTqwbU3ldxzXRBz2QaEwJDmoWte/tfO3/uxa6Jv3klErCkpDQyvVR/r3krutrkvu9Ith4ee+2KdE tgdwprTYTjYeBPG0sVn7GLVVXCYOPNCVRzpkO1XZOtmP3VKyPOe3TT40VrhDi87535Y80OGEJ/4nO pBKz6/ndQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFaLj-0003y3-Pi; Tue, 08 Sep 2020 09:55:39 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFaLg-0003xO-OG for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 09:55:37 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0889tWag121642; Tue, 8 Sep 2020 04:55:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1599558932; bh=/WVMwnfmaojk6zh6M1fbb3D/yfnAjVDfwaKQq5TPu4E=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=TaxgCbh9EQHV7HXoyeZ0ms/9mdAVCuKP0/XgR0PypvsTfyPVwZnGnQQn8uzTeHYen p8Xs/Sd1sZeh8ra2/vKpFMONOvsLobJIhUF0rIk0PiAWvHe/4l4wKMJX1VdrqZ0Klj u53TL6ZBvP3aybDLn5zCo+S1Pz4hISTaTbs3vIxw= Received: from DFLE105.ent.ti.com (dfle105.ent.ti.com [10.64.6.26]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0889tWqY067516 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 8 Sep 2020 04:55:32 -0500 Received: from DFLE101.ent.ti.com (10.64.6.22) by DFLE105.ent.ti.com (10.64.6.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 8 Sep 2020 04:55:32 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DFLE101.ent.ti.com (10.64.6.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Tue, 8 Sep 2020 04:55:32 -0500 Received: from [127.0.0.1] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0889tUst020783; Tue, 8 Sep 2020 04:55:30 -0500 Subject: Re: [PATCH v2 0/4] arm64: Initial support for Texas Instrument's J7200 Platform To: Nishanth Menon , Lokesh Vutla References: <20200827065144.17683-1-lokeshvutla@ti.com> <20200907141427.ti6r3h6namv2hezw@akan> <9d8d6980-0b22-da45-52af-474c6d96c873@ti.com> <20200907234833.r376hhl64q55gd7o@akan> From: Tero Kristo Message-ID: Date: Tue, 8 Sep 2020 12:55:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200907234833.r376hhl64q55gd7o@akan> Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_055536_916396_DC0E14DC X-CRM114-Status: GOOD ( 20.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Device Tree Mailing List , Grygorii Strashko , Sekhar Nori , Rob Herring , Linux ARM Mailing List Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 08/09/2020 02:48, Nishanth Menon wrote: > On 19:53-20200907, Lokesh Vutla wrote: > > [... I should have responded to the correct patch..] >>> Besides yaml and compatibility acks, there are a few ancillary >>> comments to fix up.. Kconfig -> I think we should either stay with >>> status quo and create a new config option per SoC OR rename the >>> config to be generic (using j7200 with j721e SoC config is not very >> >> Please suggest your preference here. I guess separate defconfig for J7200? > > > I was just scanning through remaining arm64 additions to see what others have > done. We seem to have two options here: > a) Just use ARCH_K3 and no specific SoC configs > b) Specific SoC configs > In both cases, use += instead of \ to incrementally add dtbs > > We have been going with (b) so far, Tero: any specific preference here? > > (a) has the aspect of simplicity and reduced dependencies. > (b) Allows downstream kernels to save just a little bit and focus purely > on SoC of interest. If possible, I think we should aim for a) at least for now. We have the soc type detection code in place anyways that can be used on driver level. Creating compile time flags should be avoided imo as much as possible and just go with runtime detection. I can't see why saving maybe a megabyte of memory with SoC specific kernels would be of any importance on K3 arch with the memory amounts we have in our disposal. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel