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=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 776C3C433DB for ; Thu, 21 Jan 2021 21:20:48 +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 383C722BEF for ; Thu, 21 Jan 2021 21:20:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 383C722BEF 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=RmPUpkld684v9PimfVwVYBfZt+t/8FF6C7FnQ00kzTU=; b=CfgMa6kIXqf3M0cYtX6y94Z1b U3mLrO/U/CU69w0wBnqpJvtZHa3wvI2xvsK+a4hSES1s4Ik3FApTLhJEJkonuI7KHzpAFdfsM7NJN E4owtcyFtyVteURxkCaYjbJQCnxgvpLAk+SoSrfRKDBsIvMYw8xWgux9paKW2FJYvbDCCI9X1irjD H2RGc0YztyoYfBfFiWx9f6cb8c8GO97jo5XczHUzU7OvUyldSJ8diJsFSxYwqyIxJUwjUkMpRmfmK 8vNH+YtXSDBwISffwKtUywf4c702q/ZmCC8n8hpskBdNnwVHq5JEaPZmujofxeBdIhvaG8hcV29h/ wxN6HJgvw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2hM6-0001tQ-Be; Thu, 21 Jan 2021 21:19:02 +0000 Received: from fllv0016.ext.ti.com ([198.47.19.142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2hM2-0001sj-CZ for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 21:19:00 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 10LLIqx3124538; Thu, 21 Jan 2021 15:18:52 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1611263932; bh=bH4hkOLbVYMxyOkYiR7QGJczKFpP1XcQCOzroj5A2Ik=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=THxV8yHcPX6zfPLrpu2TqDZWk46LF39rrXTHBwAQnRrRkpyIOJGqy2qC351HGVufa /wEgbm7epPR1b7DZsdv8BpEtYUYVzAoJcvkfAbkrSxH/hJdhB3uJoM/0FnMpA3R5O8 u4vbhrVCDovNPUYP7Lb3gCiwWxD4Kstdz/9oqyLs= Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 10LLIqvu089847 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Jan 2021 15:18:52 -0600 Received: from DFLE108.ent.ti.com (10.64.6.29) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Thu, 21 Jan 2021 15:18:51 -0600 Received: from fllv0040.itg.ti.com (10.64.41.20) by DFLE108.ent.ti.com (10.64.6.29) 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; Thu, 21 Jan 2021 15:18:51 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 10LLIp0d065954; Thu, 21 Jan 2021 15:18:51 -0600 Date: Thu, 21 Jan 2021 15:18:51 -0600 From: Nishanth Menon To: Suman Anna Subject: Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC Message-ID: <20210121211851.muqqyhkmwhhz3mlm@password> References: <20210120202532.9011-1-d-gerlach@ti.com> <20210120202532.9011-4-d-gerlach@ti.com> <197af185-d2ea-3c76-d0bf-714485f8f195@ti.com> <20210121174639.jqbvem6b4ozd3six@sterling> <4ee6f005-2eee-42b2-b573-e10602839e1b@ti.com> <20210121183909.pwpboiptqbof2dfu@squint> <2b35fb8b-0477-f66d-bcbd-ad640664a888@ti.com> <20210121201344.amp54x6d5fty7rkf@shriek> <13be7980-1ce8-bf7f-a6cf-7de6469a1b9b@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <13be7980-1ce8-bf7f-a6cf-7de6469a1b9b@ti.com> User-Agent: NeoMutt/20171215 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-20210121_161859_619862_CACDBB48 X-CRM114-Status: GOOD ( 34.99 ) 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: devicetree@vger.kernel.org, Vignesh Raghavendra , Arnd Bergmann , Dave Gerlach , Tony Lindgren , Sekhar Nori , Kishon Vijay Abraham , Lokesh Vutla , Rob Herring , Aswath Govindraju , linux-arm-kernel@lists.infradead.org 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 14:42-20210121, Suman Anna wrote: > On 1/21/21 2:13 PM, Nishanth Menon wrote: > > On 13:57-20210121, Suman Anna wrote: > >> This is all moot when your own tree doesn't boot properly. In this case, you are > >> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the > >> nodes that were added or you need additional driver patches (which is not how > >> maintainer-level trees are verified). > > > > Get your facts straight please. > > > > What do you mean does'nt boot? It does boot with initramfs which is > > the minimum qual i had set for any new platform (along with. - your > > need is for a device node to work - which is both a combination of > > defconfig + driver updates. > > And please re-read my first email, and what I started out with. I am not sure "I > will pick MMC nodes, but the entry criteria is only initramfs, and you need > additional patches to get MMC boot to work" is right. Normal thing to do is to > take in the next merge cycle. Sigh. As I stated, the reason I prefer not to do that is because the drivers will bit-rot for a kernel window without users. Why is it just MMC? Start off with uart: compatible = "ti,am64-uart", "ti,am654-uart"; That is not in v5.11-rc1 - it only works because driver is falling back on the backward compatible nature of the device. The binding and driver fixes are already on next. MMC by itself wont boot unless the defconfig changes were merged in upstream - and that was a painful choice to make to prevent the common Image file from bloating too much.. I mean, is there a real concern that https://lore.kernel.org/linux-devicetree/20201029065318.2437-1-vigneshr@ti.com/ or https://lore.kernel.org/linux-devicetree/20210115193218.5809-1-grygorii.strashko@ti.com/ or .... will be dropped, in which case, we should'nt introduce in the next kernel version, so that also means that those drivers will remain as is without users for a complete kernel cycle. I am not saying there are'nt instances where things have happened.. these changes have been in next for sufficiently long cycles for that NOT to happen. Without users, they can unfortunately break and no one will be the wiser till we enable the nodes again.. That would be a waste of everyone's time. > >> > >> Arnd, > >> Can you please guide us here as to what is expected in general, given that the > >> pull-request from Nishanth goes through you, and if there is some pre-existing > >> norms around this? > >> > >> Tony, > >> Appreciate your input as well since you probably have dealt with these kinda of > >> dependencies on OMAP. > > > > I am more than happy to drop this entire SoC off my queue (I am yet to > > pick it up), which is probably what I will do. > > > > You are the maintainer, do what feels right to you. You can as well wait for the > MMC driver changes to be in, and then pick up the series next merge window. Or > you can accept the versions without taking in pieces that have external > dependencies. Sure, I explained the rationale, you are adamant on not being convinced, without a counter reason - what is the breakage here that you can see when merged through to rc1 target OR to linux-next? And maybe doing some thing like this will help on (say on arm-soc PR in 5.11?) for f in `git diff v5.10-rc3..|diffstat|cut -d '|' -f1 |tr -d ' '|grep dts$|sed -e "s/^b/./g"`; do ./scripts/checkpatch.pl -f $f |grep compatible; done At all points in time, nodes are just inactive if the driver is disabled for some reason (either the driver is not enabled or the binding changes are not in) - they are never broken, Boot is not broken (a function is broken when that function support exists in Image file AND dts node for some reason results in that function not working) - yes, someone can claim NFS boot is broken or WIFI is brokken when NFS boot or WIFI is not even introduced. etc. If I go by the strictest rules, then I cannot even introduce a bugfix which involves dts via arm-soc dts pull request since the dependencies of erratum and property enabling the erratum all should come from the subsystem trees. Drivers being broken is not in anyone's interest. They tend to get broken if there are no active users.. let us release often and test often.. and I believe there is plenty of precedence in doing this already - if there is a risky property, OK fine, lets discuss about it. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel