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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 7A4A5C432BE for ; Wed, 1 Sep 2021 12:38:25 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BBDD261214 for ; Wed, 1 Sep 2021 12:38:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BBDD261214 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E80608329E; Wed, 1 Sep 2021 14:38:21 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="aozk2P07"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 36FC5834C7; Wed, 1 Sep 2021 14:38:20 +0200 (CEST) Received: from ssl.serverraum.org (ssl.serverraum.org [176.9.125.105]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E2FD98329E for ; Wed, 1 Sep 2021 14:38:15 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 7583B22221; Wed, 1 Sep 2021 14:38:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1630499895; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Crrvro8a3TSNsddQJyp+1FbE7Ciq8+WrLRTTTYpfKzk=; b=aozk2P07eyI8PqWDaFdRPA1AlhatTNPD9dWa4ZkvEvGYFPhMtribaxL4YnNkA07dojeIsC 2OPZhj/PqdZsepfUh955jbp+NO6QozBUNUQ8lLqkSGB5ritqLkuNLJ+zF24vfrgezzkchr BJi2rheSKpX0ngfbCDBUGTbj1pQIYLU= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Sep 2021 14:38:15 +0200 From: Michael Walle To: Vladimir Oltean Cc: u-boot@lists.denx.de, Jagan Teki , Priyanka Jain , Tom Rini , Peter Griffin , Manivannan Sadhasivam Subject: Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux In-Reply-To: <20210901122149.bpufsq7gzo3n73mk@skbuf> References: <20210901085522.1712104-1-michael@walle.cc> <20210901085522.1712104-9-michael@walle.cc> <20210901112414.u3dbcbtlbyanwhjn@skbuf> <713ec89615bb7fbe461b909390cc09c7@walle.cc> <20210901115554.2zlfcfc4m6ymxwfx@skbuf> <248b3bb606fa9a073a98adc0748656ad@walle.cc> <20210901122149.bpufsq7gzo3n73mk@skbuf> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <164efeb6985726c9d9f18a4e231a942e@walle.cc> X-Sender: michael@walle.cc X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Am 2021-09-01 14:21, schrieb Vladimir Oltean: > On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote: >> Am 2021-09-01 13:55, schrieb Vladimir Oltean: >> > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: >> > > Yes but that is on purpose. In the current u-boot device tree, it was >> > > disabled, but the boards reenabled them again. So it didn't matter. >> > > >> > > I want to have a specific sync point (that is the v5.14 tag) for the >> > > .dtsi. At least where possible; for phy-mode and so on I needed to to >> > > take additional patches which weren't picked up in linux yet, but >> > > these just affect the sl28 board device trees. >> > >> > Binary compatibility is one thing and I can understand it. >> > Textual compatibility, down to label names, and where the device is >> > being disabled from? Hmmmm, I'm having a hard time saying yes to that. >> >> It's a step back, yes. But only until v5.16 (I don't think the changes >> will make it during the merge window). I guess you are concerned >> because >> of your vendor fork? Mh, well actually I don't understand your >> concert, >> because your tree isn't compatible anyway if we change the labels. > > No, I don't care about "our vendor fork", it's been years since I've > stopped using that. > >> We'd trade the clear information where the device tree is from for >> something that - in my opinion - is not worth it. I mean the device >> tree (source) is used just here in u-boot for these three boards and >> all have the usb nodes enabled. > > My concern was actually much simpler: your v1 conversion of the label > names was buggy (see the LS1028A-QDS build breakage). You deleted a > bunch of comments which U-Boot had but Linux did not (luckily they did > not provide a lot of useful information anyway). You introduced some > comments which do not make sense for the U-Boot tree, because they were > in Linux: the ICIDs in the iommu-map being fixed up by the bootloader > (you can instead say that "we will fix these up for the operating > system"). > Again, not big issues, but if it would boil down to my common sense, > I'd focus more on the binary compatibility (after all, there will still > be U-Boot specifics, which will constitute textual differences, but > Linux will gladly ignore them, because this is what binary > compatibility > is about), and if it is preferable to have status = 'disabled' in the > dtsi, and a patch was already sent to Linux but not yet accepted, I > would have kept U-Boot the way it was, and follow a model of > "eventual consistency". > > If you still care more about textual consistency, I went through the > patches > once already, so it's not like changing things now will make things > easier, > or matter. Ok, I see. But shouldn't be the goal to make things easy and just copy the device tree to u-boot once in a while? Otherwise, we will eventually end up in the same mess as it is right now. Because well if they are different anyway, then "we can just add another small thing right here and there". So yes, if you mean that by textual consistency, I care about that. And about the lost/wrong comments. We should "fix"/add/reword them in linux, no? -michael