linux-kernel - Re: [RFC PATCH 0/3] UART slave device bus

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:   Mon, 22 Aug 2016 14:37:02 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Rob Herring <robh@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Jiri Slaby <jslaby@...e.com>,
        Sebastian Reichel <sre@...nel.org>,
        Pavel Machek <pavel@....cz>,
        Peter Hurley <peter@...leysoftware.com>,
        NeilBrown <neil@...wn.name>,
        "Dr . H . Nikolaus Schaller" <hns@...delico.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-bluetooth@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] UART slave device bus

On Wednesday, August 17, 2016 8:14:42 PM CEST Rob Herring wrote:
> 
> Before I spend more time on this, I'm looking mainly for feedback on the
> general direction and structure (the interface with the existing serial
> drivers in particular).

Aside from the things that have already been mentioned in the discussion,
I wonder how this should relate to the drivers/input/serio framework.

My impression is that there is some overlap in what you want
to do here, and what serio does today as a line discipline on top
of a tty line discipline (and on top of other non-uart serial
connections), so we should look into whether the two can be unified
or not. Here is what I found so far:

For all I can tell, serio is only used for drivers/input/ but could
easily be extended to other subsystems. It currently uses its own
binary ID matching between drivers and devices through user space
interfaces, though adding a DT binding for it would appear to be
a good idea regardless.

It also has a bus_type already, and with some operations defined on
it. In particular, it has an "interrupt" method that is used to
notify the client driver when a byte is available (and pass
that byte along with it). This seems to be a useful addition to
what you have. Since it is based on sending single characters
both ways, transferring large amounts of data would be slower,
but the interface is somewhat simpler. In principle, both
character based and buffer based interfaces could coexist here
as they do in some other interfaces (e.g. smbus).

While serio is typically layered on top of tty-ldisc (on top of
tty_port, which is often on top of uart_port) or on top of
i8042/ps2 drivers, I suppose we could add another back-end on top
of uart_port directly to avoid the ldisc configuration in many
cases when using devicetree based setup. This should also address
the main concern that Alan raised about generality of the
subsystem: we'd always leave the option of either manual configuration
of the tty-ldisc (for any tty_port) or configuring on-chip devices
(using uart_port) directly through DT. Of course the same thing
can be done if we hook into tty_port rather than uart_port.

	Arnd