Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751724AbbEGQSo (ORCPT ); Thu, 7 May 2015 12:18:44 -0400 Received: from mail-qc0-f172.google.com ([209.85.216.172]:35891 "EHLO mail-qc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751623AbbEGQSi (ORCPT ); Thu, 7 May 2015 12:18:38 -0400 Message-ID: <554B9056.4090904@hurleysoftware.com> Date: Thu, 07 May 2015 12:18:30 -0400 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Dr. H. Nikolaus Schaller" CC: Mark Rutland , Pavel Machek , List for communicating with real GTA04 owners , NeilBrown , One Thousand Gnomes , Arnd Bergmann , Greg Kroah-Hartman , Sebastian Reichel , "grant.likely@linaro.org" , Jiri Slaby , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3. References: <55492001.30806@hurleysoftware.com> <20150506092738.GB4508@amd> <554A03A7.2000504@hurleysoftware.com> <20150506123632.GA1764@leverpostej> <20150506141547.GB1764@leverpostej> <20150506171802.GE2974@leverpostej> <554B7716.3080504@hurleysoftware.com> <05A9A4F3-79E8-48B1-B7EC-2C43E9643620@goldelico.com> In-Reply-To: <05A9A4F3-79E8-48B1-B7EC-2C43E9643620@goldelico.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4801 Lines: 131 On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote: > > Am 07.05.2015 um 16:30 schrieb Peter Hurley : > >> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: >>> Am 06.05.2015 um 19:18 schrieb Mark Rutland : >>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote: >>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland : >>>>> >>>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this >>>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board >>>>>>>>>>> designers who want to easily import an existing board DT and overwrite device >>>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to >>>>>>>>>>> which uart. >>>>>> >>>>>> [...] >>>>>> >>>>>>>> If this happens, you can move the slave device into a fragment that you >>>>>>>> can include under the correct node. That's trivial. >>>>>>> >>>>>>> But less readable. And that is important as well. >>>>>> >>>>>> I disagree. The manipulation you have to perform to override properties >>>>>> is at least as bad as including a file. >>>>> >>>>> What about: >>>>> >>>>> #include "omap3-beagle-xm.dts" >>>>> >>>>> / { >>>>> /* HS USB Port 2 Power enable was inverted with the xM C */ >>>>> hsusb2_power: hsusb2_power_reg { >>>>> enable-active-high; >>>>> }; >>>>> }; >>>>> >>>>> compared to >>>>> >>>>> #include “board1.dts” >>>>> >>>>> / { >>>>> /* slave was reconnected to uart4 */ >>>>> slave { >>>>> uart = <&uart4>; >>>>> }; >>>>> }; >>>> >>>> As I mentioned, you can easily carve up your DTS to make that work with >>>> includes if you really must: >>>> >>>> /* UART0 board variant */ >>>> #include "board.dtsi" >>>> &uart0 { >>>> #include "some-uart-slave.dtsi" >>>> }; >>>> >>>> /* UART1 board variant */ >>>> #include "board.dtsi" >>>> &uart1 { >>>> #include "some-uart-slave.dtsi" >>>> }; >>>> >>>> If you happen to find includes ugly then you can say it's ugly, but it's >>>> functionally equivalent, and also means you can avoid having >>>> disabled/partial nodes all over the place. >>> >>> Functionally equivalent would also be to copy the whole source file and >>> s/&uart0/&uart1/. >>> >>> But this is not the best solution for the DT programmer since there is no >>> automatic *reuse* of common parts. >>> >>> And your proposal requires 3 source files instead of 2 which deteriorates >>> readibility and understanding what is really going on. And if you need to >>> change the some-uart-slave, you have to touch a different file than for >>> changing some other slave. >>> >>> Yes, it works, but IMHO other factors for a good design are also important. >>> >>> Maybe our main difference in PoV is that I specifically want to avoid that >>> we force future DT programmers into “ugly” solutions (even if they work). >>> >>> If you think that DT programmers have to live with what they are >>> given and do the best with it, we can end the discussion. >> >> The question of syntax is orthogonal to the discussion of the proper >> devicetree representation. >> >> The awkwardness of expressing variants has nothing to do with the >> appropriate device hierarchy (or whether there should be a hierarchy). >> Describing variants is just as awkward when the parent-child relationship >> is indisputable. > > That is ok. But I still have not found the key rule when a parent-child relationship > is indisputable. Candidates so far are “main interface” (which is still disputable) > or “bus” (where we can dispute if a point-to-point connection is a “bus”). Actually, at this point there is only one candidate, and that is the code under review. > But if both options are equally valid (maybe because there is no rule > making either indisputable), I would chose the one with easier syntax. There are many important criteria here. 1. Code complexity 2. Ease of adoption 3. Quality of abstraction 4. Extensibility >> There was a recent discussion on devicetree ML regarding how best to >> express and represent variance. Feel free to revive that discussion. > > Does it help? Our core issue is not the syntax and variance per se. This are > just examples to demonstrate differences in syntax of parent-child vs. phandle. > > If we decide for either one, we have to live with syntactical and other > implcationd. The future implications of both the design and implementation need careful consideration. That's why I'd like to see a v4. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/