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 BDADDC432BE for ; Wed, 1 Sep 2021 13:31:09 +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 F180460698 for ; Wed, 1 Sep 2021 13:31:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F180460698 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 C94538329B; Wed, 1 Sep 2021 15:31:06 +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="EWhjhoE0"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8A7EF832A1; Wed, 1 Sep 2021 15:31:04 +0200 (CEST) Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) (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 3B7E282DB2 for ; Wed, 1 Sep 2021 15:31:00 +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 61BB322221; Wed, 1 Sep 2021 15:30:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1630503059; 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=OgC0k+0AVTZP51Ol4CNTZU/u6YckcKFar8BDTVRPqgo=; b=EWhjhoE0RLTUCpYijroJ16Eq5tlGBz2ap9JRCXMIVoeHDRKXrLUgMDsv+TuKzupT5ISxCc PJxMrQA1/nmcCJa44UR43vPNlY3qpTvIP8uyT+F2jvhSB3KMPCxkMuQjAH0+kvDU6V17oT vHjg0FSogExk+bfIw3XqT8ILK8eozV4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Sep 2021 15:30:59 +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: <20210901125738.3q57qgfptjznaouh@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> <164efeb6985726c9d9f18a4e231a942e@walle.cc> <20210901125738.3q57qgfptjznaouh@skbuf> User-Agent: Roundcube Webmail/1.4.11 Message-ID: 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:57, schrieb Vladimir Oltean: > On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote: >> 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 if we "just add another small thing here and there", where that > thing > is a comment, or a 'status = "disabled"' structured differently but to > the same result, does that land us in the "same mess" where half of the > peripherals, and networking, would not work in Linux with the U-Boot > provided DT? I said eventually. My fear is that otherwise it will slowly diverge again, because nobody really cares to keep them in sync. Like once, I've tried to make the sl28 board dts look the same in u-boot and linux, but as soon as I saw how different they were, I just changed it like u-boot was expecting it. IMHO it's the small things that get bigger and bigger. I suspect the device tree for the LS1028A looked very similar in linux and u-boot in the beginning. It's just that the main development was going on in linux and nobody cared to bring that back into u-boot. Until there is something severly different we should have a greater goal to keep things the same and for uboot specifics we have -u-boot.dtsi. It's not that device trees are changed very often once there is has binding documentation. > My larger point was that if we now swing in the opposite direction, > and can't make a common-sense decision before making it in Linux first, > and then waiting for the next merge window, that's.. strange? That's not what I have in mind. No one is keeping you sending the patch to both. Or maybe just to u-boot but you'd have to keep in mind that it might be lost on a next sync if you didn't care to bring it into linux - or if changes were suggested in linux, you'd need to adapt u-boot afterwards. -michael