Message-Id: <160D57E1-D25F-4382-80E7-195C1921DABC@goldelico.com>
Date:	Thu, 7 May 2015 18:57:46 +0200
From:	"Dr. H. Nikolaus Schaller" <hns@...delico.com>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Mark Rutland <mark.rutland@....com>, Pavel Machek <pavel@....cz>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>, NeilBrown <neil@...wn.name>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

Hi,

Am 07.05.2015 um 18:18 schrieb Peter Hurley <peter@...leysoftware.com>:

> On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
>> 
>> Am 07.05.2015 um 16:30 schrieb Peter Hurley <peter@...leysoftware.com>:
>> 
>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@....com>:
>>>>> 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 <mark.rutland@....com>:
>>>>>> 
>>>>>>>>>>>> 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.

I meant two different candiates for DT bindings [PATCH 3/3]. Yes, the code
exists only for Neil’s proposal.

> 
>> 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

Yes. That is why I insist on discussing alternatives to show how good they
are wrt to such criteria and so far the discussion wasn’t that well structured
to have clear criteria in the beginning. Thanks.

> 
>>> 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.

Yes, I appreciate that!

And if I find time, I will propose a v4-alternative.

BR and thanks,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists