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]

Date:	Wed, 6 May 2015 15:15:48 +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.

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

> >> 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
> 
> I still wonder why UART is considered as a bus?

As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
connection between master (UART) and slave (device), and it happens that
in most other cases the master is actually a bus, so that's how things
happen to be named.

> > for other
> > interfaces like SPI and I2C. I do not see a compelling reason to do
> > otherwise for devices
> 
> why the plural? Is there a practical example where multiple devices are
> connected to a single UART and how is addressing solved?

I'm talking about UART slaves in abstract rather than multiple slaves
attached to the same UART.

> > hanging off of UARTs -- doing so would make things
> > less straightforward because you have a fundamentally different idiom.
> 
> Yes, my proposal is fundamentally different from I2C and SPI practice, but
> it is the same that is heavily used for e.g. GPIOs and Regulators.

Well, those cases are somewhat distinct, and I'd say that UART slaves
are much closer to SPI/I2C devices than GPIOs or regulators.

Let's say I have a GPIO described via a phandle. That GPIO is actually
owned by some GPIO controller whose control interface is sat on an MMIO
bus. What we're describing with the phandle is use of the GPIO, but not
the main interface for interactive with the GPIO, which is the MMIO
interface of the controller.

In the case of UART slave devices the control interface is attached to
the UART, and effectively the slave sits on the UART's "bus". We could
refer to it from elsewhere by phandle, but its canonical parent should
be the UART, as that's what its main interface is attached to.

> From my DT designer PoV I would say the UART exists in some SoC
> (independently of a device being connected) and then, a device is connected
> to the UART. Hence the proposal of adding this connection link to the device’s
> node and not making the device a subnode. And having the device driver do
> power management and only ask the uart/tty driver to be notified about open()
> and close() events. How power is managed in detail is then not any part of the
> tty/serial drivers.

The way that the power management interfaces are organised within Linux
is orthogonal to the way we describe things in the DT.

Thanks,
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/