linux-kernel - Re: [Gta04-owner] [PATCH 0/3] tty slave device support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150506123632.GA1764@leverpostej>
Date:	Wed, 6 May 2015 13:36:33 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	"Dr. H. Nikolaus Schaller" <hns@...delico.com>
Cc:	Peter Hurley <peter@...leysoftware.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.

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 <peter@...leysoftware.com>:
> 
> > On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
> >> 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.
--
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/