Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752096AbbEFMgt (ORCPT ); Wed, 6 May 2015 08:36:49 -0400 Received: from foss.arm.com ([217.140.101.70]:47339 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751130AbbEFMgp (ORCPT ); Wed, 6 May 2015 08:36:45 -0400 Date: Wed, 6 May 2015 13:36:33 +0100 From: Mark Rutland To: "Dr. H. Nikolaus Schaller" Cc: Peter Hurley , 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. Message-ID: <20150506123632.GA1764@leverpostej> References: <20150318055437.21025.13990.stgit@notabene.brown> <55492001.30806@hurleysoftware.com> <20150506092738.GB4508@amd> <554A03A7.2000504@hurleysoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3062 Lines: 101 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 : > > > 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 > > // 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/