Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:

Hi Peter,

Am 06.05.2015 um 14:05 schrieb Peter Hurley [off-list ref]:

quoted

On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:

quoted

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.

I dont' see a big distinction at the DTS source level, so your concern is wrt
binary dtbs?

No. My concern is wrt including existing board files and making small modifications
on source level (or overlays).

We discuss:

board1.dts:

uart3 {	// subnode of some SoC
	slave {	// slave connected to uart3
		compatible = „…“;
		gpio = <&gpio5 12 0>
	};
};

vs.

board1.dts:

/ {
	slave {
		compatible = „…“;
		gpio = <&gpio5 12 0>
		uart = &uart3;	// slave connected to uart3
	};
};

uart3 {	// subnode of some SoC
};

now let’s have a spin of the board design which just rewires the
slave to uart4 (somtimes hardware engineers do such things).

board2.dts:

#include <board-variant1.dts>

// reconnect device to uart4

uart4 {	// subnode of some SoC
	slave {	// slave connected to uart4
		compatible = „…“;
		gpio = <&gpio5 12 0>
	};
};

uart3 {	// subnode of some SoC
	slave {	// slave connected to uart3
		compatible = „none“		// we can’t delete imported subnodes
	};
};

/// add another device to uart5?

uart5 {	// subnode of some SoC
	slave2 {	// slave connected to uart5
		compatible = „…“;
		gpio = <&gpio5 13 0>
	};
};

If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.

If you have a large amount of variation within a given platform, that is
a problem with your platform.

So the main difference is if the slave device tells to which uart it is connected
or the uart which slave device it is connected to.

And I think the second approach is easier and more straightforward (on DT level).

We already place child nodes under their respective busses for other
interfaces like SPI and I2C. I do not see a compelling reason to do
otherwise for devices hanging off of UARTs -- doing so would make things
less straightforward because you have a fundamentally different idiom.

Having the slave live under the UART node also gives you sane probe
ordering -- you must probe the parent before the slave as the parent
driver (perhaps via common code) will trigger the scan of children.

Mark.